RE: Login Attempt Limits

From: Price, Christopher (Christopher.Price_at_encana.com)
Date: 05/05/05

  • Next message: Robert L Sowders: "Re: Login Attempt Limits" 
    Date: Thu, 5 May 2005 13:13:06 -0600
To: "MPHMedia.Net" <MPHMedia@InfoWest.com>, <secureshell@securityfocus.com>

            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: Robert L Sowders: "Re: Login Attempt Limits"

    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
      ... > ranges of IP addresses access to your SSHD service by using IP spoofing, ... > servers are not requiring sufficiently random passwords for their uesrs. ... > Hence that option would not address the current attack patterns. ...
      (SSH)
    • 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: Login Attempt Limits
      ... servers are not requiring sufficiently random passwords for their uesrs. ... Execute an IP block as above when there are 3 root user failures. ... Hence that option would not address the current attack patterns. ... and similarly a 5 bit reduction in the number of failed SSHD servers. ...
      (SSH)
    • Login Attempt Limits
      ... servers are not requiring sufficiently random passwords for their uesrs. ... Execute an IP block as above when there are 3 root user failures. ... Hence that option would not address the current attack patterns. ... and similarly a 5 bit reduction in the number of failed SSHD servers. ...
      (SSH)