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

[Michael H. Warfield]

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.

Regards,
Mike

On Thu, 2010-12-23 at 11:45 -0500, Van Loggins wrote:
> > > for some reason it's erroring out on the do command so it never gets to
> > the
> > > iptables command.
> > >
> > > any suggestions, or a better method to do this?
> >
> > fail2ban works pretty well:
> >
> > http://www.fail2ban.org/wiki/index.php/Main_Page
> >
> > - Ryan
> > --
> >
> >> http://prefetch.net
> >
> >
> Fail2ban looks like a great solution. I've downloaded it and all required
> rpm packages and installed it, and have started it up.
> 
> will monitor to see if it is working tomorrow
> 
> Merry Christmas everyone!!
> 
> Van
> 
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo

-- 
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/20101223/c978aee4/attachment.bin