What’s security by obscurity
I end up taking about the security by obscurity with other engineers and it’s
sometimes not easy to classify what solution is or isn’t of that kind.
Recently the conversation online was restarted with a post.
I’d like to propose a different way to look at this issue. Replacing the
whole concept with costs, benefits and context.
The Costs
There’s cost to every solution. Cost in a TCO-like sense, not the cost of
implementing the change in isolation. While we can talk about the details of
moving the SSH port to a different one or creating a fancy solution like port
knocking for days and how easy they are, there’s cost of doing all that is
almost never mentioned.
When you’re the only user of a pet server, setting up port knocking may look
trivial and useful to you. But at scale the problem looks very different.
Imagine even a medium sized company which tries to add port knocking and what
it would mean: onboarding documentation with this access detailed, making
sure there are solutions for 3 different OSes which support it with sample
configs, making sure other applications (like SSH-tunneled database GUI) work,
logging which allows debugging login issues, configuration of networking
which allows extra inbound ports access (for knocking), and many other
elements. Over time maintaining that can easily mean a total of weeks of
accumulated work just to hide a single service.
This analysis of course works for other examples too. Another common idea is
rejecting the IPs which repeatedly failed to login before. In that case we’ve
got an extra possibility of locking out valid users by accident for example.
The Benefits
Different solutions can have multiple different benefits. For example for the
infamous SSH port scenario we can have benefits of:
- reducing log spam
- stopping password guessing
- stopping wormable exploits
The commonly discussed SSH port changing covers only the first point and reduces the likelihood of the second one.
Ideally we want to cover all of those, but that may be unrealistic for some scenarios.
Context
So finally, we’ve got some solutions present on their own, but which ones can
be used together and still make sense? Which ones can be superseded on a
different, more generic level. Which ones can be applied to cover and
authenticate other services. And if you have only a limited time, which one
would you choose?
The SSH hiding issue
In reality there are bigger issues to solve, so this is not the best example,
but will do for some speculation.
Let’s look at the possible solutions:
Changing the port:
- cost: extra documentation / support
- benefit: less log spam
- benefit: fewer brute force attempts
Disabling password auth:
- cost: only if you’re not using keys everywhere already
- benefit: brute force eliminated
Moving to 3rd party or infrastructure auth like AWS SSM:
- cost: lower compatibility
- cost: support/implementation
- cost: effectively handing over the access to a 3rd party
- benefit: log spam eliminated
- benefit: brute force eliminated
- benefit: exploit risk eliminated (no inbound connections)
Port knocking:
- cost: low compatibility
- cost: support/implementation effort
- benefit: log spam eliminated
- benefit: brute force eliminated
- benefit: exploit risk massively reduced
Moving SSH to IPv6 only:
- cost: variable compatibility (some networks can’t do it)
- benefit: log spam eliminated
- benefit: brute force eliminated
- benefit: exploit risk massively reduced
VPN solutions - point-to-point:
- cost: deployment time, support for discovery
- cost: enterprise VPN solutions are not user friendly
- cost: exposes new surface for exploitation
- benefit: log spam moved to VPN logs
- benefit: brute force eliminated
VPN solutions - mesh without inbound:
- cost: support/implementation effort
- benefit: log spam eliminated
- benefit: brute force eliminated
- benefit: exploit risk moved to VPN and massively reduced there
Some of these techniques will be easier to implement then others. For
example, maybe you already use VPN for other purposes and only need to remove
SSH from a public address. Some may depend on the available tech - can you
guarantee access from IPv6?
For my own networks, I typically disable password authentication (since it’s not used
anyway), and move the service behind ZeroTier which can work by initiating
the outgoing connections. (operating behind a NAT) Where possible, I
use IPv6 to remove the service from the IPv4 scanning range.
Were any of the possible solutions above “security by obscurity”? Unless
you’re writing a definition for a dictionary, who cares? If they provide the
features you’re looking for, implement them and keep in mind what they don’t
provide. Think about what are the alternative/upgrade paths in the future.
Security is not binary and sometimes maybe you’re after something that
obscurity does provide. What classifies as obscurity can be left to a
discussion over a pint, right after tabs-vs-spaces and oop-vs-functional.