Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Security by obscurity is underrated

utkusen.com

Post reply on HN
Print view View original

281–290 of 530 posts

Re: Security by obscurity is underrated

#281

Post by fractionalhare »

somedude11 wrote: post #223
e40 wrote: post #207

Earlier quoted context omitted.

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/

The same with "GnuPG is bad" mantra on hackernews. There is nothing better that GPG currently for all its functionality and the only answer you get when asking for substitute is don't use this function or use some obscure application. Yeah right.

I agree that there is nothing better than GPG for the narrow scope of encrypting email. But I think there are very few cases where encrypted email is the most secure way to communicate, in lieu of other forms of encryption.

Re: Security by obscurity is underrated

#282

Post by staticassertion »

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…

This doesn't consider that you can then monitor connections to port 22, and if you see any that's suspicious.

Disagree that port knocking is obscurity. That's a secret.

Security through obscurity would be using a nonstandard SSHD service.

Re: Security by obscurity is underrated

#283

Post by server_bot »

Fun article! I'd add that malware packers are a good example of an obscurity layer that's typically effective in practice.

But food for thought: in the general case you can't reliability predict the efficacy of an obscurity mechanism, so you never know if it's an actual layer of defense or a placebo.

Re: Security by obscurity is underrated

#284

Post by cthalupa »

acoard wrote: post #273
cthalupa wrote: post #230

Earlier quoted context omitted.

I know we've spoken in another thread, but I think it's important for people to understand that this sshd thing is a perfect example of why it isn't this easy: You reduce log spam moving to a non-privileged port, but also reduce overall security - a non-privileged user can bind to a port above 10k, but can't bind to 22. sshd restarts for an upgrade, or your iptables rules remapping a high port to 22 get flushed, that…

Here's a counter-example (I said else-where in this thread): Imagine a 0day for SSH drops tomorrow. Almost immediately script kiddies all over the world will be trying to take over everything running on port 22. I'll also point out that we're generally talking about different threat vectors here, so it's good to lay them out. I don't think obscurity helps against a persistent threat probing your network, it helps aga…

>Imagine a 0day for SSH drops tomorrow. Almost immediately script kiddies all over the world will be trying to take over everything running on port 22.

Yep! And I should be clear: I am not saying just don't change the SSH port. I'm saying if you care about security, at a minimum disallow public access to SSH and set up a VPN at a minimum.

>Unfortunately that's all too rare in most web-servers I see (I'm a bit confused here. In every major distro I've worked on (RHEL/Cent, Ubuntu, Debian, SUSE) the default httpd and nginx packages are all configured to use their own user for the running service. I haven't seen a system where httpd or nginx are running as root in over a decade.

I think the bare minimum for anyone that is running a business or keeping customer/end user data should be the following:

1) Only allow public access to the public facing services. All other ports should be firewalled off or not listening at all on the public interface

2) Public facing services should not be running as root (I'm terrified that you've not seen this to be the case in the majority of places!)

3) Access to the secure side should only be available via VPN.

4) SSH is only available via key access and not password.

5) 2FA is required

I think the following are also good practices to follow and are not inherently high complexity with the tooling we have available today:

1) SSH access from the VPN is only allowed to jumpboxes

2) These jumpboxes are recycled on a frequent basis from a known good image

3) There is auditing in place for all SSH access to these jumpboxes

4) SSH between production hosts (e.g. webserver 1 to appserver 1 or webserver 2) is disabled and will result in an alarm

With the first set, you take care of the overwhelming majority of both swarms and persistent threats. The second set will take care of basically everyone except an APT. The first set you can roll out in an afternoon.

With the first set, you take care of the overwhelming majority of situations.

Re: Security by obscurity is underrated

#285

Post by snowwrestler »

All software security comes down to obscurity: it depends on the selection of specific numbers that are known to the authorized parties, but are extremely difficult to guess (i.e. very obscure) to the unauthorized parties.

The extreme of this strategy is to make a successful guess cost more than anyone can possibly pay, for example by using numbers so obscure that all known algorithms for guessing them will take longer than the heat death of the universe to succeed, or something like that.

But while there seems to be solid math to calculate such numbers, implementations are rarely perfect and can easily leave open the possibility of other guesses that cost a lot less than breaking the theoretical limit. (AKA side channels, vulnerabilities, bugs, etc)

Where "security by obscurity" comes in for criticism, it's usually because the implementers have misjudged the amount of obscurity they are actually creating, or misjudged the amount they need (their threat model), or both.

It's easy to make these mistakes because it is hard to create perfect implementations, and hard to know exactly the current and future capabilities of your attackers.

Re: Security by obscurity is underrated

#286

Post by aazaa »

This article could benefit from a definition of "security by obscurity."

Every crypto system is based on obscurity of one kind or another. That private key, password, or token is just an obscure form of information that may yield, eventually, to a brute force attack. Or not. It's really hard to know for sure.

Re: Security by obscurity is underrated

#287

Post by ocdtrekkie »

I can't tell you how many times I've seen someone say doing something for obscurity shouldn't even be done because of the adage. Some of these adages are really harmful.

InfoSec has very much gotten a bunch of these statements that can't be argued with, and people won't even take you seriously if you point out the flaws with password managers or PKI.

I've definitely used methods in my own code which "aren't trustworthy" from a security doctrine standpoint, but proven near 100% effective, on their own. Just because a state actor won't be phased by it doesn't mean it isn't a strategy that'll prevent 99% of automated attacks.

Re: Security by obscurity is underrated

#288

Post by justinsaccount »

cthalupa wrote: post #256
rsync wrote: post #242

Earlier quoted context omitted.

Again, this is where all port knocking debates devolve to ... Port knocking is not the christ child that will wash away all of our sins ... and therefore is not worth implementing. You're right! It doesn't add that much . But it's non-zero and has almost zero cost. It's very elegant, in my mind, and it makes me very happy.

I guess my point is largely: I can set up a VPN in a roughly similar timeframe to setting up port knocking, and it has roughly similar overhead for end user, but the VPN gives me significantly more security while also solving the same issue port knocking does. In that case, why not just set up a VPN instead of port knocking?

Which vpn though?

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openvpn

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=pulse+secur...

VPN doesn't magically fix all problems.

wireguard is good so far, but the kernel implementation is in C, so who knows.

Re: Security by obscurity is underrated

#289

Post by iso8859-1 »

aazaa wrote: post #286

This article could benefit from a definition of "security by obscurity." Every crypto system is based on obscurity of one kind or another. That private key, password, or token is just an obscure form of information that may yield, eventually, to a brute force attack. Or not. It's really hard to know for sure.

Does this mean that https://en.wikipedia.org/wiki/Provable_security does not exist?

Re: Security by obscurity is underrated

#290

Post by dane-pgp »

gowld wrote: post #189
iso1631 wrote: post #162

Earlier quoted context omitted.

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

Of course security can lead to operational problems. Security is a trade-off against convenience.

> Of course security can lead to operational problems.

So can lack of security.

Post reply on HN