Web Hosting Philippines, Offshore Programming, Offshore SEO Philippines, Cheap Webhosting Manila Philippines
Home -> Resources -> Linux -> Block pesky SSH brute force attacks

Block pesky SSH brute force attacks via 2 simple iptables rules

VPS and dedicated server hosting users who look at their /var/log/messages log (this is for Slackware, and may be in another directory for other Linux distros), will usually see a ton of failed SSH login attempts. These are brute force attempts by crackers to guess your SSH passwords.

As is the tradition with Linux, everyone and his uncle have their own solutions for this issue. In fact, lots of people have created entire packages for dealing with this, often requiring you to install this or that dependency. Lockout scripts such as this or this are a dime a dozen and they are generally a pain and a mess to install and maintain, often draining precious minutes, if not hours, from your day trying to track down the dependencies, installing them and getting them to work correctly.

However, as is usually the case for those who truly understand the Zen of Linux (those who use Slackware), there is a working solution that is far far simpler. This involves just 2 iptables rules:

iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 600 --hitcount 8 --rttl --name SSH -j DROP

What these rules do is limit the number of connections from a particular IP address to a maximum of 8 every 10 minutes. In Slackware, the correct place to add this to is /etc/rc.d/rc.local so that it will be preserved across reboots. The source of this tip has more useful info on how to deal with the iptables command.

Problem solved. Unless, that is, you are one of those impractical fellows who want to think up of a solution that is "even more secure" (e.g. one that will cause you far more trouble than it saves you from). In those cases, you may wish to try the solutions that involve installing packages rather than just running some commands.

OpenVZ users: If you do a cat /proc/net/ip_tables_matches and recent does not show up, then it means you will not be able to use the -m recent switch. You should request your hosting company to enable the ipt_recent module for guest OSes. You can refer them to http://lists.openvz.org/pipermail/users/2008-November/002416.html for some tips on how to do this. Also, don't forget to replace eth0 with venet0:

iptables -A INPUT -i venet0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -i venet0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 600 --hitcount 8 --rttl --name SSH -j DROP

UPDATE: In Linux (e.g. Slackware 13.37), for -m recent to work, I needed to enable the following in my kernel configuration:

"recent" match support under Networking options -> Network packet filtering framework (Netfilter) -> Core Netfilter Configuration.

In order to make the option above appear, I had to check Networking options -> Network packet filtering framework (Netfilter) -> Advanced netfilter configuration. This is if you have a custom kernel configuration and modprobe ipt_recent is not working.

 Want to tip via bitcoin?

(address string below for double checking)

Back to Top

© 2012 by Andy Sy
last updated: 2012-Dec-1

Web Development / Rich Internet Applications (RIA) Development

Programming Languages


Database Development

   © 2003-2019 Neotitans Technologies Inc.