One of the best precautions you may take against a locked down firewall is to
simply use cron to add a script that is run every 5 minutes or so that resets
the firewall, and then remove that cron line once you are sure the installation
works fine. The cron line may look something like the one below and be entered
with the command crontab -e.
*/5 * * * * /etc/init.d/rc.flush-iptables.sh stop
Make absolutely sure, that the line will actually work and do what you expect it
to do before you start doing something you expect will or may freeze the
server you are working on.
Another tool that is constantly used to debug your scripts is the syslog
facility. This is the facility that logs all log-messages created by a ton of
different programs. In fact, almost all large programs support syslog logging,
including the kernel. All messages sent to syslog have two basic variables set
to them that are very important to remember, the facility and the log
level/priority.
The facility tells the syslog server from which facility the log entry came
from, and where to log it. There are several specified facilities, but the one
in question right now is the Kern facility, or kernel facility as it may also
be called. All netfilter generated messages are sent using this facility.
The log level tells syslog how high priority the log messages have. There are
several priorities that can be used, listed below.
debug
info
notice
warning
err
crit
alert
emerg
Depending on these priorities, we can send them to different log files using
the syslog.conf. For example, to send all messages from the kern facility with
warning priority to a file called /var/log/kernwarnings, we could do as shown
below. The line should go into the /etc/syslog.conf.
kern.warning /var/log/kernwarnings
As you can see, it's quite simple. Now you will hopefully find your netfilter
logs in the file /var/log/kernwarnings (after restarting, or HUP'ing the syslog
server). Of course, this also depends on what log levels you set in your
netfilter logging rules. The log level can be set there with the --log-level
option.
The logs entered into this file will give you information about all the packets
that you wish to log via specific log rules in the ruleset. With these, you can
see if there is anything specific that goes wrong. For example, you can set
logrules in the end of all the chains to see if there are any packets that are
carried over the boundary of the chains. A log entry may look something like
the example below, and include quite a lot of information as you can see.
Oct 23 17:09:34 localhost kernel: IPT INPUT packet died: IN=eth1 OUT=
MAC=08:00:09:cd:f2:27:00:20:1a:11:3d:73:08:00 SRC=200.81.8.14 DST=217.215.68.146
LEN=78 TOS=0x00 PREC=0x00 TTL=110 ID=12818 PROTO=UDP SPT=1027 DPT=137 LEN=58
As you can understand, syslog can really help you out when debugging your
rulesets. Looking at these logs may help you understand why some port that you
wanted to open doesn't work.
