Mitigating SSH Attacks Brute-force password-guessing attacks on SSH services are common on the Internet today. They are a threat for two reasons: A large number of SSH password-guessing attempts can result in a denial of service — by saturating network connections, consuming large amounts of CPU resources (and therefore power), and/or by filling…

Rate-Limit-SSH

# INPUT:
#   First, we add any inbound SSH connection attempts to an
#   'ssh-clients' list.
iptables -A INPUT -i eth0 -p tcp -m tcp -m state --state NEW --dport 22 \
	-m recent --set --name ssh-clients --rsource

#   Then, we check to see if the source of the current packet has
#   attempted to connect more than 5 times in the last 60 seconds.  If
#   it has, then we treat it as a brute-force attack and send it to the
#   SSHATTACK chain, which does not return.
iptables -A INPUT -i eth0 -p tcp -m tcp -m state --state NEW --dport 22 \
	-m recent --update --seconds 60 --hitcount 5 --name ssh-clients \
	--rsource -j SSHATTACK

# SSHATTACK ruleset:
#   First, we log the incoming SSH attack.  However, because many
#   logged attacks could DoS our logging filesystems (and, because the
#   kernel echos everything to our slow serial terminal, the kernel as a
#   whole) we rate-limit the log messages, too.
iptables -A SSHATTACK -m limit --limit 1/minute --limit-burst 5 -j LOG \
	--log-prefix "SSH ATTACK: "

#   Finally, we reject the connection attempt.  Currently, we simply
#   return a 'port-unreachable' error packet, as if there were no
#   service listening -- but other options, such as
#   "icmp-admin-prohibited" might be more net-friendly.
iptables -A SSHATTACK -j REJECT --reject-with icmp-port-unreachable