[ale] any suggestions on an automated method for blocking repeated failed ssh login attempts?

[Michael H. Warfield]

On Thu, 2010-12-23 at 18:34 -0500, Matty wrote:
> On Thu, Dec 23, 2010 at 3:29 PM, Michael H. Warfield <mhw at wittsend.com> wrote:
> > I guess I should chime in with my obligatory 2 euros on this like I
> > always do...
> >
> > I've read all the responses to this so far and this issue comes up
> > periodically, just like clock work, and everyone comes up with these
> > same old ideas.  Simple fact is that ssh is often the most scanned for
> > service on the network and, when it's found, these chumps throw a
> > mindlessly simplistic brute force attack at it.  Much of it comes out of
> > China and some of it comes out of Russia and some of it comes out spread
> > out across Comcast (and other US providers).  I track these things and I
> > even have honeypots that dump out all the passwords they attempt.  To
> > sum it up in one word...  BORING!  Not even once have I seen them even
> > attempt those asinine Debian weak keys.  No originality in those attacks
> > what so ever.  Not even any interesting backdoor keys for the trojaned
> > varieties I know about.  Sigh...
> >
> > If you are already running a secure deployment of ssh, this is nothing
> > more than noise in your logfiles.  Period.  If you care that much about
> > the noise or you are that hurting in /var/log for space, then fine.  But
> > be clear about it.  You're not doing this for security.  You're doing it
> > purely for the noise.
> >
> > If you are NOT running a secure ssh setup, then these other measures are
> > both unnecessary and insufficient.  All they do is enable you to
> > continue to run ssh insecurely.  That's not security.  That's not
> > security in depth.  That's security through obscurity and we know what
> > that's worth.  I know there are plenty of people on this list who thinks
> > this accomplishes something, but if you are not otherwise secure, you
> > can still be owned.
> >
> > Simplest and most effective thing you can do is simply TURN OFF REMOTE
> > PASSWORDS ENTIRELY!  Use strong ssh authentication keys and prohibit
> > reusable passwords.  If you don't do this and someone really wants to
> > get you, there are plenty of distributed ssh scanning tools around.
> > That has the additional advantage that now, it's easier to use as well.
> > A little work up front and you don't have to worry about those passwords
> > any more, you just worry about keeping that private key safe.  If you
> > can't do that much, none of the rest of this stuff is worth a flip
> > anyways.
> >
> > Port knocking, moving the port, and all that other noise is just
> > avoiding really dealing with the security of your setup.  If you are
> > secure, you don't need them and you can just ignore the noise.  If you
> > are not safe, they don't make you safe, it's just a case of the
> > emperor's new cloths.
> >
> > I know I'm doing my IPv6 talk next month for ALE.  Maybe I need to
> > schedule my talk on "Securing the Secure Shell" some time in the next
> > few months as well.  I gave that talk in front of AUUG a while back but
> > I don't think I've delivered it at ALE before.

> As always, awesome reply Mike! What are your thoughts on adding delays
> after login failures?:

> http://prefetch.net/blog/index.php/2010/08/31/forcing-your-linux-users-to-wait-after-they-input-an-incorrect-password/

Login delays already exist and generally multiple levels.  You get
moderate quick response for the first couple and then it takes a long
time for one when the daemon basics goes "bugger off" and respawns a new
one.  If you don't allow passwords at all, it doesn't matter at all.  It
MIGHT cut down on some network bandwidth but these are seriously small
exchanges.  Still, having 10,000 attempts (even totally destined to
failure) in a couple of seconds is not a good thing.

> I've read the pros and cons of each, and am curious if this is
> considered more noise?

There are some valid concerns wrt the bandwidth issue.  There are some
valid concerns wrt the log noise and volume.  No argument there.  I have
no particular objection to delays since they don't impact legitimate
connections, especially when you only allow auth keys.  They either work
or they don't and you either have no delay or you're just totally
screwed.  Delays have great value in other protocols (like smtp) and I'm
not against using tools like delays and port knocking (or port sentry)
where they can do some good.  I just don't think they add anything to
the ssh protocol that the ssh protocol itself can't do better.

> Peace,
> - Ryan
> --
> http://prefetch.net
> 

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20101224/cfb5cad3/attachment.bin