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. – CodesInChaos Apr 24 '15 at 14:24
  • 6
    @CodesInChaos could you clarify and possibly provide a link for that ? – user42178 Apr 24 '15 at 16:37
  • @CodesInChaos Without information about which OS and version, then that isn't a verifiable statement. – kasperd Apr 25 '15 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 '15 at 11:28
  • 1
    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" – CodesInChaos Apr 25 '15 at 12:36

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. – WhiteWinterWolf Apr 24 '15 at 11:12
  • @GZBK I'll update my answer, though I have yet to encounter such issues. – user42178 Apr 24 '15 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.) – R.. Apr 24 '15 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. – R.. Apr 24 '15 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. – WhiteWinterWolf Apr 24 '15 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.


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?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.