[Intrusions] Locking down SSH, dictionary attacks

Andrew Daviel andrew at andrew.triumf.ca
Fri Mar 10 20:33:11 GMT 2006



FYI - just got zapped by one of those SSH exhaustion scanners (again)
1st generation - try 4 accounts e.g. guest/guest against everyone
2nd generation - multiple passwords but slow, doesn't show above noise on
  individual syslogs
3rd generation - who cares, let's blast! 230 tries in 3 minutes

To combat 2nd gen I poll multiple syslogs several times an hour, and any
source going over a couple dozen failures across site is firewalled.
3rd gen got lucky before it was blocked a few minutes later


So, I'm wondering how to lock down SSH a bit more (on Linux, maybe
Solaris, MacOS).
On critical machines with few users, I have disabled password logins -
keys only, and maybe only listen to certain addresses. And on one
standalone machine I have set norootlogin.

But what to do with multiuser machines ? Users are likely to revolt if
told they have to generate keypairs everywhere. (We have been reluctant
to get into Kerberos, and besides I'm not sure without some research
whether it would help. Ditto PAM-based stuff)
What I'd like to do is have different authentication requirements for
root and for user accounts (other than "no root at all")

e.g.

root:
- must use keys, not password
- must connect from 10.4.0.0
user A:
- can use keys or password
- can connect from anywhere
users B,C:
- can connect from anywhere with keys
- can connect from 10.4.0.0 with passwords

... OK, have just RTFM  :-)
and have now set "PermitRootLogin without-password"
which does the most important thing


... just checked my home logs .. darn scanners have 2000 attempts
there, too - so I've just installed my 2nd gen blocking script
as well as fixing root

Guess if I really want address-based filtering I could run a second
server on a different port with different config options, but this
is probably OK for now ...

(if anyone wants my blocking script - simple perl thing using iptables -
mail me. 3rd gen blocking will probably get written, monitoring "tail -f
/var/log/secure" ... should probably add check for success from scanning
source, too)

-- 
Andrew Daviel, TRIUMF, Canada
Tel. +1 (604) 222-7376  (Pacific Time)
security at triumf.ca




More information about the Intrusions mailing list