ssh server stats and reduced risk

I’ve had an SSH server up for some time on the default port 22 tcp on a Windows box. The other day I finally moved it over to a virtual Ubuntu box where it will stay indefinitely. While SSH was running on Windows, I logged all failed attempts. I didn’t expect Amsterdam to outpace Asia! Also, I suspect these were all automated attempts since root was tried the most. Using Cygwin on Windows, I don’t have a “root” account. In fact, “Administrator” was never even attempted once (what the hell?). Go figure.

This brings me back to a recent thread on the Security-Basics list hosted at SecurityFocus where a lot of people got pretty heated up about whether changing the default SSH port or using port knocking is an effective security measure. There were impassioned responses on both sides of the equation, and in a way, they were all somewhat correct. But I think it is more accurate to say changing the SSH default port is not a security enhancement, technically, but does reduce the risk of that service. Risk is decreased, and in a more high-level way of defining “security,” the security of the box was increased. This does not mean SSH became more secure or the box magically became more secure… Really, it just came down to semantics (mostly).

The stats above help illustrate that risk my SSH server faces. If the SSH port had been moved, I would honestly be surprised if I had a dozen failed login attempts. That illustrates reduced risk. I’d also be able to identify my threats a little better. Someone with 5 failed attempts on my obfuscated SSH port may indicate a targeted attacker as opposed to an automated worm scanning for SSH. If someone was able to port knock my SSH open to make failed attempts, that might perhaps indicate my port knock sequence was sniffed somewhere or an insider is atetmpting something fishy.

5 thoughts on “ssh server stats and reduced risk

  1. There was a decent discussion in #security a few weeks ago about port knocking. Good stuff. They mentioned fwknop, which allows for one-time passwords and OS profiling and filtering.
    Oh yeah and I’m all for security by obscurity when its implemented along with other countermeasures. It all goes back to making the enemy fight your fight. Or like the marines say; ‘Always cheat; always win. The only unfair fight is the one you lose.’

  2. Windows doesn’t ship with an ssh client, which is occasionally very annoying. Corporations block ssh at the firewall, and sometimes it’s a bluecoat firewall so you have to run SSH over SSL. You might as well just use SSL. Those are a few reasons why I prefer to use Ajaxterm over SSL with OPIE.
    Read more about this technique here:
    http://www.heise-security.co.uk/articles/88570/
    Then you can leave sshd running on localhost, but without having it listen to port 22 on any outside interfaces.
    Everything is going web application anyways, so you might as well get used to it. Just wait until we start combining port knocking with SSL. Then things will get really strange.
    I trust PKI such as ssh keys inside of my corporation (where ssh servers can be listening all day long), but it’s more difficult to trust outside of your organization. SSH isn’t really a service that should be available to the public Internet, that’s what SSL VPN’s are for (which should also use one-time passwords and multi-factor authentication if possible). But Ajaxterm is a viable solution, which you can further protect with multi-factor authentication using SSL/secure-cookies and a POST-based (and properly validated) HTML form with a CSRF guard. Let’s see the worms get through that!
    SSHv2 is sort of a weak service because doing multi-factor authentication is difficult. Usually you only have one option: Password or RSA/DSA, not both.
    Also of note, there are ARP based attacks against SSHv2:
    http://www.david-guembel.de/index.php?id=18
    http://www.david-guembel.de/index.php?id=6
    There is also an MSS attack on SSH as detailed in
    http://phrack.org/archives/59/p59-0x0b.txt
    Finally, there are various timing attacks on SSH as noted in this paper:
    http://www.ece.cmu.edu/~dawnsong/papers/ssh-timing.pdf

  3. Although I am living close to Amsterdam, I can assure you that machine is not mine 😉 But, why don’t you just block people rather than log their attempts? Stuff like bruteforceblocker usually helps (although I heavily tweaked my version).

  4. @dre: Dude, dre, you are a WEALTH of knowledge! I’m totally going to check into Ajaxterm and maybe trying out some of those attacks myself. I think once I’m done with trying out port knocking with SSH, I’ll move to something else. I don’t really rely on anything for my home setup, I’m really just trying to gain experience (and thus more confidence) in some technologies I’ve not done directly before.

Comments are closed.