If you’ve been playing in your virtual server you might notice this type of entry in /var/log/messages
Feb 11 12:21:10 load1 sshd(pam_unix)[397]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=mail.kwpskt.edu.hk user=root
Feb 11 12:21:10 load1 sshd(pam_unix)[398]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=mail.kwpskt.edu.hk user=root
Feb 11 12:21:11 load1 sshd(pam_unix)[402]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=mail.kwpskt.edu.hk user=root
Feb 11 12:21:11 load1 sshd(pam_unix)[404]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=mail.kwpskt.edu.hk user=root
Feb 11 12:21:12 load1 sshd(pam_unix)[406]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=mail.kwpskt.edu.hk user=root
Feb 11 12:21:13 load1 sshd(pam_unix)[412]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=mail.kwpskt.edu.hk user=root
Those lines are bad guys trying to get into your machine via brute force dictionary attacks.
If you maintain good passwords there’s little to worry about here. However, if like me these things annoy you there are a variety of ways to get rid of them.
One of the easiest is to drop these lines into your virtual server’s /etc/sysconfig/iptables file, on about line 14:
# Slow SSH connections to 3 attempts per minute
-A RH-Lokkit-0-50-INPUT -p tcp –dport 22 -i eth0 -m state –state NEW -m recent –set
-A RH-Lokkit-0-50-INPUT -p tcp –dport 22 -i eth0 -m state –state NEW -m recent –update –seconds 60 –hitcount 4 -j DROP
This limits SSH connects to, as the comment says, 3 times per minute. You can of course change the –seconds and –hitcount numbers to whatever you like (I might recommend being a little more strict) at any time.
Don’t for get to run this command when you are done:
service iptables restart
~ Oban
Don’t forget inherent hardening of your SSH config. Setting things like MaxAuthTries from 6 to 1 or 2 can help as well. I also turn down the LoginGrace time to keep connections that are open from hanging for too long.
@jeffatrackaid Good points.
For everyone else: Read Jeff’s article for a full-blown how-to on SSH hardening. Its good and we implement nearly all of the things he refers to on our own and our client servers:
http://www.rackaid.com/resources/how-to-harden-or-secure-ssh-for-improved-security/