5 ms·
> Services on unexpected ports are more likely to be insecure than services on assigned ports. That line really surprised me. I'd have thought that somebody wh
by autoexec 4y ago
> Services on unexpected ports are more likely to be insecure
than services on assigned ports.
That line really surprised me. I'd have thought that somebody who knows enough to move a frequently targeted service to a different port to avoid low effort attacks/scans would know enough to use other protections, then I saw it was partly because of cheap IoT devices that have zero issues violating specifications out of the box.
- Turskarama 4y agoIt doesn't surprise me _at all_. Security through obscurity doesn't work, if you have real security you wouldn't bother using another port because there's no (security) reason to do so. If someone is trying to use ports as their security measure then it's because they don't actually know how to make their API secure properly.
- 0cf8612b2e1e 4y ago>if you have real security you wouldn't bother using another port because there's no (security) reason to do so. Strong disagree with that. If you do something as simple as moving SSH to a different port, the number of drive-by attacks will drop enormously. Raises the signal to noise of all connection attempts in the logs.
- autoexec 4y agoSSH is what came to mind right away. The bots never sleep and will happily hammer at your server and fill your logs all day. I'd never depend on a new port as the only protection though. One man's security through obscurity is another man's defense in depth.
- Turskarama 4y agoI guess that's true, but that's not a security reason.
- JohnFen 4y agoSure it is. Running on a nonstandard port is absolutely as adequate of a security measure as locking a screen door. But it does filter out a fair number of probes, and reducing the number of probes does increase your security. So it's like locking the screen door in front of your reinforced, deadbolted door. Some people will try the screen door, find it locked, and move on. It doesn't do a lot, but it's not entirely worthless, either.
- bfung 4y ago> Security through obscurity doesn't work Going to echo a sibling comment - This catchphrase may help people who know very little about security be a bit better. But to completely throw it out is counter to security’s goals. Obscurity can help reduce the surface area of attacks, but shouldn’t be used as the exclusive tool to secure something.
- catchnear4321 4y agoIt still needs a name even if it is a misnomer. Such as if you’ve ever gotten a confused note from IT that their automated health check failed to reach your internally hosted application. Sometimes all you really need is for the low effort, high volume “white hat” to just go away. The answer for why the heath check that you didn’t ask for didn’t work is simply “security through obscurity.” They love hearing that. It sounds clever.
- BrandoElFollito 4y agoOf course it works, and can be the only protection. It just depends on your risk profile. I can hide my service with a random key and you will never get to it. This is how a lot of data is shared when you do not have identity management. Of course once you share this URI then the one who what it can access the data. But again, it is a choice. Security is difficult, especially when someone jumps on without assessing their threat profile.
- _8j50 4y agoIt's not the sysadmin but the app/dev that is setting the port. When they do that, they are not intending for the public at large to find it easily and use it and services like that get less attention and care. A lot of data breaches happen for example by elastic's restful api being exposed because people don't change the defaults.
- pugworthy 4y agoOne reason (at least in the past) to use upper ports for web servers at least is when you want to run a server, don't have root permission to use 80, so you pick 8000, 8080, 8088, etc. And you think maybe you're clever and use 8089...
- webmaven 4y agoRemember, the 'S' in IoT stands for 'security'.