It buys you enough time to check the journals and see that a group of IPs have attempted various ports giving you enough time to block the IP altogether.
It also buys you disinterest from the malicious host, since probably there’s a hard limit on how many ports they will test, and they will flag your machine as “too much work” and try another.
Again, I agree with you that obfuscation is not security, but it sure does help.
From what I understand you obfuscate the port in order to limit the amount of incoming attacks. But then fail2ban would be a much more effective tool.
The disinterested aspect you described is the actual problem. Because it’s based on the assumption your port won’t be found, but it definitely will, and as soon as that happens you’ll end up in a database such as shodan and the entire effect is GONE.
I see this claim all the time, and it bugs me every time. Obfuscation is a perfectly reasonable part of a defense in depth solution. That’s why you configure your error messages on production systems to give very generic error messages instead of the dev-centric messages with stack traces on lower environments, for example.
The problem comes when obscurity is your only defense. It’s not a full remediation on its own, but it has a part in defense in depth.
Obfuscation is not security, changing the port doesn’t increase your security
I hear you, but I disagree:
It buys you enough time to check the journals and see that a group of IPs have attempted various ports giving you enough time to block the IP altogether.
It also buys you disinterest from the malicious host, since probably there’s a hard limit on how many ports they will test, and they will flag your machine as “too much work” and try another.
Again, I agree with you that obfuscation is not security, but it sure does help.
From what I understand you obfuscate the port in order to limit the amount of incoming attacks. But then fail2ban would be a much more effective tool.
The disinterested aspect you described is the actual problem. Because it’s based on the assumption your port won’t be found, but it definitely will, and as soon as that happens you’ll end up in a database such as shodan and the entire effect is GONE.
I see this claim all the time, and it bugs me every time. Obfuscation is a perfectly reasonable part of a defense in depth solution. That’s why you configure your error messages on production systems to give very generic error messages instead of the dev-centric messages with stack traces on lower environments, for example.
The problem comes when obscurity is your only defense. It’s not a full remediation on its own, but it has a part in defense in depth.
Changing the port isn’t really much obfuscation though. It doesn’t take long to scan all ports for the entire IPv4 range (see masscan)
It helps against stupid automated attacks though.
If someone has changed the port it’s likely that they have set up a great password or disabled password auth all together.
It’s worth it for just having cleaner logs and fewer attempts.
Those logs are useful to know which IPs to permanently block :)
Technically a password is obfuscation anyway