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

[Matty]

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/

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

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