Why does Linux accept traffic on unconfigured loopback addresses?

Posted on

Problem :

On at least two version of Linux (Ubuntu 9 and Debian 7) I’ve noticed that, even though I only have a single loopback address configured on lo (the standard 127.0.0.1 one), it happily accepts packets to ANY 127.x.x.x address. I found this quite surprising, since other Unix variants drop packets for unconfigured addresses.

  • Why/how does it do this? This doesn’t happen for any other address range, does it?
  • How do I get it to do the more sensible (and secure!) thing and actually pay attention to the addresses that are configured?

Edit: I’ve read RFC 5735, and it’s a rather sloppy interpretation of that to go from “addresses within the entire 127.0.0.0/8 block do not legitimately appear on the network anywhere” to “this machine must accept packets for all of these IPs”. After all, you don’t see hosts accepting packets for all of 172.16.0.0/12, just because they have one of those addresses configured.

My intention was not to ask about the spec for the addresses, but about Linux’s implementation of the logic for accepting packets. “Why” and “how” here means what in the actual Linux kernel causes the normal “is this packet for me” logic to be bypassed?

Solution :

Loopback is special. It’s the entire 127.0.0.0/8 space, and it never leaves the machine. That is the only exception to listening for only configured addresses, if it’s on loopback it’s special.

I can’t think of any security implications to that, since those addresses can never be on the physical network.

The normal route logic is not being bypassed, and this configuration is more secure than the one you propose.

First let us look at the routing table to see what is going on.

# ip address show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
# ip route show table 0
...
broadcast 127.0.0.0 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
local 127.0.0.0/8 dev lo  table local  proto kernel  scope host  src 127.0.0.1 
local 127.0.0.1 dev lo  table local  proto kernel  scope host  src 127.0.0.1

We can see that the interface is configured with a /8 prefix, which causes Linux to automatically generate a route for 127.0.0.0/8 which goes to the lo interface. This enforces the requirement that all packets for this block do not appear on the network anywhere and loop back inside the host.

Without this route, packets for the 127.0.0.0/8 network would not be looped back inside the host and would potentially be eligible to be routed out a network interface. This would introduce insecurity and RFC noncompliance.

Keep in mind that “loopback” means exactly that. While on a regular interface, a packet sent to it goes out, on the loopback interface, a packet sent to it goes out and is immediately returned. This is what loopback means, and why you see this traffic.

It’s not Linux specific (Win works exactly the same), rather following the spec (as Eric noted):
from RFC 5735 – Special Use IPv4 Addresses

127.0.0.0/8 - This block is assigned for use as the Internet host
   loopback address.  A datagram sent by a higher-level protocol to an
   address anywhere within this block loops back inside the host.  This
   is ordinarily implemented using only 127.0.0.1/32 for loopback.  As
   described in [RFC1122], Section 3.2.1.3, addresses within the entire
   127.0.0.0/8 block do not legitimately appear on any network anywhere.

Leave a Reply

Your email address will not be published. Required fields are marked *