pf suggestions for paced attack

[Paul Mather]

On Mon, 3 May 2010 09:41:10 -0500, John <john at starfire.mn.org> wrote:

> The script kiddies have apparently figured out that we use some
> time-window sensitivity in our adaptive filtering.  From sshd, I've
> been seeing "reverse mapping checking getaddrinfo ... failed" and
> from ftpd (when I have the port open at all, which is rare), I am
> seeing probes at about 27 second intervals.  This stays well below
> the 3/30 (three connections in 30 seconds) sensitivity that I had
> been using.  It took them nearly two and a half hours to make 154
> attemps, but computers are very patient.
> 
> I have now changed the timing window sensivity, but it's to the
> point now where there's a significant probability that someone could
> lock themselves out (temporarily, at least, I do clear these tables
> periodically) if they are having a bit of a fat-finger moment with
> their password.
> 
> Anybody got any superior suggestions?

I'm not claiming these are superior, but they are suggestions. :-)

You might want to try security/sshguard-pf from ports.  It still uses a pf table to do the blocking, but hooks into syslogd and scans for various SSH login failure/abuse messages to add miscreants to that table.  (So, many successful logins won't cause a lockout.)  Sshguard will also block persistent offenders for progressively longer periods.  (Sshguard will also work with /etc/hosts.allow [security/sshguard], IPFW [security/sshguard-ipfw] and IPfilter [security/sshguard-ipfilter].)  Maintenance of the pf table is handled entirely by sshguard.

Also, you could consider instead of having a relatively short time window in which the connection attempts occur, you could try lengthening it, perhaps increasing slightly the number of permitted connection attempts.  So, instead of 3/30, you might use 5/300.  That still allows legitimate users some leeway when typing in incorrect passwords and allows for more multiple successful connections, but forces automated brute force attacks to lengthen their connection attempt delay considerably.  The downside is that if a legitimate user does provoke a lockout, he or she will be locked out for a little longer.

Cheers,

Paul.