preventing-brute-force-attacks-using-iptables-recent-matching

Software requirements

Linux kernel and iptables with ‘recent’ patch. (It seems that this patch has entered the mainline some time ago. ‘Recent’ matching e.g. is known to be included with kernels 2.4.31 and 2.6.8 ofDebian Sarge 4.0.)

Implementation

We begin with empty tables…

iptables -F

and add all the chains that we will use:

iptables -N ssh
iptables -N blacklist

Setup blacklist chain

One chain to add the remote host to the blacklist, dropping the connection attempt:

iptables -A blacklist -m recent --name blacklist --set
iptables -A blacklist -j DROP

The duration that the host is blacklisted is controlled by the match in the ssh chain.

Setup ssh chain

In the ssh chain, incoming connections from blacklisted hosts are dropped. The use of --update implies that the timer for the duration of blacklisting (600 seconds) is restarted every time an offending packet is registered. (If this behaviour is not desired, --rcheck may be used instead.)

iptables -A ssh -m recent --update --name blacklist --seconds 600 --hitcount 1 -j DROP

These rules are just for counting of incoming connections.

iptables -A ssh -m recent --set --name counting1
iptables -A ssh -m recent --set --name counting2
iptables -A ssh -m recent --set --name counting3
iptables -A ssh -m recent --set --name counting4

With the following rules, blacklisting is controlled using several rate limits. In this example, a host is blacklisted if it exceeds 2 connection attempts in 20 seconds, 14 in 200 seconds, 79 in 2000 seconds or 399 attempts in 20000 seconds.

iptables -A ssh -m recent --update --name counting1 --seconds 20 --hitcount 3 -j blacklist
iptables -A ssh -m recent --update --name counting2 --seconds 200 --hitcount 15 -j blacklist
iptables -A ssh -m recent --update --name counting3 --seconds 2000 --hitcount 80 -j blacklist
iptables -A ssh -m recent --update --name counting4 --seconds 20000 --hitcount 400 -j blacklist

The connection attempts that have survived this scrutiny are accepted:

iptables -A ssh -j ACCEPT

Setup INPUT chain

Allow packets that belong to existing connections:

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Allow all packets from loopback interface:

iptables -A INPUT -i lo -j ACCEPT

Optionally we may allow all packets from certain friendly subnets. However this should be used sparingly and it should be kept in mind that hosts from friendly subnets may be compromised and out of a sudden be not so friendly anymore…

iptables -A INPUT -s aa.bb.cc.0/24 -j ACCEPT

Now we direct all incoming ssh connections to the chain of the same name:

iptables -A INPUT -p TCP --dport ssh -m state --state NEW -j ssh

What remains in this chain has no right to continue:

iptables -A INPUT -j DROP

Variations

  • Depending on personal taste, the check against the blacklist (first rule of ssh chain) might be moved to the top of the INPUT chain so that all communication (not only subsequent connection attempts) from the blacklisted host is blocked immediately.
  • Many other packet matching criteria might be conceived that would warrant putting the sender on the blacklist.
  • Identical or similar effects possibly may be achieved using different extensions to iptables.

Limitations

Denial of Service

The described method opens a DoS vulnerability that may be exploited using SYN-packets with fake sender address to disable ssh connections from a certain host. Therefore ‘recent’ matching should not be used, when the ability to connect to the machine from any location and at all times is mission-critical.

Also it should be mentioned, that the ssh daemon itself in its current implementation is vulnerable to DoS: There is an upper value for concurrent connections.

No substitute for secure passwords

The approach described here by no means is a substitute for using secure passwords that are difficult to guess and to brute-force! Disabling root logins in sshd is very much recommended! (Oh, by the way: There is also an option to disallow empty passwords for sshd. ;-) )

Security by Obscurity

It should be noted that this scheme partly employs methods of ‘security by obscurity’ to increase its effectivity. A casual attacker probably will be blocked for a long time (possibly forever) after several tries. Yet a determined, observant attacker still may try passwords at the rate specified by the counting4 rule. However this is still a considerable improvement compared to no limit at all.

It's only fair to share...Tweet about this on TwitterShare on Google+Share on FacebookShare on LinkedInEmail this to someone
Twitter Auto Publish Powered By : XYZScripts.com