Restoring iptables Automatically On Boot
Posted by jawnsy on Tue 9 Sep 2008 at 11:55
There used to be a script to do it automatically via init.d files, but now the suggested method is to use ifup.d networking scripts, which are executed on state changes of the network interfaces. So I submit here my simple script, which does the trick for me nicely.
I tested this on Debian unstable (lenny/sid)
Drop this script into /etc/network/if-pre-up.d in a file called iptables
#!/bin/sh # Load iptables rules before interfaces are brought online # This ensures that we are always protected by the firewall # # Note: if bad rules are inadvertently (or purposely) saved it could block # access to the server except via the serial tty interface. # RESTORE=/sbin/iptables-restore STAT=/usr/bin/stat IPSTATE=/etc/iptables.conf test -x $RESTORE || exit 0 test -x $STAT || exit 0 # Check permissions and ownership (rw------- for root) if test `$STAT --format="%a" $IPSTATE` -ne "600"; then echo "Permissions for $IPSTATE must be 600 (rw-------)" exit 0 fi # Since only the owner can read/write to the file, we can trust that it is # secure. We need not worry about group permissions since they should be # zeroed per our previous check; but we must make sure root owns it. if test `$STAT --format="%u" $IPSTATE` -ne "0"; then echo "The superuser must have ownership for $IPSTATE (uid 0)" exit 0 fi # Now we are ready to restore the tables $RESTORE < $IPSTATE
Then make sure you make the script executable:
chmod +x iptables chown root:root iptables
It loads the settings from $IPSTATE - by default, /etc/iptables.conf. You have to save the rules manually; this ensures that you make sure your rules are working properly (i.e. doesn't block you from logging in remotely, for example) before you decide to save them.
You do this running the command: "iptables-save > /etc/iptables.conf" (or whatever file you have chosen to use as your $IPSTATE file)
Check out /usr/sbin/iptables-apply as well.
[ Parent | Reply to this comment ]
I think, of course, "too restrictive/paranoid" varies from one scenario to another. And yes 0644 does work. What I really should have done is allowed the permissions part to be changed at-will, so maybe in an upcoming version of the script I will do so.
Thanks for your suggestion.
On another note, I read /usr/sbin/iptables-apply and can't figure out how it's any more useful than doing an iptables-save and iptables-restore manually. Perhaps you can enlighten me there?
[ Parent | Reply to this comment ]
To understand iptables-apply, run iptables-restore with a ruleset that you hand-edited and where you made a mistake which would lock you out. iptables-apply reverts the ruleset unless you confirm that you can make new connections to the machine within a given time. It has saved me a lot of grief.
http://madduck.net/blog/2006.06.04:iptables-apply/
[ Parent | Reply to this comment ]
iface eth0 inet static
...
pre-up iptables-restore < /etc/iptables-eth0.conf
[ Parent | Reply to this comment ]
Your method is indeed, simple, but consider that you are lacking all of the checks I have in place - testing that it is owned by root, testing permissions. Without these, anyone can write to the file, which makes it dangerous to load as a firewall ruleset.
Secondly, what I mean by it not being the "Debian Way" is that it's not in a separate .d file. Those .d directories are very useful because you can simply move files in and out of there, whereas you'd have to do a bit more work editing config files otherwise.
The .d structure allows debian packages to do most of their magic, as well as the Apache2 a2enmod scripts et al.
[ Parent | Reply to this comment ]
I mean, one would save the rules as root, in a directory, say, iptables, created by root.
You can't change interfaces if you're not root, and you can't tamper with the file.
Help me if i'm missing something, i'm new to this.
[ Parent | Reply to this comment ]
It's safer to actually check ownership and permissions before loading those; otherwise if you accidentally leave the file as 666 or 777 or otherwise writable by others, then it becomes vulnerable.
When you do the first save of your iptables rules, most people would check that the permissions are set correctly. But you never know if another script or another administrator changes the permissions, and you want to make sure that you don't load anything dangerous.
The only thing is that you may wish to relax the permissions up to 0644, because others have commented that there may be no need or benefit from hiding the file contents from non-root users.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
I don't think iptables-save is unreadable at all - it just dumps whatever you throw into iptables in the beginning. But yes, if you have a large rulset generated by a script like fail2ban, then you are going to have a huge script.
Still, the script only does the iptables-restore part, so just don't manually save anything, which should prevent it from dumping a huge ruleset. Just load a basic set of rules that should always be in place, and then fail2ban can add more, and at the next reboot, the basic rules will be restored, but the fail2ban ones will be cleared.
In conclusion, you still *could* use this for what you want, but it does make it more complicated as iptables-save has no way of knowing which rules are added by fail2ban and which are added manually.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
Saves should be pretty infrequent and should be done manually. The philosophy here is that, if your machine doesn't shut down cleanly anyway, you're going to lose the rule. So best to save right after you add new rules.
Hope this helps!
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
I would do something like this:
1. Take the machine offline
2. Set up the base rules as you would like them (allow incoming connections to port 80, etc)
3. Save the rules
4. Load fail2ban
Then the new rules that are added won't be restored upon boot. The downside, of course, is that if you ever need to change the settings, you would have to take the machine offline again (or otherwise make it "safe" from outside attacks), flush the rules, load the rules (manually using iptables-restore or using the script)
Then, you'd add the rules you needed, save them again, and let fail2ban do its work as per usual.
If you also read about chaining, you may be able to add a special chain for fail2ban. Then use a -j FAIL2BAN chain... Then simply prevent iptables-save from saving the FAIL2BAN chain (hopefully this can be accomplished via some command line options)
[ Parent | Reply to this comment ]
I just generate a script with firewall builder and put it in
/etc/network/if-pre-up.d automaticaly from firewall builder
work very well
[ Parent | Reply to this comment ]
After installing, you can use it like this:
debian:/var/www/debian# iptables -I FILTER 10 -j ACCEPT -s 12.34.56.78
debian:/var/www/debian# service iptables save
Saving firewall rules to /etc/iptables-service/iptables: OK.
Look for it at http://debian.nikolas.ru/debian/
Comments are welcome.
[ Parent | Reply to this comment ]
And there I was happily hacking away at my own iptables scripts in /etc/init.d. Ah well ...
IIRC the advantage of the /etc/network/if-[pre|post]-[up|down].d is optimal inclusion at startup/shutdown
[ Parent | Reply to this comment ]
But for my router with ~10 interfaces and stable (changing rarely) iptables rules - init.d script more optimal and usable solution ;-)
[ Parent | Reply to this comment ]
Some people have the view firewalls aren't needed on a server but I like running one and I'm happy to stick with the /etc/init.d method.
Regards
Lesley
[ Parent | Reply to this comment ]
Those scripts will be run everytime admin ifup-s interface.
In case of pre-up.d script, script will run many times during boot if there is more than one interface started.
Every time interface is brought down, current rules must be saved, or else on subsequent interface up all manual rules changes will be lost.
Can someone tell any upsides of 'pre-up' solution?
[ Parent | Reply to this comment ]
Imho it is really bad to automate configuration of such things, the admin must know that his rules will get lost if he doesn't store them. What if he does something stupid and blocks himself out and has a script that automatically reboots the machine (tries to restore things) after some time of no response? The shutdown process would store his error and he will then need physical access to the machine to correct it.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
This package contains just a system startup script that restores iptables rules from a configuration file
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]