On Tuesday 2005-November-15 00:26, Rob Sterenborg wrote:
> > And to go a bit further, I should say that I am moving away from
> > scripts, in favour of iptables-save(8)/iptables-restore(8)
> > rulesets. The initial ruleset can be developed by means of a script
> > or editor, and I find that the rules files are much easier to
> > maintain.
>
> I think that's a matter of opinion.
Of course it is, and is stated as such. It is an opinion which grew
after writing many scripts. I once had, and at some sites still do
have, monster scripts that make the OP's effort look trivial.
Functions, nested loops, arrays, even nested arrays which are
supposedly not possible in bash! (I cheated, using alternate $IFS on
the internal arrays, the ones which were contained in other arrays.)
I'm pretty good with bash. I am on a first-name basis with the Advanced
Bash Scripting Guide, and even with the dreaded "man bash". :) I paid
my shell scripting dues, so to speak, and I did it in making firewalls.
I feel pretty confident that my latest firewalls, trivial to maintain
and to adjust using rules files, would be a nightmare to script. I have
complex port forwards which are allowed from some addresses but not
from others, and some which differ per external interface (at sites
with multiple external interfaces.) I have conditional branching
through multiple user chains. Two sites I can think of have even have
alternate SNAT'ing per internal address. I have several sites with
transparent proxying rules, HTTP and DNS.
I found that when I needed to add or adjust one rule I often had to dig
in the depths of the script code, and the digging could break things.
My dream of having one simple configuration file and never touching the
script internals never quite came to pass.
In the early days, I, like many who post here for help, did not fully
understand the distinction between filter INPUT and FORWARD. My early
scripts jumped to the same Allow chain for both INPUT and FORWARD,
although some of those rules belonged exclusively in one or the other.
When I come across these I am converting them to rulesets. It's simple
to do so in $EDITOR. I make separate AllowIn and AllowFwd chains and
append the "In" or "Fwd" string as needed. Spending ten minutes in
$EDITOR gives me a tighter, better firewall, that would have taken
hours to script (and to debug!)
> Personally I prefer scripts because I can put remarks and empty
> lines in them, grouping lines together that belong to each other
> so I know what I did 1 year (or so) ago, without having to read
> over the complete script/ruleset.
Red herring. No, iptables-save(8) won't preserve comments unless using
"--comment" in your rules, but you can certainly add comments to your
rules -- iptables-restore(8) is fine with that. I didn't try blank
lines, but I bet those work too.
The only grouping requirement I know is that you must keep each table's
rules together between the *table_name and COMMIT lines. Perhaps you
could add multiple sections for the same table. Again, I have not
tried. Nor would I wish to try!
> But everyone should do what (s)he wants in that matter ; the output
> of iptables-save is practically in script form so it's not that I
> can't read it.
The thing that appeals to me is that the output is linear per chain,
just like netfilter itself. You can see right away what is being done
in any particular chain.
I am not trying to convince you; I am only trying to explain where I
came from and why I went where I did. With simple firewalls, simple
scripts can surely be a viable option.
--
mail to this address is discarded unless "/dev/rob0"
or "not-spam" is in Subject: header
