4 ms·

>ssh non-standard port is actually a good thing given the massive amounts of bots around Except that if you use a port above 1024 (like the author does) you no

>ssh non-standard port is actually a good thing given the massive amounts of bots around Except that if you use a port above 1024 (like the author does) you no longer have assurances that it is a privileged user that launched the process. Any non-privileged user on a Linux system can bind to a port higher than 1024, so all it takes is sshd restarting after an update if it's directly listening on a high number port, or iptables rules getting reloaded if they're being used to forward traffic from a high port to 1024 and an attacker can have their own credential collecting service running where you think sshd is, and all it takes is someone ignoring the host key mismatch error to give up your good creds to an attacker, and now they have more access into your infrastructure.

unethical_ban 6y ago
Never thought about this before, but is this a tunable thing in the kernel config? Some way to signal to the OS "only use port ranges above 16382 for unpriv" and move the boundary up?
- cthalupa 6y ago
  I don't believe it's an easily changeable tunable with a config flag or sysctl setting, no. You could of course modify the kernel source code, but there's probably lots of unintended side effects to this - your setting is alright for most Linux distros, but what if someone picked one that overlapped with ephemeral port ranges? Or if you're running software that the commonly used port binds to something under 16382 but above 1024 - now you have to reconfigure it, or set up temporary privilege escalation so it can bind to it before going back down, a la httpd. It's also a bit of a contract with the client - on Linux something below 1024 is ALWAYS privileged so you know you're not connecting to a fake sshd and giving away your password or current 2FA token unless that system has been totally owned. If you modify the kernel you're modifying that contract - are you sure that this system has modified kernel? That's really my issue with this whole idea (and one of my top level comments goes into this in more depth) - but there's a lot of unintended side effects from these obscurity changes that people don't know about or think about. Meanwhile there's lots of well understood practices that provide real security that solve both the issue of noisy low effort attacks while also providing real security against determined attackers. VPNs and jumphosts - why should SSH be internet accessible in the first place? Use key based auth, as well as 2FA. Port knocking is... interesting... in theory, but it increases complexity for the users at a similar level of requiring them to use a VPN or jumphost (or both), but has additional flaws that they don't have - if they have access to sniff your traffic via some means, they can figure out the sequence and now they have completely removed it as a layer of security. They don't even need to be able to decrypt the traffic - just see the destination ports. Is this level of attack something most of us have to worry about? No. But if for similar levels of effort we can get better security, why would we go for the weaker form, even if it's unlikely we need more? If for some reason you do have a dedicated attacker, you're better prepared. You can also extend it to provide even more security - lock down SSH to all of your production hosts to only the jumpbox(es). Alarm on any attempt production host to production host SSH attempts. Easily audit ingress SSH access on a subset of hosts. etc.
- pixl97 6y ago
  Most distributions come with a 'portreserve' daemon for just this purpose.
  - cthalupa 6y ago
    Mentioned in my other comment ( https://news.ycombinator.com/item?id=24447846 https://news.ycombinator.com/item?id=24447846 ) but at most portreserve makes it a race. It cannot guarantee that an unprivileged user cannot bind to that port.
Sebb767 6y ago
But that's putting the second line of defence (against an on-system attacker) above the first, which is to not get someone on the system in the first place. It definitely makes sense in some setups, but for your general purpose web server a high port is probably the right trade-off.
- cthalupa 6y ago
  How many remote code execution exploits have we seen on webs applications? Many thousands. But you don't need to make this trade off. SSH does not need to be open to the internet to begin with - make it only accessible via VPN. Now you don't have log spam from botnets in your logs, and it won't show up on a port scan that has fingerprinting enabled and scans the whole range, and you won't be as vulnerable if some sort of sshd exploit comes out that allows you to bypass auth.
  - Sebb767 6y ago
    Oh, don't get me wrong, I fully agree with you. My point was only that if you see it as an either-or-scenario[0], the higher port is probably the better choice. [0] Might be true for something like a bastion host, which must expose ssh or VPN (which would be the same scenario).
pixl97 6y ago
This is the reason the 'portreserve' application exists.
- cthalupa 6y ago
  Kind of. It doesn't actually solve this. At most, it makes it a race. If you are using portreserve for the port, the portreserve daemon just holds it until your actual application calls portrelease and then binds to it. If all reserved ports are released, the daemon exits. For a service restart, you could add starting up the daemon as part of the process, however, it is still a race to try and bind to that port. If sshd crashes, there is no reason that portreserve would try to bind to that port. If you create a secondary service or script to monitor for sshd running and restarting portreserve if it isn't, then it's once again a race.

unethical_ban 6y ago

Never thought about this before, but is this a tunable thing in the kernel config? Some way to signal to the OS "only use port ranges above 16382 for unpriv" and move the boundary up?

cthalupa 6y ago
I don't believe it's an easily changeable tunable with a config flag or sysctl setting, no. You could of course modify the kernel source code, but there's probably lots of unintended side effects to this - your setting is alright for most Linux distros, but what if someone picked one that overlapped with ephemeral port ranges? Or if you're running software that the commonly used port binds to something under 16382 but above 1024 - now you have to reconfigure it, or set up temporary privilege escalation so it can bind to it before going back down, a la httpd. It's also a bit of a contract with the client - on Linux something below 1024 is ALWAYS privileged so you know you're not connecting to a fake sshd and giving away your password or current 2FA token unless that system has been totally owned. If you modify the kernel you're modifying that contract - are you sure that this system has modified kernel? That's really my issue with this whole idea (and one of my top level comments goes into this in more depth) - but there's a lot of unintended side effects from these obscurity changes that people don't know about or think about. Meanwhile there's lots of well understood practices that provide real security that solve both the issue of noisy low effort attacks while also providing real security against determined attackers. VPNs and jumphosts - why should SSH be internet accessible in the first place? Use key based auth, as well as 2FA. Port knocking is... interesting... in theory, but it increases complexity for the users at a similar level of requiring them to use a VPN or jumphost (or both), but has additional flaws that they don't have - if they have access to sniff your traffic via some means, they can figure out the sequence and now they have completely removed it as a layer of security. They don't even need to be able to decrypt the traffic - just see the destination ports. Is this level of attack something most of us have to worry about? No. But if for similar levels of effort we can get better security, why would we go for the weaker form, even if it's unlikely we need more? If for some reason you do have a dedicated attacker, you're better prepared. You can also extend it to provide even more security - lock down SSH to all of your production hosts to only the jumpbox(es). Alarm on any attempt production host to production host SSH attempts. Easily audit ingress SSH access on a subset of hosts. etc.
pixl97 6y ago
Most distributions come with a 'portreserve' daemon for just this purpose.
- cthalupa 6y ago
  Mentioned in my other comment ( https://news.ycombinator.com/item?id=24447846 https://news.ycombinator.com/item?id=24447846 ) but at most portreserve makes it a race. It cannot guarantee that an unprivileged user cannot bind to that port.

Sebb767 6y ago

But that's putting the second line of defence (against an on-system attacker) above the first, which is to not get someone on the system in the first place. It definitely makes sense in some setups, but for your general purpose web server a high port is probably the right trade-off.

cthalupa 6y ago
How many remote code execution exploits have we seen on webs applications? Many thousands. But you don't need to make this trade off. SSH does not need to be open to the internet to begin with - make it only accessible via VPN. Now you don't have log spam from botnets in your logs, and it won't show up on a port scan that has fingerprinting enabled and scans the whole range, and you won't be as vulnerable if some sort of sshd exploit comes out that allows you to bypass auth.
- Sebb767 6y ago
  Oh, don't get me wrong, I fully agree with you. My point was only that if you see it as an either-or-scenario[0], the higher port is probably the better choice. [0] Might be true for something like a bastion host, which must expose ssh or VPN (which would be the same scenario).

pixl97 6y ago

This is the reason the 'portreserve' application exists.

cthalupa 6y ago
Kind of. It doesn't actually solve this. At most, it makes it a race. If you are using portreserve for the port, the portreserve daemon just holds it until your actual application calls portrelease and then binds to it. If all reserved ports are released, the daemon exits. For a service restart, you could add starting up the daemon as part of the process, however, it is still a race to try and bind to that port. If sshd crashes, there is no reason that portreserve would try to bind to that port. If you create a secondary service or script to monitor for sshd running and restarting portreserve if it isn't, then it's once again a race.