It’s interesting to dwell occasionally into researching how people are reaching my blog and what are they looking for when they do so. As you have seen so recently I have brought back a few old articles that seem to have triggered the attention of some people on the net — at least that’s what I could tell looking at the searches performed by various in search engines which directed people on my site. One such phrase was “iptables linux” — I completely forgot that at some point I had a post about this, so here it is again:
If you are using a Linux server to control access to your network from the outside (or even from the inside), you are probably implementing some firewalling rules. While there are a few ways to implement such a facility, I have decided for iptables
— purely because I thought it simple to manage and it also has various kernel module one can load and make use of. However, I am sure that this approach can be used for the likes of iproute
, iproute2
and so on.
I am not going to go into details about how to compile your kernel to include support for iptables
as there are loads of resources on the net about this. But it needs to be said that the modules have to be compiled in the kernel in order for iptables
to work. Also, I will assume that you are already familiar with the way iptables
operates and how to use the commands associated with it (iptables
, iptables-restore
and iptables-save
).
Last but not least, as the title of this article states it, this article targets the Debian distribution of Linux, however, simply changing a few paths would render it useable on your own distribution of Linux.
So, you have set up your iptables
rules using the command line, you have tested it and made sure they work and your network is protected and then you saved them using iptables-save
. I guess the next thing you might think of implementing is an automated way to have them applied after your computer boots up. To do so is trivial, and all you need is a simple script placed in /etc/init.d
which you can then link to the runlevel of your need (/etc/rc2.d
for instance) which would just automatically load the rules at start-up. And since most of the scripts in /etc/init.d
support the “classic” start, stop, restart parameters, let’s make our script do the same. So here it is — save it in /etc/init.d/iptables
:
#! /bin/sh # /etc/init.d/iptables: load and save the iptables IPTABLES_CONF=/etc/default/iptables.conf IPTABLES_BAK=/etc/default/iptables.bak SAVE_CMD=/sbin/iptables-save LOAD_CMD=/sbin/iptables-restore check_config() { if [ ! -r $IPTABLES_CONF ]; then echo "Cannot find saved iptable!" exit 1 fi } case "$1" in start|load) check_config $0 flush echo -n "Loading iptables..." $LOAD_CMD < $IPTABLES_CONF echo "done" ;; stop|flush) echo -n "Stopping iptables..." iptables -F echo "done" ;; save) echo -n "Saving iptables..." cp $IPTABLES_CONF $IPTABLES_BAK $SAVE_CMD > $IPTABLES_CONF echo "done" ;; *) echo "Usage: /etc/init.d/iptables {start|stop|load|save}" exit 1 esac exit 0 |
As you can see, we went an extra mile and implemented some other functionality as well (save, backup). This is in order to prevent testing with iptables
to test some new rules and accidentally overwriting the configuration file (via iptables save
) — so if this ever happens at least you have a backup file which you can restore. Simply test your rules until you are happy with them and then issue an iptables save
followed by iptables backup
— this would ensure that if by any chance you overwrite the main configuration file with some wrong data, you will still be able to restore the “last known to work” configuration file.
Having saved the above file as /etc/init.d/iptables
then simply create a link to it in say /etc/rc2.d
(the standard multi-user runlevel in Debian Linux) specifying also a start priority — in my case I start this with a priority of 15
(before apache and all the other server components), so in this case simply issue:
cd /etc/rc2.d ln -s ../init.d/iptables S15iptables |
Also, it’s a good idea to stop them during reboot/shutdown (runlevel 6) — in my case, again, I’ve created a link in /etc/rc6.d/
named K99iptables
— so it’s pretty much the last service stopped — after all the other services have been stopped. (So when I turn off the iptables
firewall there’s no services that a hacker can get to.)
As a last note, the format of the file /etc/default/iptables.conf
is the standard format that you would get when issuing an iptables-save
command — here’s an example:
# *filter :INPUT DROP [210:22505] :FORWARD DROP [134:20792] :OUTPUT DROP [197:14914] # Deny Samba connections from outside the network -A INPUT -p tcp -s ! a.b.c.d -d a.b.c.d -m multiport --dports 137,138,139 -j DROP -A FORWARD -p tcp -s ! a.b.c.d -d a.b.c.d -m multiport --dports 137,138,139 -j DROP -A OUTPUT -p tcp -s ! a.b.c.d -d a.b.c.d -m multiport --dports 137,138,139 -j DROP ... |
Obviously, the comments are added by hand — and not by iptables-save
🙂 And also if you edit the file by hand and add such comments, please be aware that when you use iptables save
(or iptables-save /etc/default/iptables.conf
) the comments will be lost.
Download the shell script and a sample configuration here.