ssh dictionary attacks - Security

This is a discussion on ssh dictionary attacks - Security ; This is something that comes up once in a while... I've been subject to them as well. I've come across a couple of projects that build a 'tarpit' for attackers - the first one is for SMTP and the second ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 29

Thread: ssh dictionary attacks

  1. ssh dictionary attacks

    This is something that comes up once in a while... I've been subject to
    them as well.

    I've come across a couple of projects that build a 'tarpit' for attackers
    - the first one is for SMTP and the second one is more generic.

    I've often wondered if one couldn't use this to at least slow down a
    dictionary attack on ssh. It wouldn't do much good for a distributed
    attack, but it might for an attack comming from a few hosts.

    Any thoughts? Comments? This is sort of a curiosity quesiton for me; I
    don't know enough to really make a solid judgement if this would be useful.

    http://www.iks-jena.de/mitarb/lutz/u...rgrube.en.html
    http://labrea.sourceforge.net/labrea-info.html
    --
    o__
    ,>/'_ o__
    (_)\(_) ,>/'_ o__
    Yan Seiner, PE (_)\(_) ,>/'_ o__
    Certified Personal Trainer (_)\(_) ,>/'_ o__
    Licensed Professional Engineer (_)\(_) ,>/'_
    Who says engineers have to be pencil necked geeks? (_)\(_)


  2. Re: ssh dictionary attacks

    Captain Dondo wrote:
    > This is something that comes up once in a while... I've been subject to
    > them as well.
    >
    > I've come across a couple of projects that build a 'tarpit' for attackers
    > - the first one is for SMTP and the second one is more generic.
    >
    > I've often wondered if one couldn't use this to at least slow down a
    > dictionary attack on ssh. It wouldn't do much good for a distributed
    > attack, but it might for an attack comming from a few hosts.
    >
    > Any thoughts? Comments? This is sort of a curiosity quesiton for me; I
    > don't know enough to really make a solid judgement if this would be useful.
    >
    > http://www.iks-jena.de/mitarb/lutz/u...rgrube.en.html
    > http://labrea.sourceforge.net/labrea-info.html


    if your just trying to slow down dictionary attacks, some of these
    methods might help:
    run sshd on a arbitary, high port
    enforce key+password logins
    use iptables to throttle connections to your sshd...
    or tail the auth.log for repeated attempts and drop packets from that
    source host for a short number of minutes

    better to enforce strong passwords and audit your local users' passwords.



  3. Re: ssh dictionary attacks

    john yeo wrote:
    > Captain Dondo wrote:
    >> This is something that comes up once in a while... I've been subject to
    >> them as well.
    >>
    >> I've come across a couple of projects that build a 'tarpit' for attackers
    >> - the first one is for SMTP and the second one is more generic.
    >>
    >> I've often wondered if one couldn't use this to at least slow down a
    >> dictionary attack on ssh. It wouldn't do much good for a distributed
    >> attack, but it might for an attack comming from a few hosts.
    >>
    >> Any thoughts? Comments? This is sort of a curiosity quesiton for me; I
    >> don't know enough to really make a solid judgement if this would be useful.
    >>
    >> http://www.iks-jena.de/mitarb/lutz/u...rgrube.en.html
    >> http://labrea.sourceforge.net/labrea-info.html

    >
    > if your just trying to slow down dictionary attacks, some of these
    > methods might help:
    > run sshd on a arbitary, high port
    > enforce key+password logins
    > use iptables to throttle connections to your sshd...
    > or tail the auth.log for repeated attempts and drop packets from that
    > source host for a short number of minutes
    >
    > better to enforce strong passwords and audit your local users' passwords.


    I'll second the pubkey and throttling suggestions. Throttling can
    possibly lead to a denial of service if you're getting so many attacks
    that legitimate users cannot log in, but that's not true for me, at
    least yet.

    BTW netfilter (iptables) provides tarpitting (-j TARPIT). Note that
    tarpitting still takes system resources to hold a connection open.

  4. Re: ssh dictionary attacks

    On Tue, 15 Aug 2006, in the Usenet newsgroup comp.os.linux.security, in article
    , Captain Dondo wrote:

    >This is something that comes up once in a while... I've been subject to
    >them as well.


    Once in a while???!!!

    >I've come across a couple of projects that build a 'tarpit' for attackers
    >- the first one is for SMTP and the second one is more generic.


    Is that being maintained? Someone posted in 'comp.security.misc' yesterday

    I've just read about LaBrea (http://labrea.sourceforge.net), a tarpit
    program that looks very useful. But I see that it hasn't been updated
    since 2003.

    >I've often wondered if one couldn't use this to at least slow down a
    >dictionary attack on ssh. It wouldn't do much good for a distributed
    >attack, but it might for an attack comming from a few hosts.


    To what end? You'd have a robot playing with a robot. I have better
    things to do with CPU cycles.

    >Any thoughts? Comments? This is sort of a curiosity quesiton for me; I
    >don't know enough to really make a solid judgement if this would be useful.


    Standard answer - don't leave your SSH daemon exposed to the world, unless
    you know you are going to be needing to connect from the world. See
    http://www.iana.org/assignments/ipv4-address-space and you can probably
    put in some firewall rules to ignore huge parts of IP space. Depending on
    your circumstances, you can also reduce exposure by moving the daemon from
    the default port to "somewhere else". Hmmm...

    >Date: Tue, 15 Aug 2006 06:53:56 -0700
    >User-Agent: Pan/0.14.2.91


    There are two good port numbers to use as alternates - 65356 or 14291.

    There are also rules that can be stuck in the firewall to slow down
    repetitive connection attempts.

    Old guy

  5. Re: ssh dictionary attacks

    john yeo wrote:
    >if your just trying to slow down dictionary attacks, some of these
    >methods might help:


    >run sshd on a arbitary, high port
    >enforce key+password logins


    How do you enforce key + password? You can say key-only (which makes
    dictionary attacks completely useless), but I don't know how to say "require a
    key, and also require a password".

    >use iptables to throttle connections to your sshd...
    >or tail the auth.log for repeated attempts and drop packets from that
    >source host for a short number of minutes


    Also, limit connections to users who need it. Removing root from the
    AllowUsers list goes a long way.
    --
    Mark Rafn dagon@dagon.net


  6. Re: ssh dictionary attacks


    Captain Dondo wrote:

    > This is something that comes up once in a while... I've been subject to
    > them as well.
    >
    > I've come across a couple of projects that build a 'tarpit' for attackers
    > - the first one is for SMTP and the second one is more generic.
    >
    > I've often wondered if one couldn't use this to at least slow down a
    > dictionary attack on ssh. It wouldn't do much good for a distributed
    > attack, but it might for an attack comming from a few hosts.
    >
    > Any thoughts? Comments? This is sort of a curiosity quesiton for me; I
    > don't know enough to really make a solid judgement if this would be useful.


    Why just slow them if you can stop them?

    Have you seen DenyHosts http://www.denyhosts.net/ ? It works very
    well.

    I wish I had something similar for pop3, not many attacks but I just
    saw one a couple of days back.
    --
    René Berber


  7. Re: ssh dictionary attacks

    "René Berber" (06-08-15 15:07:56):

    > > This is something that comes up once in a while... I've been subject
    > > to them as well.
    > >
    > > I've come across a couple of projects that build a 'tarpit' for
    > > attackers - the first one is for SMTP and the second one is more
    > > generic.
    > >
    > > I've often wondered if one couldn't use this to at least slow down a
    > > dictionary attack on ssh. It wouldn't do much good for a
    > > distributed attack, but it might for an attack comming from a few
    > > hosts.
    > >
    > > Any thoughts? Comments? This is sort of a curiosity quesiton for
    > > me; I don't know enough to really make a solid judgement if this
    > > would be useful.

    >
    > Why just slow them if you can stop them?


    Easy. Slowing them down saves bandwidth for the whole internet. As
    long as the scanner 'hangs' on scanning your box, it won't issue too
    much traffic. If you banned them, then they would just go further and
    scan the next box. There are in fact scanners, which could
    simultaneously scan multiple boxes, but that is rather rare. Even then,
    if _many_ people helped slowing them down, then a lot of useless traffic
    would be saved.


    Regards,
    E.S.

  8. Re: ssh dictionary attacks

    Captain Dondo (06-08-15 06:53:56):

    > I've come across a couple of projects that build a 'tarpit' for
    > attackers - the first one is for SMTP and the second one is more
    > generic.
    >
    > I've often wondered if one couldn't use this to at least slow down a
    > dictionary attack on ssh. It wouldn't do much good for a distributed
    > attack, but it might for an attack comming from a few hosts.


    Yes, you can. There is an experimental Netfilter [1] target especially
    for this purpose. It's called TARPIT [2]. One way to do this is to
    change the port number for your real SSHd and place such a TARPIT on
    port 22 instead.

    The TARPIT target is still experimental, and thus not distributed with
    the mainstream kernel yet, but I had it running some time ago without
    problems.


    > Any thoughts? Comments? This is sort of a curiosity quesiton for me;
    > I don't know enough to really make a solid judgement if this would be
    > useful.


    Yes, if everybody did that, it would be useful. See my response to René
    Berber.


    Regards,
    E.S.


    References:
    [1] http://www.netfilter.org/
    [2] http://www.netfilter.org/patch-o-matic/pom-extra.html

  9. Re: ssh dictionary attacks

    john yeo (06-08-15 17:14:21):

    > enforce key+password logins


    Using public key authentication is fully appropriate, if your key itself
    is protected by a passphrase. In some environments it would even be
    harmful to use password authentication, too, because someone may somehow
    intercept your login password, and thus be able to log in locally
    (i.e. not via SSH).


    Regards,
    E.S.

  10. Re: ssh dictionary attacks

    Allen Kistler (06-08-15 18:30:26):

    > BTW netfilter (iptables) provides tarpitting (-j TARPIT). Note that
    > tarpitting still takes system resources to hold a connection open.


    Only when connection tracking is activated.


    Regards,
    E.S.

  11. Re: ssh dictionary attacks

    dagon@dagon.net (Mark Rafn) (06-08-15 14:38:37):

    > > enforce key+password logins

    >
    > How do you enforce key + password? You can say key-only (which makes
    > dictionary attacks completely useless), but I don't know how to say
    > "require a key, and also require a password".


    I can only speak for OpenSSH, where this doesn't seem to be possible.
    You can do this indirectly by creating a intermediate user with an
    authorized_keys file, which starts /bin/login or something similar. But
    this is error-prone. Do this only if you know what you're doing.
    Better use keys and secure them with proper passphrases instead.

    If you really want to do this, them give him a home directory, where
    only root has write access to, so the user couldn't change shell profile
    scripts or other things. At least the user shouldn't be able to change
    '~/.ssh' and the profile scripts, otherwise he can add further keys,
    delete them, or write a trojan script/function for 'su'.


    Regards,
    E.S.

  12. Re: ssh dictionary attacks

    Ertugrul Soeylemez wrote:
    > john yeo (06-08-15 17:14:21):
    >
    >> enforce key+password logins

    >
    > Using public key authentication is fully appropriate, if your key
    > itself is protected by a passphrase. In some environments it would
    > even be harmful to use password authentication, too, because someone
    > may somehow intercept your login password, and thus be able to log in
    > locally (i.e. not via SSH).


    Note that this is *impossible* to enforce, unless you can scan the user's
    home machines and anywhere they can log into for keys without passphrases.
    It's a long-term vulnerability of SSH.



  13. Re: ssh dictionary attacks

    Ertugrul Soeylemez wrote:
    > dagon@dagon.net (Mark Rafn) (06-08-15 14:38:37):
    >
    >>> enforce key+password logins

    >>
    >> How do you enforce key + password? You can say key-only (which makes
    >> dictionary attacks completely useless), but I don't know how to say
    >> "require a key, and also require a password".

    >
    > I can only speak for OpenSSH, where this doesn't seem to be possible.
    > You can do this indirectly by creating a intermediate user with an
    > authorized_keys file, which starts /bin/login or something similar.
    > But this is error-prone. Do this only if you know what you're doing.
    > Better use keys and secure them with proper passphrases instead.


    You can implement Skey, which is supported, and uses one-time passwords.

    > If you really want to do this, them give him a home directory, where
    > only root has write access to, so the user couldn't change shell
    > profile scripts or other things. At least the user shouldn't be able
    > to change '~/.ssh' and the profile scripts, otherwise he can add
    > further keys, delete them, or write a trojan script/function for 'su'.
    >
    >
    > Regards,
    > E.S.




  14. Re: ssh dictionary attacks

    "Nico Kadel-Garcia" (06-08-15 22:40:17):

    > > Using public key authentication is fully appropriate, if your key
    > > itself is protected by a passphrase. In some environments it would
    > > even be harmful to use password authentication, too, because someone
    > > may somehow intercept your login password, and thus be able to log
    > > in locally (i.e. not via SSH).

    >
    > Note that this is *impossible* to enforce, unless you can scan the
    > user's home machines and anywhere they can log into for keys without
    > passphrases. It's a long-term vulnerability of SSH.


    Sadly very true. The key file format itself should somehow force one to
    use proper passphrases. In theory this is possible, if all clients
    would enforce it. Still you can change the source code of your client
    and thus bypass this check, but just entering a passphrase seems to be
    easier for most users, even programmers.


    Regards,
    E.S.

  15. Re: ssh dictionary attacks

    Ertugrul Soeylemez wrote:
    > "René Berber" (06-08-15 15:07:56):
    >
    >
    >>>This is something that comes up once in a while... I've been subject
    >>>to them as well.
    >>>
    >>>I've come across a couple of projects that build a 'tarpit' for
    >>>attackers - the first one is for SMTP and the second one is more
    >>>generic.
    >>>
    >>>I've often wondered if one couldn't use this to at least slow down a
    >>>dictionary attack on ssh. It wouldn't do much good for a
    >>>distributed attack, but it might for an attack comming from a few
    >>>hosts.
    >>>
    >>>Any thoughts? Comments? This is sort of a curiosity quesiton for
    >>>me; I don't know enough to really make a solid judgement if this
    >>>would be useful.

    >>
    >>Why just slow them if you can stop them?

    >
    >
    > Easy. Slowing them down saves bandwidth for the whole internet. As
    > long as the scanner 'hangs' on scanning your box, it won't issue too
    > much traffic. If you banned them, then they would just go further and
    > scan the next box. There are in fact scanners, which could
    > simultaneously scan multiple boxes, but that is rather rare. Even then,
    > if _many_ people helped slowing them down, then a lot of useless traffic
    > would be saved.
    >
    >


    Another point, banning opens up the possibility of locking yourself
    out of your own box because you flubbed your password one too
    many times--or being maliciously locked out by someone else who
    exploits the banning policy.


    Chris Mattern

  16. Re: ssh dictionary attacks

    On Wed, 16 Aug 2006 14:28:37 -0400, Chris Mattern wrote:

    >Another point, banning opens up the possibility of locking yourself
    >out of your own box because you flubbed your password one too
    >many times


    Banning with a timeout: something like a three strikes within a minute
    you're banned for 20 minutes policy would prevent oneself being locked
    out forever, I don't think I 'flubbed' a password three times in a row

    >... or being maliciously locked out by someone else who
    >exploits the banning policy.


    Ban by source IP, thus preventing the DoS attack you describe. I do
    something like this to limit web traffic without DoSing legit traffic.

    Grant.
    --
    http://bugsplatter.mine.nu/

  17. Re: ssh dictionary attacks

    Grant (06-08-17 08:58:11):

    > > Another point, banning opens up the possibility of locking yourself
    > > out of your own box because you flubbed your password one too many
    > > times

    >
    > Banning with a timeout: something like a three strikes within a minute
    > you're banned for 20 minutes policy would prevent oneself being locked
    > out forever, I don't think I 'flubbed' a password three times in a row
    >


    If the attacker doesn't stop attacking, then you're still locked out.
    You would have like a two seconds time-span out of 20 minutes, where you
    could log in.


    Regards,
    E.S.

  18. Re: ssh dictionary attacks

    In the referenced article, Captain Dondo writes:
    >This is something that comes up once in a while... I've been subject to
    >them as well.
    >
    >I've come across a couple of projects that build a 'tarpit' for
    >attackers - the first one is for SMTP and the second one is more
    >generic.


    I'm currently using sshblack:

    http://www.pettingers.org/code/sshblack.html

    to just chop them off at the knees....works a treat.

    timeban:

    http://duncanthrax.net/timeban/timeban

    could also be used for a similar effect.
    --
    Dennis Davis, BUCS, University of Bath, Bath, BA2 7AY, UK
    D.H.Davis@bath.ac.uk

  19. Re: ssh dictionary attacks

    Mark Rafn wrote:
    > john yeo wrote:
    >> if your just trying to slow down dictionary attacks, some of these
    >> methods might help:

    >
    >> run sshd on a arbitary, high port
    >> enforce key+password logins

    >
    > How do you enforce key + password? You can say key-only (which makes
    > dictionary attacks completely useless), but I don't know how to say "require a
    > key, and also require a password".


    You can using commercial Tectia from SSH Communication and Van Dyke SSH
    implementation.
    Tectia was formely known as SSH and is still available as free software
    for educational.

    Bye


  20. Re: ssh dictionary attacks

    Nico Kadel-Garcia wrote:
    > Ertugrul Soeylemez wrote:
    >> john yeo (06-08-15 17:14:21):
    >>
    >>> enforce key+password logins

    >> Using public key authentication is fully appropriate, if your key
    >> itself is protected by a passphrase. In some environments it would
    >> even be harmful to use password authentication, too, because someone
    >> may somehow intercept your login password, and thus be able to log in
    >> locally (i.e. not via SSH).

    >
    > Note that this is *impossible* to enforce, unless you can scan the user's
    > home machines and anywhere they can log into for keys without passphrases.
    > It's a long-term vulnerability of SSH.
    >
    >


    its should be possible to generate the keypair with a suitable
    passphrase and set up the ssh dir so that the user cant change his key,
    or add any passphrase-less keys. then provide the user with the private
    key and passphrase.

+ Reply to Thread
Page 1 of 2 1 2 LastLast