reduction of brute force login attempts via SSH through iptables --hashlimit
Jay Libove <libove-fulldisc <at> felines.org>
2006-03-01 13:14:32 GMT
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
(Continue reading)
RSS Feed