Options to block brute force attacks - SSH

This is a discussion on Options to block brute force attacks - SSH ; My server often records log attempts of brute force attacks on system accounts, trying to connect to ssh and enter root password many times. Mostly coming from known spam havens like China and Korea. They would be unlikely to guess ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: Options to block brute force attacks

  1. Options to block brute force attacks

    My server often records log attempts of brute force attacks on system
    accounts, trying to connect to ssh and enter root password many
    times. Mostly coming from known spam havens like China and Korea.

    They would be unlikely to guess my root password, but who knows, I do
    not like that.

    My question is, is there some simple way to block them, say by
    ignoring a client for a certain period of time after, say, 20 failed
    logons without 5 minutes, or some such.

    thanks

    i


  2. Re: Options to block brute force attacks

    Ignoramus1759 writes:

    > My server often records log attempts of brute force attacks on system
    > accounts, trying to connect to ssh and enter root password many
    > times. Mostly coming from known spam havens like China and Korea.
    >
    > They would be unlikely to guess my root password, but who knows, I do
    > not like that.
    >
    > My question is, is there some simple way to block them, say by
    > ignoring a client for a certain period of time after, say, 20 failed
    > logons without 5 minutes, or some such.



    An IDS/IPS that locks out a given IP after so many failures is one
    option.

    I've considered moving ssh to a non-standard port on some of my
    servers to reduce the amount of crap to wade through on logs.



    --
    Todd H.
    http://www.toddh.net/

  3. Re: Options to block brute force attacks

    On 07 Sep 2006 10:10:46 -0500, Todd H. wrote:
    > Ignoramus1759 writes:
    >
    >> My server often records log attempts of brute force attacks on system
    >> accounts, trying to connect to ssh and enter root password many
    >> times. Mostly coming from known spam havens like China and Korea.
    >>
    >> They would be unlikely to guess my root password, but who knows, I do
    >> not like that.
    >>
    >> My question is, is there some simple way to block them, say by
    >> ignoring a client for a certain period of time after, say, 20 failed
    >> logons without 5 minutes, or some such.

    >
    >
    > An IDS/IPS that locks out a given IP after so many failures is one
    > option.
    >
    > I've considered moving ssh to a non-standard port on some of my
    > servers to reduce the amount of crap to wade through on logs.


    If I understand you correctly, SSH does not offer any support for
    this, right? I am not in favor of blocking IPs automatically.

    i


  4. Re: Options to block brute force attacks

    Ignoramus1759 writes:

    > If I understand you correctly, SSH does not offer any support for
    > this, right?


    Nah, it's supported. It's just not hte standard/usual port 22 that is
    IANA registered as the usual tcp port for sshd to listen on.

    You just set the config file to tell sshd to listen on a different
    port number. /etc/ssh/sshd_config the Port directive for OpenSSH.

    All clients I have support this as well. Command line it's just
    $ ssh -p XXXX user@server.name.com

    The only problem you may have is if you work in nazi intranet
    environments that allow outbound SSH connections on the well known
    port (22) and block it on non-standard ports.

    >I am not in favor of blocking IPs automatically.


    Yeah there are downsides.

    --
    Todd H.
    http://www.toddh.net/

  5. Re: Options to block brute force attacks

    On 07 Sep 2006 10:38:28 -0500, Todd H. wrote:
    > Ignoramus1759 writes:
    >
    >> If I understand you correctly, SSH does not offer any support for
    >> this, right?

    >
    > Nah, it's supported. It's just not hte standard/usual port 22 that is
    > IANA registered as the usual tcp port for sshd to listen on.
    >
    > You just set the config file to tell sshd to listen on a different
    > port number. /etc/ssh/sshd_config the Port directive for OpenSSH.


    Sorry for my poorly worded question.

    Let me rephrase it.

    If I understand you correctly, SSH does not offer any support for
    blocking brute force attacks, right?


    > All clients I have support this as well. Command line it's just
    > $ ssh -p XXXX user@server.name.com
    >
    > The only problem you may have is if you work in nazi intranet
    > environments that allow outbound SSH connections on the well known
    > port (22) and block it on non-standard ports.


    Yes, indeed, I am a little leery. I used to use onnstandard ports in
    the past.

    i


  6. Re: Options to block brute force attacks

    Ignoramus1759 writes:

    > If I understand you correctly, SSH does not offer any support for
    > blocking brute force attacks, right?


    Oh, no not that I'm at least aware of. But there's much of which I'm
    unaware.

    --
    Todd H.
    http://www.toddh.net/

  7. Re: Options to block brute force attacks


    "Todd H." wrote in message news:84odtradc6.fsf@ripco.com...
    > Ignoramus1759 writes:
    >
    >> If I understand you correctly, SSH does not offer any support for
    >> blocking brute force attacks, right?

    >
    > Oh, no not that I'm at least aware of. But there's much of which I'm
    > unaware.


    There IS this feature:

    MaxStartups
    Specifies the maximum number of concurrent unauthenticated con-
    nections to the SSH daemon. Additional connections will be
    dropped until authentication succeeds or the LoginGraceTime ex-
    pires for a connection. The default is 10.

    Alternatively, random early drop can be enabled by specifying the
    three colon separated values ``start:rate:full'' (e.g.
    "10:30:60"). sshd(8) will refuse connection attempts with a
    probability of ``rate/100'' (30%) if there are currently
    ``start'' (10) unauthenticated connections. The probability in-
    creases linearly and all connection attempts are refused if the
    number of unauthenticated connections reaches ``full'' (60).



  8. Re: Options to block brute force attacks

    Ignoramus1759 wrote:
    > If I understand you correctly, SSH does not offer any support for
    > blocking brute force attacks, right?


    It does. All the SSH servers I know of have an option for setting
    the allowable authentication methods. Just remove passwords as
    an allowable authentication method, leaving only the public-key
    methods. Since passwords aren't accepted at all, attempts to use
    them will always be rejected.

    Of course there's a chicken-and-egg problem: if you have a new
    client machine with a freshly-generated key pair you need to
    log onto the server to add the key into the authorized-keys file,
    but you can't log in until after you've uploaded the key.

    --
    death.net: because for some problems there's only one solution.

  9. Re: Options to block brute force attacks

    On Thu, 7 Sep 2006 17:04:18 GMT, Mike Lowery wrote:
    >
    > "Todd H." wrote in message news:84odtradc6.fsf@ripco.com...
    >> Ignoramus1759 writes:
    >>
    >>> If I understand you correctly, SSH does not offer any support for
    >>> blocking brute force attacks, right?

    >>
    >> Oh, no not that I'm at least aware of. But there's much of which I'm
    >> unaware.

    >
    > There IS this feature:
    >
    > MaxStartups
    > Specifies the maximum number of concurrent unauthenticated con-
    > nections to the SSH daemon. Additional connections will be
    > dropped until authentication succeeds or the LoginGraceTime ex-
    > pires for a connection. The default is 10.
    >
    > Alternatively, random early drop can be enabled by specifying the
    > three colon separated values ``start:rate:full'' (e.g.
    > "10:30:60"). sshd(8) will refuse connection attempts with a
    > probability of ``rate/100'' (30%) if there are currently
    > ``start'' (10) unauthenticated connections. The probability in-
    > creases linearly and all connection attempts are refused if the
    > number of unauthenticated connections reaches ``full'' (60).
    >
    >


    Looks very nice. Is there some way to exempt some hosts (like my home
    computer) from these limits? Otherwise, a password attack becomes a
    DOS attack.

    I will likely put them to use in any case. Thanks!

    i


  10. Re: Options to block brute force attacks


    Ignoramus1759 wrote:

    > My server often records log attempts of brute force attacks on system
    > accounts, trying to connect to ssh and enter root password many
    > times. Mostly coming from known spam havens like China and Korea.
    >
    > They would be unlikely to guess my root password, but who knows, I do
    > not like that.
    >
    > My question is, is there some simple way to block them, say by
    > ignoring a client for a certain period of time after, say, 20 failed
    > logons without 5 minutes, or some such.


    Yes, I'm using DenyHosts and it works very well. Take a look at:

    http://www.denyhosts.net/

    As others have replied, sshd_config does have several options you can
    use, I use the following (in addition to DenyHosts):

    MaxStartups 1:3:6
    AllowUsers ...
    #AllowGroups ...

    The last two can be used together and both have to be satisfied. I
    only use AllowUsers where you can specify not only the user name but
    from where, as in root@spark.mydomain.com

    HTH
    --
    René Berber


  11. Re: Options to block brute force attacks

    On Thu, 07 Sep 2006 14:56:41 GMT, Ignoramus1759
    wrote:

    >My server often records log attempts of brute force attacks on system
    >accounts, trying to connect to ssh and enter root password many
    >times. Mostly coming from known spam havens like China and Korea.
    >
    >They would be unlikely to guess my root password, but who knows, I do
    >not like that.
    >
    >My question is, is there some simple way to block them, say by
    >ignoring a client for a certain period of time after, say, 20 failed
    >logons without 5 minutes, or some such.


    I'm assuming that you have already limited SSH login to normal user
    accounts, excluding direct login to role accounts. If "root" isn't an
    authorized SSH login, no password-guessing attack for that account can
    do anything but fill your logs. If one of the users with login
    permission needs root access, they have to `su` ... and leave anaudit
    trail.

    Beyond that, though, you still need to defend the SSH port against two
    things: log-filling DOS attacks, and the possibility of a
    vulnerability in the SSH code that permits a knowledgeable attacker to
    gain access in some unorthodox manner.

    Absolutely the easiest way to defend your system against those
    eventualities is to firewall the SSH port against the entire 'net,
    except those areas from which authorized users are likely to wish to
    connect.

    If you know the places from which authorized connections are likely,
    say by reviewing your logs, you can open them _a_priori_. If not, you
    can use a portknocking scheme to open various ports on demand.
    Portknocking seems to be invulnerable in practice, although, in
    theory, an attacker could break it, given enough time. However, even
    a one-port knocking scheme, with a one-minute wait time after
    knocking, would require that an attacker spend 32,000 minutes
    (approximately, on average) knocking. Since there's no assurance (to
    the attacker) that _any_ amount of knocking will open the port, it
    would seem a bootless exercise for him.

    -Shel


  12. Re: Options to block brute force attacks

    "Mike Lowery" writes:

    > "Todd H." wrote in message news:84odtradc6.fsf@ripco.com...
    >> Ignoramus1759 writes:
    >>
    >>> If I understand you correctly, SSH does not offer any support for
    >>> blocking brute force attacks, right?

    >>
    >> Oh, no not that I'm at least aware of. But there's much of which I'm
    >> unaware.

    >
    > There IS this feature:
    >
    > MaxStartups
    > Specifies the maximum number of concurrent unauthenticated con-
    > nections to the SSH daemon. Additional connections will be
    > dropped until authentication succeeds or the LoginGraceTime ex-
    > pires for a connection. The default is 10.
    >
    > Alternatively, random early drop can be enabled by specifying the
    > three colon separated values ``start:rate:full'' (e.g.
    > "10:30:60"). sshd(8) will refuse connection attempts with a
    > probability of ``rate/100'' (30%) if there are currently
    > ``start'' (10) unauthenticated connections. The probability in-
    > creases linearly and all connection attempts are refused if the
    > number of unauthenticated connections reaches ``full'' (60).


    Hi Mike,

    Correct me if I'm wrong, but the implication here is that a
    brute-force attack is usually orchestrated by ganging up as many
    simultaneous connections (N) to the target as possible, essentially
    allowing N password attempts per T time, where T is the time to
    connect, enter a password, observe the response, and disconnect. This
    gives attackers a speed-up of a factor of N over a simple
    one-at-a-time approach. Am I thinking about this correctly?

    While I see that, given this attack tactic, the "three colon
    separated" version of MaxStartups, S:P:M, can help mitigate
    brute-force attacks by a factor >= N/M, it still doesn't eliminate
    them.

    There seem to be superior solutions. For example, establish a maximum
    number N of connection attempts from any specific domain. This would
    imply that the maximum number of *simultaneous* connections from that
    domain is also N.

    However, this technique may become inefficient for the daemon because it
    requires every domain that's ever attempted to connect to be stored in
    a database, and the database must be searched for each new connection.

    Therefore one way to mitigate this problem is to augment the approach
    above to also specify a "timeout period" after which connections from
    the domain are allowed again. For example establish a new parameter
    MaxAttempt = K:L, where K is the maximum number of attempts that
    are allowed and L is a timeout period (say, in seconds) after
    which the daemon will allow the domain to attempt to connect once
    again. In this manner the daemon only has to keep domains that attempted
    to connect in the last L seconds, and could possibly just keep this
    in cache memory rather than storing to non-volatile storage.
    --
    % Randy Yates % "Remember the good old 1980's, when
    %% Fuquay-Varina, NC % things were so uncomplicated?"
    %%% 919-577-9882 % 'Ticket To The Moon'
    %%%% % *Time*, Electric Light Orchestra
    http://home.earthlink.net/~yatescr

  13. Re: Options to block brute force attacks


    Randy Yates wrote:

    [snip]
    > Hi Mike,


    I'm not Mike but...

    > Correct me if I'm wrong, but the implication here is that a
    > brute-force attack is usually orchestrated by ganging up as many
    > simultaneous connections (N) to the target as possible, essentially
    > allowing N password attempts per T time, where T is the time to
    > connect, enter a password, observe the response, and disconnect. This
    > gives attackers a speed-up of a factor of N over a simple
    > one-at-a-time approach. Am I thinking about this correctly?


    No. There are many different brute force attack procedures, from the
    simplest of one connection trying passwords for one user name, to the
    most complex of distributed connections trying passwords for multiple
    users.

    The configuration parameters for sshd try to address any kind of
    flooding, not necesarily an attack but you play your odds.

    Other alternatives, and they have been discused in this list recently,
    are teergrube (tar pits) and automated tcp_wrappers use (like DenyHosts
    that I mentioned wich also includes sharing of known attacker IPs).
    The first one slows down the attacker (attacker is defined as anyone
    giving invalid passwords repetedly), the second uses the optional
    compiled support for tcp_wrappers in sshd to deny connections after a
    threshold is reached.

    > While I see that, given this attack tactic, the "three colon
    > separated" version of MaxStartups, S:P:M, can help mitigate
    > brute-force attacks by a factor >= N/M, it still doesn't eliminate
    > them.


    Correct. None of the counter-measures eliminate attacks.

    > There seem to be superior solutions. For example, establish a maximum
    > number N of connection attempts from any specific domain. This would
    > imply that the maximum number of *simultaneous* connections from that
    > domain is also N.


    Yes, and that could be done at the firewall.

    > However, this technique may become inefficient for the daemon because it
    > requires every domain that's ever attempted to connect to be stored in
    > a database, and the database must be searched for each new connection.


    Usually those databases include a timestamp and they are cleaned
    periodically.

    > Therefore one way to mitigate this problem is to augment the approach
    > above to also specify a "timeout period" after which connections from
    > the domain are allowed again. For example establish a new parameter
    > MaxAttempt = K:L, where K is the maximum number of attempts that
    > are allowed and L is a timeout period (say, in seconds) after
    > which the daemon will allow the domain to attempt to connect once
    > again. In this manner the daemon only has to keep domains that attempted
    > to connect in the last L seconds, and could possibly just keep this
    > in cache memory rather than storing to non-volatile storage.


    All this is done by DenyHosts and other similar programs.

    One thing not discused is that the parameters have to be determined for
    each situation, if you have low connection rates the values should be
    low numbers, but if you have a server that many people use
    simultaneously then the numbers will have to be higher.

    Regards.
    --
    René Berber


+ Reply to Thread