7 ms·

> Nearly anybody that bothers to change the port is also going to follow most of the other industry-standard practices If they're following industry standard p

> Nearly anybody that bothers to change the port is also going to follow most of the other industry-standard practices If they're following industry standard practice (I'm hoping you mean "key-based auth only") then there is absolutely zero reason to move the port, other than to avoid filling up your logs, and two IPTables rules take care of that anyway. Moving the port is like being at a bar and needing to go to the bathroom, but first leaving your cellphone on the bar, covered with a little napkin. It is literally obscuring a thing, hoping that it is secure. Honestly, if people insist on security by obscurity, they should just do it already and stop apologizing for it.

onion2k 6y ago
If they're following industry standard practice (I'm hoping you mean "key-based auth only") then there is absolutely zero reason to move the port, other than to avoid filling up your logs, and two IPTables rules take care of that anyway. This is what's known as 'putting all your eggs in one basket'. Relying on a strong auth mechanism is extremely sensible but only relying on that isn't. Exploits are found even in the oldest and best reviewed code. Nothing is 100% safe. If an exploit is discovered in the auth mechanism you're relying on then the obscurity of having SSH on a different port, with a mechanism to block port scanning, could at least buy you enough time to delay an attacker long enough for you to shut down auth until there's a fix. Considering the cost of switching port is so low it seems foolhardy not to.
liability 6y ago
If you interpret the term literally, then yes. However that's not the correct approach when dealing with terms of art like 'security through obscurity.' Wikipedia describes the term as it's actually used (emphasis mine): > Security through obscurity (or security by obscurity) is the reliance in security engineering on design or implementation secrecy as the main method of providing security to a system or component. An properly configured sshd on a non-standard port is not in any remote way using obscurity as it's main method of security.
petercooper 6y ago
I don't apologize for it, but I don't think yours is the only argument that can be made. What if a security hole is discovered in OpenSSL and overnight all those bots smashing port 22 are tweaked to take advantage of it? Let's assume a vulnerability that doesn't care about password auth being disabled. Sure, they might discover my sshd on port 17263 or whatever eventually but I am surely going to get a significant head start on all of the people having their boxes hacked left right and center. Sure, it's still security by obscurity, but it's nothing like the napkin example. It's more like hiding your phone under a table that has 20 other phones on top of it. When I hear about phones getting stolen, I've got a while to get mine back.
- thinkharderdev 6y ago
  That works both ways though. Imagine in your scenario you have thousands of servers across a large organization, many that may be running on auto-pilot and don't have any active team maintaining them. When the hypothesizes critical OpenSSL bug pops up, the first thing you will want to do is find out all the server in your network running sshd so you can patch them. If they are all listening on some random port then that task becomes much, much harder.
cedilla 6y ago
One thing to keep in mind here is that there is no absolute security. There is only security against some specific threat. If the threat is "someone is specifically targeting you", then changing the port is indeed useless. However, if the threat is "a botnet trying to abuse a new openSSH vulnerability", then changing the port does help. Because no bot takes the time to scan tens of thousands of ports in that case when there are millions of other hosts around who listen on port 22. By the way, when I lived in a dormitory, it was actually best practice to hide your valuables from view if you lived in a ground floor apartment. Literally obscuring the thing, but thieves only broke into the apartment where they knew there's something to steal quickly. A napkin over your wallet might not help in a bar but it did help in this case.
- thaumasiotes 6y ago
  > Literally obscuring the thing, but thieves only broke into the apartment where they knew there's something to steal quickly. A napkin over your wallet might not help in a bar but it did help in this case. The same approach works well for leaving stuff in cars. Visible bags or electronics tend to get stolen. The same thing under a sweatshirt doesn't.
- peterwwillis 6y ago
  > However, if the threat is "a botnet trying to abuse a new openSSH vulnerability", then changing the port does help. Because no bot takes the time to scan tens of thousands of ports in that case when there are millions of other hosts around who listen on port 22. It takes about 8 minutes to scan the whole internet for port 22. If there's an SSH 0day, and I have a botnet, I am going to make the entire botnet scan the entire internet on every port, because I know people move their SSH port. With 5,000 hosts, I can scan all 65,535 TCP ports across the entire internet in 104 minutes. How fast can you patch your server after the 0day's been announced? What if you're asleep? The time it takes to change the SSH port could also be used to harden the sshd config, which would eliminate several classes of previous exploits. A little more time and the entire system could be hardened, so that even if you are attacked, the attacker can't do much of anything.
  - 6y ago
kps 6y ago
Someone attacking ssh may also attack other services (e.g. http) that may have vulnerabilities. fail2ban on port 22 keeps them away.
- Karunamon 6y ago
  I was going to say.. fail2ban or sshguard serve a purpose in ensuring that ssh skiddies don’t get to talk to anything else on the machine either.
staticassertion 6y ago
A major reason to move the port is exactly so that you can log when someone does hit 22, especially internally. If you standardize on port 5555, for example, and all of your tooling understands this, now you can audit 22. Anyone hitting 22 is either not using your standard tooling, or is at least potentially an attacker. Being alerted to an attacker is not a small thing.
- tachyonbeam 6y ago
  I'd be curious to see what happens if you setup a sophisticated fake SSH daemon on port 22. Give them access to a virtual machine connected to that port, and log every command they try to run.
- thinkharderdev 6y ago
  There is a flip side of that as well though. You may have a tool that tries to look at all SSH traffic across a fleet of servers (maybe trying to identify compromised internal hosts). If every server has sshd running on a different random port then you can't do this (or at least it becomes a lot harder). More generally, I think there is in fact a trade-off involved in deciding to explicitly ignore standards. Whether it hobbles automated network analysis or just causes friction in the development process, it can add up over time. That is not to say it is always a bad idea but I would just caution that, just as you shouldn't blindly reject "security by obscurity" you shouldn't blindly accept "security through obscurity" even if you have layered defenses. There is no substitute for thinking about individual circumstances and weighing explicit trade-offs.
  - staticassertion 6y ago
    No question, it's not a 0 cost change.

onion2k 6y ago

If they're following industry standard practice (I'm hoping you mean "key-based auth only") then there is absolutely zero reason to move the port, other than to avoid filling up your logs, and two IPTables rules take care of that anyway. This is what's known as 'putting all your eggs in one basket'. Relying on a strong auth mechanism is extremely sensible but only relying on that isn't. Exploits are found even in the oldest and best reviewed code. Nothing is 100% safe. If an exploit is discovered in the auth mechanism you're relying on then the obscurity of having SSH on a different port, with a mechanism to block port scanning, could at least buy you enough time to delay an attacker long enough for you to shut down auth until there's a fix. Considering the cost of switching port is so low it seems foolhardy not to.

liability 6y ago

If you interpret the term literally, then yes. However that's not the correct approach when dealing with terms of art like 'security through obscurity.' Wikipedia describes the term as it's actually used (emphasis mine): > Security through obscurity (or security by obscurity) is the reliance in security engineering on design or implementation secrecy as the main method of providing security to a system or component. An properly configured sshd on a non-standard port is not in any remote way using obscurity as it's main method of security.

petercooper 6y ago

I don't apologize for it, but I don't think yours is the only argument that can be made. What if a security hole is discovered in OpenSSL and overnight all those bots smashing port 22 are tweaked to take advantage of it? Let's assume a vulnerability that doesn't care about password auth being disabled. Sure, they might discover my sshd on port 17263 or whatever eventually but I am surely going to get a significant head start on all of the people having their boxes hacked left right and center. Sure, it's still security by obscurity, but it's nothing like the napkin example. It's more like hiding your phone under a table that has 20 other phones on top of it. When I hear about phones getting stolen, I've got a while to get mine back.

thinkharderdev 6y ago
That works both ways though. Imagine in your scenario you have thousands of servers across a large organization, many that may be running on auto-pilot and don't have any active team maintaining them. When the hypothesizes critical OpenSSL bug pops up, the first thing you will want to do is find out all the server in your network running sshd so you can patch them. If they are all listening on some random port then that task becomes much, much harder.

cedilla 6y ago

One thing to keep in mind here is that there is no absolute security. There is only security against some specific threat. If the threat is "someone is specifically targeting you", then changing the port is indeed useless. However, if the threat is "a botnet trying to abuse a new openSSH vulnerability", then changing the port does help. Because no bot takes the time to scan tens of thousands of ports in that case when there are millions of other hosts around who listen on port 22. By the way, when I lived in a dormitory, it was actually best practice to hide your valuables from view if you lived in a ground floor apartment. Literally obscuring the thing, but thieves only broke into the apartment where they knew there's something to steal quickly. A napkin over your wallet might not help in a bar but it did help in this case.

thaumasiotes 6y ago
> Literally obscuring the thing, but thieves only broke into the apartment where they knew there's something to steal quickly. A napkin over your wallet might not help in a bar but it did help in this case. The same approach works well for leaving stuff in cars. Visible bags or electronics tend to get stolen. The same thing under a sweatshirt doesn't.
peterwwillis 6y ago
> However, if the threat is "a botnet trying to abuse a new openSSH vulnerability", then changing the port does help. Because no bot takes the time to scan tens of thousands of ports in that case when there are millions of other hosts around who listen on port 22. It takes about 8 minutes to scan the whole internet for port 22. If there's an SSH 0day, and I have a botnet, I am going to make the entire botnet scan the entire internet on every port, because I know people move their SSH port. With 5,000 hosts, I can scan all 65,535 TCP ports across the entire internet in 104 minutes. How fast can you patch your server after the 0day's been announced? What if you're asleep? The time it takes to change the SSH port could also be used to harden the sshd config, which would eliminate several classes of previous exploits. A little more time and the entire system could be hardened, so that even if you are attacked, the attacker can't do much of anything.
- 6y ago

kps 6y ago

Someone attacking ssh may also attack other services (e.g. http) that may have vulnerabilities. fail2ban on port 22 keeps them away.

Karunamon 6y ago
I was going to say.. fail2ban or sshguard serve a purpose in ensuring that ssh skiddies don’t get to talk to anything else on the machine either.

staticassertion 6y ago

A major reason to move the port is exactly so that you can log when someone does hit 22, especially internally. If you standardize on port 5555, for example, and all of your tooling understands this, now you can audit 22. Anyone hitting 22 is either not using your standard tooling, or is at least potentially an attacker. Being alerted to an attacker is not a small thing.

tachyonbeam 6y ago
I'd be curious to see what happens if you setup a sophisticated fake SSH daemon on port 22. Give them access to a virtual machine connected to that port, and log every command they try to run.
thinkharderdev 6y ago
There is a flip side of that as well though. You may have a tool that tries to look at all SSH traffic across a fleet of servers (maybe trying to identify compromised internal hosts). If every server has sshd running on a different random port then you can't do this (or at least it becomes a lot harder). More generally, I think there is in fact a trade-off involved in deciding to explicitly ignore standards. Whether it hobbles automated network analysis or just causes friction in the development process, it can add up over time. That is not to say it is always a bad idea but I would just caution that, just as you shouldn't blindly reject "security by obscurity" you shouldn't blindly accept "security through obscurity" even if you have layered defenses. There is no substitute for thinking about individual circumstances and weighing explicit trade-offs.
- staticassertion 6y ago
  No question, it's not a 0 cost change.