It doesn't add enough to compensate for its costs, which are commensurate with those of VPNs, which provide drastically more return on the investment. But VPNs don't have a cheering section, because they're so obviously useful that nobody has any incentive to make that banal observation. "Port knocking" is idiosyncratic and widely looked down on by security engineering teams, so there's a contrarian impulse that makes them seem worth discussing.
I'm struggling to walk away with a crystallized view of why port-knocking is bad, though.
I do agree, nobody should be going to sleep at night, relying solely on obscurity as their source of protection. But these commenters are offering it as an additional layer of indirection. They're not touting it as _the_ solution, full stop.
At the most basic level, would you refute the claim that port knocking or alternate ports are adding additional friction for an attacker, or no?
Myself, I would prefer to run a simple, (hopefully) set-and-forget daemon on my server if it really did add an extra layer of obscurity to my secured SSH service.
I guess I just fail to see why it's one against the other.
Foremost, there is an opportunity cost to setting it up. The time you spend setting up port knocking could be spent setting up another form of security. I believe it is a sound argument to say that a VPN provides more security at a similar level effort. No public SSH means an attack cannot know SSH is running on the server from a port scan because it simply isn't listening. It allows you to reduce the attack surface - you can add more and more servers that you need to SSH into, but you are only allowing public access via your VPN - so you have fewer potential ingress points, and can ratchet up your security and auditing commensurately. And if your VPN concentrator is owned, you should have been setting things up so that they did not implicitly trust someone just because they were on the VPN, so you still have all of your usual measures of security in place.
In that case, there's just not much point. You could also enable port knocking, but I don't think it provides much benefit.
That brings us to the next part. Port knocking is a "weird" thing. It's idiosyncratic and not standardly used. Documenting it and understanding it is additional overhead, and it's something you have to manage and worry about on every server that's using it. Additionally, both standard and SPA implementations are vulnerable to man in the middle attacks, though most SPA based implementations will require an active MITM in that blocks the initial packet rather than just replaying a knock sequence. So extra complexity, less secure, and an oddity on the network that you have to have documented and explain to new team members, etc.
If you're a single person managing a single server, well, honestly you're probably fine just turning off password auth. And you can feel free to do port knocking and whatever else. It probably doesn't matter.
It sounds like port knocking and VPNs, while starkly different in approach, have some overlap in their approach to threat mitigation.
Wireguard et al are much better equipped to handle the needs of an organization, while port knocking's value trends to smaller teams, or even individuals.
I wouldn't want to manage knock rotations for 600 employees, for example.
You're asking for my opinion, and that's all I can relate, but here's my ranked ordering of things likely to have RCE vulnerabilities, from least to most secure:
* A Java, Python, or Ruby app server
* OpenVPN
* Stock nginx
----- starts to get really unlikely right here ----
One crude first-order comparison is to look at the relative size of the code. More code is more likely to have more vulnerabilities, to a first-order BOEC metric.
