Re: Locking down SSH, dictionary attacks

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:(
 
 
 
 
[email protected] giac

________________________________

From: [email protected] on behalf of [email protected]
Sent: Fri 3/10/2006 2:23 PM
To: Andrew Daviel
Cc: [email protected]
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 <[email protected]>
To:                     [email protected]
Subject:                [Intrusions] Locking down SSH, dictionary attacks
Send reply to:          "Intrusions List \(GCIA Practicals\)" <[email protected]>
        <mailto:[email protected]?subject=unsubscribe>
        <mailto:[email protected]?subject=subscribe>
Keywords:              
> 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)
> [email protected]
>
> _______________________________________________
> Intrusions mailing list
> [email protected]
> 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
[email protected]
http://www.dshield.org/mailman/listinfo/intrusions



_______________________________________________
Intrusions mailing list
[email protected]
http://www.dshield.org/mailman/listinfo/intrusions