Rundown on SSH Brute Force Attacks

An anonymous reader writes "Whitedust has a very interesting article on the recent SSH brute force attacks. The article goes into depth on how to monitor these attackes and to report them to the authorities. It also discusses various tools that are available. According to the article, mostly compromised Linux systems from outside of North America are responsible for the attacks. Even the author's DSL connection was getting break-in attempts."

Comments

As always...

[jsight]

If possible, restrict access by source IP address, limit the user accounts w/ SSH access, and don't allow remote root logins.

Another step to improve security if there are very few users is just to ONLY allow public key authentication. I've never seen such a box compromised remotely.

Re:As always...

[MyDixieWrecked]

I run a webserver out of my room for a dozen or so of my friends.

I've just started disabling shell access to the users of my system by default. If they want to log in with ssh, they have to explicitly enable it from the web-based front-end.

I tried forcing public-key authentication, but I kept running into trouble when I was away from home and needed to log in from someone else's computer.

I've got some explicit rules in iptables, also, where I've been blocking entire IP blocks (ie- I've got several countries blocked completely). Whenever I notice a string of failed login attempts, I do an ARIN lookup of that IP block. So far, nearly every attack has come from korea, so I 've been blocking off those addresses as they come.

I should probably only allow ssh access to american addresses... I know one should always make time for security, but I just haven't had the time to look into how to do that.

also, I've got root login enabled only because I've got a backup script running that mirrors /home and a couple other directories over to my backup server. But root has a very, very strong password. took me weeks to memorize it.

Re:As always...

[clymere]

try putting your public keys on a usb thumb drive. Toss putty on there as well, and you've got what you need no matter where you're at ;)

Re:As always...

[Homology]

If possible, restrict access by source IP address, limit the user accounts w/ SSH access, and don't allow remote root logins.

Another step to improve security if there are very few users is just to ONLY allow public key authentication. I've never seen such a box compromised remotely.

No kidding? By disallowing password authentication you've stopped the script kiddies dead in their tracks. As for disallowing root access, here are some words from an OpenBSD developer:

... All unmitigated horseshit. Sorry. Look I use sudo, and I like it. but it is no substitute for allowing root login to a box, and is no substitute for "su", Sorry. They are different. I don't want to add a billion sudoable local accounts to run boxen in a distributed authentication environment. I want "root" local, and be done with it. I want root exposed if someone knows the root password, not if someone knows the root password or fourteen other idiot's passwords that are used every day. That's not more secure. If you want a useful diff to help stop this ridiculous discussion from propping up every little while. Here's what I propose: ....

Saying "don't login as root" is horseshit. It stems from the days when people sniffed the first packets of sessions so logging in as yourself and su-ing decreased the chance an attacker would see the root pw, and decreast the chance you got spoofed as to your telnet host target, You'd get your password spoofed but not root's pw. Gimme a fucking break. this is 2005 - We have ssh, used properly it's secure. used improperly none of this 1989 bullshit will make a damn bit of difference. -Bob

Re:As always...

[Ann Elk]

Moral of the story? AllowUsers is a really good idea :-P

And running Apache as root is a Really Bad Idea (tm).

Re:As always...

[feronti]

Speaking of which, why is it said not to login as root over SSH? The only plausible reason I've ever heard is that the encryption is stronger after the login is complete, so your root password is safer if you 'su' to root after logging into another account.

I think it may be due to an old vulnerability. In versions of OpenSSH earlier than 2.5, you can discover the length of the password using traffic analysis. Basically you look for the following sequence of packets:

C: 1 packet (s)
S: 1 packet (echo s)
C: 1 packet (u)
S: 1 packet (echo u)
C: 1 packet (newline)
S: 1 packet (echo newline)
S: 10 packets ("Password: ")
C: x packets (the password)
C: 1 packet (newline)
S: 1 packet (echo newline)

Basically, since the x packets aren't echoed, we know that they are the password. We don't know the contents of the packets, but we now know the length of the password, which can help tremendously in brute force and dictionary attacks (we can eliminate a huge portion of the search space by only searching passwords of length x).

This technique worked for both SSH-1 and SSH-2 protocols. For more detail, (and a better, more accurate description of how the vulnerability worked) you can read the original security advisory.

Another problem with logging in directly as root is that you no longer can audit who is logging in as root in an environment where multiple users have root access.

Easy fix

[Anonymous Coward]

i have had this on a number of occasions.. i just set the max auth attepts to 4, this renders the attempts useless

Re:Easy fix

[tek.net-ium]

RTFM. sshd_config(5) MaxAuthTries Specifies the maximum number of authentication attempts permitted per connection. Once the number of failures reaches half this value, additional failures are logged. The default is 6. Crackers will just open up more connections.

DenyHosts

[roubles]

I use DenyHosts http://denyhosts.sourceforge.net/ from a cronjob. It detects any suspicious logins in /var/log/auth.log and adds the ip address of the user into the /etc/hosts.deny file. It also sends me an email telling me the IP address that was last added to the file.

Lately I have been getting atleast 1 hack attempt a day on my personal computer connected to the internet over a cable connection. On weekends I get more.

Just this morning I had two ssh dictionary attacks. DenyHosts caught them both.

Use another port

[objorkum]

Use another port than 22. I have not noticed one single bruteforce attempt after I did that.

why not disable passwords entirely?

[toby]

If you only need access from a limited set of machines which can have pre-generated keys, you can disable password authentication entirely (PasswordAuthentication no) and use RSA instead, with optional passphrase. In addition to PermitRootLogin no, I suggest judicious use of AllowUsers in sshd_config.

Dynamically blocking with iptables

[meisenst]

I tried to post this in the talkback on the article but it got horribly munged.

Here are the iptables rules I use to dynamically stop this kind of thing (with a good degree of success):

# SSH
-A PREROUTING -m tcp -p tcp -d $EXTERNAL --dport 22 -m recent --rcheck --hitcount 3 --seconds 600 -j LOG --log-prefix "SSH attack: "
-A PREROUTING -m tcp -p tcp -d $EXTERNAL --dport 22 -m recent --rcheck --hitcount 3 --seconds 600 -j DROP
-A PREROUTING -m tcp -p tcp -d $EXTERNAL --dport 22 -m recent --set -j DNAT --to-destination $INTERNAL:22
-A OUTPUT -m tcp -p tcp -d $EXTERNAL --dport 22 -j DNAT --to-destination $INTERNAL:22

Your mileage may vary. This blocks attempts for 1 minute after 3 attempts (successful or failed, so if someone forgets their password, they may trip it as well).

These have been going on for a long time

[angst7]

I've been logging and reporting these attacks since last October (when I first started using BFD). I'm figuring they've been going on for a long long time. A simple install of APF and BFD will keep you from having too much trouble though. That and making sure noone is using easy to guess passwords.

APF and BFD can be got here: RFX Networks.