Using IPTables to Prevent SSH Brute Force Attacks
If you have a server with a world facing ssh server, you've probably seen brute force attacks in your logs. Some machine starts hammering your ssh server, trying all sorts of logins (staff, root, a, admin, etc...) over and over and over again.
This is bad on a lot of fronts.
I use two simple iptables rules to block any IP address who has made more than 3 ssh connections or attempted connections within the past 3 minutes. So your would-be brute force attacker, gets three tries, and then is locked out for a minimum of three minutes. However, since 99% of the attacks are run by an automated bot, it will either: give up after the connection is refused multiple times, or it will keep hammering away on the closed door, which keeps the running count of attempted connections in the past 3 minutes over 3, keeping the door closed.
First:
iptables -I INPUT -i eth1 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource
Then run:
iptables -I INPUT -i eth1 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 4 --name DEFAULT --rsource -j DROP
I'd also recommend using the script in my post on blocking IP addresses using iptables to deal with any persistent folks, or people poking too hard on your web site, or other services.
July 24th, 2008 at 12:28 pm
Is this an immediate measure or do you also have it in a script somewhere so it is started with your server?
July 24th, 2008 at 6:07 pm
I save my iptables rules and have them loaded at startup using the commands here:
http://www.digitalsanctuary.com/tech-blog/debian/how-to-block-an-ip-in-linux.html
As for the block, it’s just for a few minutes (in case I lock myself out - which I’ve done before), but totally breaks any brute-force attempt, since they never stop trying, and hence stay blocked out until they’ve given up.
Does that answer your question?
July 25th, 2008 at 2:09 am
Ahh I guess I figured it out. To make the rules above permanent I just have to save them to a file (as you did in the script in the other article) and edit the interfaces file to load my rules file.
Thanks a lot! I’m very new to the iptables business and reading through the manual pages I dint really get how to do the 3 attempts thing. So your blog was kind of a live-safer
August 9th, 2008 at 6:26 pm
Why would you run SSH on port 22? Running sSH on a other port is a simple solution, that keeps most of the attempts out.
August 9th, 2008 at 6:37 pm
@Andreis: Good question.
A few answers:
1) a different port is a good idea for part of a security solution, but you should still have measures in place to prevent brute force attacks. Port scanning to identify ssh server ports isn’t hard. You might duck a large number of automated scanners, but it won’t do anything for a targeted attack. My solution will. So you should do the above anyhow:)
2) one of the main reasons I don’t run on a different port myself is convenience. I ssh in from a large number of other servers, and scp files frequently. Having to specify a port every time I do any of that would be a pain.
August 22nd, 2008 at 12:44 am
Thnx this helps me out a lot, I was looking for something like this already.
@Andries
Still some clients (like on iphone) don’t support different ports then 22