Message-ID: <Pine.LNX.4.61.0603010757130.4145@panther7.felines.org>
Date: Wed Mar  1 13:14:43 2006
From: libove-fulldisc at felines.org (Jay Libove)
Subject: reduction of brute force login attempts via SSH
 through iptables --hashlimit

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 
interesting.

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 
my system...

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 :)
-Jay

Powered by blists - more mailing lists