[linsomniac]

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.

[Aurornis]

> 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]

> 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]

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]

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]

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]

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

[i_think_so]

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

[vlovich123]

If you think it’s not trivial to get 64k random IP addresses to make requests for you for pennies, you are completely delusional if you think fail2ban protects a random port number in any way.

[i_think_so]

It's not "trivial", and it costs dollars, not pennies for that many attack endpoints[1]. My firewalls scale much more cost effectively, especially when I coalesce individuals into netblocks.

I don't think fail2ban protects obfuscated ports, I know it. If an IP is trying to connect to a system on port 22, it is ipso facto unwanted and doing unauthorized activities. Plonk! Onto the ban list it goes. You'd be surprised how effective that is.

Once the roar of automated skiddies is silenced, the signal of real attacks cuts through the noise quite clearly.

Remember, to avoid being eaten by most bears, you don't have to outrun them -- you only have to outrun the poor sap next to you. ;-) There is real world value in raising the bar and becoming even a moderately harder target than the rest of the crowd.

Maybe I should spin up a vanilla VM and just let it get hammered for a month and post the logs here....

[1] It's been a while since I looked at prices for tens of thousands of distinct proxy connections. Anyone want to pretend to be a hax0r and get a current price quote?

[spacemule]

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.

[i_think_so]

> 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]

> 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]

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."

[logifail]

> 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]

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