Using iptables to Block Brute Force Attacks
We can use the iptables recent module to write some iptables rules that can block brute force attacks. In order to use this method you need a kernel and iptables installation that includes ipt_recent. If your linux distribution doesn’t include the ipt_recent module or you are using a custom compiled kernel you might need to first include the iptables recent patch that can be found on the author’s website or in the iptables patch-o-matic area. If you are using Debian/Ubuntu you don’t need to do anything special as this is already included in your system.
Let’s see how we can use the iptables recent module to block brute force attacks agains ssh. Let’s see a simple example:
iptables -N SSHSCAN
iptables -A INPUT -p tcp --dport 22 -m state –state NEW -j SSHSCAN
iptables -A SSHSCAN -m recent –set –name SSH
iptables -A SSHSCAN -m recent –update –seconds 300 –hitcount 3 –name SSH -j DROP
This will basically allow only 3 NEW connections (as matched by the state NEW) in the timeframe of 300sec (5min). Any new connection will be automatically dropped.
The main disadvantage of using this method is that it will not make any distinction between successful and failed logins. If you are not careful and open too many connections yourself you might found yourself locked out. One walk-around for this issue is to whitelist our own administrative ips (still if we can do this for all the locations that need to connect to the system, then we can protect ourselves with simple firewall rules and we don’t need this added complexity). So at least for the hosts that we can (static ips) we should do this (replace with as many lines needed containing $WHITE_LIST_IP):
iptables -N SSHSCAN
iptables -A INPUT -p tcp –dport 22 -s $WHITE_LIST_IP -j ACCEPT
iptables -A INPUT -p tcp –dport 22 -m state –state NEW -j SSHSCAN
iptables -A SSHSCAN -m recent –set –name SSH
iptables -A SSHSCAN -m recent –update –seconds 300 –hitcount 3 –name SSH -j DROP
Even if we lock ourselves out, our existing connections will remain up since we are matching only on NEW connections. If needed we can take appropriate actions.
In case we want to have the blocked hosts logged, then we will have to add another iptables rule:
iptables -N SSHSCAN
iptables -A INPUT -p tcp --dport 22 -s $WHITE_LIST_IP -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSHSCAN
iptables -A SSHSCAN -m recent --set --name SSH
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j LOG --log-level info --log-prefix "SSH SCAN blocked: "
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH -j DROP
You can peek at the internal database kept by the module, by looking inside: /proc/net/ipt_recent/* (DEFAULT will contain default matches; in our example the name of the file is SSHSCAN):
cat /proc/net/ipt_recent/SSHSCAN
This solution is very effective and easy to implement. You just add the needed iptables rules to your existing firewall setup and you are set. Still, it has many limitations when compared with the other methods shown: like limited time frames, it will not differentiate against failed/successful logins, etc.
References:
http://snowman.net/projects/ipt_recent/
http://www.netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-3.html#ss3.16
Return to the main page: “Blocking Brute Force Attacksâ€
Share This








29th June 2006, 12:47
this would be a great way to lock yourself out if you’re not whitelisting admin ip’s… i could easily register 3 per 5 min just from random scanners on the internet hitting boxes
3rd July 2006, 06:22
Well this is the reason why I have shown how you can whitelist some IPs. Also the timers show above are just examples and you might want to tweak them for your own needs (maybe you want to block only after 5 new ssh connections in 60 sec?, or whatever might be good for you).
4th July 2006, 21:45
[...] Using iptables to Block Brute Force Attacks Using PAM to Block Brute Force Attacks Using fail2ban to Block Brute Force Attacks [...]
26th February 2007, 22:02
The simple example using iptables you used to block ssh brute force attack was incorrect. The correct arrangement of the rules should be:
iptables -A INPUT -p tcp –dport 22 -m state –state NEW -j SSHSCAN
iptables -A SSHSCAN -m recent –update –seconds 300 –hitcount 3 –name SSH -j DROP
iptables -A SSHSCAN -m recent –set –name SSH
4th March 2007, 18:00
This looks useful, but I must be missing something:
Ubuntu 6.06
root@fido:/# iptables -A INPUT -p tcp –dport 22 -m state –state NEW -j SSHSCAN
iptables: No chain/target/match by that name
root@fido:/# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain SSHSCAN (0 references)
target prot opt source destination
Any ideas? Thanks!
9th March 2007, 15:41
You forgot this:
iptables -A SSHSCAN -m recent –set –name SSH
SSH is how the packet is tagged and SSHSCAN is the name of the iptables chain.
25th May 2007, 09:12
I think the log line should have the –rcheck instead of the –update because otherwise two new packets will be logged for 1 connection attempt or?
29th August 2007, 01:11
Nice, sounds like a quick/dirty way to minimize brutes. Do you think it would work well with ftp and pop3 brute attacks? Trying to visualize how ftp/pop3 protocols work, if there are multiple/numerous tcp connections established even with valid use…which would render ipt_recent useless in these cases…
29th August 2007, 16:33
Johnny: this basically depends on your setup, and the number of valid connections you want to allow. Still for something like this there might be more appropriate other methods like fail2ban for ex:
http://www.ducea.com/2006/07/03/using-fail2ban-to-block-brute-force-attacks/
31st October 2007, 14:51
[...] Using iptables to Block Brute Force Attacks [...]
24th July 2008, 20:08
Hi, I using mod recent since …. well a lot of time … to block por 25 in a mail server.
I just wanna know if there are some easy way to get the blocked IPs from the list on /proc/net/etc…blahblah/BadGAys…
Thanks!!!
PD: My list is up to 500 IPs
13th August 2008, 21:40
Thanks for providing this nice write up I made some changes for my application, but the method you published works as promised.
At least on all of my fedora boxes.