As I mentioned in an earlier post, ssh attacks are on the rise. If research solutions on combating these attacks, you will often find a long list of tools, most of which are log analyzers that block IPs that repeatedly fail authentication. Popular tools such as fail2ban, denyhosts, and others are subject to attack because they fail to verify log data, so a better method is needed. Fortunately, you have one right there on your server: Netfilter, more commonly known as IPtables.

Rate Limiting SSH with IPTables

You are most likely using Netfilter, aka IPTables, if you are running a recent Linux distro. Most firewalls supplied with hosting control panels or simple setup scripts fail to take advantage of some of the more advanced features available. A feature that can used to combat SSH brute force attacks is a module that remembers recent connections. By tracking recent connections SSH’s port, you can begin to block IP addresses based on the rate at which they connect to SSH. By using IPTables to rate-limit connections, you can mitigate SSH brute force attacks without the mess of third party software or having to deal with ever growing ban lists.

The rules are relatively simple.

/usr/sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
/usr/sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent  --update --seconds 60 --hitcount 4 -j DROP

This rule will block an IP if it attempts more than 3 connections per minute. Notice that the state is set to NEW. This means only new connections not established ones are impacted. Established connections are the result of a successful SSH authentication, so users who authenticate properly will not be blocked. The Debian Administration site has more details on how to rate-limit connections using IPTables.

If you need to see what’s being done, you may want to log these drops. You can do so by setting up a log rule and then using these rules instead.

/sbin/iptables -N LOGDROP
/sbin/iptables -A LOGDROP -j LOG
/sbin/iptables -A LOGDROP -j LOGDROP
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent  --update --seconds 60 --hitcount 4 -j LOGDROP

Notice that I’ve changed the rule from DROP to LOGDROP. This way your drops will get logged and you can see the results in your logs:

Jan 27 08:22:29 server kernel: IN=eth1 OUT= MAC=00:30:48:94:fb:21:00:1b:00:00:00:00:00:00 SRC=118.103.140.3 DST=208.43.148.64 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=16406 DF PROTO=TCP SPT=31003 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 
Jan 27 08:22:29 server kernel: IN=eth1 OUT= MAC=00:30:48:94:fb:21:00:1b:00:00:00:00:00:00 SRC=118.103.140.3 DST=192.168.1.1 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=5076 DF PROTO=TCP SPT=45354 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 
Jan 27 08:22:35 server kernel: IN=eth1 OUT= MAC=00:30:48:94:fb:21:00:1b:00:00:00:00:00:00 SRC=118.103.140.3 DST=208.43.148.66 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=37295 DF PROTO=TCP SPT=21077 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 
Jan 27 08:22:35 server kernel: IN=eth1 OUT= MAC=00:30:48:94:fb:21:00:1b:00:00:00:00:00:00 SRC=118.103.140.3 DST=208.43.148.64 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=16408 DF PROTO=TCP SPT=31003 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 

Effectiveness
I always try to get a sense of effectiveness of any tool or configuration we deploy. I find many “security” tools that are popular amongst the web hosting crowd provide little to no value. In many cases, appropriate configuration of your server or web application could achieve similar results without the hassle of maintaining a third party product.

Are the IPTables rules effective? In short yes.

During a recent attack on a server, the SSH service remained fully accessible with no service interruption.

Previously such aggressive attack would have caused service interruptions. So on the service side, this approach works. When I dug into the logs, I found three failed user attempts against SSH prior to the rate-limiting kicked in. The attack then sent 67 more attempts before it gave up.

Pros and Cons
The benefit of this approach is you don’t need any added software. IPtables is likely sitting on your server already if not already in use. There are no cumbersome ban lists to clear out or fix. The rate of false positives should be low as legitimate user should not trip the limits. If you have some automation tools tripping the limits, you could white list these by allowing them before the rate-limiting rule or raise the limits.

One of the drawbacks is that this approach does not lock accounts. A slow, distributed attack could fall under the radar. If it was a directed attack against a specific user account, the attacker could churn away for days or weeks without detection. For that, you would need something that can lock user accounts after failures. PAM includes a module called pam_tally that does just this. If you fail too many times, an account is locked.

Stay Tuned
In addition to these IPTables settings, there are some things you can do within SSH itself to harden the service from attacks. I will cover those in my next post on SSH.