5 ms·

People really lose their mind over changing the SSH port. It's not an either/or choice between a non-standard port and all of the other SSH security settings. N

People really lose their mind over changing the SSH port. It's not an either/or choice between a non-standard port and all of the other SSH security settings. Nearly anybody that bothers to change the port is also going to follow most of the other industry-standard practices.

tracker1 6y ago
It's pretty much one of the first things I do when setting up a system... ssh port, no password logins, ufw. Of course, when I mess one of those up, I'm doing it again... but in general, that's my getting started step. If it's a really important system I'll go a step farther and enable a port knocking sequence... but that's about the extent of it. Generally speaking, I rarely setup port knocking.
- mercer 6y ago
  Same here. Just changing the port makes brute force attacks so rare that I feel I don't need to bother with port knocking or the like.
  - tracker1 6y ago
    65022 for the win... it's funny but many scanning scripts stop at 60000 or 65000, or only target specific known ports.
peterwwillis 6y ago
> 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

tracker1 6y ago

It's pretty much one of the first things I do when setting up a system... ssh port, no password logins, ufw. Of course, when I mess one of those up, I'm doing it again... but in general, that's my getting started step. If it's a really important system I'll go a step farther and enable a port knocking sequence... but that's about the extent of it. Generally speaking, I rarely setup port knocking.

mercer 6y ago
Same here. Just changing the port makes brute force attacks so rare that I feel I don't need to bother with port knocking or the like.
- tracker1 6y ago
  65022 for the win... it's funny but many scanning scripts stop at 60000 or 65000, or only target specific known ports.

peterwwillis 6y ago

> 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