Security by obscurity is underrated • Hacker News Board

Re: Security by obscurity is underrated

#251

Post by _tk_ » Fri, Sep 11, 2020, 7:21 PM UTC

thinkharderdev wrote: post #196

mercer wrote: post #64

Earlier quoted context omitted.

> Typically you want to know who is connecting to what server via what service and log these connections. If something is off, an alert can be generated. If ssh isn't served on a standardized port, logging and alerting becomes more complicated - albeit not impossible. Could you elaborate on that? I serve ssh on a non-standard port precisely in part because it drastically cut down on the noise of failed log-ins, to th…

Not the OP but I assume what they mean is that if you have network-wide monitoring across a network with lots of servers then it won't be able to easily make sense of what is happening if servers are all using non-standard ports for things.

Correct. This is an argument made from a corporate network perspective.

Re: Security by obscurity is underrated

#252

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

A lock that keeps an experienced lock-picker out for a few minutes will keep the layperson out indefinitely... Until they grab the bolt cutters. Everything is relative to context.

Re: Security by obscurity is underrated

#253

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

Macha wrote: post #206

Sebb767 wrote: post #170

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

So I get 10s of attempts a day for my sshd on port 7xxx. If I had an account with say ubuntu:ubuntu, it'd totally have been found by now.

I have 0 in the last 14 days on port 2xxx. Probably depends a lot on your IP range (I'd assume AWS etc is scanned more thoroughly) and whether you've happened to hit a port used by another service. But even in commercial ranges, I've seen hardly any hits on >10k.

But I have only anecdotal evidence as well, so my guess is as good as yours.

Re: Security by obscurity is underrated

#254

Post by draugadrotten » Fri, Sep 11, 2020, 7:25 PM UTC

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.

> Wasting an attackers time is a fine goal. reply

This. Putting a tarpit on port 22 isn't going to stop an attacker, but it will slow the ssh scans down for everyone.

https://github.com/skeeto/endlessh

Re: Security by obscurity is underrated

#255

Post by cthalupa » Fri, Sep 11, 2020, 7:26 PM UTC

dec0dedab0de wrote: post #7

I'm surprised port knocking never really caught on. Does anyone know of it being used in production anywhere?

For production use cases in a business environment it's just not as good as the alternatives. Setting up VPNs and blocking SSH access to the internet is just as easy, less overhead, and more secure.

Let's say you're a bank. You implement port knocking as your security measure of choice to keep SSH secure.

I know from your job postings that your developers and IT department work at X location in Y city. I know the IP range of your public facing servers. I go to the closest coffee shops to that office, and drop off some wifi sniffers that record and send me all the communication to that IP range. All it takes is one of your employees doing some work on one of those servers from the coffee shop, and now I know your port knock sequence. Layer defeated.

Or, you use a VPN. I do the same thing. All I see is VPN traffic. Maybe I can identify what type of traffic with DPI (unlikely to have the horsepower on the type of device you'd be leaving unattended at/near coffee shops for extended periods of time), but no real details on where that traffic is ultimately headed, and I have no ingress point given up to me. The VPN can also be used to secure other types of traffic beyond SSH.

There's just not really any reason to use port knocking over a VPN when the difference in overhead and complexity is minimal and the benefits you get with a VPN vs. port knocking are so massive.

Re: Security by obscurity is underrated

#256

Post by cthalupa » Fri, Sep 11, 2020, 7:31 PM UTC

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.

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?

Re: Security by obscurity is underrated

#257

Post by tlarkworthy » Fri, Sep 11, 2020, 7:31 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/

Yes, you have lovely clean logs to audit

Re: Security by obscurity is underrated

#258

Post by yabones » Fri, Sep 11, 2020, 7:32 PM UTC

scarmig wrote: post #195

yabones wrote: post #165

Earlier quoted context omitted.

I think a lot of the people in this comment thread are missing the point when using the `sshd` example. There is no single infallible way to secure ssh, but there are a lot of things that can be done together to make it pretty darn hard to hack, and most of those countermeasures have some degree of 'obscurity' to them. Example: * Use RSA keys instead of passwords -> This will eliminate most risk, except for exploits…

Each security measure has a value and a cost. Keys over passwords provide by far the best value/cost ratio. Using obscure ports or port knocking or whitelisted IPs are relatively clunky mechanisms that are more expensive and obscure your security posture as much to yourself as to adversaries.

This is absolutely true, but in some ways this is more about reducing the number of 'attempted connections' in the sshd log. Meaning, any failed connection that is recorded (and ideally shipped off to a centralized log system) is in some way actionable. Opening up port 22 (with keys) will still create tonnes of alerts from any SIEM.

The other thing to consider is that there could be exploits in OpenSSH itself. There hasn't been a truly critical vulnerability in a very long time, but low severity or non RCE vulnerabilities aren't exactly rare: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openssh

Re: Security by obscurity is underrated

#259

Post by yalogin » Fri, Sep 11, 2020, 7:32 PM UTC

The author doesn’t understand the phrase “security by obscurity” and doesn’t know why we use that. He took the normally used phrase literally and ran with it.

The phrase is used to suggest developers shouldn’t think that obscuring something provides security. We don’t say not to obscure stuff. In fact all the examples in the articles are from what’s already used in products. So the security community uses the best available method to secure the given task/stack already.

Re: Security by obscurity is underrated

#260

Post by topkai22 » Fri, Sep 11, 2020, 7:33 PM UTC

GhostVII wrote: post #50

One thing I didn't see discussed in the article was the balance between the benefits of security by obscurity, and the benefits of having your code open source (or at least making your security methods known) so more people can audit it. Personally I don't actually think there is that much security benefit to having open source code since most people don't audit random codebases for fun, but that is one of the argume…

Open sourcing has to be done with the audience in mind. It generally doesn’t make sense to (publicly) open source a system that is idiosyncratic to a single organization. The only likely interested audience is hostile attackers. A useful general purpose dev tool though? Sure, and the people using it might be able to help.