9 ms·

I really hate the accusation that changing services to uncommon ports is security through obscurity. It's not a security practice, it's a high pass filter. The

I really hate the accusation that changing services to uncommon ports is security through obscurity. It's not a security practice, it's a high pass filter. There's billions of hosts on the Internet and many millions of them running an SSH service. Even attackers with huge botnets at their disposal have finite resources and time to probe for hosts and then try exploiting vulnerable ones. Every exploit attempt has some percentage chance of being against a honeypot used to help catch the attacker. There's little point in even sniffing non-standard/uncommon ports for different services. Anyone changing a service port has a higher likelihood of having a more secure system than someone with standard ports. So even if you scan high number ports for an SSH service you're unlikely to find one on a high port that's not using a more secure than default configuration. So when you have SSH listening on some uncommon port and see hits in your logs you have a reasonable assurance the attacker isn't some script kiddy spamming the "attack" button on some stupid app. You also have reasonable assurance blocking that host/network with fail2ban or equivalent will actually be effective. You can also set way more strict fail2ban rules since you're far less likely to ever lock out authorized traffic. The more specific your allow criteria the better and more effective your block rules can be. A "Beware of Dog" sign doesn't physically secure your house on its own. You might not even have a dog. What it does in change the calculus for a burglar. Why risk it when there's more obviously less risky targets nearby? The sign is a high pass filter.

dheera 6y ago
Fully agree. If you want security by obscurity, modify openssh-server and jumble up the protocol a bit. XOR all the bits with some key. Send ssh packets encapsulated in Skype video frames or encoded in the fur of cat pictures over HTTP port 80. I'm not actually joking -- the above tricks work really well for stable connections through the China firewall.
a1369209993 6y ago
Exactly: moving your SSH port isn't security by obscurity because it's not security in the first place.
- geekamongus 6y ago
  It is just obscurity.
  - naniwaduni 6y ago
    It's log filtering. Log filtering has about as much impact on security as having overseas contractors watch your security cameras.
    - opless 6y ago
      It's not even that. I have certain hosts behind a single IP and forward SSH to them on arbitrarily chosen ports. Do I still get random logins on those ports? Why yes I do. Does putting SSH on a different port make any difference? No it doesn't. Putting SSH on a different port is either done for a specific reason, or you're just deluding yourself that you've somehow reduced your attack surface.
      - p4bl0 6y ago
        It clearly makes a difference for me. My servers which have SSH listening on port 22 have countless failed login attempts. Those running it on another random port have almost none.
        opless 6y ago
        Then you're clearly a statistical outlier :)
        edoceo 6y ago
        Me and @p4bl0. I've got one box with ssh on 22. Logs are very noisy and the rules from fail2ban grow and grow. On the other 20+ boxen with ssh on port xxx22 the logs and f2b rules are much smaller - which means less hassle for the admin. And on the boxen with services behind WG there is zero noise. Naturally we're using keys only with all this. The reduced noise in the logs/rules/firewall are very handy.
spullara 6y ago
Haven't seen one in a while bug a steering wheel club lock had the same effect. A determined attacker could just cut the steering wheel and remove it but there were a bunch of other cars without them.
cthalupa 6y ago
So here's the problem: Ports under 1024 are privileged in Linux - they require root or root delegated privileges to run. When SSH is on port 22, you have the assurance that unless the server is root compromised, it is what you think it is running on that port. When you make that port 2222 or whatever, like so many people do, you have cut out a lot of noise... but now that compromised PHP application you had running has allowed someone to now race you every time SSH is restarted for an update or crashed or whatever to bind on that port. Let's say it wins - now you've got something listening on the SSH port. If someone using SSH ignores the fact that the host key has changed, now they're trying to login to a fake SSH server. Maybe you use password auth and you just gave them the password. Maybe they're using an OpenSSH client that is vulnerable to leaking private keys in certain situations. Maybe the fake SSH server pretends to be a real shell and they then log whatever actions you try to take when you SSH in. Because they're going to be able to figure out what port SSH is listening on - a fingerprinting port scan can be done in seconds. You are sacrificing security when it comes to a more focused attacker for the sake of filtering out the low effort mass scans and basic brute forces. The thing is - I'm worried about the former, not the latter. If you care enough about securing or filtering your SSH to go through any of this trouble, just set up a VPN on a separate machine and restrict SSH access via firewall to that machine. Spin up the smallest VM your cloud provider has, throw up wireguard on it, and you're good to go. It'll be plenty for a VPN that's basically just there for SSH access. Now someone has to have both an exploit for wireguard and an exploit for SSH to get into your machine that has things you care about, you've filtered out all the noise, and you haven't introduced new security risks for a more determined attacker.
- ses1984 6y ago
  >If someone using SSH ignores the fact that the host key has changed Here's the real problem. Also if you're worried you could use SELinux, AppArmor, or things like docker to limit the capabilities of a compromised PHP application.
  - cthalupa 6y ago
    It is a major issue. Things like autoscaling have got a lot of bad habits ingrained in people though. You should definitely use SELinux or AppArmor. For any production workload I do. But for any production workload I don't allow SSH over the public internet. I require a VPN connection to a subnet that only has jumphost(s), the jumphost access logs are shipped to an ELK stack, SSH requires both a key + MFA to login to the jumphost, and SSH between production servers is blocked and alarmed on.
noncoml 6y ago
You mean low pass? High pass filter allows high frequencies through. High. Pass.
- pas 6y ago
  They mean filter out the low value noise (like you would filter out the constant hum of the PSU/grid), the scans on the usual ports (which all happen to be low port numbers).
  - deleted 6y ago
    [deleted]
Florin_Andrei 6y ago
Non-standard ports greatly reduce the incidence of drive-by shooting attacks. That alone is worth the minimal effort involved.
macspoofing 6y ago
>I really hate the accusation that changing services to uncommon ports is security through obscurity. If you're doing this for security reasons, then it is by definition 'security through obscurity'. The problem is that you don't like the term because it generally carries a negative connotation. What you and the author should be arguing is that 'security through obscurity' shouldn't be seen as a negative necessarily. >So when you have SSH listening on some uncommon port and see hits in your logs you have a reasonable assurance the attacker isn't some script kiddy spamming the "attack" button on some stupid app. How do you figure that?
dwild 6y ago
EDIT: What happens to HN? It's my second post that get downvoted for no reason in this thread. This whole post is mostly question asking for clarification, how can they deserve to be downvoted? > So when you have SSH listening on some uncommon port and see hits in your logs you have a reasonable assurance the attacker isn't some script kiddy spamming the "attack" button on some stupid app. Do you remove a vulnerability by doing this? Whatever you are afraid that the script kiddy may do, still can happen, thus it is security by obscurity. > You also have reasonable assurance blocking that host/network with fail2ban or equivalent will actually be effective. Can you explain that to me? How is it less effective to block a script kiddy or not? Block him... that's it... > You can also set way more strict fail2ban rules since you're far less likely to ever lock out authorized traffic. Wait, what? How will it make less likely to block authorized traffic? As long as that traffic act like authorized traffic, it should still be authorized, isn't it? You would blanked ban traffic that doesn't try too many username/password?
- antoineMoPa 6y ago
  The argument is that moving ports act on the probability of the attack, not the possibility of the attack. Reducing the probability of the attack attemp is good in itself and reduces the noise and thus allows easier detection of worse attackers in server logs.
  - dwild 6y ago
    Hell I'm not arguing security by obscurity doesn't have an effect. I do believe it does hide security vulnerabilities that can be attacked, but it's still security by obscurity. >thus allows easier detection of worse attackers in server logs I would be amazed if you could show me a single instance where people would see an attacker in server logs and act on it... quickly enough too that it's effective. I'm pretty sure that it's extremely rare that anyone will look at logs, even small one, to catch theses kinds of situation. If that's really what you suggest as being an effective way to protect yourself, than that's what you should mentions that it's required to do to become effective. Fail2ban will act noise or not... which was my point in my comment.
gitgud 6y ago
> I really hate the accusation that changing services to uncommon ports is security through obscurity. It's not a security practice, it's a high pass filter. Well the high pass filter's purpose is to increase security. Therefore it is literally security through obscurity... Even if it's effective, that's what it is...
- lyjackal 6y ago
  No, seems to me that giantrobot's point is that adding randomness to port numbers is a light security through computational complexity (almost a shared secret), that can in turn be used to help prop up other security practices, such as fail2ban. Security through obscurity is reliance in security engineering on design or implementation secrecy
- MrStonedOne 6y ago
  Preventing people from ddosing your auth logs leading to false negative fatigue that lowers the effectiveness of your login monitoring security measures is actual security, not security by obscurity.
paul_f 6y ago
Thank you for this. The reason for moving ssh to a different port is not to stop a determined hacker, it is to lower the risk from script kiddies. It lowers the risk from stupid stuff, and is worth doing.
reincarnate0x14 6y ago
I think a useful related question is: Does running SSH on IPv6 count as security, or security through obscurity? Because the public facing SSH services I have on IPv6 have never been probed or had bad login attempts even once in the last four years. I don't consider that a security control at all.
- speleding 6y ago
  Good question. There is a lot of stuff you can safely move to IPv6 (monitoring, SNMP) and it will completely clean your logs of script kiddies trying get in that way. (Although it does not preclude you from actually securing those things, of course.) SSH is bit tricky though, because you may find yourself on a laptop in a hotel and then you would first need to create an IPv6 tunnel to be able to get in. If the only time you need to get in is during an emergency that's a hassle you don't need.
  - reincarnate0x14 6y ago
    If you're going to the trouble of having a tunnel solution then you don't need public SSH or whatever else to begin with :) It's a pity IPSEC is still such a total dumpster fire on Windows as it works great for ad-hoc with everything else, but thankfully Wireguard has been about as light-touch as VPNs get and I've had good luck getting it out of nearly any network.

dheera 6y ago

Fully agree. If you want security by obscurity, modify openssh-server and jumble up the protocol a bit. XOR all the bits with some key. Send ssh packets encapsulated in Skype video frames or encoded in the fur of cat pictures over HTTP port 80. I'm not actually joking -- the above tricks work really well for stable connections through the China firewall.

a1369209993 6y ago

Exactly: moving your SSH port isn't security by obscurity because it's not security in the first place.

geekamongus 6y ago
It is just obscurity.
- naniwaduni 6y ago
  It's log filtering. Log filtering has about as much impact on security as having overseas contractors watch your security cameras.
  - opless 6y ago
    It's not even that. I have certain hosts behind a single IP and forward SSH to them on arbitrarily chosen ports. Do I still get random logins on those ports? Why yes I do. Does putting SSH on a different port make any difference? No it doesn't. Putting SSH on a different port is either done for a specific reason, or you're just deluding yourself that you've somehow reduced your attack surface.
    - p4bl0 6y ago
      It clearly makes a difference for me. My servers which have SSH listening on port 22 have countless failed login attempts. Those running it on another random port have almost none.
      - opless 6y ago
        Then you're clearly a statistical outlier :)
        edoceo 6y ago
        Me and @p4bl0. I've got one box with ssh on 22. Logs are very noisy and the rules from fail2ban grow and grow. On the other 20+ boxen with ssh on port xxx22 the logs and f2b rules are much smaller - which means less hassle for the admin. And on the boxen with services behind WG there is zero noise. Naturally we're using keys only with all this. The reduced noise in the logs/rules/firewall are very handy.

spullara 6y ago

Haven't seen one in a while bug a steering wheel club lock had the same effect. A determined attacker could just cut the steering wheel and remove it but there were a bunch of other cars without them.

cthalupa 6y ago

So here's the problem: Ports under 1024 are privileged in Linux - they require root or root delegated privileges to run. When SSH is on port 22, you have the assurance that unless the server is root compromised, it is what you think it is running on that port. When you make that port 2222 or whatever, like so many people do, you have cut out a lot of noise... but now that compromised PHP application you had running has allowed someone to now race you every time SSH is restarted for an update or crashed or whatever to bind on that port. Let's say it wins - now you've got something listening on the SSH port. If someone using SSH ignores the fact that the host key has changed, now they're trying to login to a fake SSH server. Maybe you use password auth and you just gave them the password. Maybe they're using an OpenSSH client that is vulnerable to leaking private keys in certain situations. Maybe the fake SSH server pretends to be a real shell and they then log whatever actions you try to take when you SSH in. Because they're going to be able to figure out what port SSH is listening on - a fingerprinting port scan can be done in seconds. You are sacrificing security when it comes to a more focused attacker for the sake of filtering out the low effort mass scans and basic brute forces. The thing is - I'm worried about the former, not the latter. If you care enough about securing or filtering your SSH to go through any of this trouble, just set up a VPN on a separate machine and restrict SSH access via firewall to that machine. Spin up the smallest VM your cloud provider has, throw up wireguard on it, and you're good to go. It'll be plenty for a VPN that's basically just there for SSH access. Now someone has to have both an exploit for wireguard and an exploit for SSH to get into your machine that has things you care about, you've filtered out all the noise, and you haven't introduced new security risks for a more determined attacker.

ses1984 6y ago
>If someone using SSH ignores the fact that the host key has changed Here's the real problem. Also if you're worried you could use SELinux, AppArmor, or things like docker to limit the capabilities of a compromised PHP application.
- cthalupa 6y ago
  It is a major issue. Things like autoscaling have got a lot of bad habits ingrained in people though. You should definitely use SELinux or AppArmor. For any production workload I do. But for any production workload I don't allow SSH over the public internet. I require a VPN connection to a subnet that only has jumphost(s), the jumphost access logs are shipped to an ELK stack, SSH requires both a key + MFA to login to the jumphost, and SSH between production servers is blocked and alarmed on.

noncoml 6y ago

You mean low pass? High pass filter allows high frequencies through. High. Pass.

pas 6y ago
They mean filter out the low value noise (like you would filter out the constant hum of the PSU/grid), the scans on the usual ports (which all happen to be low port numbers).
- deleted 6y ago
  [deleted]

Florin_Andrei 6y ago

Non-standard ports greatly reduce the incidence of drive-by shooting attacks. That alone is worth the minimal effort involved.

macspoofing 6y ago

>I really hate the accusation that changing services to uncommon ports is security through obscurity. If you're doing this for security reasons, then it is by definition 'security through obscurity'. The problem is that you don't like the term because it generally carries a negative connotation. What you and the author should be arguing is that 'security through obscurity' shouldn't be seen as a negative necessarily. >So when you have SSH listening on some uncommon port and see hits in your logs you have a reasonable assurance the attacker isn't some script kiddy spamming the "attack" button on some stupid app. How do you figure that?

dwild 6y ago

EDIT: What happens to HN? It's my second post that get downvoted for no reason in this thread. This whole post is mostly question asking for clarification, how can they deserve to be downvoted? > So when you have SSH listening on some uncommon port and see hits in your logs you have a reasonable assurance the attacker isn't some script kiddy spamming the "attack" button on some stupid app. Do you remove a vulnerability by doing this? Whatever you are afraid that the script kiddy may do, still can happen, thus it is security by obscurity. > You also have reasonable assurance blocking that host/network with fail2ban or equivalent will actually be effective. Can you explain that to me? How is it less effective to block a script kiddy or not? Block him... that's it... > You can also set way more strict fail2ban rules since you're far less likely to ever lock out authorized traffic. Wait, what? How will it make less likely to block authorized traffic? As long as that traffic act like authorized traffic, it should still be authorized, isn't it? You would blanked ban traffic that doesn't try too many username/password?

antoineMoPa 6y ago
The argument is that moving ports act on the probability of the attack, not the possibility of the attack. Reducing the probability of the attack attemp is good in itself and reduces the noise and thus allows easier detection of worse attackers in server logs.
- dwild 6y ago
  Hell I'm not arguing security by obscurity doesn't have an effect. I do believe it does hide security vulnerabilities that can be attacked, but it's still security by obscurity. >thus allows easier detection of worse attackers in server logs I would be amazed if you could show me a single instance where people would see an attacker in server logs and act on it... quickly enough too that it's effective. I'm pretty sure that it's extremely rare that anyone will look at logs, even small one, to catch theses kinds of situation. If that's really what you suggest as being an effective way to protect yourself, than that's what you should mentions that it's required to do to become effective. Fail2ban will act noise or not... which was my point in my comment.

gitgud 6y ago

> I really hate the accusation that changing services to uncommon ports is security through obscurity. It's not a security practice, it's a high pass filter. Well the high pass filter's purpose is to increase security. Therefore it is literally security through obscurity... Even if it's effective, that's what it is...

lyjackal 6y ago
No, seems to me that giantrobot's point is that adding randomness to port numbers is a light security through computational complexity (almost a shared secret), that can in turn be used to help prop up other security practices, such as fail2ban. Security through obscurity is reliance in security engineering on design or implementation secrecy
MrStonedOne 6y ago
Preventing people from ddosing your auth logs leading to false negative fatigue that lowers the effectiveness of your login monitoring security measures is actual security, not security by obscurity.

paul_f 6y ago

Thank you for this. The reason for moving ssh to a different port is not to stop a determined hacker, it is to lower the risk from script kiddies. It lowers the risk from stupid stuff, and is worth doing.

reincarnate0x14 6y ago

I think a useful related question is: Does running SSH on IPv6 count as security, or security through obscurity? Because the public facing SSH services I have on IPv6 have never been probed or had bad login attempts even once in the last four years. I don't consider that a security control at all.

speleding 6y ago
Good question. There is a lot of stuff you can safely move to IPv6 (monitoring, SNMP) and it will completely clean your logs of script kiddies trying get in that way. (Although it does not preclude you from actually securing those things, of course.) SSH is bit tricky though, because you may find yourself on a laptop in a hotel and then you would first need to create an IPv6 tunnel to be able to get in. If the only time you need to get in is during an emergency that's a hassle you don't need.
- reincarnate0x14 6y ago
  If you're going to the trouble of having a tunnel solution then you don't need public SSH or whatever else to begin with :) It's a pity IPSEC is still such a total dumpster fire on Windows as it works great for ad-hoc with everything else, but thankfully Wireguard has been about as light-touch as VPNs get and I've had good luck getting it out of nearly any network.