Hacker News Reader

Comment by gregmac | Hacker News Reader

(I'm primarly a developer, not sysadmin)

Is using non standard ports a reasonable approach? On one hand, it's kind of a security-by-obscurity measure, and it's also a (very minor) inconvenience to real users. However if it's not being used in place of other reasonable security measures, I'm not really sure what's bad about it, but it does feel a bit janky to me.

Same goes for other non-public services such as VPN.

What ports should be used? I think clearly you don't want to use other well known services (eg, running ssh on port 25 is just going to fill your logs with failed connection errors). Should you use ports >1024? >10000?

View on HN

> it's kind of a security-by-obscurity measure

This comes up as a point of confusion often, so allow me to clarify:

A non-standard port as the only security mechanism (e.g., an unauthenticated HTTP admin-interface) would indeed be 'security through obscurity', but a non-standard port as an extra mitigation layer on top of existing security mechanisms (e.g., SSH authentication) is 'defense in depth'.

That’s a distinction I never understood but makes a lot of sense. Thanks for the explanation.

I’m so tired of hearing people quote “security by obscurity” in relation to moving ssh ports. It is NOT security by obscurity (SBO). SBO is taking an insecure thing and trying to hide it, and relying on the hiddenness as the ONLY means of security. SSH is already highly secure, so hiding it has nothing to do with the security. You can debate whether it’s worth the inconvenience vs reducing log spam, but SBO does not come into it at all.

It's not security by obscurity; obscurity can be a useful component of security. Something that's well protected and hard to find is less likely to be compromised than something that's well protected and easy to find, because some percentage of attackers won't bother to look for it. "Security by obscurity" occurs when someone tries to use obscurity in place of security, by 'hiding' their insecure thing.

Besides, running a service on a non-standard port offers pretty good protection against a fairly common threat scenario in which a new vulnerability is discovered in a well-known service and attackers start sweeping the internet for open ports in order to exploit it.

Not that you should automatically run your services on non-standard ports; there are tradeoffs as others have mentioned. But if you've got to expose something dangerous to the internet at large (and that's an assumption that you should question frequently), then avoiding the standard ports can be a useful tool.

I typically just pick a high numbered port. > 10k would work.

I see it as a way to reduce the number of attacks, which is helpful, and may end up being more secure, but I wouldn't count on that alone. Against botnet attacks it will likely help, but against someone specifically targeting you, it likely will only slow them down.

Basically it boils down to 'why not?' for me.

A high numbered port (above 1024) can be bound by non root programs. Use some non 22 port below 1024 if you want to change the port. Or use some RBAC system like selinux to keep anyone from binding to 2222 or whatever.

What is the problem?

Another authorized user or a non-root RCE compromise could start listening on the ssh port if sshd ever dies for some reason.

And then what? /etc/ssh is still owned by root, another user can't see the hostkeys. So you'll get an error message if custom keys are used.

Remote user tries to log in. Cannot. Issues (or trojan prompts for) password.

It's a game of percentages.

SSH key verification...

Server key? Sure, but what's the accept rate on new keys? On short-lived, poorly provisioned, AWS instaances, as just one example.

Again, percentages. With enough attempts, some will succeed.

If it's a new server (like your example) there should be no other user already logged in. If it's not new, then you'll get a warning. And focusing on the "shortlived", so the damage is also shortlived...

I can only speak for myself, if other people are ignoring warnings, it's their problem.

The original question was: what's the risk, or threat model.

I believe that's been adequately addressed.

The other question is whether other risks are greater; if a high port number is your only choice, or handled by port forwarding on a router, or you are the only user, or high numbers are scanned sufficiently less often, then maybe you still choose one.

Quite. Though, as you note, another question.

Restricting the remote IP range is another option.

Awesome point, and exactly the advice I was looking for.

> I'm not really sure what's bad about it

You say it yourself:

> also a (very minor) inconvenience to real users

I would disagree with the “very minor” part. To paraphrase myself (https://news.ycombinator.com/item?id=6617312):

As I understand the argument, it’s “Changing port number add security, therefore it’s a good idea.” I think nobody argues that it adds security. The problem is that:

1. It adds very little security: 16 bits is not much, and the result is not 256 bits (say) of SSH key plus 16 bits equals 272 bits, but instead effectively still 256 bits, or 256+8×10⁻⁷³ bits.

2. The security it adds is itself bad (sent in cleartext, easily brute-forced)

3. These problems stand against the many drawbacks of this previously discussed (complexity, confusion, etc.).

And the final argument: If increased security is what you want, simply increase your key lengths and/or password lengths, and you will get much more than 8×10⁻⁷³ bits of security, without any of the above problems.

You know what it does do though? Dramatically reduces the amount of log spam :). Running SSH on port 22 vs. even just 2222 significantly reduces the number of failed login attempt messages. They'd always fail anyway unless they happened to somehow get ahold of my ssh private key, but it's sure a lot less annoying when looking for something in the logs to not have to filter through all that noise.

You're looking at this the wrong way, because you seem to assume that non-standard ports adds to security the same way the key length does, which is not the case.

I can’t think of any way it could be otherwise, but please, feel free to enlighten us all how a non-standard port number adds any more security than would an additional 16-bit key.

There is no added security. Just added comfort of not having to deal with spammers filling up logs.

Vastly fewer attacks -> less cognitive load on admins. The logs don't fill up.

Technical protection is likely limited, but then, admin attention is also a limited resource.

Also means attackers are much easier to spot in the logs. It's also a point of real interest if an attacker took the time to port scan you first in order to detect which port your ssh is on.

Or, if you prefer, you're choosing to associate with a higher grade of adversary.

Non-standard ports, port knocking and similar things work before anything reaches sshd; so they can mitigate vulnerabilities in sshd. Obviously a non-standard port is the weakest fellow in the bunch, but that does not mean the effect is zero. An extra 16 bit key length would obviously never mitigate a sshd vulnerability.

An entirely different effect has been brought up by others already; a non-standard port is enough to evade ~99 % of all automated attacks, therefore you can run at higher log levels and might notice actual attackers earlier.

> Obviously a non-standard port is the weakest fellow in the bunch, but that does not mean the effect is zero.

Like I said, nobody argues that it adds zero security, but that, for all the hassle it introduces, it adds way too little security to be worth it. 16 bits is nothing, and can be brute forced quickly.

Regarding port knocking: I’m assuming that most people don’t write their own port knocking software, but use something standard. The configuration of any port knocking scheme is equivalent to an additional separate key of length log2(number_of_possible_port_knocking_configurations). What is the effective “key length” of port knocking schemes?

Also remember that the “key” of port knocking, just like a non-standard port number, is transmitted in the clear, so anybody listening to the traffic can see it. (And if you assume that the attacker can’t listen to the traffic, why are you even using SSH instead of something simpler like telnet?)

I am using high ports >30000 but you can chose what you want.

Really, this sounds like a bad practice to bind on non privileged port.

A user can keep running a program to check if your non privileged port can be bound and if it could, it can start any behaving daemon that could be pretending to be a valid SSH daemon but could have anything like key loggers. Even a single restart of sshd could make it happen.

It doesn't have access to the host keys, so it can't do very much unless you intentionally bypass the "someone is intercepting your connection" error your ssh client will give you in that case.

Reply on news.ycombinator.com