Linux Firewalls - Michael Rash [88]
[+] Writing 144.202.X.X to socket. psad will remove the IP address within
5 seconds.
Indeed, the running psad daemon expires the blocking rules:
Mar 6 01:34:51 iptablesfw psad: removed iptables auto-block against 144.202.X.X
Flushing All Blocking Rules
Sometimes achieving basic network connectivity can be problematic, and in some circumstances, these connectivity issues can be exacerbated by an active response mechanism. In addition to offering the ability to whitelist certain IP addresses and networks, an active response mechanism should also make it easy to remove its influence over the network. In the case of psad, with its dynamically generated iptables rules, this implies there should be a way to easily remove all rules within the custom psad chains. The psad --Flush command does just this:
[iptablesfw]# psad --Flush
[+] Flushing psad chains via running psad daemon within 5 seconds.
Once the CHECK_INTERVAL timer expires, the running psad daemon generates the following syslog messages:
Mar 6 01:35:37 iptablesfw psad: flushing existing psad Netfilter auto-response chains
Mar 6 01:35:37 iptablesfw psad: flushed: PSAD_BLOCK_INPUT
Mar 6 01:35:37 iptablesfw psad: flushed: PSAD_BLOCK_OUTPUT
Mar 6 01:35:37 iptablesfw psad: flushed: PSAD_BLOCK_FORWARD
Integrating with Swatch
The Swatch utility (http://swatch.sourceforge.net), written by Todd Atkins, allows Perl regular expressions to be applied to arbitrary logfiles. Swatch can be used to monitor all sorts of log messages that are reported via syslog. Probably one of the most common applications of Swatch is to look for authentication failures reported by an SSH daemon via syslog, as shown here:
Mar 7 01:20:20 iptablesfw sshd[31403]: error: PAM: Authentication failure for root
from 192.168.10.3
Now, we configure Swatch to execute psad with the appropriate command-line arguments to block any IP address that commits the above authentication failure. This implies that we need a regular expression that uses a back reference to pull the IP address out of such a syslog message and use the contents of the back reference in the psad command. The two boldface lines in the Swatch configuration file here accomplish this:
#
# Swatch -> psad active response for SSH bad logins
#
watchfor /sshd.*Authentication\s*failure.*((?:[0-2]?\d{1,2}\.){3}[0-2]?\d{1,2})/
echo mode=red
exec "/usr/sbin/psad --fw-block-ip $1"
With Swatch configured to our liking, we'll fire it up from the command line. The following code listing shows how it reacts to the first authentication failure message:
[iptablesfw]# ./swatch --config-file swatchrc.sshauth --tail-file /var/log/auth.log
*** swatch version 3.1.1 (pid:3543) started at Tue Mar 6 01:34:00 EST 2007
Mar 7 01:55:20 iptablesfw sshd[31403]: error: PAM: Authentication failure for root
from 192.168.10.3
Can't ignore signal CHLD, forcing to default.
[+] Writing 192.168.10.3 to socket. psad will add the IP address
within 5 seconds.
The running psad daemon dutifully writes the following syslog message:
Mar 7 01:55:25 sshdhost psad: added iptables auto-block against 192.168.10.3 for 3600
seconds
This example illustrates how the response features in psad can be used to block an IP address based on authentication failures against OpenSSH. These failures are most likely not detectable with an IDS that is not privy to the unencrypted session,[47] so this example highlights the power derived from tying a network response to suspicious activity recorded in a logfile.
Integrating with Custom Scripts
Instead of using the psad command line to issue iptables rule addition or deletion directives against IP addresses, a program can interface directly with a running psad daemon via the /var/run/psad/auto_ipt.sock Unix domain socket. The following Perl script (sshauth.pl) monitors the /var/log/auth.log file for 20 successive authentication failures from the same IP address. If this threshold is met or exceeded, the script sends the command add IP over the socket to the running psad