Home page logo

fulldisclosure logo Full Disclosure 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 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 :)

Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]