Acting on logfiles with sec.pl

Block Brute Force SSH Attacks

The Simple Event Correlator (SEC), or sec.pl, can follow logfiles (written by syslog-ng or other log sources), and trigger actions depending on user defined rules.

swatch is another tool for monitoring logfiles.

Block Brute Force SSH Attacks

Using sec.pl, brute force SSH attacks can be automatically detected and blocked. This section outlines how to detect the brute force attacks, and update a Packet Filter (PF) firewall. Ensure good hosts cannot be blocked, or that blocks timeout, to prevent legitimate users from being locked out. Use expiretable to expire table entries by age.

Other options to stop brute force attacks include pam_tally. Traffic from undesirable sources can also be sent to a slow queue instead of being blocked.

Note that attackers may possess massive numbers of systems—usually compromised Microsoft Windows hosts, organized into a huge zombie cloud—available from which to launch brute force SSH attacks. This means they can make SSH or other password authentication attempts never from the same system twice—in other words, a slow brute zombie attack. However, pointless network traffic from attackers who lack a zombie cloud can still be blocked via logscan methods.

Rules for sec.pl

Rule to match failed SSH logins, and trigger a block. The thresholds are set very low, as the rules are for a personal system that does not see failed logins. The badhost script is available elsewhere.

type=singlewiththreshold
ptype=regexp
pattern=sshd\[\d+\]: Failed password for (?:illegal user )?(.+?) from (\S+)
desc=ssh brute force from $2
action=shellcmd /usr/local/sbin/badhost $2
thresh=3
window=600

To run sec.pl, read the above data via a block.conf configuration file:

$ sec.pl --detach --syslog=local0 \
--conf=/etc/sec/block.conf --input=/var/log/messages

badhosts rules for pf.conf

The firewall must define a badhosts table, and block all traffic from (or even to) the addresses in the table. If using quick, place the following block statements near the top of the pf.conf configuration file. I strongly recommend the use of a goodhosts table, so that spoofed queries do not lock out allowed systems.

table <badhosts> persist

block in quick on $ext_if from <badhosts>
block return out quick on $ext_if to <badhosts>