Home / server / Questions / 612145
Accepted
Encoderer
Asked: 2014-07-13 10:47:04 +0800 CST

iptables tables -- fixing a typo in lo handling

  • 772

I spent some time today auditing my iptables script. I'm a software engineer, not an Ops guru, but I've tried to pick up the basics of iptables. I noticed something that must have been broken for a long time: 

# Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT -i lo -d 127.0.0.0/8 -j REJECT

Ok, so, that looks like it should be: 

-A INPUT -i ! lo -d 127.0.0.0/8 -j REJECT

Right?

Trouble is, the server is running live traffic. While this looks like a harmless change, I treat iptables with a proper amount of deference. Also, it means that i've been accepting traffic from /8 that comes from other interfaces. What does that mean in real world terms? How would the machine receive any requests from 127/8 on a different interface?

iptables

1 Answers

  1. Best Answer

    looks like it should be:

    -A INPUT -i ! lo -d 127.0.0.0/8 -j REJECT

    Right?

    Probably, yes. The spirit of this rule appears to be to block anything whose IP destination is 127.0.0.0/8 which does not arrive on the lo (loopback) interface.

    See this question on the correct positioning of the ! character: Iptables bang position.

    I've been accepting traffic from /8 that comes from other interfaces. What does that mean in real world terms?

    If someone manufactures a fake packet, destined for your machine on one of its publicly connected interfaces, you may have replied to it, and in some degenerate cases, may have permitted access to local daemons and services only listening on a loopback interface. I would be surprised if that behaviour actually occurred though, and any potential attack surface is fairly remote.

    In reality, the chances of exploiting this seem, to me at least, to be remote. The attacker would need to be on the same network segment as you to fake an IP header while keeping the Ethernet header (in particular, the destination MAC address) in tact. Remote hosts wouldn't be able to exploit a faked IP header, because the packet would be discarded undelivered as it crossed routers in the network. Any services on the machine explicitly bound to the IP address of the loopback interface should only respond to traffic so received, not to spoofed packets arriving on other interfaces, so I (personally) don't see this as being a major issue for you.

    Trouble is, the server is running live traffic. While this looks like a harmless change, I treat iptables with a proper amount of deference.

    Quite rightly, any configuration change which risks turning a machine which is actively moving packets into a machine which actively rejects network traffic should be treated with caution, particularly if downtime will bear financial implications. You should also weigh the consequences of any such change -- the chances of this mistype leading to an exploit bringing the machine down are slim, yet manipulating the iptables configuration on a working machine have greater risks of causing downtime. This trade-off should be considered carefully.

    A change of this type should be harmless, but there are still relatively many failure modes: fat-fingering a keyboard transaction, misunderstanding the interplay between this aspect of your iptables configuration and some other entries in the firewall, etc.

    For all non-routine firewall changes, especially those dealing with REJECT rules, you should plan downtime. If you are performing a change on a machine from a remote location, be sure you have some other means of accessing the machine should access be lost -- preferably, this should be available within the maintenance window so you can avoid breaching any SLAs. An OOB connection via an onboard IPMI controller or a serial console, or alternatively, the ability to physically access the machine in the data centre during the at risk period, would all be suitable here.

    • 3