4 ms·

What's the problem with brute-force attacks? Why can't a simple incorrect-password timeout prevent them?

by Jabbles 16y ago

dopkew 16y ago
If the encrypted private-key is stolen, then it can be stored on a powerful computer and brute-force attacks can be applied on it. Even if symmetric encryption is used to encrypt the private-key ( which makes straight-on brute-force attacks unfeasible), if the user uses an easy passphrase to encrypt the private-key, then the private-key can be compromised. From Wikipedia: In the case of an offline attack where the attacker has access to the encrypted material, he can try key combinations at his leisure without the risk of discovery or interference. However database and directory administrators can take countermeasures against online attacks, for example by limiting the number of attempts that a password can be tried, by introducing time delays between successive attempts and locking accounts out after unsuccessful logon attempts. Website administrators may prevent a particular IP address from trying more than a predetermined number of password attempts against any account on the site.
mike-cardwell 16y ago
That would be ok against the brute force attacks which involve one account and lots of passwords. It doesn't work so well against brute force attacks which involve just a few passwords and lots of accounts on lots of servers.
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 ago
  Why 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 ago
    The number of connections is equal, but it is - at least in theory - possible to set a lower timeout when using private keys.
- bradleyland 16y ago
  We 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 ago
  There 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.
qjz 16y ago
I've nearly eliminated the problem with brute force attacks, but it's quite multilayered. I use public key authentication with strong passphrases, but leave password authentication enabled for the standard port, so I'll focus on that as the weak link. Assuming high quality passwords and nonobvious user names on systems where password authentication is allowed, set "PermitRootLogin no", "MaxAuthTries 3", and explicitly list users: "AllowUsers fooz1 barx2 cary3" in sshd_config. This is usually enough to foil most random brute force attacks seeking low hanging fruit. After that, the main problem is log noise and the fact that the attack has been slowed, but not stopped. My next line of defense is a short-lived block using the recent module in my iptables startup script (on Linux): IPTABLES=/usr/sbin/iptables # only allow up to 2 connections in a 15 second period $IPTABLES -A INPUT -p tcp --dport 22 \ -m state --state NEW \ -m recent --update --seconds 15 --hitcount 2 \ -j DROP $IPTABLES -A INPUT -p tcp --dport 22 \ -m state --state NEW \ -m recent --set \ -j ACCEPT That's enough to really slow down brute force attacks without locking out fat-fingered users for too long. Finally, I use fail2ban to block persistent attacks for 6 hours after 8 failures/hr in jail.conf: # Failed login attempts against SSH (port 22) [ssh-iptables] enabled = true filter = sshd logpath = /var/log/messages maxretry = 8 bantime = 21600 findtime = 3600 action = iptables[name=SSH, port=ssh, protocol=tcp] sendmail-whois-lines[name=SSH, dest=admin, logpath=/var/log/messages] This allows me to identify attacks and penalize them hard without affecting real users. This basically leaves a DoS as the only threat, and only if you're using the same IP address as the attacker. It may look complicated, but it only takes a few minutes to set up and doesn't require using a nonstandard port (which you can do to further harden the system, along with other things). In my experience, this has been enough to thwart brute force attacks against ssh.

What's the problem with brute-force attacks? Why can't a simple incorrect-password timeout prevent them?

by Jabbles 16y ago

What's the problem with brute-force attacks? Why can't a simple incorrect-password timeout prevent them?

If the encrypted private-key is stolen, then it can be stored on a powerful computer and brute-force attacks can be applied on it. Even if symmetric encryption is used to encrypt the private-key ( which makes straight-on brute-force attacks unfeasible), if the user uses an easy passphrase to encrypt the private-key, then the private-key can be compromised. From Wikipedia: In the case of an offline attack where the attacker has access to the encrypted material, he can try key combinations at his leisure without the risk of discovery or interference. However database and directory administrators can take countermeasures against online attacks, for example by limiting the number of attempts that a password can be tried, by introducing time delays between successive attempts and locking accounts out after unsuccessful logon attempts. Website administrators may prevent a particular IP address from trying more than a predetermined number of password attempts against any account on the site.

mike-cardwell 16y ago

That would be ok against the brute force attacks which involve one account and lots of passwords. It doesn't work so well against brute force attacks which involve just a few passwords and lots of accounts on lots of servers.

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 ago
Why 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 ago
  The number of connections is equal, but it is - at least in theory - possible to set a lower timeout when using private keys.
bradleyland 16y ago
We 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 ago
There 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.

qjz 16y ago

I've nearly eliminated the problem with brute force attacks, but it's quite multilayered. I use public key authentication with strong passphrases, but leave password authentication enabled for the standard port, so I'll focus on that as the weak link. Assuming high quality passwords and nonobvious user names on systems where password authentication is allowed, set "PermitRootLogin no", "MaxAuthTries 3", and explicitly list users: "AllowUsers fooz1 barx2 cary3" in sshd_config. This is usually enough to foil most random brute force attacks seeking low hanging fruit. After that, the main problem is log noise and the fact that the attack has been slowed, but not stopped. My next line of defense is a short-lived block using the recent module in my iptables startup script (on Linux): IPTABLES=/usr/sbin/iptables # only allow up to 2 connections in a 15 second period $IPTABLES -A INPUT -p tcp --dport 22 \ -m state --state NEW \ -m recent --update --seconds 15 --hitcount 2 \ -j DROP $IPTABLES -A INPUT -p tcp --dport 22 \ -m state --state NEW \ -m recent --set \ -j ACCEPT That's enough to really slow down brute force attacks without locking out fat-fingered users for too long. Finally, I use fail2ban to block persistent attacks for 6 hours after 8 failures/hr in jail.conf: # Failed login attempts against SSH (port 22) [ssh-iptables] enabled = true filter = sshd logpath = /var/log/messages maxretry = 8 bantime = 21600 findtime = 3600 action = iptables[name=SSH, port=ssh, protocol=tcp] sendmail-whois-lines[name=SSH, dest=admin, logpath=/var/log/messages] This allows me to identify attacks and penalize them hard without affecting real users. This basically leaves a DoS as the only threat, and only if you're using the same IP address as the attacker. It may look complicated, but it only takes a few minutes to set up and doesn't require using a nonstandard port (which you can do to further harden the system, along with other things). In my experience, this has been enough to thwart brute force attacks against ssh.