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.