Protecting against SSH brute-force password attacks
I run an internet facing ssh server, so my logs are regularly full of brute-force password attacks like this:
Jan 20 02:59:21 drevil sshd[12803]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:24 drevil sshd[12806]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:27 drevil sshd[12816]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:30 drevil sshd[12820]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:34 drevil sshd[12827]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:37 drevil sshd[12830]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:40 drevil sshd[12833]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:44 drevil sshd[12836]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:47 drevil sshd[12840]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
Jan 20 02:59:51 drevil sshd[12843]: error: PAM: Authentication failure for illegal user root from 213.136.100.86
There are several simple ways of reducing the chance of a break-in through this method:
1. Use strong passwords
This is an obvious place to start. The vast majority of these attacks come from automated scanning tools. These attempt to log in using passwords from a commonly used “dictionary”, so avoid simple words like “password”. Using a combination of letters, lower and upper case letters, and even symbols (!”£$%^&*) will give a password that is unlikely to be listed in a “common passwords” dictionary.
2. Restrict the users who can connect via ssh
OpenSSH has the capability to specify a “white list” of allowed users and deny all others. Simply add this line to your /etc/sshd_config and restart the sshd service:
AllowUsers dave mike sarah
This will block attempts to connect as any of the common system users (root, postfix, mysql etc), EVEN if the attacker guesses the correct password. If this list is kept as small as possible, it is much easier to verify these users have strong passwords.
3. Rate limit new ssh connections
A simple iptables script can be used to rate limit new incoming connection attempts. There are two ways of doing this, using the limit and recent iptables modules. Here’s the limit solution:
iptables -N NEW_SSH
iptables -A INPUT -p tcp –dport 22 -m state –state NEW -j NEW_SSH
iptables -A NEW_SSH -s 10.0.0.0/24 -j ACCEPT
iptables -A NEW_SSH -m limit –limit 3/min –limit-burst 3 -j ACCEPT
iptables -A NEW_SSH -j DROP
The third line ensures that connections from the internal network (in this example 10.0.0.0/24) are not subject to rate-limiting. The weakness of this approach is that while an attack is underway, ALL new ssh connections from outside are blocked. The recent module allows a slightly different approach (taken from debian administration):
iptables -N NEW_SSH
iptables -A INPUT -p tcp –dport 22 -m state –state NEW -j NEW_SSH
iptables -A NEW_SSH -s 10.0.0.0/24 -j ACCEPT
iptables -A NEW_SSH -m recent –set
iptables -A NEW_SSH -m recent –update –seconds 60 –hitcount 4 -j DROP
iptables -A NEW_SSH -j ACCEPT
This module “blacklists” IP addresses that exceed the rate limit, while still allowing other IP addresses to connect. If a connection makes it past this rate limiting, we accept it (last line).
4. Run your ssh server on a different port
The automated scanners look for ssh services on the default port (22), so if you move your sshd to a non-standard port less scanners will find you. It’s worth noting that this approach doesn’t improve security at all against a determined attacker. Personally I don’t use this technique, my SSH servers run on port 22.
September 24th, 2008 at 6:50 am
Hello,
Is it possible to enable Password Authentication for a specified host only, while keeping Pubkey Authentication for any other hosts available?
I ask this because I currently use public key authentication, but want to setup freenx on the host, and using sshd to control the login is by far the easiest method to setup (no need to recreate passwords for passdb, for instance), but requires password authentication enabled on localhost to work.
September 25th, 2008 at 10:50 am
Hi LKRaider,
Yes, but only if you have OpenSSH 4.3p2 or later. You can use the new “Match” configuration block to override some settings for selected hosts, users or groups.
There’s an example of using it here: http://prefetch.net/blog/index.php/2006/09/05/limiting-access-to-openssh-directives/
September 27th, 2008 at 7:19 pm
Thanks, that’s exactly what I needed!