mailing list archives
reduction of brute force login attempts via SSH through iptables --hashlimit
From: Jay Libove <libove-fulldisc () felines org>
Date: Wed, 1 Mar 2006 08:14:32 -0500 (EST)
Well, as expected, this, like most postings here, generated much heat and
actually a little light :) Particular thanks to those who went to the
effort to write scripts to read log files and make a more permanent
reaction than iptables --hashlimit provides, and to further take the
expected heat for posting anything here. I'm actually impressed that
nobody took me to task for something stupid I did in my iptables
--hashlimit command line. I can't have got it completely right, can I?
What, not even one "you're a loser" for me? Heh.
The conversation about scripts which read log files and the holes in those
scripts and the holes in those holes and the *ssholes and... are certainly
I would like to point out that - good old defense in depth - it probably
is best to use some combination of these things. Putting together
iptables --hashlimit with some kind of log file reader will slow down the
initial attack in real time, and allow a more leisurely (and less system
intensive) log file scanner to react in not-so-real-time with more
complete blockages against detected significant attackers.
Based on what I am now seeing in my log files every night after adding the
hashlimit to my iptables rules, I don't feel a need to add any follow-up
stronger blocking scripts. The total number of brute force login attempts
to my system is now so low that the expected occurrence of a password
actually being guessed is in the noise just above zero.
Calculation: None of the accounts on my system use dictionary words. They
aren't based on knowable information about me. And knowable information is
not what these brute force attacks through SSH are going after anyway -
they're going after known passwords from weakly configured applications or
applications which come with default passwords which some system
administrators do not change. If an attack is truly targeted, it won't
look like these, or it will be hidden in these, and the current discussion
about simply slowing it down won't be sufficient anyway.
Any one source IP address typically now gets only about 3 password guesses
per night. One particularly tenacious one actually got in 8 last night on
Of course, a sustained targeted attack could produce a lot more, at 2
logins/minute and three attempts per login that's 720/hour or 17280/day
from one source IP address - of course, I'd notice that and manually block
it. Hasn't happened yet.
Assuming only an eight character password with a rich character set of
[a-zA-Z0-9[:symbol:]] - that's about 72 characters - the permutations
number 72^8 = 722204136308736. At 17280/day that would take 114504714
years (okay, on average, half of that so only 57252357 years).
Yes, people could simultaneously carry out a sustained attack from
multiple IP addresses, but as noted above, if an attack was so sustained,
it would be manually blocked long before it got to a tiny fraction of 1%
of the password space.
So, I'm not going to add any scripts to take up CPU and disk time reading
log files, and possibly open my *sshole to script holes to ... &etc.
Have fun everyone :)
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/