[Intrusions] Locking down SSH, dictionary attacks

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


Any kind of rate limiting will help.
Security shouldn't be ONE feature. 
Every feature/function that can add to the security of a system should be configured to do so!
 
 
Changing ports only helps in the mass scanning attacks where they only scan port 22.
But that's the VAST majority of what I am seeing. Some of that could be because those being targeted don't want to talk about it. If your targeted it wouldn't be hard to scan for open ports (64k) and then connect to any ports that answered with a version tool that would tell you if it was ssh.
Trivial but expensive in the mass scanning that I have been seeing.
 
 
donald.smith at qwest.com giac

________________________________

From: intrusions-bounces at lists.sans.org on behalf of kenneth gf brown
Sent: Fri 3/10/2006 7:58 PM
To: 'Intrusions List (GCIA Practicals)'
Subject: Re: [Intrusions] Locking down SSH, dictionary attacks






yeah nothing like having
to guess those ports...

if u wish to stay reachable
on standard ports like the real
internet ...

something like
this might work...

iptables -N SSH_CHECK

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_CHECK
iptables -A SSH_CHECK -m recent --set --name SSH
iptables -A SSH_CHECK -m recent --update --seconds 60 --hitcount 4
        --name SSH -j LOG --log-prefix "New info: " --log-level info
iptables -A SSH_CHECK -m recent --update --seconds 60 --hitcount 4
        --name SSH -j DROP






> -----Original Message-----
> From: intrusions-bounces at lists.sans.org
> [mailto:intrusions-bounces at lists.sans.org] On Behalf Of Smith, Donald
> Sent: March 10, 2006 16:05
> To: Intrusions List (GCIA Practicals); intrusions at incidents.org
> Subject: Re: [Intrusions] Locking down SSH, dictionary attacks
>
>
> Switch to a non standard port and publish that port to your
> users. Unless your specifically being targeted you won't see
> any more bruteforce attacks.
>
>
> Security through obscurity WORKS against some worms and other
> tools:) Donald.Smith at qwest.com giac
>
> > -----Original Message-----
> > From: intrusions-bounces at lists.sans.org
> > [mailto:intrusions-bounces at lists.sans.org] On Behalf Of
> Andrew Daviel
> > Sent: Friday, March 10, 2006 1:33 PM
> > To: intrusions at incidents.org
> > Subject: [Intrusions] Locking down SSH, dictionary attacks
> >
> >
> >
> > 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
> >
> > _______________________________________________
> > Intrusions mailing list
> > Intrusions at lists.sans.org
> > http://www.dshield.org/mailman/listinfo/intrusions
> >
>
> _______________________________________________
> Intrusions mailing list
> Intrusions at lists.sans.org
> http://www.dshield.org/mailman/listinfo/intrusions
>
>
> __________ NOD32 1.1170 (20050715) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
>
>

_______________________________________________
Intrusions mailing list
Intrusions at lists.sans.org
http://www.dshield.org/mailman/listinfo/intrusions






More information about the Intrusions mailing list