Re: [PLUG] Brute force SSH attack confounds defenders

[bergman@merctech.com]

In the message dated: Wed, 10 Dec 2008 13:18:41 EST,
The pithy ruminations from "Douglas Muth" on 
<Re: [PLUG] Brute force SSH attack confounds defenders> were:
=> On Wed, Dec 10, 2008 at 12:00 AM, John Von Essen <john@essenz.com> wrote:
=> >
=> > But... if we all leave SSH open with strong passwords, the brute force
=> > bots will have a ton of hosts to waste their time on, and eventually brute
=> > force ssh will become boring and a waste of cpu time.
=> >
=> 
=> Why not do the following:
=> 
=> 1) Move "real" SSH service to another port

Philosophically, I hate that answer. It's really just security by obscurity. 
Without adding in things like port knocking[1], it still means you're 
vulnerable to port scanning. For the purpose of building a honeypot[2] I can 
sort of understand it. In a production environment, with any significant user 
base, it doesn't scale.

=> 
=> 2) Build a "fake SSH" daemon to listen on port 22, that does nothing
=> but /dev/null information that is sent to it and return an "invalid
=> password" response on every login attempt.
=> 
=> #2 wouldn't take up a whole lot of memory or CPU, since it really
=> isn't *doing* anything.  But it would go a long way in wasting the
=> time of botnets that are trying to get in.

I'd actually return a high number (10%?) of (fake) successful password
responses. 

Assuming that the botnet is collecting the login/password pairs that have 
succeeded, this reduces the value of their database when they go 
to use or resell the data.

Also, if the botnet is "smart" enough, after you return a (fake) successful 
login message, the login attempts should stop. (Modulo any residual attempts 
that are queued on the compromised bots, before the botnet C&C machines update 
the zombies.)

=> 
=> For bonus points, such a "fake" daemon could also have options to
=> sleep() for an abnormally long time before giving out an "invalid
=> password" response, further tying up attacking machines.

Absolutely. You're thinking something like the iptables "tarpit" rules[3].

=> 
=> I wouldn't necessarily want to do this on a production server at the

I absolutely wouldn't do any of this on a production server.

=> office, but it's the sort of thing I would have no problem installing
=> on my personal mail server.

For fun, maybe...

Mark


	[1] http://en.wikipedia.org/wiki/Port_knocking
	[2] http://en.wikipedia.org/wiki/Honeypot_(computing)
	[3] http://www.securityfocus.com/infocus/1723


=> 
=> -- Doug
=> ___________________________________________________________________________
=> Philadelphia Linux Users Group         --        http://www.phillylinux.org
=> Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
=> General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug
=> 



___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug