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â€
>
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.
24th December 2008, 19:41
Awesome article!
Works as promised
Thanks
19th January 2009, 03:39
[...] also discovered a great iptables tip to block SSH scans. The downside is that it will catch normal users if you start up too many SSH [...]
25th June 2009, 10:46
[...] These guides were used to compose this walk-through: http://wiki.tyk.nu/index.php/Using_Varnish_to_protect_Apache_against_slowloris#Configuring_Varnish http://developer.mindtouch.com/User:PeteE/Varnish_Installation http://varnish.projects.linpro.no/ http://maxgarrick.com/reverse-proxy-with-nginx http://www.ducea.com/2006/06/28/using-iptables-to-block-brute-force-attacks/ [...]
20th October 2009, 04:18
I thought i followed this correctly but twice i’ve had the same error:
iptables v1.3.5: Unknown arg `badconns’
21st October 2009, 23:36
@Ben: what distro do you use? did you built iptables manually?
27th May 2010, 13:37
Hello dude, can i post articles to your website ? Let me know if you are interested
19th July 2010, 21:12
This seems like an easy way to open yourself up for DoS attackes. All I need to do is to make N connections/minute to your server and you can never access it again other than a whitelisted IP. And if you only access it from whitelisted IP, then as you say, just allow whitelisted IPs. Pretty weak IMO.
19th July 2010, 21:12
This seems like an easy way to open yourself up for DoS attackes. All I need to do is to make N connections/minute to your server and you can never access it again other than a whitelisted IP. And if you only access it from whitelisted IP, then as you say, just allow whitelisted IPs. Pretty weak IMO.