Security by obscurity is underrated • Hacker News Board

Re: Security by obscurity is underrated

#201

Post by bob1029 » Fri, Sep 11, 2020, 6:40 PM UTC

Do we feel that honeypots might actually be one form of this? I.e. something that isn't deterministically going to prevent an attack like a OTP cryptographic scheme, but that may trick a large majority of attackers into thinking they are actually in a secure production system for a long time.

I know they are used primarily for detection, but why not go the extra step and make a honeypot that is a truly believable facsimile of a real corporate environment so the attacker wants to stay around even longer. There are lots of clever ways you can switch network traffic to make it look like you are talking to one host when in reality you are talking to a VM jail under a security administrator's desk. Load these environments up with fake, but believable data. How would an attacker know if they are in production actual, or fake prod? Once you "acquire" an attacker, you could even monitor their approach and string them along with hopes of getting into SVRSQLPROD (which is obviously going to be loaded with fake bullshit, but they wont know until they find the symmetric encryption key which you will probably never give them).

Again, I think we are all clear that the above is not deterministic security and that certain experienced attackers (or insiders) may be able to smell such a honeypot from a mile away.

Re: Security by obscurity is underrated

#202

Post by stjohnswarts » Fri, Sep 11, 2020, 6:40 PM UTC

Security by obscurity is dumb to count as part of your main toolbox of tactics. However it can be icing on the cake, like moving ports around and turning off ssh root login at all. Lowering your footprint never hurt. Sometimes you just have to run a little bit faster than the other guy if you're being chased by a bear.

Re: Security by obscurity is underrated

#203

Post by Shared404 » Fri, Sep 11, 2020, 6:40 PM UTC

umvi wrote: post #40

Shared404 wrote: post #30

Earlier quoted context omitted.

For JS, does it not make sense to use random variable names in production? Obviously you don't want to while developing, but it seems like an efficient method to help obfuscate.

Yeah, GP is saying you as the developer should not use random variable names. Let an uglifier select random names for you.

Ok, that makes sense. Thanks for clarifying for my stupid self.

Re: Security by obscurity is underrated

#204

Post by jonfw » Fri, Sep 11, 2020, 6:41 PM UTC

dec0dedab0de wrote: post #180

jonfw wrote: post #60

Earlier quoted context omitted.

port knocking is just, another way of doing a password, right? It's pretty much just a PIN code with a slightly obscure method of inputting the digits. I would imagine that this is open for a man in the middle attack- if this traffic were intercepted- you'd be able to see port numbers, right?

if this traffic were intercepted- you'd be able to see port numbers, right? Sure but I hope the service you're opening up with the knock is actually secure like ssh. The idea is just that you cant portscan to find something to attack. Its basically the same reasoning behind using non standard ports, but takes it a bit further.

The non-standard port is of trivial value, but it's practically zero cost- that's why it's used. Port knocking doesn't have that benefit- you're establishing another secret that has to be maintained and accessed- but unlike key based auth or passwords- that secret is insecure in transit and unwieldy to use.

If you want to add another layer and manage another secret- why not just add another layer of the lower-friction and more secure methods we already use to establish secret-based auth?

Re: Security by obscurity is underrated

#205

Post by ziml77 » Fri, Sep 11, 2020, 6:41 PM UTC

iso1631 wrote: post #162

bhauer wrote: post #143

Earlier quoted context omitted.

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'…

That isn't obscurity. And in your scenario, there was a security hole if the requirement was that you had to be on the intranet, but someone was able to gain access from the outside.

Re: Security by obscurity is underrated

#206

Post by Macha » Fri, Sep 11, 2020, 6:42 PM UTC

Sebb767 wrote: post #170

bleepblorp wrote: post #120

Earlier quoted context omitted.

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…

So I get 10s of attempts a day for my sshd on port 7xxx. If I had an account with say ubuntu:ubuntu, it'd totally have been found by now.

Re: Security by obscurity is underrated

#207

Post by e40 » Fri, Sep 11, 2020, 6:43 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…

The number of times I've seen people shitting all over port knocking is truly confusing. Since we added it several years ago, we've not had a single case of hackers trying to break into sshd. Before port knocking, 100's a day, even though it was on a very unusual port.

I try to tell people this, when they poo poo port knocking, but they just don't get it.

EDIT: s/the/they/

Re: Security by obscurity is underrated

#208

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

cthalupa wrote: post #168

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, o…

But that's putting the second line of defence (against an on-system attacker) above the first, which is to not get someone on the system in the first place. It definitely makes sense in some setups, but for your general purpose web server a high port is probably the right trade-off.

Re: Security by obscurity is underrated

#209

Post by thinkharderdev » Fri, Sep 11, 2020, 6:45 PM UTC

OminousWeapons wrote: post #92

The article is correct but they miss the true value add of security through obscurity: signaling lower ROI to attackers. Security through obscurity generally forces attackers to perform more actions and do more recon. Every additional action taken increases the risk of detection by defenders, costs the attackers valuable time (meaning lower ROI), and makes the target less appealing relative to other targets. Security…

I think it depends on what system you are talking about and where it is. So if you have an internet-facing server running sshd on port 22 then you are going to get hammered with low-effort, automated scans and changing to non-standard port can cut down on noise and at least "hides" you from low-effort attackers. But if your server is in a hardened, private subnet then any attacker that is even in a position to connect port 22 has already bypassed multiple layers of security and is already invested so likely won't be in the least bit deterred by a non-standard port.

Re: Security by obscurity is underrated

#210

Post by acoard » Fri, Sep 11, 2020, 6:46 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…

The article addresses this. He did a poll, and just under 50% of people use the default ports. So just by changing your default port, you eliminate half the break-in attempts.

Now you're absolutely right that this only deters less-skilled/inept hackers, a more competent hacker easily gets past this. But it's worth dwelling on the fact that we still stopped a substantial number of requests. Port knocking is definitely an improvement (i.e. more obscure). I'd guess with port-knocking more than 90% (even 99%) of attempts would completely miss it. The goal here isn't to rely completely on obscurity. It's security in depth. Your SSH server should still be secure and locked down.

The other question with this is what's your threat vector. Most people decry security through obscurity because an APT can easily bypass it. They can, but most people trying to hack you are script kiddies. Imagine an SSH exploit was leaked in the wild – all the script kiddies would be hammering everything on port 22 immediately.