I am a terrible Sys Admin…

Brute force attacks are *very* rare, unless you happen to have something of high value, such as important data or access to high bandwidth (for use to attack more valuable targets), etc.

The reason why they’re so rare, is due to the fact that the chances of success are very low for decent passwords. This becomes more true if the attacker has to brute force through some public authentication mechanism (like ssh), as this adds connection overhead which adds to the cost of the attack - lowering the chances for success even further.

What is far more common however, is a dictionary attack. This is where the attacker attempts very common usernames with a list of common passwords. It’s hard to have a machine on the net these days without being ‘attacked’ via this scheme.

There are a couple of things you can do to protect yourself from this sort of attack, that are very simple and very effective:

1) In your /etc/ssh/sshd_config allow only users that really need shell to login to your box. Some people are very religious about not allowing root logins, I’m not one of them. Remote exploits are much rarer than local ones, so usually the first attack vector is to get shell, then use a local priv escalation exploit. So, if they don’t need shell, don’t give it to them.

2) Use decent passwords. I know this sounds like a no-brainer, but some people don’t know what that means. A decent password is an alpha-numeric password that is easy to remember and hard to guess. Make it at least 8 chars long, and include at least alphanum and some punctuation. Contrary to some beliefs, ‘decent’ doesn’t mean random, in fact random passwords are usually more of a security problem than good ones. People will write down hard to remember passwords, often in clear text files. This is bad, and becomes the security hole.

3) There is rarely a good reason to have the same root password for two boxes, avoid this. Don’t use a user’s password for root either. Users are more likely to use the same password for unsecure/untrusted things (like blogs, slashdot accounts, etc.). However, if this was their root password, one would hope that they would be less likely to use it elsewhere.

4) Firewall - iptables is your friend. Only allow ports that you absolutely need to be public facing. So, for example, web servers are 80/443 and everything else blocked. If you can and you’re really paranoid, on a very public machine allow port 22 from a specific IP or subnet only. This can be annoying as it means an extra hop if you’re out in the wild and need to get to the machine. A fun iptables trick is to limit the number of port 22 connections per minute from a given IP. So, this reduces the chances of an attack from extremely low to better odds of winning the lottery several times. Here are two lines you can add to your RH based iptables config that will do this:


-A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --name DEFAULT --rsource -j DROP
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource


This uses the conntrack extension of iptables to limit the number of SSH attempts to 4 times per minute.

5) Lastly, if you are hacked, consider *everything* on that box as untrusted. Take it physically off your network ASAP (unplug the network cable). You can try to recover things, but do this while the box is no longer on a network, and never put it back on one until the drives have been formatted or at least booted from another source (optical disk maybe). If you have tools like tripwire installed, you can check md5sums of binaries and such, but most of the time these sorts of things are more time consuming than just formatting the disks and re-installing. Again, this sounds obvious, but I’ve known a couple of people who’ve been hacked and thought they’ve removed the offending software installed only to find later on that a binary was trojaned and they were hacked again shortly afterward. Of course, once you’ve done this, change all of your passwords on all of your other boxes. Since the attacker had access to your /etc/shadow file, their odds of a brute force attack can be much greater if they have access to big iron, since they’re no longer limited by connection overhead, just raw CPU. Even with your crypted passwords, brute force attacks are expensive and not likely to succeed with good passwords.