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