On firewalls
A few recent posts on Planet Debian make me wonder why some people seem to insist on using someone else's "firewall scripts", yada yada. Personally, I just have my own #!/bin/sh in /etc/init.d which runs iptables with some appropriate options. And that's it.
Well, no, I'm lying. It also has some ip6tables lines in it. An tc. But that's really it, I swear.
So, indulge me, please. What's the great thing about these firewall ruleset generators? Apart from the fact that some of them provide a GUI to change the ruleset, which I don't care for.
Yeah, I mostly agree. There's no use relying on extra pieces of software if a simple /bin/sh script does the job, especially as you can use such a script on a multitude of OSes or distributions (not all of them might have extra firewall frontend software installed). For example, my iptables script is freely available/downloadable from my website (comments welcome, hint hint), and I regularly download it when I'm installing new systems (my own, or for other people), for example.
Any chance you'll post your firewall script, or is it publically available already? I'm always eager to learn...
Main problem with iptables is that one can't add set of rules in atomic fashion.
Writing shell scripts is bad way of configuring firewall, I mean -- there must me error detection after every command!
I usually start every firewall script with something like that:
!/bin/sh
set -e
err() { iptables -F iptables -X iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT
echo 'error somewhere' exit 1 }
trap err 0 trap err 2 trap err 3 trap err 15
common iptables stuff goes here...
Writing such things sucks badly, so someone have written something like that for you.
ipf (from BSDs) doesn't have this problem. Not only rules are read from one file and applied only if syntax is correct they also have notion of active/non-active ruleset. You add rules to non-active one and when you are ready switch non-active to active and vice versa. Nice thing, I would say.
~$ grep iptables /etc/network/interfaces pre-up iptables-restore < /etc/network/iptables/strictiptables-restore takes as input the output of iptables-save, which is a human-readable and reasonably editable copy of your iptables configuration (most of it takes the form of arguments that could be used to invoke iptables).
I'm using shorewall, and this is surely not for a GUI or something like that. This is because it provides a well-thought abstraction layer, with configuration files matching the way I see my network. This way I can configure the network with a global view. It's straightforward, flexible, and does all I want.
I don't want to lose time in writing cryptic iptable commands, and I really don't need to.
Hi, The firewall for my laptop is also just a few lines of raw iptables commands.
But have you ever maintained a firewall e.g. for a university chair, with a failover setup of two firewalls, with four different networks, a dozen of different services in the DMZ, a couple of things needing to cross from the DMZ to the internal network, some NATs, a couple of different OSes in there, and so on?
That would be like ~200 lines of iptables rules. It used to be that way. It totally sucked. Thats why I wrote pyroman, to have some easy way of adding new host configurations, a way even iptables-illiterate can use.
Do you have same kernels on your laptop and server? My laptop/server/self-build-embedded-ap all have different kernel .configs. I can't test my AP's script on my laptop and be sure that it will work everywhere. Different kernels, different configuration options. Error recovery/rollback is important when configuring firewall remotely, I think.
..and no, iptables-restore isn't the answer. iptables-restore may leave your firewall in really broken state (if preceding apply).