Distributed brute force ssh attacks [LWN.net]

Distributed brute force ssh attacks

Posted Oct 22, 2009 21:00 UTC (Thu) by shane (subscriber, #3335)
In reply to: Distributed brute force ssh attacks by Tuxie
Parent article: Distributed brute force ssh attacks

That may or may not be a good idea, but today you can do "aptitude install denyhosts" on any Debian or Ubuntu system and have SSH brute-force protection in a couple of minutes.

We've got over 550 IP addresses blocked in the last couple of months on a server I share with some friends.

(Log in to post comments)

Distributed brute force ssh attacks

Posted Oct 25, 2009 11:46 UTC (Sun) by cortana (subscriber, #24596) [Link]

Why doesn't openssh have this kind of feature built in by default? I've always been put off tools such as denyhosts or its alternatives because they seem, well, a bit hacky.

You have to have a process continuing to run in the background; if it somehow crashes then you lose the protection.

They work by tailing /var/log/auth.log. That requires you to have configured syslog to log to the right place, and you have to be careful to synchronise the reloading of the log file with any log rotation that takes place.

ISTR a bug a while back where a remote attacker could take control of the tool by using a specially crafted user name, to exploit a bug in the regular expression parsing library that the program used.

I'd feel much safer if the mechanism for detecting these kind of attacks was built into OpenSSH itself, leaving the policy up to third party plugins.

Distributed brute force ssh attacks

Posted Oct 25, 2009 22:50 UTC (Sun) by jordanb (guest, #45668) [Link]

I use iptables. I suppose my ssh protection rules could be flushed, but it's nothing like having a daemon die.

Distributed brute force ssh attacks

Posted Nov 17, 2009 8:34 UTC (Tue) by Brenner (subscriber, #28232) [Link]

> You have to have a process continuing to run in the background; if it somehow crashes then you lose the protection.

With DenyHosts, you do not have to have a daemon running. You do not even have to use or change iptables rules. You can do all you want with tcpwrappers using the relatively unknown spawn feature.

If ssh comes from an authorized IP (listed in /etc/hosts.allow): allow sshd to ask password.
If ssh comes from a banned IP (listed in eg /etc/hosts.blocked): close connection right away.
If ssh comes from another IP, spawn a denyhost process (just for this connection) that will update the list of banned IPs. Then allow sshd to ask password

It boils down to
1) adding known good IPs to /etc/hosts.allow (to avoid being locked out):
sshd:some.good.ip.address
2) adding these two lines to /ets/hosts.deny (with denyhosts configured to update the file /etc/hosts.blocked)
sshd:/etc/hosts.blocked
sshd:ALL:spawn /usr/bin/denyhosts.py --purge -c /etc/denyhosts.cfg: allow

This works very well and looks pretty clean to me.

Reference:
http://pubnotes.wordpress.com/2007/10/14/securing-ssh-wit...
after the paragraph starting with "Eventually, I found a hack to realize it. It is quit simple."

Best Regards,
Antoine