[Full-disclosure] 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

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

Relevant Pages

  • Interesting webserver intrusion (apache 1.3.31, mod_ssl 2.8.18, php 4.3.7)
    ... attack occurred roughly 25 days after the release of the security fixed ... I believe the execution is done blindly. ... and 30 minutes before one of the scripts was uploaded. ... I am fairly sure the normal-user accessible php scripts on the server do ...
    (Incidents)
  • Re: [Full-Disclosure] Re: Teenager cleared of hacking - Off Topic?
    ... > The experts gave very clear evidence that the attack was initiated ... > locally and log files cannot be planted remotely the way they werew ... overflow an allocated cluster - disk is allocated in "chunks" that are ... > that it was inserted later because of the physical position of the ...
    (Full-Disclosure)
  • Re: Help! Hacker is turning off my server.
    ... examples from my log files. ... Unless it's a pure denial of service attack, ... >> Disabling the QoS service should get rid of the two QoS related error ... >> but it looks like you've disabled the anonymous FTP account, ...
    (microsoft.public.inetserver.iis.security)
  • Re: Benchmarking a script that cant be executed form the command line
    ... It's been in production ... > With other scripts I have always used DProf/SmallProf or something ... plain old log files ... this will help you locate problem areas. ...
    (comp.lang.perl.misc)
  • Re: Illegal access attempt - FreeBSD 5.4 Release - please advise
    ... > access to my server (see snippet from log files ... Use dig to get a clue about who owns the network that is attacking you: ... Sending a complaint to them ... The log you show appears to be an automated attack. ...
    (freebsd-questions)