| |||||||||||||
Unrelated IP addressesUnrelated IP addressesPosted Oct 22, 2009 22:05 UTC (Thu) by man_ls (subscriber, #15091)In reply to: Distributed brute force ssh attacks by ikm Parent article: Distributed brute force ssh attacks 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.
(Log in to post comments)
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
|
|||||||||||||