Hacker News Reader

Comment by phoronixrly | Hacker News Reader

> By using those two techniques together:

> your attackers will have a tough time while trying to identify your real services.

So... Security through obscurity?

> the only way to determine if a service is emulated is through a protocol probe (imagine probing protocols for 65k open ports!).

So... Security through obscurity?

> it takes more than 8hours and 200MB of sent data in order to properly go through the reconessaince phase for your system ( nmap -sV -p - equivalent).

So... Security through obscurity?

Idk... Maybe I am not versed enough in infosec but this also begs the question are you not attracting more interest if your system lights up green for an exposed Redis instance for an adversary to notice you and take a closer look for anything else vulnerable.

View on HN

>So... Security through obscurity?

This is not a valid criticism on its own.

Security through obscurity is bad when obscurity is the only thing stopping an attacker. It's a meme because obscurity is not a substitute for stronger security mechanisms. That does not mean it cannot be an appropriate compliment to them, however.

If I wanted to hide a gold bar, sticking it in an open hole behind a painting on the wall wouldn't be particularly great security. As soon as a robber found the hole, the entirety of my security is compromised.

If I put it in a safe on the wall, it's much more secure. The robber has to drill through the lock to get the gold bar.

If I put it in a safe behind a painting on the wall, the robber has to discover that there's a safe there before they're able to attempt drilling through it. Bypassing the painting is trivial compared to bypassing the safe, but the painting reduces the chance of the actual safe being attacked (up until it doesn't!)

Security should be layered. Obscurity will generally be the weakest of those layers, but that doesn't mean that it has no value. As long as you're not using obscurity as a replacement for stronger mechanisms, there's nothing wrong with leveraging it as part of a larger overall security posture.

Accepted cryptography is also security through obscurity. The thing is that the amount of obscurity must be quantified. Cryptanalysis allows one to calculate these quantities of "obscurity." Then, a full study of effectiveness combines that with the costs associated with brute-forcing the bounds arrived at by the cryptanalysis.

Other parts of infosec are the same, but often with less well-quantified measures of effectiveness. E.g. memory hardening techniques like FORTIFY_SOURCE and MTE are effective in raising the difficulty of exploiting memory vulnerabilities, but under some conditions the vulnerabilities may still be exploitable.

Before using labels like "security through obscurity" one has to first answer: how much does the technique raise the cost for attackers? This is what articles about security systems (including this one) should focus on. In the end, hacking, like most things, comes down to economics.

How much do you think this tool raises the cost for attackers?

Most modern attacks succeed by remaining undetected and this directly counters that. When combined with “every IP address responds to ARP and ICMP” (as discussed recently), you can make it impossible for an attacker to scan your network without firing off a honeypot alarm that introduces increasing packet loss on the attacker’s host as scans continue, providing enough time for an oncall human to finish what they’re doing and get to a keyboard to deal with the intrusion.

The next level of value for this is to TLS-encrypt random traffic between ports and hosts on the network, generated and injected by the switch into each network port, so that sniffing traffic is not an effective discovery mechanism. After that, address and port randomization of servers using a time-linked randomization seed stored in an HSM, so that attackers have no way to pierce the onion skin if they lose control of the HSM-bearing host.

This is all the natural outgrowth of container approaches, but in labor terms is nightmarishly complicated if you aren’t willing to spend for it.

No, instead of dropping all the packets into a black hole, you could put the packets into a hey we just got a scan request pile and if the pile is bigger than some heuristic call the on-call guy it’s completely unnecessary to respond to him to have this functionality

The “cost” includes all resources, including time. Some classes of attackers will be significantly slowed down by this.

People who criticize 'security through obscurity' don't know how hard it is to reverse engineer shit.

Either that or they're researchers or adversaries playing a game. Because trying to figure out WTF is going on is hard, so any clues you can extract from your targets makes things easier.

Agree, a lot of people misunderstand the purpose of security through obscurity.. it's a layer on top of other layers of security designed to waste attacker time. If your attacker is a nation state that's probably not going to stop it, but it might stop a lot of other lesser threats who realize it's not worth the effort.

When you see someone probing every single port on the box, you know they’re either a bad actor, or a security tool. No legit user is going to keep hammering ports without a known service.

Bad actors you can either block or counter attack. Security tools should be registering their address with whatever internal tracker you’re using so they can be white listed.

> When you see someone probing every single port on the box, you know they’re either a bad actor

That is not what the tool is for though... It is a tool specifically made to hinder... IDK... Making any information out of an NMAP scan?

The objective here is to give script kiddies and other spray-and-pray attackers the finger.

How does it do that though?

You light up in a skid's Internet-wide scan for let's say Redis. They try and fail to dump anything from it so they proceed and run a vulnerability scanner on your host (skids gonna skid)... It proceeds to discover IDK... a trivial SQLi you coded like a dumbass...

They try to run some other attack on you. For something you dont have.

If more servers use the tool, they waste attacker's time. A bit like herd immunity

It’s literally an arms race. You make it more expensive for attackers to progress. Yes, security through obscurity is bad on its own, but it’s not necessarily useless as an additional measure.

For a similar concept, look at the delay you get after entering a password wrong to a login prompt: That technically does not add any barrier whatsoever, but it does make it much harder for an attacker to brute force the password.

Security through obscurity is somewhat helpful even though it can be defeated. Take camouflage and honeypots for example. It would probably be unwise to use this without a thorough audit of the code however.

Look up post-exploit mitigations, such as ASLR and pointer authentication. These are mechanisms that only become relevant when software has already been breached. In most cases, they cannot entirely prevent further progress by the attacker, just make it significantly harder.

Similar principle (only on the other end).

Reply on news.ycombinator.com