Slashdot Mirror

← Back to Stories (view on slashdot.org)

Rundown on SSH Brute Force Attacks

Posted by Zonk on from the more-you-know! dept.

An anonymous reader writes "Whitedust has a very interesting article on the recent SSH brute force attacks. The article goes into depth on how to monitor these attackes and to report them to the authorities. It also discusses various tools that are available. According to the article, mostly compromised Linux systems from outside of North America are responsible for the attacks. Even the author's DSL connection was getting break-in attempts."

7 of 360 comments (clear)

  1. As always... by jsight · · Score: 5, Informative

    If possible, restrict access by source IP address, limit the user accounts w/ SSH access, and don't allow remote root logins.

    Another step to improve security if there are very few users is just to ONLY allow public key authentication. I've never seen such a box compromised remotely.

    --
    Throw the bums out!
    1. Re:As always... by justMichael · · Score: 5, Insightful
      limit the user accounts w/ SSH access, and don't allow remote root logins.
      I tend to think of this in a slightly different direction.

      Use AllowUers and only have acocunts that I want logging in. If some package/whatever creates an account and I don't know, it can't be exploited.

      Any login not in that list just gets a Password: promt over and over...

      If my sshd_config gets changed I'm probably going to know.

      The article states "200 to 300 times per day"...

      This is only one box out of 63 for one day:
      Authentication Failures:
      unknown (xxxx.ip.secureserver.net): 2214 Time(s)
    2. Re:As always... by feronti · · Score: 5, Informative

      Speaking of which, why is it said not to login as root over SSH? The only plausible reason I've ever heard is that the encryption is stronger after the login is complete, so your root password is safer if you 'su' to root after logging into another account.

      I think it may be due to an old vulnerability. In versions of OpenSSH earlier than 2.5, you can discover the length of the password using traffic analysis. Basically you look for the following sequence of packets:

      C: 1 packet (s)
      S: 1 packet (echo s)
      C: 1 packet (u)
      S: 1 packet (echo u)
      C: 1 packet (newline)
      S: 1 packet (echo newline)
      S: 10 packets ("Password: ")
      C: x packets (the password)
      C: 1 packet (newline)
      S: 1 packet (echo newline)
      Basically, since the x packets aren't echoed, we know that they are the password. We don't know the contents of the packets, but we now know the length of the password, which can help tremendously in brute force and dictionary attacks (we can eliminate a huge portion of the search space by only searching passwords of length x).

      This technique worked for both SSH-1 and SSH-2 protocols. For more detail, (and a better, more accurate description of how the vulnerability worked) you can read the original security advisory.

      Another problem with logging in directly as root is that you no longer can audit who is logging in as root in an environment where multiple users have root access.

  2. DenyHosts by roubles · · Score: 5, Informative

    I use DenyHosts http://denyhosts.sourceforge.net/ from a cronjob. It detects any suspicious logins in /var/log/auth.log and adds the ip address of the user into the /etc/hosts.deny file. It also sends me an email telling me the IP address that was last added to the file.

    Lately I have been getting atleast 1 hack attempt a day on my personal computer connected to the internet over a cable connection. On weekends I get more.

    Just this morning I had two ssh dictionary attacks. DenyHosts caught them both.

  3. Use another port by objorkum · · Score: 5, Informative

    Use another port than 22. I have not noticed one single bruteforce attempt after I did that.

    --
    objorkum dot com
  4. 20th Century Authority by handy_vandal · · Score: 5, Insightful

    The article goes into depth on how to monitor these attackes and to report them to the authorities.

    The authorities ... how very ... twentieth-century.

    Better we should self-organize our collective defense.

    Peer-to-peer government -- making the nation-state obsolete, one node at a time ....

    -kgj

    --
    -kgj
  5. Re:Easy fix by tek.net-ium · · Score: 5, Informative

    RTFM. sshd_config(5) MaxAuthTries Specifies the maximum number of authentication attempts permitted per connection. Once the number of failures reaches half this value, additional failures are logged. The default is 6. Crackers will just open up more connections.