Live data from Hacker News

Security by obscurity is underrated

utkusen.com

411–420 of 530 posts

Re: Security by obscurity is underrated

#411

Earlier quoted context omitted.

> I believe there are sshd vulns extant that you and I don't know about and port knocking allows me to worry less about them. That's interesting, that's the first time I've heard a justification for port knocking that actually makes sense to me. I'm curious for others' thoughts here -- are non-public vulnerabilities something you consciously try to mitigate? So that, for example, using 2 different 8-character passwor…

I agree. I think this comes down to the Mickens Security Threat Model. Your adversaries come in basically two forms: Mossad and Not-Mossad. If your adversary is Mossad, you've already lost; if a governmental actor wants your data badly enough, they'll get it. If your adversary is not-Mossad, they almost certainly don't have access to any secret zero-day exploits; stay up to date on patches and use good passwords and…

[deleted]

Re: Security by obscurity is underrated

#412

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…

Also, related, the kind of traffic needed to probe in a reasonable amount of time can easily be spot.

Re: Security by obscurity is underrated

#413

Earlier quoted context omitted.

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?

My daily bread and butter is VPNs, but I must admit that I think there may be a truth here. While I fully agree that portknocking doesn’t provide the same layer of protection or flexibility a VPN does - but with the original article in mind: if your reason for deploying a VPN is because you fear to expose unknown bugs in sshd to the Internet the same could be said about every vpn solution. Therefore portknocking is /…

I think get where you're coming from here, but I don't fully agree.

>f your reason for deploying a VPN is because you fear to expose unknown bugs in sshd to the Internet the same could be said about every vpn solution.

Yeah. You might have a VPN zero day - but then you still have to get into the other SSH servers. Two zero days simultaneously active for openssh and your VPN solution? Pretty unlikely, especially public ones. Someone burning two private zero days on you means you're an incredibly high value target and neither of these would suffice as your sole defense to begin with.

The rest of your argument, if I'm understanding it correctly, is that you think people will get more lax with securing SSH on a box only reachable via VPN than if it was reachable by port knocking? It's possible, but I don't know that the evidence really shows that - lots of comments on this article are along the lines of "i set up port knocking and I've never even seen a malicious ssh connection attempt since then!" - no details of the rest of the security measures they've got in place.

And yeah, going from 'I set up a VPN to connect to my web servers via ssh' to 'I have VPN access to a whole network with all sorts of things running on it' is a big step up, but I don't think it's really in the boundaries of this discussion. Port knocking was never going to be a replacement for a larger VPN deployment, and when you're opening up network access to a wider range of things then how you approach things definitely needs to change.

Re: Security by obscurity is underrated

#414

Earlier quoted context omitted.

In the setups I've seen, once you've connected through VPN you're essentially on the LAN. If you compromise the SSH server, then you're also essentially on the LAN. Yes with the VPN you still have to compromise the server running the SSH service if that's the machine you want access to, but inside the LAN you now have a much greater attack surface. Of course if the setup is VPN -> firewall -> SSH to make sure only th…

But without the VPN, you're already the equivalent of on the LAN because all of these services are exposed to the public internet. In the discussion we're having, we're going from a setup where there is no equivalent to a private network because everything is public, to having a private network that only allows you access to the things that were previously public.

No because I have a firewall in front of the SSH, as mentioned. I would assume a firewall is in front of the VPN as well of course.

So either only SSH is exposed to the public, or only VPN is exposed. Without an additional firewall after the VPN, how is my LAN more protected with the VPN vs SSH?

Re: Security by obscurity is underrated

#415
post #393

Earlier quoted context omitted.

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

A tangent: are VPNs other than WireGuard less likely to have vulns compared to SSH? Seems the same to me (or worse for OpenVPN a few years ago)

You're asking for my opinion, and that's all I can relate, but here's my ranked ordering of things likely to have RCE vulnerabilities, from least to most secure:

* A Java, Python, or Ruby app server

* OpenVPN

* Stock nginx

    ----- starts to get really unlikely right here ----
* OpenSSH

* The Linux IP stack

* WireGuard

Re: Security by obscurity is underrated

#416
post #112

Earlier quoted context omitted.

> You seem to be thinking in terms of security mechanisms either perfectly blocking attacks or being useless. That's the wrong model. It's about costs. This is something that bothered me quite a bit in Bruce Schneier's various comments on airline security. He repeatedly wrote that profiling young Arab men as likely terrorists was pointless, because if it became harder for young Arab men to get through security, terro…

But it’s easier to find Arab women. Or an Irish girlfriend of an Arab man. Or two old Korean people. (All real examples)

No, obviously it's harder to find two old Korean people than one old Japanese person. Everything you've listed is hundreds, thousands, or millions of times more difficult than the young-Arab-man case.

Suppose you take down a plane with a young Arab man, and then you want to take down a second plane. There is a neverending stream of similar men willing to do the job. If your strategy requires you to use elderly Korean couples, you're done after the first plane -- you'll never find a second one.

Re: Security by obscurity is underrated

#417
"if you can reduce risk probabiloty with zero cost..." since when is obscurity zero cost? You've seen how much denuvo and vmprotect cost? Can you name any free free code obfuscator besides proguard that actually works? Can you name one that supports golang or rust? Security trough obscurity is considered bad because it's not zero-cost, and the investment you put into it might rather go into actual security

Re: Security by obscurity is underrated

#418

"if you can reduce risk probabiloty with zero cost..." since when is obscurity zero cost? You've seen how much denuvo and vmprotect cost? Can you name any free free code obfuscator besides proguard that actually works? Can you name one that supports golang or rust? Security trough obscurity is considered bad because it's not zero-cost, and the investment you put into it might rather go into actual security

Changing the port number is quite cheap.

Re: Security by obscurity is underrated

#419
post #362

Earlier quoted context omitted.

Yeah, I'm seeing a lot of nonsense in here. Why is SSH publicly accessible in the first place??? Security through obscurity is just some feel good bullshit.

Why shouldn't SSH be public? It is useful and simple to secure.

Well, there's basically two stances you can reasonably take:

1) SSH is secure enough just by using key based auth to not worry about it.

2) SSH isn't secure enough just by using key based auth so we need to do more stuff.

If you believe #1, then you don't need to do anything else. If you believe #2, then you should be doing the things that provide the most effective security.

Personally, I believe #1 is probably correct, but when it comes to any system that contains data for users other than myself, or for anything related to a company, I should not make that bet and should instead follow #2 and implement proper security for that eventuality.

I'm willing to risk my own shit when it comes to #1, but not other people's.

Re: Security by obscurity is underrated

#420
post #101
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 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…

I just turn off password authentication on SSH and moved to keys, then moved to IPv6. The automated scans haven't made it to v6 yet. The only better thing I could do is have an external v4 SSH honeypot that moves as slowly as possible to tie up a (tiny) resource.
Post reply on HN