Re: [gentoo-user] Re: scripted iptables-restore

[Michael Orlitzky <michael@orlitzky.com>]

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.