1 |
On 10/03/2013 04:28 PM, Kerin Millar wrote: |
2 |
> |
3 |
> The iptables runscript is ideal for persisting the rules. However, |
4 |
> during the initial construction of a non-trivial ruleset, I prefer to |
5 |
> write a script that adds the rules. An elegant way of doing this is to |
6 |
> use iptables-restore with a heredoc. The method - and its advantages - |
7 |
> are described in this document (section 3): |
8 |
> |
9 |
> http://inai.de/documents/Perfect_Ruleset.pdf |
10 |
> |
11 |
|
12 |
This advice is dubious in my opinion. The `iptables` command line is the |
13 |
published interface to iptables. The iptables-restore syntax is an |
14 |
implementation detail, subject to change at any time. |
15 |
|
16 |
Here are his arguments: |
17 |
|
18 |
1. Calling iptables repeatedly is slow. |
19 |
|
20 |
Who cares? How often do you invoke the script? Once or twice a year |
21 |
when you change it. |
22 |
|
23 |
2. There is an opportunity for someone to bypass the rules between |
24 |
dropping/recreating them. |
25 |
|
26 |
Again, you run the script once or twice a year. Turn off the interface |
27 |
beforehand if a few microseconds per year is too long to run without a |
28 |
firewall. |
29 |
|
30 |
|
31 |
And my counterarguments: |
32 |
|
33 |
1. The iptables-restore syntax is uglier and harder to read. |
34 |
|
35 |
2. You get better error reporting calling iptables repeatedly. |
36 |
|
37 |
3. The published interface will never change; iptables-restore reads an |
38 |
input language whose specification is "whatever iptables-save outputs." |
39 |
|
40 |
4. A bash script is far more standard and less confusing to your coworkers. |
41 |
|
42 |
5. You can't script iptables-restore! What if you want to call sed, cut, |
43 |
or grep on something and pass that to iptables? You can write a bash |
44 |
script that writes an iptables-restore script to accomplish the same |
45 |
thing, but how much complexity are you willing to add for next to no |
46 |
benefit? |