On 10/13/2013 11:19 AM, Martin Vaeth wrote: >>> >> [...] >> If you have a million rules and you need to wipe/reload them all >> frequently you're probably doing something wrong to begin with. > > I don't know how this is related with the discussion. > The main advantage of using iptables-restore is avoidance of > race conditions. A secondary advantage is a speed improvement; > in my case, the machine boots about 2 seconds faster which can > be a considerable advantage if you start virtual machines. >
I was just reiterating that there's not much benefit to save/restore if you're doing things properly (pontification alert!). I should say first of all that save/restore is perfect for reboots. If you're not *changing* anything, of course save/restore is better, and suffers none of the problems that I mentioned: you don't read it, the output is fed directly as input, no errors should occur... The bash script is used a couple times a year, and really is there to serve as the specification for what your firewall should do. For example, I'm rebuilding our MX today. I checked the config out of git, ran iptables-config (our script), ran /etc/init.d/iptables save, and the firewall is up and running. When will I run the script again? The next time I rebuild the server? That's certainly the last time I ran it. We have firewalls that change more often, but not so frequently that the speed would be a problem if it were 1000x slower. The MX firewall is actually updated many times per day and accumulates many rules, but they're inserted/deleted in-place by fail2ban, so a full wipe/reload doesn't occur. If you have frequently-changing permanent rules -- say, lots of static NAT entries going in/out for new employees -- then you should be doing insert/delete instead of a full reload just the same. But, add the rule to your iptables script (with a comment!) so that you have it on the record. Once every six months or so, run the thing to make sure nobody made a copy/paste error. Race conditions don't really seem that serious to me. Of course, if you're using iptables for both authorization and authentication, then you're already doing something wrong, and you should fix that instead of trying to make the broken thing run faster. But if not, who cares if you're vulnerable to a brute force attack for 2 seconds? If you're worried about that, implement a password policy. The firewall is the last layer of defense-in-depth; if the absence of a firewall gives you nightmares, the absence of a firewall is not your problem. All of security is a trade-off, and in my opinion, having human-friendly, easily-readable rules (with error checking) will prevent more problems over time than does eliminating the race condition.
