There's No Protection In High Ports

&#62;obscuring your login service via non-standard ports or even a requirement to try several ports in sequence really only buys you security equivalent to lengthening your password by two characters per port.<p>Not even that. It's like a <i>separate</i> two-byte password because you get to guess and confirm the port separately from the password.<p>Lengthening your password by N bits <i>multiplies</i> the number of necessary guesses by 2^N. Having a <i>separate</i> N bit password <i>adds</i> 2^N to the number of of necessary guesses. So if your real password's effective key length is more than 16 bits, using a random port effectively adds less than 1 bit of entropy.<p>Also, rate-limiting port scans is way harder to do than rate-limiting authentication.

While I'm not sure if you can argue 'no protection' while at the same time admitting that the number of attacks was greatly reduced for a while: I always hated that advice with a passion.<p>No, do not run SSH on a non-default port. It's nothing but an obscurity hack, does little good and breaks a lot of workflows (routers that prioritize port 22 as interactive traffic, firewalls that explicitly allow ssh - on port 22 of course, tools that are awkward to use as soon as you need to use a different port than the _standard_ one).<p>I admit that I mocked people recommending that practice in the past. That's childish of course, but if the data of this submission is correct I can now add a more serious 'Please do not do that' argument to my list.

Port 22 should only be used if the SSHd needs to be accessible to strangers; I think a lot of people use alternate ports. Go a step farther by running Kippo[1] (or other SSH honeypot) on port 22 to accept SSH traffic and waste attackers' time. Not only do attackers forgo scanning for the true SSH port, but they believe they've successfully intruded into the system and leave keystroke-by-keystroke logs of their actions in the decoy shell.<p>[1]: <a href="https://code.google.com/p/kippo/" rel="nofollow">https://code.google.com/p/kippo/</a>

&#62;As I've argued elsewhere, obscuring your login service via non-standard ports or even a requirement to try several ports in sequence really only buys you security equivalent to lengthening your password by two characters per port. After all, TCP and UDP port numbers are limited to 65536 distinct values, within the scope of a 16-bit value. Moving your service to a non-standard port means that the would-be intruder has to guess a two-byte value. Introducing a sequence of ports buys you the added obscurity of two bytes per port.<p>It needs to be pointed out that it is actually worse than that. Guessing a password is O(2^n) on the length of the password. Making the attacker guess a random m bit value before starting to guess passwords is O(2^m + 2^n). To put numbers behind this, a password with 32 bits of entropy has ~4 billion possible combinations, 16 bits of random port + 32 bits of password has 65536 + ~4 billion possible combinations (also known as ~4 billion), while a 34 bit password would have ~16 billion possible combinations.

The whole hi/low ports as security was always bogus. From day one. Ask those who implemented it from that era, and they will now agree. If someone had a shell account on a machine, they could have 'root'. If they had root, they can bind low ports (and anything else). The fact that Linux still requires a root user to bind a listener to a &#60;1024 port was just the Linux guys being conservative. They wanted adoption, not someone saying 'Linux is insecure because they let non root bind to low ports'. They now have adoption, and quite a bit of legacy decisions still in there.<p>I used to fume about 15 years ago. These days, I'm much more zen about this. (or trying to be zen).<p>Also, I welcome posts like this. I've come to understand that what was once understood by many, may not be when you add 10 or 5 years. For example, the recent HN post from dadgum.com about C's most powerful operator being 'switch'. This is well known. However, maybe there are 17 or 15 year olds who lurk HN. In order for them to learn, they should be exposed to that knowledge.<p>So, while we are trying to help one another, here is some advice. One <i>really good</i> way to run sshd securely is to use a different operating system other than Linux. This isn't because Linux is bad, it is just that certain decisions were made that will not change. People might extrapolate what I just said too far. Let me illustrate this as a conversation for entertainment.<p>world says: 'drudru just said don't run linux anywhere'<p>drudru says: 'Nope. What I'm saying is if you need high security, yet open to the world, sshd install, don't run it on Linux. Run it on an OS and config designed for security. You can still use Linux and other OSs for other things.'<p>world says: 'Ok, if I do that, how do I ssh to my Linux hosts?'<p>drudru says: 'Since your sshd host is running not on Linux and it is secure, you can use it to login to your other hosts. You should run it on a static IP address. Then you will only allow ssh in to all your other hosts from that known secure IP and host key. You can have multiple jump machine/static IPs, say 2 on different networks for redundancy.'<p>world says: 'I've heard OpenBSD was secure. I don't want to learn OpenBSD, FreeBSD, etc.'<p>drudru says: 'You should just run on Heroku or something equivalent. It will allow you to outsource the entire problem.'<p>world says: 'I cannot run my Hadoop,Cassandra, etc. on XYZ cloud platform.'<p>drudru says: 'I am pretty sure you can. There are a lot of new solutions out there if you get a moment to search.'<p>ALTERNATE ENDING<p>world asks: 'Can I run sshd on Windows securely?'<p>drudru says: 'You should just run on Heroku or something equivalent. It will allow you to outsource the entire problem.'<p>RING RING<p>drudru says: 'hey, good luck with that. gotta go.'

As we all know security through obscurity only buys you time like the article points out. Please correct me if I'm wrong but a pretty simple solution exists here. I run SSH over port 22 and do the following which I think is a pretty reasonable and safe solution (again, please correct me if I'm wrong):<p>1. Configure a decent firewall, edit iptables and disable anything you aren't or don't plan to use.<p>2. Disable root login completely.<p>3. Install fail2ban just in case and set it to block IPs of failed attempts for 2 to 24 hours<p>4. Use key based authentication and disable SSH logins using passwords altogether.<p>I'd recommend going a step further on number 4 and put a strong password on your key. A lot of people believe that key based authentication in and of itself is enough but if you somehow leak your keys and there's no password on them then an attacker has just easily gained access to your machine. Now I'm guilty of not using a password with my keys because like a lot of people it feels like it defeats the purpose but you can actually set things up so that you only need to enter your password once and it won't ask you for it again for a while just like the sudo "grace period" which lets you sudo without a password after you've entered it once. I do plan to give my keys a password and stop being so lazy in the very near future.<p>I know the Linode library as well as a few posts that have made it to the front page here explain how to do this. Here are the links:<p><a href="http://feross.org/how-to-setup-your-linode/" rel="nofollow">http://feross.org/how-to-setup-your-linode/</a><p><a href="http://news.ycombinator.com/item?id=4618808" rel="nofollow">http://news.ycombinator.com/item?id=4618808</a> (Discussion of the above which has some more helpful hints)<p><a href="http://library.linode.com/securing-your-server" rel="nofollow">http://library.linode.com/securing-your-server</a>

Related: Protecting sshd using spiped <a href="http://www.daemonology.net/blog/2012-08-30-protecting-sshd-using-spiped.html" rel="nofollow">http://www.daemonology.net/blog/2012-08-30-protecting-sshd-u...</a>

It would also be nice if SSHd had an option to block an IP address after a certain number of failed attempts. Sure, you can hack something together with iptables but that's just horrible.

Another thing that occasionally cheeses me off is the restriction on canonical ports &#60; 1000 to user 0. Yes, I know it's standardized. Yes, I know that when it was codified the world looked very, very different. It's still annoying and requires cargo-cultish hoop-jumping (albeit well understood hoop jumping) to run a decently secure service.

I like some mix of the following:<p>- disable passworded logins (only keys)<p>- ssh bastion host<p>- decoy ssh honeypot on port 22 (<a href="http://www.plainlystated.com/2013/02/ssh-honeypots-dataviz/" rel="nofollow">http://www.plainlystated.com/2013/02/ssh-honeypots-dataviz/</a>)

This is useful to protect sshd from random scans, but to still allow you access from anywhere when you need that access:<p><a href="http://www.pkts.ca/ssh-faker.shtml" rel="nofollow">http://www.pkts.ca/ssh-faker.shtml</a>

Ok, fine.<p>Now give me <i>one</i> reason why I should actually run sshd on port 22.

SSH is rarely a public service. What's the motivation for making it so public?