RE: Login Attempt Limits

From: Jeff Rosowski (rosowskij_at_ie.ymp.gov)
Date: 05/06/05

  • Next message: Derek Martin: "Re: bash_logout and sftp" 
    Date: Fri, 6 May 2005 11:50:01 -0700 (PDT)
To: "Price, Christopher" <Christopher.Price@encana.com>

    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
    >
    >
    >
    >

  • Next message: Derek Martin: "Re: bash_logout and sftp"

    Relevant Pages

    • RE: Login Attempt Limits
      ... >> of the attempts come from hacked SSHD servers because the attempt ... > passwords from the ... >> Hence that option would not address the current attack patterns. ...
      (SSH)
    • RE: Login Attempt Limits
      ... I had around 650 failed atttempts on the SSHD server from about 5 ... servers are not requiring sufficiently random passwords for their uesrs. ... Hence that option would not address the current attack patterns. ... and similarly a 5 bit reduction in the number of failed SSHD servers. ...
      (SSH)
    • Re: limiting ssh login attempts by ip
      ... >I wrote a script that creates firewall rules to drop packets from IPs ... >How do you protect your servers from this kind of attack? ... to only allow sshd to accept connections from ...
      (freebsd-questions)
    • Re: High levels of breakin attempts
      ... >> brute force attacks logged by sshd. ... to an easy denial-of-service attack. ... with default passwords on a number of accounts. ... feel better to lock out such "attacks," but I don't actually kid ...
      (freebsd-questions)
    • Re: Attempt to breakin
      ... >>2) Lock out direct root logins, require people to come in as a normal ... Nobody can guess passwords if sshd won't accept passwords ... >> off or add deny entries in hosts.allow to block access to sshd from ...
      (comp.os.linux.networking)