Security by obscurity is underrated • Hacker News Board

Re: Security by obscurity is underrated

#161

Post by shadowgovt » Fri, Sep 11, 2020, 6:13 PM UTC

Verdex wrote: post #65

cataflam wrote: post #13

Agree with the article. People have been misinterpreting "security by obscurity is bad" to mean any obscurity and obfuscation is bad. Instead it was originally meant as "if your only security is obscurity, it's bad". Many serious real-world scenarios do use obscurity as an additional layer. If only because sometimes, you know that a dedicated attacker will be able to breach, what you are looking for is to delay them…

In nature, prey animals will sometimes jump when they spot a predator[1]. One of the explanations is that this is the animal communicating to the predator that it is a healthy prey animal that would be hard to catch and therefore the predator should choose to chase someone else. I think we can kind of view obscurity in the same way. It's a way to signal to a predator that we're a hard target and that they should give…

The only downside I see immediately is that there's a counterweighted risk to obscurity in your security layer: you can confuse your own users (or yourself).

Many security tools I've used are downright user hostile in how little information they provide the end-user (or the admin!) regarding why an auth process failed. It incentivizes people to simplify or bypass the system entirely when they can't understand the system.

Re: Security by obscurity is underrated

#162

Post by iso1631 » Fri, Sep 11, 2020, 6:13 PM UTC

bhauer wrote: post #143

cataflam wrote: post #13

Agree with the article. People have been misinterpreting "security by obscurity is bad" to mean any obscurity and obfuscation is bad. Instead it was originally meant as "if your only security is obscurity, it's bad". Many serious real-world scenarios do use obscurity as an additional layer. If only because sometimes, you know that a dedicated attacker will be able to breach, what you are looking for is to delay them…

Agreed. The maxim warning against "security from obscurity" is often reduced to an irrational comprehensive avoidance of obscurity. It's similar to the irrational avoidance of all performance optimization because Knuth warned of premature optimization. Both reductions lose practical utility by omitting nuance. * Avoid wasting your time doing performance optimization until tuning is necessary. But definitely take obvi…

> But definitely take obvious and easy measures that leverage obscurity to add another layer of defense, such as changing default ports, port-knocking, or whatever.

Except that can lead to operational problems down the road. For example "oh yes, we're nice and secure, not only do you need a 512bit private key to get into this device, you also need to connect from a secure network"

Then along comes covid, and you can't get into the building.

"Oh dear, you're not on the secure network, you can't come in"

So you spend 2 hours (while your network isn't working right and you're losing customers) finding and getting in through a back door.

Re: Security by obscurity is underrated

#163

Post by Florin_Andrei » Fri, Sep 11, 2020, 6:14 PM UTC

cataflam wrote: post #13

Agree with the article. People have been misinterpreting "security by obscurity is bad" to mean any obscurity and obfuscation is bad. Instead it was originally meant as "if your only security is obscurity, it's bad". Many serious real-world scenarios do use obscurity as an additional layer. If only because sometimes, you know that a dedicated attacker will be able to breach, what you are looking for is to delay them…

All encryption is "security through obscurity". The parameter space is very large. The key is somewhere in it. You have access to the whole space, but no clue as to where the key is. Good luck finding the key.

> Instead it was originally meant as "if your only security is obscurity, it's bad".

Since all security is essentially "through obscurity" somehow, I would simply reframe that into the onion model. Good security is like an onion, it has many layers. When you only have one layer, that's bad security.

Re: Security by obscurity is underrated

#164

Post by surak » Fri, Sep 11, 2020, 6:14 PM UTC

bleepblorp wrote: post #120

acoard wrote: post #101

Earlier quoted context omitted.

>I think we can kind of view obscurity in the same way. It's a way to signal to a predator that we're a hard target and that they should give up. This has it completely backwards. Security through obscurity's goal is not to signal predators, it's the opposite. The goal is to obscure, to hide. The "signal" is there is nothing here (or nothing here worth your time). One of the best examples (it's in the article!) is ch…

Using a non-standard SSH port is a bad example because nmap can see through that deception in a few seconds. Any attacker who is looking for more than just the lowest of low-hanging fruit will not be even slightly deterred. A better example would be a port-knocking arrangement that hides sshd except from systems that probe a sequence of ports in a specific way. This is very much security by obscurity, because it's tr…

I agree with you that the example is not the best, but obscurity has a lot of benefits. We did an experiment with a few students on obscuring a WordPress installation some years ago to catch ppl scanning for certain plugins. That gave us the ability to use the regular paths as honeypots. Gives you an ability to detect 0-day attacks as well.

Re: Security by obscurity is underrated

#165

Post by yabones » Fri, Sep 11, 2020, 6:15 PM UTC

tptacek wrote: post #27

There's something to the idea of rehabilitating "obscurity", or at least recognizing that "cost" is part of threat models, and you can raise costs for particular attack vectors by degrees instead of "to infinity". But SSH is a terrible example, because the cost to the defender of simply not having SSH vulnerabilities is the same, or even less, than the cost of obfuscating it with nonstandard ports, "port knocking", o…

I think a lot of the people in this comment thread are missing the point when using the `sshd` example. There is no single infallible way to secure ssh, but there are a lot of things that can be done together to make it pretty darn hard to hack, and most of those countermeasures have some degree of 'obscurity' to them.

Example:

* Use RSA keys instead of passwords -> This will eliminate most risk, except for exploits in sshd itself,

* Change the default port from 22 to something in the 40k+ range, which will keep you from being scanned, and

* Whitelist IP addresses that can connect to port xx on your server -> This will eliminate 95% of remaining risk

* Using a 'clean' bastion server to access other systems via agent-forwarding, preventing malware on admin workstations from being able to propagate over SSH.

So, no you're never going to be 100% secure, that's just unreasonable. But like you said, the cost can be increased to the point that all but the most determinted state sponsored APT groups.

Re: Security by obscurity is underrated

#166

Post by kstrauser » Fri, Sep 11, 2020, 6:15 PM UTC

weare138 wrote: post #114

umvi wrote: post #72

Earlier quoted context omitted.

> Assume for every code obfuscator there's a deobfuscator or at least someone as clever as you out there. There is still some information lost in the process: - "let eigenvector_coefficient = 23" => "let x = 23" A de-obfuscator isn't going to be able to recover the valuable information contained in the original name. Will it stop a determined attacker? Maybe not, but it would surely slow them down as they now need to…

Let me give you an example. At a previous job as a devops, of my predecessors frequently used these "techniques, minus the encrypted database but I sure he would have done it if he knew how. So there was some buggy internal app they needed some new features added to and the person who wrote it thought he was clever and obfuscated the code. It took me a whopping 30 minutes churn through his 'clever' obfuscation scheme…

> I'm going to find whatever port your running ssh on if your running it.

I still think it's a good idea. With SSH on port 22, ten thousand bots plus an attacker try to hammer it (so says fail2ban). With SSH on port 9278, zero bots plus an attacker try to hammer it. By throwing away the 99.99% of the chaff, you can see the remaining wheat you care about.

Changing SSH ports isn't about saying "yep, we fixed it!" and calling it a day. It's about decreasing the amount of stuff you have to deal with, which is quite useful. It's something you can do in addition to everything else that gives a decent bang for its buck. No, it doesn't keep you out, but it does keep out those thousands of bots crawling around looking for an open 22 to pester.

Re: Security by obscurity is underrated

#167

Post by UI_at_80x24 » Fri, Sep 11, 2020, 6:17 PM UTC

I like to think of this in military terms.

"Don't be where the enemy expects to find you."

As TFA and several others have pointed out:

(1) Don't use this as your only method of defense. The further from your LOCK the better the key needs to be. (2) Use your security in the layers that offer the most benefit. (3) Be proactive in your defense.

-Changing your SSH port will stop that largest number of attempts on your service. -A non-default port PLUS port-knocking PLUS key-only PLUS whitelisted IPs PLUS whitelisted login names. Is better then only one of those. -Apply very liberal firewall rules to prevent any unauthorized from IP's that should have access to your service. Country-code level blocklists are a thing.

Being obscure is about NOT being where your opponent expects to find you.

Re: Security by obscurity is underrated

#168

Post by cthalupa » Fri, Sep 11, 2020, 6:17 PM UTC

n0on3 wrote: post #58

It seems to me that the article is missing a few of points on what "security by obscurity" means. From Wikipedia: "reliance [...] on design or implementation secrecy as _ the main method _ of providing security [...]" So, to use the model mentioned in the article, a single slice of cheese. It's not "an additional layer of defense", it's the main one (so you have other... weaker layers? ¯\_(ツ)_/¯) Second, "reliance on…

>ssh non-standard port is actually a good thing given the massive amounts of bots around

Except that if you use a port above 1024 (like the author does) you no longer have assurances that it is a privileged user that launched the process. Any non-privileged user on a Linux system can bind to a port higher than 1024, so all it takes is sshd restarting after an update if it's directly listening on a high number port, or iptables rules getting reloaded if they're being used to forward traffic from a high port to 1024 and an attacker can have their own credential collecting service running where you think sshd is, and all it takes is someone ignoring the host key mismatch error to give up your good creds to an attacker, and now they have more access into your infrastructure.

Re: Security by obscurity is underrated

#169

Post by johnisgood » Fri, Sep 11, 2020, 6:18 PM UTC

In many cases it is much better to fake (or spoof) information, rather than try to hide it. Browsers come into mind. Instead of trying to hide information about yourself, which would make you unique, just give them false information that is common, and that way you blend in with the rest of the people, everyone is content, and nothing true has been revealed of you.

Re: Security by obscurity is underrated

#170

Post by Sebb767 » Fri, Sep 11, 2020, 6:19 PM UTC

bleepblorp wrote: post #120

acoard wrote: post #101

Earlier quoted context omitted.

>I think we can kind of view obscurity in the same way. It's a way to signal to a predator that we're a hard target and that they should give up. This has it completely backwards. Security through obscurity's goal is not to signal predators, it's the opposite. The goal is to obscure, to hide. The "signal" is there is nothing here (or nothing here worth your time). One of the best examples (it's in the article!) is ch…

Using a non-standard SSH port is a bad example because nmap can see through that deception in a few seconds. Any attacker who is looking for more than just the lowest of low-hanging fruit will not be even slightly deterred. A better example would be a port-knocking arrangement that hides sshd except from systems that probe a sequence of ports in a specific way. This is very much security by obscurity, because it's tr…

> Using a non-standard SSH port is a bad example because nmap can see through that deception in a few seconds.

Compared to milliseconds. Do yourself the favor and open one sshd on port 22 vs one on a port >10000, then compare logs after a month. The 22 one will have thousands of attempts; the other one hardly tens if even any.

The 99% level we're defending against here is root:123456 or pi:raspberry on port 22. Which is dead easy to scan the whole IPv4 space for. 65K ports per host though? That's taking time and, given the obvious success rate of the former, is not worth it.

Therefore I'd say it's the perfect example: It's hardly any effort, for neither attacker nor defender, and yet works perfectly fine for nearly all cases you'll ever encounter.

EDIT: Note that it comes with other trade-offs, though, as pointed out here: https://news.ycombinator.com/item?id=24445678