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

351–360 of 530 posts

Re: Security by obscurity is underrated

#351

Post by [deleted] »

b0rsuk wrote: post #245
Verdex wrote: post #65

Earlier quoted context omitted.

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…

I've heard a better analogy - security by obscurity is like camouflage on a tank. A tank has massive armor and a terrifying gun to defend itself with. But even a half-assed camouflage can delay enemy reaction by a few seconds. Sometimes it's all it takes, because it lets you shoot first. In addition, the cost of camouflage paint or a net is laughably low and can be replaced in the field. It's simply an extra layer of…

[deleted]

Re: Security by obscurity is underrated

#352

Post by hnruss »

The problem with security through obscurity is the false sense of security that it provides. This in itself can lead to vulnerabilities.

Regarding data obfuscation, for example:

- Can an average person differentiate between encrypted data and well-obfuscated data just by looking at it?

- Would it be reasonable for the average person to assume that obfuscated data is equally as "secure" as encrypted data?

- Might someone store and transmit "secure" data differently than normal data?

Re: Security by obscurity is underrated

#353

Post by cthalupa »

magicalhippo wrote: post #335
cthalupa wrote: post #243

Earlier quoted context omitted.

>* Change the default port from 22 to something in the 40k+ range, which will keep you from being scanned, and I'm replying to these suggestions all over this item because I think it's important, so I apologize if you've since seen this comment elsewhere, but: This introduces new security risks. Non-privileged users can bind on ports in the 40k+ range and cannot bind on 22. If you restart sshd for a software upgrade…

> This introduces new security risks. Non-privileged users can bind on ports in the 40k+ range and cannot bind on 22. My firewall does port mapping so externally it's not 22, but internally it is.

This is significantly better than just changing the port the daemon listens on, for sure.

There's still public access to SSH, so you're still at risk from a zero day, weak credentials, etc., so I don't think it's quite to ideal levels where you are employing a VPN, disallowing all public access, etc., but at least you're not introducing new potential attack vectors :)

Re: Security by obscurity is underrated

#354

Post by cogman10 »

tetha wrote: post #41
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…

Internally, we phrase it as "Make the system objectively hard, then don't tell all the details". Wasting an attackers time is a fine goal.

It's a lot like bike locks.

Yes, most people can grab some bolt cutters, snip, and bike off. Yet, so many bikes remain unstolen with extremely week locks.

The vast majority of attacks are crimes of opportunity. Hackers aren't generally trying to target a single company or computer for a bot net, they are looking to get as many as possible. Almost any amount of effort above and beyond the typical will cause them to jump past you as a target.

Back to the bike lock analogy. Again, most locks can be bypassed, getting one that requires an edge grinder will almost certainly ensure that your bike won't be stolen (Why steal that bike when there are 20 with simple wire locks?). Add 2 locks and you've got a bike that will almost never be knicked.

https://www.youtube.com/watch?v=oPDHPpnXPv8

This video can teach you a LOT about software security.

Re: Security by obscurity is underrated

#355

Post by bleepblorp »

cthalupa wrote: post #317
bleepblorp wrote: post #313

Earlier quoted context omitted.

Protecting sshd behind a VPN just moves your 0day risk from sshd to the VPN server. Choosing between exposing sshd or a VPN server is just a bet on which of these services is most at risk of a 0day. If you need to defend against 0days then you need to do things like leveraging AppArmor/Selinux, complex port knocking, and/or restricting VPN/SSH access only to whitelisted IP blocks.

Except you don't assume that just because someone is on the VPN you're secure. If the VPN server has a 0day, they now have... only as much access as they had before when things were public facing. You still need there to be a simultaneous sshd 0day. I'll take my chances on there being a 0day for wireguard at the same time there's a 0day for sshd. (I do also use selinux and think that you should for reasons far beyond…

A remote code execution 0day in your VPN server doesn't give an attacker an unauthorized VPN connection, it gives them remote code execution inside the VPN server process, which gives the attacker whatever access rights the VPN server has on the host. At this point, connecting to sshd is irrelevant.

Worse, since Wireguard runs in kernel space, if there's an RCE 0day in Wireguard, an attacker would be able to execute hostile code within the kernel.

One remote code exploit in a public-facing service is all it takes for an attacker to get a foothold.

Re: Security by obscurity is underrated

#356

Post by magicalhippo »

cthalupa wrote: post #353
magicalhippo wrote: post #335

Earlier quoted context omitted.

> This introduces new security risks. Non-privileged users can bind on ports in the 40k+ range and cannot bind on 22. My firewall does port mapping so externally it's not 22, but internally it is.

This is significantly better than just changing the port the daemon listens on, for sure. There's still public access to SSH, so you're still at risk from a zero day, weak credentials, etc., so I don't think it's quite to ideal levels where you are employing a VPN, disallowing all public access, etc., but at least you're not introducing new potential attack vectors :)

What about VPN makes the VPN server software more secure than the SSH server software?

Re: Security by obscurity is underrated

#358

Post by viraptor »

rsync wrote: post #215
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…

"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", or fail2ban, which are all silly ideas." I know who I am arguing with here but port knocking is not silly. It's fantastic . When I say fantastic, I don't mean it solves all of our problems and obviates any other pr…

> almost zero cost

If it's your private pet server - sure. In larger networks you have to document the access, manage the allowed ports on the network, configure security groups or equivalent on instances, provide alternative steps for people with unusual clients (for example database UI app proxying over SSH), etc. The cost suddenly becomes very non-trivial.

Re: Security by obscurity is underrated

#359

Post by surfsvammel »

cthalupa wrote: post #346
jeroenhd wrote: post #324

Earlier quoted context omitted.

There have been bugs found in SSH server implementations that allowed limited remote code execution or even authentication bypasses. Missing an update or two isn't bad when nobody can figure out how to connect to your server. Of course you have to update at some point. However, if someone drops a zero day on your SSH server while you're asleep you're probably glad that you've got a secret sauce to protect your server…

If port knocking existing in a vacuum, sure. It'd be great. The issue is there are other options that are better - like VPN only access to SSH - that you can use instead of (or in addition to) If everyone advocating for port knocking was also saying set up VPN only access, sure. It's an additional authorization factor via where ports are used as a proxy for a PIN. But I haven't seen a single person in here saying the…

Curious, how does this work? I am not very familiar with VPN. Is the VPN connection setup for the SSH session only? What if someone needs to have multiple SSH session, going to different networks altogether?

Im thinking it could be pretty impractical to go onto a whole other network to open an SSH session.

Re: Security by obscurity is underrated

#360

Post by samatman »

fractionalhare wrote: post #281
somedude11 wrote: post #223

Earlier quoted context omitted.

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.

I basically use GPG for one thing, at this point: signing git commits.

As far as I know, there isn't another GitHub/GitLab compatible way to do this. So I'll keep using GPG until there is.

Post reply on HN