Chapter 12. Debugging your scripts
One of the big and underestimated sides of writing your own rulesets is how to
debug the rulesets on your own, and how to find where you have done your
mistakes in the rulesets. This chapter will show you a few basic steps you can
take to debug your scripts and find out what is wrong with them, as well as some
more elaborate things to look for and what can be done to avoid being unable to
connect to your firewall in case you accidentally run a bad ruleset on it.
Most of what is taught here is based upon the assumption that the ruleset was
written in bash shell scripts, but they should be easy to apply in other
environments as well. Rulesets that have been saved with
iptables-save are another piece of code alltogether
unfortunately, and pretty much none of these debugging methods will give you
much luck. On the other hand, iptables-save files are much
simpler and since they can't contain any scripting code that will create
specific rules either, they are much simpler to debug as well.
Debugging is more or less a necessity when it comes to iptables and netfilter
and most firewalls in general. The problem with 99% of all firewalls is that
in the end there is a human being that decides upon the policies and how the
rulesets are created, and I can promise you, it is easy to make a mistake while
writing your rulesets. Sometimes, these errors are very hard to see with the
naked eye, or to see the holes that they are creating through the firewall.
Holes that you don't know of or didn't intend to happen in your scripts can
create havoc on your networks, and create an easy entry for your attackers. Most
of these holes can be found rather easily with a few good tools.
Other than this, you may write bugs into your scripts in other ways as
well, which can create the problem of being unable to login to the firewall.
This can also be solved by using a little bit of cleverness before running the
scripts at all. Using the full power of both the scripting language as well as
the system environment can prove incredibly powerful, which almost all
experienced Unix administrators should already have noticed from before, and
this is basically all we do when debugging our scripts as well.
