Security by obscurity is underrated • Hacker News Board

Re: Security by obscurity is underrated

#221

Post by justinsaccount » Fri, Sep 11, 2020, 6:55 PM UTC

Sebb767 wrote: post #194

justinsaccount wrote: post #69

Earlier quoted context omitted.

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

> * The boxes using port knocking would be safe. No, saf er . It is very well possible to brute-force port knocking or eavesdropping the ports since that information is not encrypted. Is it harder? Of course, a lot, but if you think scanning 65k ports on each host on the internet is reasonable, then evading a port knock is very much, too.

eavesdropping, maybe. There are tools like https://github.com/mrash/fwknop that are not vulnerable to that or brute-forcing.

But brute forcing in general? not a chance. There are 18446744073709551616 4 port sequences.

Re: Security by obscurity is underrated

#222

Post by acoard » Fri, Sep 11, 2020, 6:55 PM UTC

Verdex wrote: post #111

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…

> 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). Most of the usages of "security through obscurity" that I've seen dissected and decried haven't been in the sense that something was being hidden, but rather that something was being confused. For…

Fair point! Obscurity as confusion is not what I had in mind, but your points on confusion are totally valid. Your analogy with predators works better here.

Using base64 encoding, or encrypting your database, are both examples in the article. While I agree base64 is super trivial, the point about either of these is defence in depth. In the language of the article, it's reducing likelihood of being compromised.

>If an attacker sees that your SSH port isn't where it's supposed to be OR if an attacker sees that your SSH port ignores all packets sent to it (unless you first send a packet thats 25 0xFF bytes), then either way they're being signaled that you are more trouble than the computer that has an open telnet port.

This is semantics. Personally I'd say if an attacker cannot sense anything to connect to, there is no "signal" you're sending. You're rather not sending a signal that you're a threat, as you're not sending a signal at all due to being functionally invisible. Otherwise, we could say literal nothingness is sending the same signal that your server is. We agree on the substance here, i.e. the obscurity increases the economic cost of hacking and works as a disincentive, so we may just agree to disagree on the semantics.

Re: Security by obscurity is underrated

#223

Post by somedude11 » Fri, Sep 11, 2020, 6:56 PM UTC

e40 wrote: post #207

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/

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.

Re: Security by obscurity is underrated

#224

Post by jopsen » Fri, Sep 11, 2020, 6:57 PM UTC

outworlder wrote: post #96

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…

Maybe the test should be: "is my system considered to be secure even without any obscurity?" If the answer is yes, then add obscurity. For instance, the port 22 example. Suppose you have a bastion host. SSHD running on port 22, root password disabled, passwords disabled (only SSH keys), no other services running, all other ports filtered/closed. It should be fairly secure, even if exposed to the internet, right? Now…

They are also non-trivial amounts of work, both to build and to maintain..

Someday, someone will have problems connecting and waste half a day debugging it before they realize what is up.

Re: Security by obscurity is underrated

#225

Post by cthalupa » Fri, Sep 11, 2020, 6:58 PM UTC

Sebb767 wrote: post #208

cthalupa wrote: post #168

Earlier quoted context omitted.

>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.

How many remote code execution exploits have we seen on webs applications? Many thousands.

But you don't need to make this trade off. SSH does not need to be open to the internet to begin with - make it only accessible via VPN. Now you don't have log spam from botnets in your logs, and it won't show up on a port scan that has fingerprinting enabled and scans the whole range, and you won't be as vulnerable if some sort of sshd exploit comes out that allows you to bypass auth.

Re: Security by obscurity is underrated

#226

Post by austincheney » Fri, Sep 11, 2020, 6:58 PM UTC

    risk = probability * severity

Security by obscurity is bad regardless of other controls because it does little to reduce probability of attack and nothing for severity. It is only barely helpful at reducing the probability of attack because it is ineffective against various forms of automated footprinting. That is just the attacker.

Security controls impact everybody though. Not only does it make the problem obscure to an attacker it also makes the problem obscure to non-attackers. This dramatically increases risks because it impacts the application and distribution of other security controls.

Since it’s barely helpful where intended and harmful where it’s unintended security by obscurity only increases risks.

The analogy to software is the belief that hiding source code makes it safer. Hidden source code is not any safer but the vulnerabilities are a bit harder to find. The benefit of open source is that the vulnerabilities are exposed to anybody who reads the code which allows more vulnerabilities to be exposed and patched.

Re: Security by obscurity is underrated

#227

Post by daneel_w » Fri, Sep 11, 2020, 6:59 PM UTC

daneel_w wrote: post #99

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…

Though it would be a tragicomic shame if you got caught by a nasty 0-day while the clown up at port 34015 narrowly escaped and earned enough time to patch before pre-mapped host scans begun.

Doesn't matter how much you vote me down. You know it's an entirely possible scenario, and having your sshd "off-port" as part of the security strategy can make the difference.

Re: Security by obscurity is underrated

#228

Post by xenocyon » Fri, Sep 11, 2020, 7:00 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…

That's not the only problem with obscurity. It not only obscures flaws from attackers, it also obscures them from you and makes a system hard to maintain. In any complex system, ultimately there will develop chinks in your armor that owe their existence to obscurity hacks that were thought clever at the time.

Re: Security by obscurity is underrated

#229

Post by Sebb767 » Fri, Sep 11, 2020, 7:03 PM UTC

cthalupa wrote: post #225

Sebb767 wrote: post #208

Earlier quoted context omitted.

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.

How many remote code execution exploits have we seen on webs applications? Many thousands. But you don't need to make this trade off. SSH does not need to be open to the internet to begin with - make it only accessible via VPN. Now you don't have log spam from botnets in your logs, and it won't show up on a port scan that has fingerprinting enabled and scans the whole range, and you won't be as vulnerable if some sor…

Oh, don't get me wrong, I fully agree with you. My point was only that if you see it as an either-or-scenario[0], the higher port is probably the better choice.

[0] Might be true for something like a bastion host, which must expose ssh or VPN (which would be the same scenario).

Re: Security by obscurity is underrated

#230

Post by cthalupa » Fri, Sep 11, 2020, 7:04 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…

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 non-privileged user that got access via a RCE on your web application can now set up their own fake sshd and listen in to whatever you are sending if it manages to bind to that port first and you ignore the host key mismatch error on the client side.

Or you can implement real security, like not allowing SSH access via the public internet at all and not have to make this trade off.