RE: Login Attempt Limits

From: Mojito Jones (mojito_at_gmail.com)
Date: 05/07/05

  • Next message: Corey: "Re: bash_logout and sftp" 
    To: <secureshell@securityfocus.com>
Date: Fri, 6 May 2005 18:40:30 -0400

    This is easier:

    $IPTABLES -A allowed -p TCP -m state --state ESTABLISHED,RELATED -j ACCEPT

    $IPTABLES -A allowed -p TCP --syn -m limit --limit 3/minute --limit-burst 3
    -j ACCEPT

    $IPTABLES -A allowed -p TCP -j LOG --log-level "NOTICE" --log-prefix
    '[DROP:RATE_LIMIT] '

    $IPTABLES -A allowed -p TCP -j REJECT

    $IPTABLES -A tcp_packets -p TCP -s 0/0 -d $INET_IP --dport 22 -j allowed

    Mojito

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

  • Next message: Corey: "Re: bash_logout and sftp"

    Relevant Pages

    • 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)
    • 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)
    • 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)
    • 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: 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)