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.
