[Intrusions] Locking down SSH, dictionary attacks

Smith, Donald Donald.Smith at qwest.com
Sat Mar 11 22:44:47 GMT 2006

That certainly helps.
Root should not be allowed to login directly in most cases.
However most ssh bruteforce scanning I am seeing they compromise a non-admin account and use one of the hundreds of local priv escalations to gain root:(
donald.smith at qwest.com giac


From: intrusions-bounces at lists.sans.org on behalf of bschnzl at cotse.net
Sent: Fri 3/10/2006 2:23 PM
To: Andrew Daviel
Cc: intrusions at incidents.org
Subject: Re: [Intrusions] Locking down SSH, dictionary attacks

Do not allow root to log in remotely.  Require sudo(8), and limit
abilities through that. 

On 10 Mar 2006, this text appeared purporting to belong to Andrew

Date sent:              Fri, 10 Mar 2006 12:33:11 -0800 (PST)
From:                   Andrew Daviel <andrew at andrew.triumf.ca>
To:                     intrusions at incidents.org
Subject:                [Intrusions] Locking down SSH, dictionary attacks
Send reply to:          "Intrusions List \(GCIA Practicals\)" <intrusions at lists.sans.org>
        <mailto:intrusions-request at lists.sans.org?subject=unsubscribe>
        <mailto:intrusions-request at lists.sans.org?subject=subscribe>
> 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
> user A:
> - can use keys or password
> - can connect from anywhere
> users B,C:
> - can connect from anywhere with keys
> - can connect from 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
> _______________________________________________
> Intrusions mailing list
> Intrusions at lists.sans.org
> http://www.dshield.org/mailman/listinfo/intrusions

Bill Scherr IV, GSEC, GCIA
EWA / Information & Infrastructure Technologies
office:         703-478-7608
cell:   571-262-1428

Intrusions mailing list
Intrusions at lists.sans.org

More information about the Intrusions mailing list