Securing sshd

March 25, 2006

Any system with a direct connection to the internet is a potential security risk. If you leave your computer open to the world, someone will probably find it and try to access it. This has been true forever, but the number of attacks I received in the first few days of getting my new system online was startling. My sympathies go out to the unsecured masses.

After looking at my logs, one person had the audacity to try and gain access through ssh for over five hours using a brute force method of trying different usernames and passwords. Of course this was a script with a database of common usernames and passwords, but nevertheless, as unsophisticated as the attacker may be, if he tries enough ip addresses different machines he will eventually succeed.

My solution is two-fold. First, since there are only a few people that should be using my system to begin with, it is easy for me to allow remote access only to a handfull of users. I added these users to the AllowUsers list in /etc/ssh/sshd_config. sshd is clever in that it doesn’t reveal any unnecessary information to someone attempting to login. If an attacker tries to use a username that isn’t in AllowUsers, sshd only gives them the standard invalid password message. Now someone needs to know both a correct username and the corresponding password to break in. Two pieces of information are harder to guess than one.

Here is an example from auth.log after implementing the first step:

Mar 20 09:06:52 roark sshd[26974]: Failed password for invalid user root \
    from port 52979 ssh2
Mar 20 09:06:53 roark sshd[26976]: User root from not \
    allowed because not listed in AllowUsers
Mar 20 09:06:53 roark sshd[26976]: (pam_unix) authentication failure; \
    logname= uid=0 euid=0 tty=ssh ruser=  user=root

The second layer of security is a program called fail2ban which temporarily bans IP addresses which make too many failed login attempts. I have configured it to so that an IP which makes more than 5 unsuccessful attempts in 60 seconds will be banned for 10 minutes. This second measure alone seems to be more than enough to turn away the impatient and naïve who use these pre-packaged attacks.

An example of fail2ban in action:

2006-03-23 11:10:36,754 INFO: SSH: has 5 login failure(s). Banned.
2006-03-23 11:10:36,774 WARNING: SSH: Ban
2006-03-23 11:20:37,316 WARNING: SSH: Unban

I haven’t had the time or motivation to setup something along the lines of Tripwire, but running logcheck has been a simple and useful way of detecting potential intrusion attempts.