6 ms·

(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

(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?

orev 8y ago
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.
xur17 8y ago
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.
- munin 8y ago
  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.
  - gsich 8y ago
    What is the problem?
    - nitrogen 8y ago
      Another authorized user or a non-root RCE compromise could start listening on the ssh port if sshd ever dies for some reason.
      - gsich 8y ago
        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.
        dredmorbius 8y ago
        Remote user tries to log in. Cannot. Issues (or trojan prompts for) password. It's a game of percentages.
        gsich 8y ago
        SSH key verification...
        dredmorbius 8y ago
        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.
        gsich 8y ago
        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.
wgjordan 8y ago
> 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'.
- debaserab2 8y ago
  That’s a distinction I never understood but makes a lot of sense. Thanks for the explanation.
gsich 8y ago
I am using high ports >30000 but you can chose what you want.
- h1d 8y ago
  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.
  - wiml 8y ago
    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.
teddyh 8y ago
> 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 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.
- tonyarkles 8y ago
  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.
- blattimwind 8y ago
  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.
  - teddyh 8y ago
    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.
    - gsich 8y ago
CommieBobDole 8y ago
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.

orev 8y ago

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.

xur17 8y ago

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.

munin 8y ago
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.
- gsich 8y ago
  What is the problem?
  - nitrogen 8y ago
    Another authorized user or a non-root RCE compromise could start listening on the ssh port if sshd ever dies for some reason.
    - gsich 8y ago
      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.
      - dredmorbius 8y ago
        Remote user tries to log in. Cannot. Issues (or trojan prompts for) password. It's a game of percentages.
        gsich 8y ago
        SSH key verification...
        dredmorbius 8y ago
        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.
        gsich 8y ago
        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.

wgjordan 8y ago

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

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

gsich 8y ago

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

h1d 8y ago
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.
- wiml 8y ago
  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.

teddyh 8y ago

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

tonyarkles 8y ago
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.
blattimwind 8y ago
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.
- teddyh 8y ago
  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.
  - gsich 8y ago

CommieBobDole 8y ago

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.