full-disclosure - reduction of brute force login attempts via SSH through iptables --hashlimit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: Tue Feb 28 14:51:05 2006
From: libove at felines.org (Jay Libove)
Subject: reduction of brute force login attempts via SSH
 through iptables --hashlimit

Quite some time back, I posted a question here about brute force login 
attempts through SSH which had recently become a noticeable annoyance. 
There was some discussion here on the list, someone suggested using 
hashlimit, and I think the issue of brute force attempts through SSH has 
become just one more part of the background noise of the Internet.

I finally got back around to looking at this on my system, and I figured 
out why my first attempts at using the hashlimit functionality in iptables 
had not worked.  Hopefully late is better than never, so I present it here 
to anyone else who was as stupid and/or lazy as I was :) so that it took 
me this long to get back to work on it and get it right.

Here is an iptables command to allow inbound SSH with a quite low limit on 
the number of connections which may arrive from a specific IP address in a 
short period of time. Combined with the default setting of OpenSSH which 
drops a connection after just a few failed login attempts, this has 
reduced the number of failed logins I am seeing in my nightly logwatch 
output from thousands to about ten per day. Since this use of hashlimit 
filters on source IP address, it does not create a denial of service 
against legitimate SSH connections, unless someone spoofs a very large 
range of source addresses and can somehow get those connections to 
actually open instead of just consume partly open TCP sessions.  In such a 
case, other defenses are needed anyway.

# iptables --table filter -A INPUT --protocol tcp --source 0/0 \
--destination-port ssh -m hashlimit --hashlimit 2/minute \
--hashlimit-burst 3 --hashlimit-mode srcip --hashlimit-name ssh \
-m state --state NEW --jump ACCEPT

The stupid thing I did the first time I tried to set this up months ago 
was to put a command like the above in, and forget to take out the 
original iptables command allowing connections to the SSH port. 
hashlimit is a limiter on an iptables rule.  Having one rule with a 
hashlimit in it, and a second matching rule with no hashlimit, just 
results in all connections being accepted without limit.

Of course, the same thing would work to reduce brute force speeds on 
telnet, FTP, &etc by changing the destination port argument.

Please direct all flames to /dev/null, all cash contributions to /dev/me 
:) and all constructive comments and enhancement suggestions back to the 
list.

Cheers!
-Jay