5 ms·

Moving the port reduces security. Port 22 is a privileged port. Standard users can’t listen on port 22. If you move the port to 2222 or wherever, then if an att

Moving the port reduces security. Port 22 is a privileged port. Standard users can’t listen on port 22. If you move the port to 2222 or wherever, then if an attacker with local access can get sshd to crash, they can run their own sshd instead. If you left the port as the default, they wouldn’t be able to do that without chaining it with a privilege escalation attack. But because you changed the port, you disabled this security feature and it could become a privilege escalation attack.

throwaway2048 5y ago
Its pretty trivial to disable the ability of users to listen on certain ports higher than 1024 with a firewall config.
- JimDabell 5y ago
  In practice, people won’t do that. Case in point: the article doesn’t mention this mitigation at all. It introduces an additional attack vector and tells you it’s safer.
- usr1106 5y ago
  A firewall config can block listening? What would that firewall config be? The firewall can block packets by owner uid. But I am not sure who is the owner in legitimate sshd case. Root or the user logged in? SELinux can do it, probably other LSMs, too.
  - throwaway2048 5y ago
    you cant block the actual port bind, but you can block any packets from reaching it, so the difference is mostly semantics
    - usr1106 5y ago
      Yes, but that port needs to remain "open" for the legitimate sshd traffic. Can you see a difference in ownership as the firewall sees it between sshd and some user daemon? Sshd drops root partially when login succeeds.
      - throwaway2048 5y ago
        that has nothing to do with sshd's listening socket, which remains owned by root
        usr1106 5y ago
        Sure the listening one remains owned by root. But the connected one? If you limit packets from/to e.g. 2222 to uid 0, will legitimate ssh traffic work? I don't say it won't, genuinely unsure. Haven't tried and today is a holiday. Maybe tomorrow :)
password4321 5y ago
Your point about privileged ports is valid. So maybe change to a different but still privileged port?
usr1106 5y ago
I am not sure it reduces security. You have a valid point. I adds an attack vector. However "only" if you have the attacker in your system already. Having all the log spam from failed attempts on 22 might the make the admin negligent on carefully following their logs at all. Having it pretty silent on a higher port usually will make you notice occasional scanning. At least I have noticed it and made me tighten the firewall a bit. There is no perfect security.
beagle3 5y ago
Only if they already have local access. And the sshd is not listening on the port (if it’s on, you can’t just bind it) And they still can’t show the host certificate, so your client would tell you the certificate changed. Unless, of course, they have a local root exploit — but then port 22 is just as unsafe. I fail to see how changing a port makes anything less safe.

throwaway2048 5y ago

Its pretty trivial to disable the ability of users to listen on certain ports higher than 1024 with a firewall config.

JimDabell 5y ago
In practice, people won’t do that. Case in point: the article doesn’t mention this mitigation at all. It introduces an additional attack vector and tells you it’s safer.
usr1106 5y ago
A firewall config can block listening? What would that firewall config be? The firewall can block packets by owner uid. But I am not sure who is the owner in legitimate sshd case. Root or the user logged in? SELinux can do it, probably other LSMs, too.
- throwaway2048 5y ago
  you cant block the actual port bind, but you can block any packets from reaching it, so the difference is mostly semantics
  - usr1106 5y ago
    Yes, but that port needs to remain "open" for the legitimate sshd traffic. Can you see a difference in ownership as the firewall sees it between sshd and some user daemon? Sshd drops root partially when login succeeds.
    - throwaway2048 5y ago
      that has nothing to do with sshd's listening socket, which remains owned by root
      - usr1106 5y ago
        Sure the listening one remains owned by root. But the connected one? If you limit packets from/to e.g. 2222 to uid 0, will legitimate ssh traffic work? I don't say it won't, genuinely unsure. Haven't tried and today is a holiday. Maybe tomorrow :)

password4321 5y ago

Your point about privileged ports is valid. So maybe change to a different but still privileged port?

usr1106 5y ago

I am not sure it reduces security. You have a valid point. I adds an attack vector. However "only" if you have the attacker in your system already. Having all the log spam from failed attempts on 22 might the make the admin negligent on carefully following their logs at all. Having it pretty silent on a higher port usually will make you notice occasional scanning. At least I have noticed it and made me tighten the firewall a bit. There is no perfect security.

beagle3 5y ago

Only if they already have local access. And the sshd is not listening on the port (if it’s on, you can’t just bind it) And they still can’t show the host certificate, so your client would tell you the certificate changed. Unless, of course, they have a local root exploit — but then port 22 is just as unsafe. I fail to see how changing a port makes anything less safe.