Security by obscurity is underrated • Hacker News Board

Re: Security by obscurity is underrated

#271

Post by Jumziey » Fri, Sep 11, 2020, 7:56 PM UTC

This article is so odd in its conclusion. The problem lies in obscurity generating a mess thats hard to reason around by designers, hiding obvious weakpoints, making it hard to find the most valuable area to work on. Changing from a default port should not really count as this since its easily configurable and does not impact neither the design nor usability (unless it does). Port scanning avoidance also fills an actual function in terms of load issues.

Rather what seem to be the issue is what security by obscurity actually means and can be missinterpreted as.

Layering lots of obscurity and putting time on that when it can be spent to increase security in the actual weakpoints or/and hiding them for developers/maintainers are problematic to say the least.

Re: Security by obscurity is underrated

#272

Post by choward » Fri, Sep 11, 2020, 7:58 PM UTC

cthalupa wrote: post #248

riquito wrote: post #232

It's like a painting in front of a safe: - doesn't reduce the security of the safe - ensure you don't advertise "THERE'S A SAFE HERE" to whoever visit your house, possibly reducing burglar attempts Now, if you have just the painting over a hole in the wall, you got something wrong...

Now, assume that every painting in your house can be checked for a safe behind it in milliseconds (total, for all safes) by the people in your house. Did you actually accomplish anything?

Yes, let's say you have random people over you don't know (to fix things for example). One of them is a criminal that wants to case your house to see if it's worth bteaking into when you're out of town. If you're with them the whole time they are working, they won't be able to just look behind the painting and your house doesn't become a target. That's assuming of course that the painting isn't too valuable.

Re: Security by obscurity is underrated

#273

Post by acoard » Fri, Sep 11, 2020, 7:59 PM UTC

cthalupa wrote: post #230

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…

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…

Here's a counter-example (I said else-where in this thread):

Imagine a 0day for SSH drops tomorrow. Almost immediately script kiddies all over the world will be trying to take over everything running on port 22.

I'll also point out that we're generally talking about different threat vectors here, so it's good to lay them out. I don't think obscurity helps against a persistent threat probing your network, it helps against swarms.

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

This is getting closer to APT territory, but I'll bite. If someone has RCE on your SSH server it honestly doesn't matter what port you're running on. They already have the server. You're completely right it would work if you have separate linux users for SSH and web server. Unfortunately that's all too rare in most web-servers I see (You're right that these events could happen. But you have to ask yourself what's actions of yours will have a bigger impact:

* Changing to non-standard SSH port, blocking out ~50% of all automated hacking attempts. Or port-knocking to get >90% (just a guess!). * Use standard port, but you still have an APT who owns your web server and will find other exploits.

Re: Security by obscurity is underrated

#274

Post by Enginerrrd » Fri, Sep 11, 2020, 8:02 PM UTC

robocat wrote: post #231

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…

Your example is advertising which is the opposite of security through obscurity. Obscurity is another layer of hiding or indirection: like the owl has camouflage and it has a hole in a tree. Advertising your fitness (your stotting metaphor) is effective when: you are part of a herd, and the attacker will only attack the weakest in that herd and then be satisfied. Like double locking your bike next to a similar bike t…

>An example of advertising your security might be Google project zero, or bug bounties.

That's more akin to a gecko sacrificing it's tail IMO. You're taking a predator that's capable of a successful attack and rewarding them for not doing it at some cost to yourself. It provides an easy and less risky way of getting paid.

Re: Security by obscurity is underrated

#275

Post by dublin » Fri, Sep 11, 2020, 8:03 PM UTC

weare138 wrote: post #44

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…

But the examples given won't help and is just bad advice in general. - Assume for every code obfuscator there's a deobfuscator or at least someone as clever as you out there. - Randomizing variable names it just a nuisance, it won't stop any competent pen tester or attacker. - Encrypting the database is an odd one. Your program will also have to decrypt the data to use it. Where do you store the encryption keys? In y…

Overloading names is a good code obfuscation strategy, but tricky and best done with code for obvious reasons (unless you like your regular code to present the challenges of BrainF). For instance, depending on your language, you may be able to have a variable, a function, an object, a pointer, a data structure, an index variable, etc. all called just "a".

Making sense out of code obfuscated this way is really* hard for humans, but will compile or interpret just fine so long as your obfuscator obeys the rules of your language. (We started on this at one of my early startups nearly 20 years ago, but didn't get funded soon enough for protecting the IP in our unique JS to matter. It was unique enough that we actually applied for a patent on part of it - drawing a 16 trace live strip chart of data from network sources at better than 4-10 Hz per channel was really hard with the bowsers and computers of 2002!)

Re: Security by obscurity is underrated

#276

Post by cthalupa » Fri, Sep 11, 2020, 8:05 PM UTC

choward wrote: post #272

cthalupa wrote: post #248

Earlier quoted context omitted.

Now, assume that every painting in your house can be checked for a safe behind it in milliseconds (total, for all safes) by the people in your house. Did you actually accomplish anything?

Yes, let's say you have random people over you don't know (to fix things for example). One of them is a criminal that wants to case your house to see if it's worth bteaking into when you're out of town. If you're with them the whole time they are working, they won't be able to just look behind the painting and your house doesn't become a target. That's assuming of course that the painting isn't too valuable.

But that scenario now takes us firmly outside the realms of what we’re discussing here. You’re actively monitoring the actions of people that you know are going to be there.

For an Internet facing server, it would be more like an art gallery where you have hidden the safe behind one painting, and the gallery is open 24/7 with no security to stop people from looking behind paintings, where you know a good portion of visitors are going to do so. You can see an identifier for each visitor that looks behind paintings, but many visitors are doing so and the person that comes in to crack the safe might not have been the person who found it.

Re: Security by obscurity is underrated

#277

Post by dastx » Fri, Sep 11, 2020, 8:09 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…

Sure, security by obscurity slows down bad actors, but in reality it's not by a significant amount. Often the obscurity that you add aren't even where they're looking. You have to go through a certain level of effort to add it the obscurity. That effort is not enough to warrant the insignificant slowdown of the bad actor. You're better off using that effort to improve your real security in other areas. In addition, you're adding complexity that you have to maintain.

Re: Security by obscurity is underrated

#278

Post by gridlockd » Fri, Sep 11, 2020, 8:11 PM UTC

Sebb767 wrote: post #238

justinsaccount wrote: post #221

Earlier quoted context omitted.

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.

And there are roughly 1267650600228229401496703205376 port 22's in the IPv6 space - I've substracted a few for reserved and unassigned spaces, but at this scale a few orders of magnitude hardly matter. Here, for comparison: 281474976710656 - total ports in IPv4 space 18446744073709551616 - 4 port combinations 1267650600228229401496703205376 - my estimation for 22 in IPv6 And if you don't block the knocking when recei…

The actual chances for guessing the 4 port combination are closer to 0.000000000000000000001%, about as likely as winning the lottery three times in a row. If you're trying to brute-force me with those odds, I'll take my chances.

Re: Security by obscurity is underrated

#279

Post by [deleted] » Fri, Sep 11, 2020, 8:14 PM UTC

cthalupa wrote: post #230

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…

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…

[deleted]

Re: Security by obscurity is underrated

#280

Post by Havoc » Fri, Sep 11, 2020, 8:15 PM UTC

The people arguing against "security through obscurity" seem to have an implicit assumption that you're not also doing proper security.

e.g. I move my SSH ports to a high port. But I also ed25519 keys. I think the port helps though. Plus keeps the logs clean.