Monday, 2 July 2007

iptables

iptables is something that I've steered clear of until recently. Partly because it looks blooming complicated (and why bother when scripts such as system-config-securitylevel will set up a firewall without getting involved in the nitty-gritty), but also for fear of locking myself out of the server (which is 100+ miles away at a server farm and doesn't have a screen and keyboard attached). When I became interested in port-knocking however, it seemed that the time had come to do a little research.

The first bit of good news came when I discovered that you can 'mess' with iptables without making the changes permanent. When the server boots and iptables sets up the firewall, it loads rules from /etc/sysconfig/iptables however you can then change those rules from the linux command line using the iptables command. In fact you can create a script to delete the current rules and load a new set. The crucial thing here is that you do not edit /etc/sysconfig/iptables directly. Firstly because it's 'system generated' and secondly because if things go wrong, you can reinstate the original set of rules by rebooting the server. While I can't get physical access to my server, there's a mechanism by which I can request a reboot. Of course when you have a set of rules that work you will want the server to use them when it boots and you do this by issuing the following command causing the rules that are currently in memory to be written to the /etc/sysconfig/iptables file:

service iptables save


Safe in the knowledge that we can dabble, it's time to look at creating the script that will install our rules. The first three lines look like this:


#!/bin/sh
/sbin/iptables --flush
/sbin/iptables --delete-chain


Obviously the first line starts our shell. The next two lines clear out any existing iptables rules and user defined chains (of rules) that are currently in memory.

iptables works by looking at packets that are wanting to cross the firewall. These could be packets coming into the computer from the network, going from the computer out to the network, or being forwarded (if the computer is also being used as a router). Because of this it is normal for a set of iptables rules to start with a set of default policies such as:


/sbin/iptables -P INPUT DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT ACCEPT


I've seen examples sets that work on the basis of accepting anything that doesn't get blocked by a later rule, and I've seen others that block everything unless it's accepted by a later rule. I've gone for a mixture. Nothing comes in unless a later rule allows it. My server is not being used as a router so all packets for forwarding are dropped. All outgoing packets are allowed.

It might seem odd that you would want to do anything other than allow all outgoing packets however in a scenario where the computer is allowing a number of machines on a LAN to connect to a WAN, you may want to implement restrictions.

The next thing is to set up the loopback interface:


/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -j ACCEPT


This allows local traffic such that daemons running on our computer can send packets to other daemons running on our computer via the firewall. Stricly speaking, we only need the first of the above lines in our script because our default policy for output already allows outgoing packets from our daemons.

With the default policies set up and our daemons able to talk to each other, our computer can see out, but nothing can see in. If this were a home computer being used to access the web, we could stop right here, however I'm creating rules for a web server and there's no point having a server if nothing can access it.

Before we create a few rules to open things up, it's important to understand that we can split and packets reaching the interface into one of two groups: those initiating a connection, and those that are part of an established connection. This simplifies things because we can allow packets for established connections to pass through unhindered because we already did all our checks before we allowed the initial connection.


/sbin/iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT


The first line says that all new TCP connections must start with a SYN packet i.e. that they must start properly. The second line says that packets for established or related connections are allowed through. If we stop there then we will still be blocking all input because we haven't allowed anything to establish a new connection yet.


/sbin/iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 25 -m state --state NEW -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT


The three lines above allow new connections by accepting packets coming in on ports 22, 25, and 80 i.e. SSH, SMTP and HTTP. Note that this does not mean that anybody can connect via SSH. The still have to be on the list of allowed users and they have to know a password. The above simply means that the port it 'open' such that it is possible to connect.

We're almost done now although there are lots of other things that could be done with our rules and that you will see in other suggested iptables setup scripts. Sometimes you may need other ports open and sometimes you may want to do things like blocking traffic from IP addresses that are being a nuisance. You can also do things like locking out an IP (for a period of time) that has made more than a given number of connection attempts in a given amount of time. In a later post I'll describe describe a technique that I've implemented to greatly enhance the security of my server using iptables rules but in the meantime I want to make just one final addition:


/sbin/iptables -A INPUT -p ICMP --icmp-type 8 -j ACCEPT


This accepts incomming type 8 ICMP messages and allows people to ping the server. If this were a desktop computer from which I wanted to issue the traceroute command then I should also allow type 11 ICMP messages. However it isn't, so I won't, and our final script looks like this:


#!/bin/sh

# Flush old rules, old custom chains
/sbin/iptables --flush
/sbin/iptables --delete-chain

# Set default policies for all three default chains
/sbin/iptables -P INPUT DROP
/sbin/iptables -P FORWARD DROP
/sbin/iptables -P OUTPUT ACCEPT

# Enable free use of loopback
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -j ACCEPT

# All TCP sessions should begin with SYN
/sbin/iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

# Accept inbound TCP packets
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 25 -m state --state NEW -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT

# Accept inbound ICMP messages
/sbin/iptables -A INPUT -p ICMP --icmp-type 8 -j ACCEPT


Of course the final steps are to save our script, make it executable, and run it as root. We then need to check that everything works as we expect. Most especially that we can still initiate new SSH connections to our server. When we are happy we use the 'system iptables save' command to write our configuration to /etc/config/iptables and we're done.

No comments: