Slashdot Mirror


Rundown on SSH Brute Force Attacks

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

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

    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 SlightOverdose · · Score: 4, Interesting

      One of my clients had apache running as root, and an attacker was able to create a new account on the system via a hole in a php script.

      The attacker then tried about 50 times to login to the new account via ssh, but wasn't in AllowUsers. Eventually the idiot gave up- most likely a script kiddie who didn't realise the potential of his initial attack.

      Moral of the story? AllowUsers is a really good idea :-P

    3. Re:As always... by Homology · · Score: 4, 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.

      No kidding? By disallowing password authentication you've stopped the script kiddies dead in their tracks. As for disallowing root access, here are some words from an OpenBSD developer:

      ... All unmitigated horseshit. Sorry. Look I use sudo, and I like it. but it is no substitute for allowing root login to a box, and is no substitute for "su", Sorry. They are different. I don't want to add a billion sudoable local accounts to run boxen in a distributed authentication environment. I want "root" local, and be done with it. I want root exposed if someone knows the root password, not if someone knows the root password or fourteen other idiot's passwords that are used every day. That's not more secure. If you want a useful diff to help stop this ridiculous discussion from propping up every little while. Here's what I propose: ....

      Saying "don't login as root" is horseshit. It stems from the days when people sniffed the first packets of sessions so logging in as yourself and su-ing decreased the chance an attacker would see the root pw, and decreast the chance you got spoofed as to your telnet host target, You'd get your password spoofed but not root's pw. Gimme a fucking break. this is 2005 - We have ssh, used properly it's secure. used improperly none of this 1989 bullshit will make a damn bit of difference. -Bob

    4. Re:As always... by Ann+Elk · · Score: 4, Informative
      Moral of the story? AllowUsers is a really good idea :-P

      And running Apache as root is a Really Bad Idea (tm).

    5. 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. What next? by hoka · · Score: 4, Insightful

    What are we going to see next on Slashdot? A review for the movie "Scr1pt k1dd15"? I was interested when I saw the link and after clicking on it, I was sadly disappointed. This has nothing to do with SSH, and could just as easily be used on Apache logins, FTP, Telnet, IRC, etc. Brute forcing is an old concept and is the whole reason you are supposed to use strong passwords (well that and offline password attacks).

  3. Easy fix by Anonymous Coward · · Score: 4, Informative

    i have had this on a number of occasions.. i just set the max auth attepts to 4, this renders the attempts useless

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

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

  5. 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
  6. The idea is old, but the attempt is new by jfengel · · Score: 4, Insightful

    The idea of brute force is extremely old, but the fact that somebody is out there actually doing them is important. The use of strong passwords is no longer just a theoretical "it would be a good idea" policy, but now somebody actually is looking to get through.

    Other Slashdot readers are reporting the same effect: a recent rise in brute-force, scripted attacks, possibly by compromised boxes.

    Most accounts of all sorts remain secure simply because they're obscure, and it's tempting to be lulled by past successes. We always knew that this was possible, but the fact that somebody is actually doing it is news.

  7. Re:Highly annoying by cdrguru · · Score: 4, Interesting

    We use a script called sshd_sentry. It is set up so that after five failed attempts the IP address is blocked for 24 hours.

    This has essentially ended the problem for us. It allows SSH to be wide open so out-of-the-office employees can log in from a hotel or Treo in case something bad happens and it absolutely blocks dictionary attacks.

    No longer a problem.

  8. why not disable passwords entirely? by toby · · Score: 4, Informative

    If you only need access from a limited set of machines which can have pre-generated keys, you can disable password authentication entirely (PasswordAuthentication no) and use RSA instead, with optional passphrase. In addition to PermitRootLogin no, I suggest judicious use of AllowUsers in sshd_config.

    --
    you had me at #!
  9. They actually got in on my parent's computer by yorgasor · · Score: 4, Interesting

    I made an account for my dad on my mom's computer so he could have a samba share over the network, and gave it a really easy, completely forgetting that it was also accessible via ssh. Fortunately, I added their computer to my personal DNS domain so I could remember how to get to it easier. Shortly after it was compromised, I got an email informing me that phish spams were being sent from the computer.

    I analyzed the system, and quickly determined that the person was not a big time hacker. Looking at his .bash_history file His only attempt to gain root access was to run 'sudo'. He copied over a list of people to spam, a mail script, and an email. He fired off a test email first, and then spammed the email list. A couple days later, he copied over a different list and message and sent those off. After that, I was tipped off and sealed off his entry.

    Since he made no effort to cover his tracks or avoid detection, either this script-kiddie didn't know how to, or had so many computers to manage it wasn't worth his while to do so.

    --
    Looking for a computer support specialist for your small business? Check out
  10. 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