Linux Firewalls - Michael Rash [55]
iptables Policy Configuration
Fundamentally, psad is a log analyzer. It assumes that the iptables policy on the system where psad is deployed is configured in a log-and-drop stance. This ensures that iptables only accepts those packets that are strictly necessary for the network to function; all other packets are logged and dropped. Port scans, probes for backdoor programs, subversive application commands (we will see in Chapter 9 that iptables can filter on application layer data), and other nefarious miscellany lie outside the list of acceptable network traffic, so iptables logs derived from such a policy can commonly provide a valuable supplement to a dedicated intrusion detection system.
An automated mechanism for verifying that the local iptables policy is configured with default LOG and DROP rules in both the INPUT and FORWARD chains is provided by psad. This mechanism is a dedicated script located at /usr/sbin/fwcheck_psad, which is executed by psad at start time (unless the --no-fwcheck command-line switch is given or psad is running on a separate syslog server). The fwcheck_psad script uses the IPTables::Parse Perl module to acquire a representation of the local iptables policy, which it interprets to see if it contains the LOG and DROP rules. If not, psad will send a configuration alert email to inform you that the iptables policy is not properly configured.
PROCESS MONITORING WITH KILL()
The strategy of writing a PID to disk is a standard among system daemons, and everything from syslog to OpenSSH uses it. Once a PID file is available in the filesystem, there is an elegant solution by which a process may check to see if another instance of the process is already running without parsing through ps output or rummaging around in the /proc pseudo-filesystem. This solution involves the return value of the kill() system call, but instead of sending a SIGTERM, SIGHUP, or other standard signal against the process we wish to check, we send SIG_0. This instructs kill() to return zero if the process is currently running (that is, if it has an entry in the process table), or a nonzero value if the process is not running or if an error condition is encountered. To illustrate the use of this method to check whether or not the psad daemon is running on the local system, we can use the following commands:
# kill 0, 'cat /var/run/psad/psad.pid'
# echo $?
0
Since zero was returned, we know that psad is currently running on the system.
To see how the kill() system call is actually used and what it returns, use the strace utility. Note that the = 0 on the last line is the return value of kill().
# strace kill −0 'cat /var/run/psad/psad.pid' 2>&1 |grep kill
execve("/bin/kill", ["kill", "−0", "7940"], [/* 43 vars */]) = 0
kill(7940, SIG_0) = 0
Lastly, any mature programming language offers an interface to the kill() system call, and here, I'll illustrate how we can use Perl to detect whether or not psad is currently running. (The programmatic usage of the kill() system call is derived from the line in bold below.)
# cat pid.pl
#!/usr/bin/perl -w
open PIDFILE, "< /var/run/psad/psad.pid" or die $!;
while ( if (/(\d+)/) { print "psad pid: $1 is running...\n" if kill(0, $1); } } close PIDFILE; # ./pid.pl psad pid: 7940 is running... For example, if no iptables rules are currently instantiated, fwcheck_psad will generate an email like this (the hostname on the system is iptablesfw): [-] You may just need to add a default logging rule to the INPUT chain on iptablesfw. For more information, see the file "FW_HELP" in the psad sources directory or visit: http://www.cipherdyne.org/psad/fw_config.html [-] You may just need to add a default logging rule to the FORWARD chain on iptablesfw . For more information, see the file "FW_HELP" in the psad sources directory or visit: http://www.cipherdyne.org/psad/fw_config.html Note Because iptables policies can be quite complex, the parsing ability of the IPTables::Parse module is not always sufficient to determine