
Obscurity Is a Valid Security Layer - danielrm26
https://danielmiessler.com/study/security-by-obscurity/#gs.P5WL7sw
======
Tinned_Tuna
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](https://wiki.mozilla.org/Security/Guidelines/OpenSSH)
Security/Guidelines/OpenSSH, Mozilla

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

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

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

------
leepowers
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](https://www.owasp.org/index.php/Minimize_attack_surface_area)

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

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

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

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

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

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

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

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

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

------
dom0
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"

