pf suggestions for paced attack

[John]

On Mon, May 03, 2010 at 05:29:24PM +0100, Matthew Seaman wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 03/05/2010 15:41:10, John 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?
> 
> Heh.  If the attackers are forced to slow down the probe rate so
> drastically, then their chances of breaking in would be greatly reduced
> /even/ if you were using guessable passwords.  Which I shall assume you
> aren't: key based auth is what you need, or maybe OTP.  You certainly
> should not be relying on rate-adaptive blocking alone to secure your
> system -- it's more a way of preventing your log files from being
> flooded with crap -- and you've limited that quite effectively by
> forcing the attackers to slow down.  I'd not feel any necessity to
> modify the rate settings on your PF rule.
> 
> Anyhow, there is certainly a potential to lock yourself out using
> adaptive blacklisting.  If you know where your friends are going to be
> logging in from, then I'd set up a whitelist.  Something like this:
> 
> (replace with a list of the addresses / ranges you want to allow)
> 
> table <ssh-whitelist> const { \
>     192.0.2.0/24              \
> } persist
> table <ssh-bruteforce> persist
> 
> set skip on lo0
> 
> scrub in
> pass all
> 
> antispoof log quick for lo0
> block drop in log quick from <ssh-bruteforce>
> 
> pass in proto tcp from !<ssh-whitelist> to port ssh \
>      flags S/SA keep state                          \
>      (max-src-conn-rate 3/30, overload <ssh-bruteforce> flush global)
> pass in proto tcp from <ssh-whitelist> to port ssh  \
>      flags S/SA keep state
> 
> 	Cheers,
> 
> 	Matthew
> 
> - -- 
> Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
>                                                   Flat 3
> PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
>                                                   Kent, CT11 9PW

Hi, Matthew.  Indeed, yes, you may not recall, but my rules are
based on a set that I originally got from you, and I do, in fact,
have a white list, which I should have mentioned, but some of my
users are "road warriors" and could be coming from virtually anywhere.
You're right, though - it's time to look into alternatives to
password-based authenticaion.  I think I've taken password-based
protection and rate adaptive rules to their logical limit.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkve+eQACgkQ8Mjk52CukIzpTwCgg/NpuZjR1mnfkcBX169LB5Ih
> ykYAnjQLprMKxMtKW2IfgWNEB5bTt33Q
> =12Jn
> -----END PGP SIGNATURE-----
-- 

John Lind
john at starfire.MN.ORG