2 SSH Brute-Force-Attack Countermeasures

By Daniel Miessler on December 9th, 2008: Tagged as Information Security

hacking
Image from siliconvalleysleuth.co.uk

SSH attacks are in the news again, this time due to new bot-based, distributed brute force campaign.

Essentially, the attackers are bypassing brute force attempts by coming from thousands of different bot-controlled IPs, which allows them to try far more passwords against a given system. Most brute-force protection focuses on source IP, and with a botnet they have plenty of those to spare.

Here are two simple countermeasures:

  1. Switch to Pure Key-based Authentication
    I say pure because it doesn’t help to just enable key-based authentication; you have to disable passwords as an option altogether or you won’t be increasing your resistance to brute-forcing at all.

    Give it a try and compare your logs before and after.

  2. Move Your SSH Port
    There’s a lot to be said for simply not being there when attacks are coming in. There’s a lot of debate on this one, but I stand firmly on the side of obscurity being a good addition to a security posture, as long as the cost of implementation isn’t prohibitive.

    So if you have a small user-base, or if you have an easy means of updating the client your users use, simply move your SSH daemon to another port. These attacks are automated and aren’t likely to hit on any port other than 22. The amount of additional effort required to mount similar attacks against all 65,000+ ports makes the attempts a waste of time for attackers, and makes it very much worth the time for you.

As you can see from this crude experiment I did back in March, moving your SSH port does in fact make a difference in the number of brute-force probes you’ll see, and if you combine this avoidance measure with additional security (key-based auth) you’ll have improved your situation significantly. From my experiment post:

The stats over the weekend are now over 18,000 connections to port 22, and five (5) to port 24

Just remember to always any additional security first, then add avoidance/obscurity afterwards. ::

Links

[ Security and Obscurity | dmiessler.com ]
[ Does Changing Your SSH Port Lower Your Risk? | dmiessler.com ]

  • nerfed

    I use Denyhosts (http://denyhosts.sourceforge.net/) on several production machines. It’s a small python script that drops IP’s of hosts into /etc/hosts.deny that try to brute force. You can set the threshold.

  • nerfed

    I use Denyhosts (http://denyhosts.sourceforge.net/) on several production machines. It’s a small python script that drops IP’s of hosts into /etc/hosts.deny that try to brute force. You can set the threshold.

  • http://dmiessler.com/ Daniel Miessler

    nerfed,

    Denyhosts is being bypassed by this; that’s the whole point of the story. They don’t care if you deny one IP or 100; they have thousands to try from. See?

  • http://dmiessler.com Daniel Miessler

    nerfed,

    Denyhosts is being bypassed by this; that’s the whole point of the story. They don’t care if you deny one IP or 100; they have thousands to try from. See?

  • Brett Dreher

    Don’t you feel you should mention that if you have multiple machines if you allow only key based authentication without a password that say once your key gets cracked, like this past year with the Debian issue, that someone will now have full access to your entire network without even using a single password?

    Passwords are not poor security practice if you use secure ones and rotate them sufficiently.

    Couldn’t agree more on changing the ssh port, a decent option is that you set two ports for ssh on your machine, the default and an open one (say 22 and 24). Simply have your firewall only forward port 24 to the machine and it will save you from having to append the port number when you would like to access the machine from other local ones.

  • Brett Dreher

    Don’t you feel you should mention that if you have multiple machines if you allow only key based authentication without a password that say once your key gets cracked, like this past year with the Debian issue, that someone will now have full access to your entire network without even using a single password?

    Passwords are not poor security practice if you use secure ones and rotate them sufficiently.

    Couldn’t agree more on changing the ssh port, a decent option is that you set two ports for ssh on your machine, the default and an open one (say 22 and 24). Simply have your firewall only forward port 24 to the machine and it will save you from having to append the port number when you would like to access the machine from other local ones.

  • bob schäfer

    great observation. the real trifecta is obscure port + keys only + only from restricted addresses, but honestly, i’ve had boxes in hostile networks for almost a decade and they all run with ssh on some ephemeral port and there’s simply never failed attempts in my logs.

    hopefully, people will harken to your advice.

  • bob schäfer

    great observation. the real trifecta is obscure port + keys only + only from restricted addresses, but honestly, i’ve had boxes in hostile networks for almost a decade and they all run with ssh on some ephemeral port and there’s simply never failed attempts in my logs.

    hopefully, people will harken to your advice.

  • http://na.com/ double oh

    since this is tagged security by obscurity, i’ll let it pass.

  • http://na.com double oh

    since this is tagged security by obscurity, i’ll let it pass.

  • http://steamcommunity.com/id/m-p-3 m-p{3}

    I already use a different port (443) and it works very well so far, no failed logins (except mine..) in the logs. I should consider using keys, but I’d like to use it simultaneously with a password, to make it more like a two-factors authentication. We learn something new everyday :)

  • http://steamcommunity.com/id/m-p-3 m-p{3}

    I already use a different port (443) and it works very well so far, no failed logins (except mine..) in the logs. I should consider using keys, but I’d like to use it simultaneously with a password, to make it more like a two-factors authentication. We learn something new everyday :)

  • Pingback: Email Content Security


Top

Popular

Information Security / Technology

Politics

Philosophy & Religion

Technology & Science

Culture & Society

Miscellaneous

Arguments

Projects

Collections

Twitter

What I'm Reading

Favorite Books and Essays

Top Blog Categories

Inputs