| |||||||||||||
Distributed brute force ssh attacksDistributed brute force ssh attacksPosted Oct 22, 2009 10:25 UTC (Thu) by Tuxie (guest, #47191)Parent article: Distributed brute force ssh attacks
Why not just make each try slower after each fail?
After first fail, the second try will take 2 seconds (plus the time it normally takes). The third try will take 4 seconds. The fourth 8 seconds, and so on...
(Log in to post comments)
Distributed brute force ssh attacks Posted Oct 22, 2009 10:54 UTC (Thu) by ikm (subscriber, #493) [Link]
Problem is, each new attempt is made from a different IP. Therefore you can't determine if a particular request is a successive attempt or a new, unrelated login.
Distributed brute force ssh attacks Posted Oct 22, 2009 13:13 UTC (Thu) by Felix.Braun (subscriber, #3032) [Link]
On my server I still see lots of attempts coming from the same IP-address. I presume the individual drones of a botnet don't coordinate their attacks, so they wouldn't be able to achive a sufficient attack rate per minute to brute-force the passwords.
Unrelated IP addresses Posted Oct 22, 2009 22:05 UTC (Thu) by man_ls (subscriber, #15091) [Link] Then delay the failures (even from unrelated IP addresses), but not successful logins. And add a max time of, say, 20s. If you enter your password wrong then you suffer a penalization of at most 20 seconds; if you do it right then you enter immediately. This should be enough to make brute force attacks impractical.
Unrelated IP addresses Posted Oct 22, 2009 22:14 UTC (Thu) by ikm (subscriber, #493) [Link]
No, I'm afraid this won't hinder distributed attacks a lot. Each bot is probing a lot of different servers simultaneously, but for each server it tries e.g. one login per hour. That's the idea behind distributed brute force attacks. The 20s penalization won't change anything much -- albeit it would perhaps make bots consume more resources (tcp connections stay open longer, probing processes sleep and exist longer).
Unrelated IP addresses Posted Oct 24, 2009 14:45 UTC (Sat) by NAR (subscriber, #1313) [Link]
I think a brute force attack with one attempt per hour is not a problem if the passwords are at least half-decent. The password will expire long before the brute force attack succeeds.
Unrelated IP addresses Posted Oct 24, 2009 15:38 UTC (Sat) by ikm (subscriber, #493) [Link]
Multiply by 1000 nodes and you get 1000 attempts per hour.
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.
Unrelated IP addresses Posted Oct 26, 2009 16:07 UTC (Mon) by giraffedata (subscriber, #1954) [Link] 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.
Unrelated IP addresses Posted Oct 26, 2009 19:19 UTC (Mon) by ikm (subscriber, #493) [Link]
We're talking about the same kind of attack: someone wants into your system. It's YOUR host which gets probed 1000 times per hour. It's just that it's done by 1000 different machines simultaneously -- each of which probing only once an hour.
Unrelated IP addresses Posted Oct 26, 2009 19:35 UTC (Mon) by NAR (subscriber, #1313) [Link]
But after the third try, the user will be locked out for 2 minutes, so the next 33 tries will be in vain, even if the attacker would guess the right password...
Unrelated IP addresses Posted Oct 26, 2009 19:45 UTC (Mon) by ikm (subscriber, #493) [Link]
That does make sense. Though you'd have to combine it with IP-based banning too. Otherwise it'd be really easy to DoS a specific person one happens to dislike, and also bots tend to try many different user names, not just one over and over again.
Unrelated IP addresses Posted Oct 26, 2009 22:26 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
but the attacking IP address doesn't try again for 60 min, so it's not affected by your block.
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.
Unrelated IP addresses Posted Nov 2, 2009 12:16 UTC (Mon) by robbe (guest, #16131) [Link]
Penalising just the wrong attempts won't work. If a successful attempt
normally gives an ACK after 1s, the attacker won't bother to hang around for your NACK if you delay it for 5s or 60s or whatever. Therefore all decent systems delay *both* answers.
You probably have to limit the delay to one minute or less, or your
Distributed brute force ssh attacks Posted Oct 22, 2009 21:00 UTC (Thu) by shane (subscriber, #3335) [Link]
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.
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.
It boils down to
This works very well and looks pretty clean to me.
Reference:
Best Regards,
|
|||||||||||||