Securing SSH Against Bruteforce Attacks
Using the iptables recent module to cap new SSH connections per source, log and drop the excess, and let whitelisted hosts through untouched.
This is one of the methods I’ve used in the past to secure a Linux host against brute force ssh attacks. While its not a perfect method, it does a good job of preventing 100s of brute force entries in your syslog.
bash
# Create a new table...
iptables -N SSH_WHITELIST
# On the input chain, mark new packets with the SSH 'tag'
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
# Push new ssh connections through the SSH_WHITELIST table
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
# Limit 4 connections from an ip per 60 seconds, to be more strict, use 300 seconds.
# Log connections that go over this limit and drop the packets.
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update \
--seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update \
--seconds 60 --hitcount 4 --rttl --name SSH -j DROP
# Check source IPs, if they match trusted hosts, remove SSH 'tag' and accept the traffic.
iptables -A SSH_WHITELIST -s 10.0.1.1 -m recent --remove --name SSH -j ACCEPT
iptables -A SSH_WHITELIST -s 192.168.88.0/24 -m recent --remove --name SSH -j ACCEPT> from the rack
> subscribe
New posts in your inbox when they publish. No digest, no marketing.
Comments
5 archived comments from Disqus 2009–2014
Well, thats the thing about iptables, there is no way to save the entries, so they’re only blocked for the timer amount… But that’s usually enough to stop the attack and they’ll move on elsewhere to an easier target. I tested another method, but never got it perfected.. I may work on it some more and post a follow up..