Let's say we're running a service that's bound to localhost (, and the goal is to only allow local clients (i.e. from the same machine only)

What techniques might be used to break this security, are there additional measures that could be used to enforce it?

  • 1
    Apparently computers in the local network can spoof the IPv6 equivalent ::1 on some operating systems. Apr 24, 2015 at 14:24
  • 6
    @CodesInChaos could you clarify and possibly provide a link for that ?
    – user42178
    Apr 24, 2015 at 16:37
  • @CodesInChaos Without information about which OS and version, then that isn't a verifiable statement.
    – kasperd
    Apr 25, 2015 at 8:34
  • 1
    Bear in mind that anyone with local access to the machine will be able to port forward. The obvious culprit is ssh which has portforwarding built in, but it's pretty trivial to do in other ways. If all your users with access are trusted, this isn't an issue.
    – Sobrique
    Apr 25, 2015 at 11:28
  • 3
    Project Zero - Finding and exploiting ntpd vulnerabilities wrote "Any IP packet arriving on an external interface and with the source IP will be dropped immediately. But if we use IPv6 instead we can actually spoof ::1 and send control mode packets to the daemon (some Linux distributions have firewall rules in place that protect against this, e.g. Red Hat). Thus, if we are on the same local network, we can send spoofed packets to the link-local address of the target" Apr 25, 2015 at 12:36

5 Answers 5


The first and main thing is to ensure that the firewall on your host is configured to properly drop incoming packets with source or destination address set to

Under normal circumstances, there should be no packet coming from the network and showing such addresses. However an attacker may attempt to forge such packets in order to reach your local listening services.

I do not know which kind of other services are listening on your machine, but if any service can be used as a relay you must ensure it is properly configured to prevent to relay anything to the local listening services.

For instance, if you have an HTTP proxy running on this host, an attacker can use this proxy to request the host "": from the firewall perspective this will be a legit connection coming from the network to the proxy service, and locally this will be a legit communication between two local services (the proxy and the targeted local port). The HTTP proxy here is just an example, such technique may also work with other services, including services where relaying connections is not the main functionality (the FTP bounce attack for instance is a classical example of such threat).


A potential vulnerability would be to compromise a low-privilege account/service and use that as a pivot to access the localhost-bound service.

I usually prefer UNIX sockets for that purpose as you can apply user/group permissions on them (that will be transparently handled by the OS, the user won't have to keep yet another password). Plus, they're also a bit faster which makes them preferable for IPC on the same machine.

Note that socket permissions aren't always respected on some UNIX variants and OS-specific tuning may be needed (like increasing the number of allowed connections per socket).

  • 1
    Unix sockets comes with their own issues. Beware that the Unix rights on socket files is not universally respected: on some systems they are not checked at all, in case of doubt use parent directory's rights instead. Moreover, under high load (hundreds of connections), using a socket file may cause performance issue and need specific OS tuning (increase the number of allowed connections per socket) while using standard TCP socket on local interface would not cause any trouble. Apr 24, 2015 at 11:12
  • @GZBK I'll update my answer, though I have yet to encounter such issues.
    – user42178
    Apr 24, 2015 at 11:16
  • The first paragraph is key. On Linux you can mitigate that with iptables rules that inspect the uid of the process from which the packet originated and drop local ip packets from users who should not be able to connect. (This ability is also useful for preventing compromise of low-privilege accounts from allowing the attacker to use your host as a spam relay.) Apr 24, 2015 at 15:37
  • @AndréDaniel: Not if you're reusing existing code/services already implemented on TCP without a unix socket transport. In that case the iptables approach is quite practical. Apr 24, 2015 at 17:10
  • The question here was mainly about how to reach remotely processes listening on local interfaces. Using Unix sockets for this is indeed a good workaround. Regarding local processes isolation, Jails / Containers attached to local interface aliases and with communication restrained by the host firewall is also quite powerfull. For @AndréDaniel, I mainly encountered the socket limitation issue when dealing with nginx + php-fpm, as documented here for instance. Apr 24, 2015 at 18:34

If the service provides a web interface it might be vulnerable to CSRF attacks, XSS attacks or "same site" scripting. All of these can be triggered by just visiting the attackers external website, which by itself might be caused by malvertising or phishing. For these attacks it does not matter if the service is listening only on localhost, because it is only needed that the host is reachable by the local web browser. The same problems exist with attacking intranet hosts from outside.

  • So in this attack scenario an authorized person is browsing the web with a browser running on the server?
    – Rick
    Apr 7, 2021 at 12:16
  • @Rick: Correct. The whole question is about running a server and client on the same machine. Apr 7, 2021 at 13:26
  • Yep, it makes sense now. I just was just thrown off since I was looking at raw TCP connection security for non-web related things. But, the server also happens to have an external facing web interface. But, in this case the browser is on a client PC so your scenario doesn't apply.
    – Rick
    Apr 7, 2021 at 13:41

Also consider that the hostname localhost is not exactly the same as the IP (it naturally needs to be resolved first), and in most situations relies on either an entry in the hosts file or a resolver/dns server capable of resolving So, be sure you can strictly specify instead of localhost when implementing security measures, otherwise you will need to step back and also consider security issues in the resolver.


The answer depends on different factors. A few that may or may not apply:

  • What protocol is it? (For example UDP is more prone to security issues in this case as it works statelessly and you might achieve something with a single spoofed packet).
  • Do you consider attacks or only data access. (See above: you might be able to do a DoS attack for a faulty UDP service with a single packet, but won't achieve data flow).
  • Do you have remote access on user level (by design or as a security issue itself)? (For example, a user may set up an SSH tunnel.)
  • Do you have remote root access (by design or as a security issue itself)? (One could set up a NAT to redirect public IP traffic to
  • Do you have firewall, ingress filtering set up properly?
  • Do you have other network services open on non-localhost that can be "tricked" to access the localhost-only service on your behalf?

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .