Hi all,

I am in the process of creating a firewall script for Linux(CentOS 5.3) IPTables, for my current company firewall.
We have various zones;
DMZ, Trusted, Web, Squid and a few others.

Instead of having all these in one script, what will or can be the best way to break the entire script apart, and have the script call various config files, like;

My script is called: firewall.sh
I would like to break it apart so that each zone is in its own file;
dmz.zone
trusted.zone
...
...
etc

And then the script file must call these zone files when loading.

What would be the best way in setting that up ??
And how do you call files from a script ??

Thank you

Calling a script from within another script is done by sourcing it

eg.
That said, using scripts is not the usual process for running iptables firewalls, is your script just for initial configuration or does it load the rules on startup ?

Hi kbp,

The script initially loads the rules at startup.
I found it easier to maintain a script and reload new or removed rules.

Is there a better/easier way?
Or a more secure way?


Thanks for the help

Usually the rules are stored in /etc/sysconfig/iptables, but whatever works for you is fine. Just make sure everyone knows where they're supposed to go otherwise it could get confusing

cheers

hmmm, I'm not totally sure whether you mean that you want one script to call other scripts or whether you want one script that looks up, eg, the ip addresses for the DMZ in one conf file and for the squid zone from another...but, I don't really see any big advantage in breaking it up.

• if you mean a script that calls other scripts, you have the problem that it might not all happen at once (or, if something goes wrong, the later part might not happen) and that might leave you in an insecure state, if only transiently.
  
• if you mean saving the conf for separate zone separately, you can do that within a properly-structured script, so I don't see that being a big advantage either (and you still have the 'what if one of the zone configs is missing or inaccessible' problem, although you can almost cure that by testing for the presence of readable conf files and writing out a suitable error message if the file isn't readable, I suppose)

Another question might be 'Should I write this as a shell script or in a scripting language such as Python, Perl, etc?' Python might be neater, but it does depend on the python interpreter being runnable when you invoke the script (and if someone upgrades the python package, that can't be guaranteed, necessarily) where, by contrast, you can pretty much guarantee that a bash script will be runnable, so you'd need a demonstrable benefit to writing in the 'higher' scripting language for that to be a useful way forward.

Personally, I have a bash script of roughly 1000 lines for setting up iptables and the accompanying syscontrol junk, and I find that is in no danger of becoming unmanageable (not currently in use, but I was at that time interested in iptables and what it could do). That said, I did take pains to comment it pretty extensively (...which is why its ~1000 lines to write out ~100 lines of iptables rules...) and structure the thing so that the separate 'stanzas' of the rules are kept separate.

I wouldn't rely on that; I think that's Red Hat and derivatives only. I know the OP is using Centos, and so it is probably true for that and for Fedora, but I don't think outside of those it is generally true (but I don't have extensive experience of others).

I keep a firewall script under version control that I use to load (and re-load) the ruleset. After doing so, it's a simple:
And the ruleset persists going forward.