3 ms·
There doesn't appear to be a way to prevent these attacks without locking out legitimate users, making DoS (denial-of-service attacks) trivial (thereby locking
by JoachimSchipper 16y ago
There doesn't appear to be a way to prevent these attacks without locking out legitimate users, making DoS (denial-of-service attacks) trivial (thereby locking out legitimate users), or both. The fundamental problem is that the bad guys can open lots of connections.
Suppose you pause for 10s (after an incorrect password/before checking the password/...). This make it very easy to spawn so many sshd processes that you end up with a DoS (either the system stops spawning sshd processes, locking out everyone, or it is overwhelmed). If you solve this somehow, the bad guys can just open a ton of connections and just wait 10s - they'll need more connections, but they can still saturate the link with login attempts. Blocking IPs after too many connections doesn't help much against botnets; limiting the number of total connections locks out legitimate users; blocking all but specific address blocks locks out legitimate users (at home, or your sysadmin-on-a-holiday trying to fix your system in an internet cafe halfway across the globe.)
In short, anything you do seems to make it easy (easier) to lock out legitimate users. On the other hand, switching to private-key-only or private-key-and-one-time-password-only (or instituting a check on password quality) makes this attack infeasible.
- Jabbles 16y agoWhy doesn't opening a large number of connections to a server secured by private-key work as a DoS attack? Isn't the number of connections required to overload the system the same regardless of security method?
- JoachimSchipper 16y agoThe number of connections is equal, but it is - at least in theory - possible to set a lower timeout when using private keys.
- bradleyland 16y agoWe solved a lot of our "battering ram at the gate" problems by simply moving our SSH port. It seems that most hackers go after low hanging fruit. I'd venture they're looking for people who aren't paying attention to security. The number of ssh auth attempts against our VPSs dropped by at least one order of magnitude when we moved the sshd off the default port. Prior to the move, the fail2ban process ranked third or fourth for CPU time on most of our VPSs behind processes like MySQL or our app server. Now that we've moved ports, it's at 10th or 15th. We're going to implement a port knocking setup as well. That should limit our exposure to targeted attacks.
- deleted 16y ago[deleted]
- dfranke 16y agoThere doesn't appear to be a way to prevent these attacks without locking out legitimate users There is, but I've never seen it implemented. Throttle login attempts by requiring a cryptographic proof-of-work to accompany each attempt. Send the credentials and proof-of-work over UDP so that there's no connection state to hold open. Scale the required amount of work up and down based on the total number of incorrect attempts in the past minute. After a successful login, issue systems a long-lived cookie that exempts them from future proof-of-work requirements. That way, during attacks, legitimate users may experience a longer delay when trying to log in, but only if they've never logged in from that system before, and they can never be locked out completely.
- JoachimSchipper 16y agoProof-of-work systems are really neat, but that's cheating: if you make it optional, it doesn't work at all, and if you make it mandatory, you're arguably not speaking SSH anymore. Besides, I, too, do not recall any actually working implementations.
- dfranke 16y agoI meant this as a general answer to the brute-force-mitigation-without-DoS-vulnerability problem, not as something SSH-specific. Somewhere on my hard drive I have a half-finished draft of a spec for a Kerberos replacement implementing the idea.