Rundown on SSH Brute Force Attacks 360
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."
As always... (Score:5, Informative)
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.
Easy fix (Score:4, Informative)
DenyHosts (Score:5, Informative)
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.
Non-default Port (Score:3, Informative)
Attacks are a sad reminder on stupidity (Score:3, Informative)
I got annoyed enough that I wrote a little script to pull the data out of my logs in real time and add an entry to my firewall, but the attacks are harmless to any sysadmin with a clue.
-Matt
Use another port (Score:5, Informative)
Re:Highly annoying (Score:2, Informative)
http://www.rfxnetworks.com/bfd.php [rfxnetworks.com]
it looks through your
It works really well for me. Catches a lot of attackers.
why not disable passwords entirely? (Score:5, Informative)
Re:Non-default Port (Score:2, Informative)
Re:As always... (Score:4, Informative)
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
Dynamically blocking with iptables (Score:4, Informative)
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 (Score:4, Informative)
APF and BFD can be got here: RFX Networks [rfxnetworks.com].
Re:Easy fix (Score:5, Informative)
Re:As always... (Score:4, Informative)
Comment removed (Score:3, Informative)
Re:As always... (Score:3, Informative)
Perhaps, but root is the obvious target - it's both the most powerful account, and the only one that exists on all systems. With user accounts, there's the problem of guessing a valid account name.
Re:why not disable passwords entirely? (Score:3, Informative)
Re:As always... (Score:5, Informative)
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 [neohapsis.com] an OpenBSD developer:
Re:As always... (Score:2, Informative)
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 ;)
First of all, your public key goes onto the server you are logging into. You need your private key on the client.
Second, it isn't very secure to use your private key from an untrusted machine. What you want to use from untrusted machines are one time passwords.
Re:As always... (Score:5, Informative)
And running Apache as root is a Really Bad Idea (tm).
Re:Use another port (Score:3, Informative)
# Protect against DOS attacks - rate limit various ICMP messages
$IPTABLES -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
$IPTABLES -A INPUT -p tcp --syn -m limit --limit 1/s -j ACCEPT
$IPTABLES -A INPUT -p tcp --tcp-flags SYN,ACK,FIN,RST -m limit --limit 1/s -j ACCEPT
Re:sshdban.sh (Score:1, Informative)
awk '/Illegal user/ { print " ALL:" $10 ":deny" }' \
Re:Won't work (Score:3, Informative)
Changing the port does work. I went from having hundreds of attacks a day to zero. Not a single attempt in months.
Re:As always... (Score:5, Informative)
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:
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 [openwall.com] 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.
Re:Highly annoying (Score:2, Informative)
Re:DenyHosts (Score:2, Informative)
I have to second DenyHosts, it is truly an awesome tool. My favorite feature is that it will find IP's with more than X failed attempts, and at least one successful login and warn you that there have been suspicious log-ins.
Very powerful feature, imho.
Re:As always... (Score:3, Informative)
Re:Easy fix (Score:2, Informative)
Re:Highly annoying (Score:2, Informative)
Re:As always... (Score:3, Informative)
Yes, there's several. Some SSH software has S/Key support (eg OpenSSH "./configure --with-skey"). The most current S/Key implementation seems to be the one in Wietse Venema's logdaemon [porcupine.org] package.
You can also do OTP through PAM or BSDauth if your platform supports those, eg pam_skey [freshmeat.net], pam_opie (OPIE [inner.net]: One-time Passwords In Everything)
Several systems have either S/Key or OPIE support natively (OPIE seems to be becoming the more popular of the two).