Rate limiting should be done at the IPS level or at the firewall.
If your running *nix give portsentry a look
http://sourceforge.net/projects/sentrytools/
rls
"MPHMedia.Net" <MPHMedia@InfoWest.com>
05/05/2005 04:53 AM
To: secureshell@securityfocus.com
cc:
Subject: Login Attempt Limits
I had around 650 failed atttempts on the SSHD server from about 5
different IPs yesterday.
From prior daily reviews of the log file it is clear that the majority
of the attempts come from hacked SSHD servers because the attempt
username pattern is the same from IPs located in different parts of the
world (though South Korea seems to have the largest volume of any
country).
The clear evidence is that the SSHD system fails in a good number of
cases.
One way to look at this failure is to say that the managers of those
servers are not requiring sufficiently random passwords for their uesrs.
The clear mathematics is that use of 8 byte random passwords from the
complete available password character set will not be cracked (to a very
high probability).
But the clear reality is that very few passwords are selected from the
widest possible selection pool and rather from a rather small pool of
familar words and phrases. This reality combined with a high volume of
attempts obtains an SSHD system failure at a fairly regular rate, as
evidence by the attacking IP variation.
I looked briefly at some earlier secureshell pages along the lines of my
following suggestions with the apparent conclusion that the suggestions
have been considered but not implemented for one reason or another. They
are:
1. When an IP has failed attempts for different usernames within a short
period block that IP for some number of minutes. This would be done
automatically using configuration file parameters. With this option I
would block an IP for 30 minutes after three failed attempts with
different usernames occuring under a minute.
2. Execute an IP block as above when there are 3 root user failures.
3. Execute an IP block as above when there are 5 same user failures.
Apparently there is an option to block an IP completely after the fact.
I am not seeing repeated attempts on subsequent days from the same IP.
Hence that option would not address the current attack patterns.
With the above automatic IP block features, the 650 failed attempts
yesterday would have been reduced to less than 20. That could be seen as
a 5 bit (32 times) reduction in the probability of a successful attack
and similarly a 5 bit reduction in the number of failed SSHD servers.
The effective result would be some multiple greater than 5 bits overall
in that the hacked server pool would decline by a 5 bit multiple. That
is, the attack volume originates from already hacked servers meaning
that the overall attack volume derives from at least two layers to which
5 bit attenuation could be applied. I would consider an obvious 5 bit
attenuation very useful, but an apparent compounded 5 bit attenuation
seems to argue for immediate implementation. Looked at another way, the
effective randomness of the currently used password pool should increase
by 5 to, say, 15 bits. Or we could say that overall SSHD security would
be increased by a similar degree.
Whatever the implementation difficulties, the design is clear.
Save failures by IP in the above categories and execute the block using
new configuration file parameters.
Neil Nelson
