Remix.run Logo
linsomniac 10 hours ago

I get what this post is saying, but I'm going to push back that "security through obscurity" isn't just something that people parrot without understanding.

Obscurity provides, effectively, no security. There may be other benefits to the obscurity, but considering the obscurity a layer of your security is bad. I hope we all agree that moving telnet to another port provides no security (it's easily sniffable, easily fingerprintable).

If it provides another benefit, use it, but don't think there's any security in it.

For ~30 years I've moved my ssh to a non-standard port. It quiets down the logs nicely, people aren't always knocking on the door. But it's not a component of my security: I still disable password auth, disable root login, and only use ssh keys for access. But considering it security is undeniably bad.

an hour ago | parent | next [-]
[deleted]
Aurornis 9 hours ago | parent | prev | next [-]

> but I'm going to push back that "security through obscurity" isn't just something that people parrot without understanding.

I disagree on this. It's right up there with "premature optimization is the root of all evil" on the list of phrases that get parroted by a certain type of engineer who is more interested in repeating sound bites than understanding the situation.

You can even see it throughout this comment section: Half of the top level comments were clearly written by people who didn't even read the first section of the article and are instead arguing with the headline or what they assumed the article says

elevation 9 hours ago | parent | prev | next [-]

> But it's not a component of my security

You may not see it as “security“, but any entity that is actively monitoring their logs benefits when the false positives decrease. If I am dealing with 800 failed login attempts per minute I cannot possibly investigate all of them. But if failed logins are rare in my environment, I may be able to investigate each one.

Obscurity that increases the signal to noise ratio is a force multiplier for active defense.

vlovich123 9 hours ago | parent | prev | next [-]

If port numbers were 64bit or 128bit, actually it would provide a meaningful amount of security through obscurity. Port numbers are easy to dunk on because it’s such a trivially small search space.

sudb 9 hours ago | parent | next [-]

Similarly I've often flip-flopped on the safety of public API endpoints that are "protected" by virtue of no sitemap + UUIDs in the URL path - I think the answer ultimately is that this is fine so long as there's no way to enumerate the IDs in use?

vlovich123 9 hours ago | parent [-]

It’s fine as a hardening measure, not as a security measure. The lack of a site map doesn’t necessarily guarantee it doesn’t leak somehow and then the question is what happens after it leaks

gavmor 4 hours ago | parent | prev | next [-]

But at this point, that's like saying my password is merely 'obscure.'

i_think_so 5 hours ago | parent | prev [-]

Good luck scanning 64k ports on a server that has a few randomly assigned fail2ban listeners.

spacemule 9 hours ago | parent | prev | next [-]

I would argue moving SSH to a non-standard port is security, but it's a different kind. By reducing the noise in logs, it reduces the workload on the human or agent reviewing the logs. So, you can detect an attack in progress or respond to an attack before it gets out of hand. With SSH on a standard port, the harmful malicious logs can blend in with the annoying malicious logs much better.

logifail 7 hours ago | parent | next [-]

> By reducing the noise in logs, it reduces the workload on the human or agent reviewing the logs.

Q: Why would you "review the logs" by (human/agent) hand for a service exposed to the Internet? What are you actually looking for?

[I say this as someone who has tens of thousands of failed auth attempts against services I expose to the Internet. Per day.]

i_think_so 5 hours ago | parent [-]

Sounds like you are the poster child for moving ssh to a different port. :-)

If I were you I would do that immediately. Then, once your logs become actually useful again, look at them.

"Hmmm. There sure seem to be a lot of failed login attempts for bobsmith@server. Maybe I should call him up and see if there's something going on."

i_think_so 9 hours ago | parent | prev [-]

> By reducing the noise in logs, it reduces the workload on the human or agent reviewing the logs. So, you can detect an attack in progress or respond to an attack before it gets out of hand. With SSH on a standard port, the harmful malicious logs can blend in with the annoying malicious logs much better.

Advice like this should be at the top of the chapter in the textbook that teaches young sysmonkeys how to admin a box securely. Well stated.

logifail 7 hours ago | parent | prev [-]

> It quiets down the logs nicely, people aren't always knocking on the door.

Q: If you've still done the right things - "disable[d] password auth, disable[d] root login, and only use ssh keys for access" - why do you care about how 'quiet' your logs are?

rcxdude 6 hours ago | parent [-]

Whatever you've done, you should keep an eye on your logs for anything suspicious. A quieter log is easier to monitor.