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

371–380 of 530 posts

Re: Security by obscurity is underrated

#371

Post by weare138 »

kstrauser wrote: post #166
weare138 wrote: post #114

Earlier quoted context omitted.

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

But new people in the industry shouldn't think that the things recommended in the article should be used as a primary defense and are accepted industry practices. Moving SSH to a new port to reduce false security alerts is one thing, having people read that article and walk away thinking this is how we do things is another. We don't.

Re: Security by obscurity is underrated

#372

Post by tptacek »

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…

It solves none of your problems and adds complexity and cost to your defense without corresponding increases to attacker costs.

If you believe there are unknown OpenSSH attacks, you can't coherently believe that port knocking is a real defense, since port knocking doesn't do anything to protect the SSH channel that attacks will be carried out in.

Instead, if you're actually worried about OpenSSH vulnerabilities, you shouldn't be exposing SSH to the public Internet at all. I'm not super worried about OpenSSH server vulnerabilities, but I would never recommend that teams leave SSH exposed; they should just hide that stuff behind WireGuard.

Re: Security by obscurity is underrated

#373

Post by magicalhippo »

cthalupa wrote: post #368
magicalhippo wrote: post #356

Earlier quoted context omitted.

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

The level of security is cumulative. You do not trust a connection just because it's connected to the VPN. So if your VPN concentrator is compromised via 0day, the only access they get is the same as if things were listening on the public internet. To gain access to the server via SSH they now need both a way in to the VPN and a way in to SSH, vs. just needing a way in via SSH. It doesn't do much if someone just give…

Yeah but if they compromise the VPN they potentially have access to a lot more than just the SSH server. At least in the setups I've seen deployed.

Re: Security by obscurity is underrated

#374

Post by SahAssar »

snowwrestler wrote: post #285

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

> All software security comes down to obscurity

Isn't this the same as saying something like all astronomy is a matter of looking at the right place? Or all math is solving an equation? Or all surgery is cutting the right thing?

If you reduce anything to it's simplest part, it will sound simple.

Re: Security by obscurity is underrated

#375

Post by cthalupa »

bleepblorp wrote: post #355
cthalupa wrote: post #317

Earlier quoted context omitted.

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…

I do not run my VPNs on the same systems I am running other services on, so an RCE at most compromises the VPN concentrator and does not inherently give them access to other systems. Access to SSH on production systems is only available through a jumphost which has auditing of all logins sent to another system, and requires 2FA. There are some other services accessible via VPN, but those also require auth and 2FA.

If you are running them all on the same system, then yes, that is a risk.

Re: Security by obscurity is underrated

#376

Post by tptacek »

rsync wrote: post #242
cthalupa wrote: post #234

Earlier quoted context omitted.

Why not just block SSH access from the public internet and use a VPN? Trivially easy to setup and more secure than knocking. All it takes is me somehow being able to listen in on your traffic - not even decrypt it - and now I know the knock sequence. I know that you have SSH listening on that server. I know you are actively doing something on it. vs. a VPN where... all I know is you are communicating over a VPN. With…

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.

It doesn't add enough to compensate for its costs, which are commensurate with those of VPNs, which provide drastically more return on the investment. But VPNs don't have a cheering section, because they're so obviously useful that nobody has any incentive to make that banal observation. "Port knocking" is idiosyncratic and widely looked down on by security engineering teams, so there's a contrarian impulse that makes them seem worth discussing.

Re: Security by obscurity is underrated

#378

Post by perl4ever »

aeternum wrote: post #108
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…

It might make sense in some contexts, but code obfuscation is a great example of where software engineers think it provides security where it provides none. Developers often have some idealized notion that an attacker is going to need to piece their program logic back together and try to decode the purpose of each obfuscated variable in order to find a hardcoded password/value. In reality an attacker is just going to…

>simply set a breakpoint

I knew nothing about this topic in general, but elsewhere in this thread there was a link to a blog post about obfuscation methods used in a piece of commercial software. One item was a function that detects a breakpoint, obfuscates its boolean return value so you can't tell if it did, and makes the program hang when it does. Pretty neat.

I think your (and my) ignorance of such methods is evidence that they probably are reasonably effective, even though when explained, they're not quantum physics.

Re: Security by obscurity is underrated

#379

Post by px43 »

justinsaccount wrote: post #69
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…

> Just use SSH keys, and disable passwords. CVE-2001-0144 - SSH1 CRC-32 compensation attack detector allows remote attackers to execute arbitrary commands on an SSH server or client via an integer overflow CVE-2008-0166 - OpenSSL 0.9.8c-1 up to versions before 0.9.8g-9 on Debian-based operating systems uses a random number generator that generates predictable numbers, which makes it easier for remote attackers to con…

There is a vastly higher chance of there being exploitable bugs in port knocking tooling than there is of there being exploitable bugs in SSH. You are adding extra exposure and gaining nothing.

Re: Security by obscurity is underrated

#380

Post by cthalupa »

magicalhippo wrote: post #373
cthalupa wrote: post #368

Earlier quoted context omitted.

The level of security is cumulative. You do not trust a connection just because it's connected to the VPN. So if your VPN concentrator is compromised via 0day, the only access they get is the same as if things were listening on the public internet. To gain access to the server via SSH they now need both a way in to the VPN and a way in to SSH, vs. just needing a way in via SSH. It doesn't do much if someone just give…

Yeah but if they compromise the VPN they potentially have access to a lot more than just the SSH server. At least in the setups I've seen deployed.

I'm not sure I necessarily understand your argument, so my apologies if I'm off here.

In scenario 1, you do not gate access via VPN. Things are accessible via the public internet.

In scenario 2, you do gate access via VPN. Things are not accessible via the public internet. Someone compromises the VPN. They now have as much access as if there was no VPN and things were accessible to the public internet.

In scenario 2, you are more secure than in scenario 1 until the VPN is compromised. You are then just as secure as you were in scenario 1.

If you are not restricting access to a VPN in the first place, how would compromising a theoretical VPN result in greater access?

Post reply on HN