Obscurity Is a Valid Security Layer | Hacker News Reader

Obscurity Is a Valid Security Layer

danielmiessler.com

22 pointsdanielrm2616 comments

This is an interesting read, but it's worth digging down into the particulars. In particular:

> Is adding obscurity the best use of my resources given the controls I have in place, or would I be better off adding a different (non-obscurity-based) control?

Is a really important question to ask. In this case, I'd argue that port-knocking, SPA, and changing the port are not cost-effective.

Obscurity is not free. There are additional costs and risks to consider:

  * Has the port-knocking or SPA software been well tested or audited?
  * What if my pentester mistakenly believes that there is no OpenSSH service, and so doesn't check it?
  * Is it worth re-configuring all of my SSH clients? What if I have to go through change control?
  * Is it worth re-configuring any vuln. scanners I deploy?
  * Do my clients support port-knocking or SPA?

I could spend an hour setting up port-knocking, SPA, or rolling out a port change. Could I do something more useful with my time? Perhaps better testing my application? Finishing that pressing code review? Buying and using a vulnerability scanner? Reaching out to a pentest company? Setting up an IDS?

All of the above will probably have a better cost-benefit ratio than port-knocking, SPA, or changing the default port.

It is almost always more cost-effective to just use Mozilla's OpenSSH guide[1], keep up with security patches, and direct your attention to the weaker components of your stack.

References:

[1] : https://wiki.mozilla.org/Security/Guidelines/OpenSSH Security/Guidelines/OpenSSH, Mozilla

>I'd argue that port-knocking, SPA, and changing the port are not cost-effective.

Changing ports is very effective, at least at reducing noise. This is especially true when setting up a new service with no preexisting clients. Default port 22 is an ocean of noise and constant password attempts, no reason to fill up my log servers with millions and millions of attempts per year.

fail2ban and similar tools are standard, widely used, quick to configure, and very effective at removing noise. You won't need to hassle to configuration of any new or existing clients, vulnerability scanners, etc.

It's OK to hide from the bear. Maybe he won't see you. But if he finds you, you'll need at least bear spray and maybe a shot gun to defend yourself. That's the basic idea. Obscurity is only bad when it's the only thing you depend on for your safety and security.

Obscurity is mostly useless. But minimizing the attack surface[1] is certainly useful. Changing the SSH port, port knocking, IP restricting which hosts can connect, etc., are all methods of reducing the attack surface. If you have a service (like SSH) that doesn't need to be available to every possible internet host then don't expose it to every possible internet host.

Can you SSH into an AWS load balancer? No, but someone is, or is otherwise managing these servers.

[1] https://www.owasp.org/index.php/Minimize_attack_surface_area

Ok, so this is going to sound crazy, but it's deeper than that.

When you put yourself on another port or make yourself invisible on a battlefield you didn't actually reduce your attack surface. You are equally vulnerable to a bullet or an 0day. If it comes towards you, it will hit you.

What was reduced was their ability to TARGET you. That's not reducing attack surface.

I'm thinking about doing a write-up on risk reduction methods that break all these down, where:

- Obscurity is hiding a secret that reduces your resilience if you are discovered - Avoidance is limiting the likelihood that you'll be targeted - Hardening makes you more survivable if you are hit

How does that grab you? You think that's the distinction we need?

Ultimately it's all security because it's reducing risk, i.e. probability and/or impact. But the ways in which that is done are important to understand.

Obscurity, Avoidance, Hardening seem to be useful ways to explore the idea of attack surface and related security concepts.

Reducing surface area refers to ways to increase the overall security of a system by restricting the set of features accessible to user groups. Every feature is an attack vector. So limiting access reduces the total number of possible attackers. Surface area is related strongly to the concepts of Obscurity and Avoidance.

The other thing to consider is the total risk and any associated costs/tradeoffs.

In terms of SSH, changing the port number changes the set of attackers from A) attackers scanning standard ports across many hosts, to B) attackers deep port scanning fewer hosts. The relative risk will decrease if group A is significantly larger than group B. If there are 1,000,000 shallow scanners (group A) and only 100,000 deep scanners (group B) the reduction in relative risk is significant.

But what is total risk? Using SSH public-key authentication creates another set of users, group C, that can actually login to the server. Group C is also very small, usually consisting of only 1 member. Whether or not attackers belong to group A or group B isn't particularly significant in total, as the likelihood that a member of A or B is also a member of C is very, very low.

This, I think, is the crux of the "security by obscurity" criticism. Such security measures seem to do little to decrease the total risk to a system. So why implement obscure/avoidance measures?

The value of changing port numbers or port knocking (and reducing attack surface in general) isn't statistical. The value is completeness, or as a type of insurance. Using alternate port numbers could buy an admin some time if a OpenSSH 0-day occurs. This event isn't very likely, so we might dismiss it. But managing the risk of unlikely events is exactly the point of insurance.

> You didn’t replace the service’s security with this layer, you simply added it to what already existed. Remember, the NSA most likely has great algorithms, but they still don’t publish them.

I feel like this is a great example of why this "obscurity as a security layer" is misleading, to say the least. Having a "great algorithm" that you don't publish is bad for the same reason security by obscurity is bad - there are fewer people criticizing and tempering the algorithms you use. This feeds into the idea that "anyone can make cryptography they can't crack" (NSA or not).

The problem with these "obscurity as a valid security layer" arguments is that there's already obscurity built into these protocols. The algorithm is open, the key (or password) is kept obscure. Adding some non-standard flourishes on top of a secure protocol is basically just using an insecure protocol (security by obscurity) to "extra" secure an already secure protocol. The point being that the overall security of the system is not meaningfully increased by these actions.

That said, I understand why you'd want to use a non-standard SSH port or port knocking or something to reduce noise on your logs.

> ... the key (or password) is kept obscure...

I often think about this, and the conclusion I've come to is secret != obscure. Obscurity describes information you do not know but can research to determine; secret describes information you do not know but and must guess.

But I agree that the argument that the NSA probably uses obscurity (I speculate to make messages harder to attribution to them and not to protect the secrecy of the content) isn't very moving.

Think of security as reducing risk.

If you're invisible your risk is lower because you have a lower chance of being targeted.

This is wholly separate from what happens if you're hit. That's resilience, or armor, or whatever we want to call that.

But both reducing the probability of being a target and being more resilient once you are a target qualify as security.

This is not invisiblity. It's putting your safe door behind a curtain. Yes, fewer people are seeing the safe, but the curtain is not actually increasing your security, it's just preventing casual attackers from seeing you as a target of opportunity (who, for the most part, are also not going to get past real security, anyway).

I don't know that it's dangerous, but it's not really additional meaningful security, in my opinion, so long as it has zero downsides. The example of the NSA keeping their algorithm hidden does have downsides. One of the biggest downsides of doing some non-standard thing is that you might not realize that you are actually weakening your security. If you have some protocol that involves not revealing the existence of a server to casual attackers, that's completely fine with me, but it's worth noting how easily these things can get conflated together.

It's the same as cloaking a tank in a tank battle.

If you didn't take the armor off it's great. But if you did then you've put your eggs in the don't get hit basket.

The trick is figuring out if you could have bought more armor with the money you spent on the cloaking device.

Or, if enemy weapons are so good that armor doesn't matter, then it's time to think about cloaking very seriously.

It's a balance between probability and impact. With cloaking you're reducing likelihood. With armor you're reducing impact.

But in both cases you're reducing risk.

Sure, if you want to argue this point, you're right--if you're already secure, then security through obscurity won't technically make you less secure.

However, taking literally any actual security measure is a better usage of your time. So sure, when you've audited your entire server carefully and are absolutely sure, then it will be useful to add a security through obscurity layer. That is to say, it will never be.

So running your SSH daemon on a port other than 22 will never be better than doing something above patching, a solid config, and key or cert-based auth?

I disagree.

If you're listening you are potentially vulnerable to an 0day that is simply far less likely to hit you on 2222 than 22---especially before you hear about others getting pwned and have time to patch.

If you harden to a certain point (like the list above), the next best thing MAY be to get out of the line of fire, either by moving your listener or putting up a portknocker system or something.

The fact that Heartbleed remained undetected for two years certainly revealed one uncomfortable truth about the "security by openness" paradigm: the one agent who actually bothers to audit the source code may be the bad guy.

SSH on something like port 666 or 25519 also has the advantage that there's much less log chatter about failed attempts.

Plus, nmap thinks that SSH on 666 is "DOOM"

Reply on news.ycombinator.com