Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Distributed brute force ssh attacks
Posted Oct 22, 2009 10:54 UTC (Thu) by ikm (subscriber, #493)
Posted Oct 22, 2009 13:13 UTC (Thu) by Felix.Braun (subscriber, #3032)
Unrelated IP addresses
Posted Oct 22, 2009 22:05 UTC (Thu) by man_ls (subscriber, #15091)
Posted Oct 22, 2009 22:14 UTC (Thu) by ikm (subscriber, #493)
Posted Oct 24, 2009 14:45 UTC (Sat) by NAR (subscriber, #1313)
Posted Oct 24, 2009 15:38 UTC (Sat) by ikm (subscriber, #493)
I think though, too, the password lists are limited to some most common passwords only (e.g. 123, qwerty and so on). I think in that sense server-side password auditing would be enough to secure the host.
Posted Oct 26, 2009 16:07 UTC (Mon) by giraffedata (subscriber, #1954)
Multiply by 1000 nodes and you get 1000 attempts per hour.
And divide that by 1000 nodes and you get 1 attempt per hour, and since my actions will secure 1 of the 1000 nodes, that's the number that matters for me.
I think we're talking about two kinds of hacks: 1) someone wants into my system; 2) someone wants into any system. In (2), there's no reason for the hacker to hit my system frequently, but there's also correspondingly less chance he'll get into my system.
Hey another statistical reality: the user's password change interval is irrelevant to the probability of successfuly guessing. The expected number of guesses it takes is the same no matter how many how times the password changes while the guessing is going on.
Posted Oct 26, 2009 19:19 UTC (Mon) by ikm (subscriber, #493)
Posted Oct 26, 2009 19:35 UTC (Mon) by NAR (subscriber, #1313)
Posted Oct 26, 2009 19:45 UTC (Mon) by ikm (subscriber, #493)
Posted Oct 26, 2009 22:26 UTC (Mon) by dlang (✭ supporter ✭, #313)
unless you say you are locking the _user_ out from any IP address for 2 min.
if that's the case an attacker will just DOS you so that you can't login to the box yourself.
Posted Nov 2, 2009 12:16 UTC (Mon) by robbe (guest, #16131)
You probably have to limit the delay to one minute or less, or your
legitimate users will just declare your host broken.
Posted Oct 22, 2009 21:00 UTC (Thu) by shane (subscriber, #3335)
We've got over 550 IP addresses blocked in the last couple of months on a server I share with some friends.
Posted Oct 25, 2009 11:46 UTC (Sun) by cortana (subscriber, #24596)
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.
Posted Oct 25, 2009 22:50 UTC (Sun) by jordanb (guest, #45668)
Posted Nov 17, 2009 8:34 UTC (Tue) by Brenner (subscriber, #28232)
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):
2) adding these two lines to /ets/hosts.deny (with denyhosts configured to update the file /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.
after the paragraph starting with "Eventually, I found a hack to realize it. It is quit simple."
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds