using PubkeyAuthentication, still getting dictionary attacks! - SSH

This is a discussion on using PubkeyAuthentication, still getting dictionary attacks! - SSH ; I used to run my ssh server on a high port no. to avoid the dictionary attacks. It worked quite well but I've had to go back to good ol' port 22 because I've been plugging laptop into networks with ...

+ Reply to Thread
Results 1 to 19 of 19

Thread: using PubkeyAuthentication, still getting dictionary attacks!

  1. using PubkeyAuthentication, still getting dictionary attacks!

    I used to run my ssh server on a high port no. to avoid the dictionary
    attacks. It worked quite well but I've had to go back to good ol' port
    22 because I've been plugging laptop into networks with *crazy*
    restrictions like blocking huge ranges of client ports except for
    specific services.

    So I've changed the server config to allow PubkeyAuthentication only,
    and that's working fine, BUT the dictionary attacks are still
    coming. (See below for the sort of stuff I mean, in syslog.)

    AIUI, dictionary attacks on PubkeyAuthentication are hopeless, and I'm
    surprised the attacking "clients" try it. Am I right? Why do they keep
    trying? Anything else I can/should do?

    Thanks!



    Invalid user webmaster from 24.148.29.250
    Invalid user ftp from 24.148.29.250
    Invalid user sales from 24.148.29.250
    Invalid user admin from 24.148.29.250
    Invalid user andrea from 24.148.29.250
    Invalid user guest from 24.148.29.250
    Invalid user guest1 from 24.148.29.250
    Invalid user guest2 from 24.148.29.250
    Invalid user guest3 from 24.148.29.250
    Invalid user guest4 from 24.148.29.250
    Invalid user guest5 from 24.148.29.250
    Invalid user guest6 from 24.148.29.250
    Invalid user guest7 from 24.148.29.250
    Invalid user guest8 from 24.148.29.250
    Invalid user guest9 from 24.148.29.250


  2. Re: using PubkeyAuthentication, still getting dictionary attacks!

    Nomen Nescio wrote:

    > I used to run my ssh server on a high port no. to avoid the dictionary
    > attacks. It worked quite well but I've had to go back to good ol' port
    > 22 because I've been plugging laptop into networks with *crazy*
    > restrictions like blocking huge ranges of client ports except for
    > specific services.
    >
    > So I've changed the server config to allow PubkeyAuthentication only,
    > and that's working fine, BUT the dictionary attacks are still
    > coming. (See below for the sort of stuff I mean, in syslog.)
    >
    > AIUI, dictionary attacks on PubkeyAuthentication are hopeless, and I'm
    > surprised the attacking "clients" try it. Am I right? Why do they keep
    > trying? Anything else I can/should do?


    How should they know you have disabled password authetication? (you did,
    didn't you?)
    --
    Cezary Morga

  3. Re: using PubkeyAuthentication, still getting dictionary attacks!

    Nomen Nescio wrote:
    > I used to run my ssh server on a high port no. to avoid the dictionary
    > attacks. It worked quite well but I've had to go back to good ol' port
    > 22 because I've been plugging laptop into networks with *crazy*
    > restrictions like blocking huge ranges of client ports except for
    > specific services.


    I've thought about a stupid simple web page (most sites would allow 80)
    that I could type in an IP address and enable that address for port 22.
    Even with *zero* authentication on the web page, I don't think it would
    be a problem. A bot isn't going to do that kind of work for one host.

    > AIUI, dictionary attacks on PubkeyAuthentication are hopeless, and I'm
    > surprised the attacking "clients" try it. Am I right? Why do they keep
    > trying?


    Stupid bots don't care.

    --
    Darren Dunham ddunham@taos.com
    Senior Technical Consultant TAOS http://www.taos.com/
    Got some Dr Pepper? San Francisco, CA bay area
    < This line left intentionally blank to confuse you. >

  4. Re: using PubkeyAuthentication, still getting dictionary attacks!

    Nomen Nescio writes:

    >I used to run my ssh server on a high port no. to avoid the dictionary
    >attacks. It worked quite well but I've had to go back to good ol' port
    >22 because I've been plugging laptop into networks with *crazy*
    >restrictions like blocking huge ranges of client ports except for
    >specific services.


    >So I've changed the server config to allow PubkeyAuthentication only,
    >and that's working fine, BUT the dictionary attacks are still
    >coming. (See below for the sort of stuff I mean, in syslog.)


    >AIUI, dictionary attacks on PubkeyAuthentication are hopeless, and I'm
    >surprised the attacking "clients" try it. Am I right? Why do they keep
    >trying? Anything else I can/should do?


    Do you thinkthat there is a human being behind those attacks, trying all
    the passwords? It is a program. which is launched from someone else's
    computer.

    You could just put that IP address into /etc/hosts.allow with a deny tag
    for ssh.
    sshd: 24.148.29.250:deny


    >Thanks!




    >Invalid user webmaster from 24.148.29.250
    >Invalid user ftp from 24.148.29.250
    >Invalid user sales from 24.148.29.250
    >Invalid user admin from 24.148.29.250
    >Invalid user andrea from 24.148.29.250
    >Invalid user guest from 24.148.29.250
    >Invalid user guest1 from 24.148.29.250
    >Invalid user guest2 from 24.148.29.250
    >Invalid user guest3 from 24.148.29.250
    >Invalid user guest4 from 24.148.29.250
    >Invalid user guest5 from 24.148.29.250
    >Invalid user guest6 from 24.148.29.250
    >Invalid user guest7 from 24.148.29.250
    >Invalid user guest8 from 24.148.29.250
    >Invalid user guest9 from 24.148.29.250



  5. Re: using PubkeyAuthentication, still getting dictionary attacks!

    Darren Dunham writes:

    >Nomen Nescio wrote:
    >> I used to run my ssh server on a high port no. to avoid the dictionary
    >> attacks. It worked quite well but I've had to go back to good ol' port
    >> 22 because I've been plugging laptop into networks with *crazy*
    >> restrictions like blocking huge ranges of client ports except for
    >> specific services.


    >I've thought about a stupid simple web page (most sites would allow 80)
    >that I could type in an IP address and enable that address for port 22.
    >Even with *zero* authentication on the web page, I don't think it would
    >be a problem. A bot isn't going to do that kind of work for one host.


    Or you could simply have your ssh respond to port 80. Unless you actually
    have a web server running on that machine, that will be fine.

    >> AIUI, dictionary attacks on PubkeyAuthentication are hopeless, and I'm
    >> surprised the attacking "clients" try it. Am I right? Why do they keep
    >> trying?


    >Stupid bots don't care.


    >--
    >Darren Dunham ddunham@taos.com
    >Senior Technical Consultant TAOS http://www.taos.com/
    >Got some Dr Pepper? San Francisco, CA bay area
    > < This line left intentionally blank to confuse you. >


  6. Re: using PubkeyAuthentication, still getting dictionary attacks!

    Nomen Nescio writes:

    > Why do they keep
    > trying?


    Because they're script kiddie attacks and will try no matter what your
    config.

    > Anything else I can/should do?


    Just move sshd to listen on a non-standard port and the annoyance will
    cease.

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

  7. Re: using PubkeyAuthentication, still getting dictionary attacks!

    Todd H. wrote:
    > Nomen Nescio writes:
    >
    >> Why do they keep
    >> trying?

    >
    > Because they're script kiddie attacks and will try no matter what your
    > config.
    >
    >> Anything else I can/should do?

    >
    > Just move sshd to listen on a non-standard port and the annoyance will
    > cease.
    >


    Or just don't worry about it if you've disabled password authentication.
    That keeps them busy trying hopelessly to get into your server instead
    of attacking one that's truly vulnerable.

  8. Re: using PubkeyAuthentication, still getting dictionary attacks!

    Chuck writes:

    > Todd H. wrote:
    > > Nomen Nescio writes:
    > >
    > >> Why do they keep
    > >> trying?

    > >
    > > Because they're script kiddie attacks and will try no matter what your
    > > config.
    > >
    > >> Anything else I can/should do?

    > >
    > > Just move sshd to listen on a non-standard port and the annoyance will
    > > cease.
    > >

    >
    > Or just don't worry about it if you've disabled password authentication.
    > That keeps them busy trying hopelessly to get into your server instead
    > of attacking one that's truly vulnerable.


    If the sshd server isn't there to listen to an attack on port 22, sshd
    won't cut a failed login attempt to a log. The host level port
    filter will just quietly ignore the tcp connection request. Seems to
    work a treat.



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

  9. Re: using PubkeyAuthentication, still getting dictionary attacks!

    I am surprised that no one has mentioned the possibility of using
    IPTables in order to address the issue raised by the OP, all the more so
    bearing in mind that he seems to be annoyed about his logs getting full of
    traces from those childish dictionary attacks.

    This is a deterrent against SSH breakin attempts. Without this,
    /var/log/ messages tends to get flooded by traces from such attempts. The
    last two lines of this script prevent such attempts to take place more
    frequently than every 15 seconds. Effectively, a failed SSH login attempt
    from a given IP address results in any further SSH login attempts from
    that address to be summarily dismissed for 15 seconds. The first line in
    the script is there so that this mechanism is not used in the 192.168.0
    internal network.


    iptables -A INPUT -p tcp -i eth0 -s 192.168.0.0/24 --dport 22 -j ACCEPT
    iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m recent --update --seconds 15 -j DROP
    iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m recent --set -j ACCEPT



  10. Re: using PubkeyAuthentication, still getting dictionary attacks!

    In comp.security.ssh Frank W. Steiner :
    > I am surprised that no one has mentioned the possibility of using
    > IPTables in order to address the issue raised by the OP, all the more so


    I am surprised how you got the OP would run Linux at all?

    [..]

    BTW
    Please quote some context on reply, thx.

    --
    Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
    mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
    #bofh excuse 162: bugs in the RAID

  11. Re: using PubkeyAuthentication, still getting dictionary attacks!



    On Oct 5, 3:52 pm, Frank W. Steiner wrote:
    [snip]
    > This is a deterrent against SSH breakin attempts. Without this,
    > /var/log/ messages tends to get flooded by traces from such attempts. The
    > last two lines of this script prevent such attempts to take place more
    > frequently than every 15 seconds. Effectively, a failed SSH login attempt
    > from a given IP address results in any further SSH login attempts from
    > that address to be summarily dismissed for 15 seconds. The first line in
    > the script is there so that this mechanism is not used in the 192.168.0
    > internal network.
    >
    > iptables -A INPUT -p tcp -i eth0 -s 192.168.0.0/24 --dport 22 -j ACCEPT
    > iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m recent --update --seconds 15 -j DROP
    > iptables -A INPUT -p tcp -i eth0 -m state --state NEW --dport 22 -m recent --set -j ACCEPT


    And if you don't want or can't use iptables, then look for DenyHosts
    which does a similar function using the tcp_wrappers support that most
    sshd daemons are built with.
    --
    René Berber


  12. Re: using PubkeyAuthentication, still getting dictionary attacks!

    Unruh wrote:

    > >AIUI, dictionary attacks on PubkeyAuthentication are hopeless, and I'm
    > >surprised the attacking "clients" try it. Am I right? Why do they keep
    > >trying? Anything else I can/should do?

    >
    > Do you thinkthat there is a human being behind those attacks, trying all
    > the passwords? It is a program. which is launched from someone else's
    > computer.


    Of course I know that ... what I mean is, can't the bot tell that the
    server only takes key authentication?

    What's the bot trying to send me, random big numbers?


  13. Re: using PubkeyAuthentication, still getting dictionary attacks!

    Cezary Morga wrote:

    > How should they know you have disabled password authetication?


    My ssh client can tell. If I try to log in without the key loaded in
    ssh-agent and I hit enter when it asks for the key passphrase, ssh no
    longer asks me for the login password next, it just says "Permission
    denied (publickey)", so can't the bot tell the same thing?


    > (you did, didn't you?)


    Yes, that's what I meant! Here are the bits of sshd_config:

    RSAAuthentication yes
    PubkeyAuthentication yes
    IgnoreRhosts yes
    RhostsRSAAuthentication no
    HostbasedAuthentication no
    PermitEmptyPasswords no
    ChallengeResponseAuthentication no
    PasswordAuthentication no


  14. Re: using PubkeyAuthentication, still getting dictionary attacks!

    >>>>> "NN" == Nomen Nescio writes:

    NN> Unruh wrote:
    >> >AIUI, dictionary attacks on PubkeyAuthentication are hopeless, and

    >> I'm >surprised the attacking "clients" try it. Am I right? Why do
    >> they keep >trying? Anything else I can/should do?
    >>
    >> Do you thinkthat there is a human being behind those attacks,
    >> trying all the passwords? It is a program. which is launched from
    >> someone else's computer.


    NN> Of course I know that ... what I mean is, can't the bot tell that
    NN> the server only takes key authentication?

    NN> What's the bot trying to send me, random big numbers?

    No, it's likely still trying password authentication. The SSH-AUTH
    protocol allows a client to try any authentication method it likes at any
    point, regardless of whether the server accepts it. The attack program in
    question probably just connects and tries passwords, without bothering to
    notice whether password authentication is even supported.

    --
    Richard Silverman
    res@qoxp.net


  15. Re: using PubkeyAuthentication, still getting dictionary attacks!

    "Richard E. Silverman" wrote:

    > NN> Of course I know that ... what I mean is, can't the bot tell that
    > NN> the server only takes key authentication?
    >
    > NN> What's the bot trying to send me, random big numbers?
    >
    > No, it's likely still trying password authentication. The SSH-AUTH
    > protocol allows a client to try any authentication method it likes at any
    > point, regardless of whether the server accepts it. The attack program in
    > question probably just connects and tries passwords, without bothering to
    > notice whether password authentication is even supported.


    Now I see! My "normal" ssh client doesn't give me a paswsord option
    because the server has told it not to bother. The bot tries it anyway
    because it wasn't paying attention.

    Stupid bot!



  16. Re: using PubkeyAuthentication, still getting dictionary attacks!

    Todd H. wrote:
    > Chuck writes:
    >
    >> Todd H. wrote:
    >>> Nomen Nescio writes:
    >>>
    >>>> Why do they keep
    >>>> trying?
    >>> Because they're script kiddie attacks and will try no matter what your
    >>> config.
    >>>
    >>>> Anything else I can/should do?
    >>> Just move sshd to listen on a non-standard port and the annoyance will
    >>> cease.
    >>>

    >> Or just don't worry about it if you've disabled password authentication.
    >> That keeps them busy trying hopelessly to get into your server instead
    >> of attacking one that's truly vulnerable.

    >
    > If the sshd server isn't there to listen to an attack on port 22, sshd
    > won't cut a failed login attempt to a log. The host level port
    > filter will just quietly ignore the tcp connection request. Seems to
    > work a treat.
    >
    >
    >


    That's what I do too but I think the OP said he needs to set up camp
    behind FW's that he doesn't control. Hence he is stuck with port 22.

  17. Re: using PubkeyAuthentication, still getting dictionary attacks!

    In comp.security.ssh Nomen Nescio :
    > "Richard E. Silverman" wrote:


    >> NN> Of course I know that ... what I mean is, can't the bot tell that
    >> NN> the server only takes key authentication?


    >> NN> What's the bot trying to send me, random big numbers?


    >> No, it's likely still trying password authentication. The SSH-AUTH
    >> protocol allows a client to try any authentication method it likes at any
    >> point, regardless of whether the server accepts it. The attack program in
    >> question probably just connects and tries passwords, without bothering to
    >> notice whether password authentication is even supported.


    > Now I see! My "normal" ssh client doesn't give me a paswsord option
    > because the server has told it not to bother.


    Not exactly, your client asks the sshd for key authentication
    before password authentication if this succeeds, there is no need
    for any other authentication, you are already logged in.

    You can see this if you just try 'ssh -vvv remotehost'.

    debug1: Authentications that can continue:
    publickey,password,keyboard-interactive

    ^^^^^^^^^

    As first.

    --
    Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
    mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
    #bofh excuse 88: Boss' kid ****ed up the machine

  18. Re: using PubkeyAuthentication, still getting dictionary attacks!

    >>>>> "MH" == Michael Heiming writes:

    MH> In comp.security.ssh Nomen Nescio :
    >> "Richard E. Silverman" wrote:


    NN> Of course I know that ... what I mean is, can't the bot tell that
    NN> the server only takes key authentication?

    NN> What's the bot trying to send me, random big numbers?

    >>> No, it's likely still trying password authentication. The
    >>> SSH-AUTH protocol allows a client to try any authentication method
    >>> it likes at any point, regardless of whether the server accepts
    >>> it. The attack program in question probably just connects and
    >>> tries passwords, without bothering to notice whether password
    >>> authentication is even supported.


    >> Now I see! My "normal" ssh client doesn't give me a paswsord option
    >> because the server has told it not to bother.


    MH> Not exactly, your client asks the sshd for key authentication
    MH> before password authentication if this succeeds, there is no need
    MH> for any other authentication, you are already logged in.

    MH> You can see this if you just try 'ssh -vvv remotehost'.

    It may or may not do this; it depends on the method order defined in the
    client configuration with PreferredAuthentications.

    MH> debug1: Authentications that can continue:
    MH> publickey,password,keyboard-interactive
    MH> ^^^^^^^^^

    MH> As first.

    This is actually irrelevant. The client is showing methods supported by
    the server, in the order in which the server happens to list them. It
    does not actually show the order in which it will try them. Play with
    PreferredAuthentications a bit and you will see this.

    --
    Richard Silverman
    res@qoxp.net


  19. Re: using PubkeyAuthentication, still getting dictionary attacks!

    In comp.security.ssh Richard E. Silverman :
    >>>>>> "MH" == Michael Heiming writes:


    > MH> In comp.security.ssh Nomen Nescio :
    > >> "Richard E. Silverman" wrote:


    > NN> Of course I know that ... what I mean is, can't the bot tell that
    > NN> the server only takes key authentication?


    > NN> What's the bot trying to send me, random big numbers?


    > >>> No, it's likely still trying password authentication. The
    > >>> SSH-AUTH protocol allows a client to try any authentication method
    > >>> it likes at any point, regardless of whether the server accepts
    > >>> it. The attack program in question probably just connects and
    > >>> tries passwords, without bothering to notice whether password
    > >>> authentication is even supported.


    > >> Now I see! My "normal" ssh client doesn't give me a paswsord option
    > >> because the server has told it not to bother.


    > MH> Not exactly, your client asks the sshd for key authentication
    > MH> before password authentication if this succeeds, there is no need
    > MH> for any other authentication, you are already logged in.


    > MH> You can see this if you just try 'ssh -vvv remotehost'.


    > It may or may not do this; it depends on the method order defined in the
    > client configuration with PreferredAuthentications.


    Presuming zero client configuration, which seems fair, at least
    the openssh client defaults to key authentication if it finds
    some.

    > MH> debug1: Authentications that can continue:
    > MH> publickey,password,keyboard-interactive
    > MH> ^^^^^^^^^


    > MH> As first.


    > This is actually irrelevant. The client is showing methods supported by
    > the server, in the order in which the server happens to list them. It
    > does not actually show the order in which it will try them. Play with
    > PreferredAuthentications a bit and you will see this.


    Indeed, but it goes on like this:

    debug3: start over, passed a different list publickey,password,keyboard-interactive
    debug3: preferred publickey,keyboard-interactive,password
    debug3: authmethod_lookup publickey

    A little later:

    debug1: Server accepts key: pkalg ssh-dss blen 433
    [..]
    debug1: Entering interactive session.

    I trust you that the message was just showing the supported
    methods.

    Best regards

    --
    Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
    mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
    #bofh excuse 394: Jupiter is aligned with Mars.

+ Reply to Thread