-----Original Message-----
From: Jeff Rosowski [mailto:rosowskij@ie.ymp.gov]
Sent: 06 May 2005 14:50
To: Price, Christopher
Cc: MPHMedia.Net; secureshell@securityfocus.com
Subject: RE: Login Attempt Limits
take a look at the following:
http://blog.andrew.net.au/2005/02/17#ipt_recent_and_ssh_attacks
On Thu, 5 May 2005, Price, Christopher wrote:
Your proposal could lead to a DoS attack designed to deny large
ranges of IP addresses access to your SSHD service by using
IP spoofing,
no?
-----Original Message-----
From: MPHMedia.Net [mailto:MPHMedia@InfoWest.com]
Sent: Thursday, May 05, 2005 8:53 AM
To: secureshell@securityfocus.com
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
