Port knocking was somewhat silly when it was introduced ~20 years ago --- at most, on a reasonably designed network, it was saving you from your own misconfigurations, but at least in 2005 it was reasonable to imagine a highly diverse network of machines that people logged into using multiple protocols, where those misconfigurations were likely.
In 2020, it's gone past "silly" and is now a design smell, in the same way that actually relying on fail2ban would be. Whatever port knocking is doing to help you is a a description of something you're doing wrong with your architecture.
We're not even comfortable with long-lived keys anymore; modern networks are built with short-lived certificates issued off 2FA from an IdP. We have good VPNs right now for the other weird cases. Our networks default to all-ports all-hosts closed. Arguably, port knocking is literally setting your security back, by making it harder for automated tooling to scream bloody murder if you've managed to expose a dev instance unexpectedly to the Internet.
Don't bother. If you've got a single system you're managing outside of a cloud provider with its own decent network firewall, just set up WireGuard and filter everything but that. If it helps, think of WireGuard as the evolution of SPA port knocking.
> modern networks are built with short-lived certificates issued off 2FA from an IdP
Modern networks are sadly far too rare; 95%+ of the industry is built on legacy networks.
My take on fail2ban and port knocking are:
* they reduce the amounts of logs produced
* they defend against fully automated at-scale scans / password stuffing attacks that a well-maintained application wouldn't need defending against, but we all know that in any sufficiently big organization, not all applications and accounts will be well maintained.
I use port knocking and I don’t take it seriously. Anyone using it in a serious setup is batshit. However, for fun home projects where users install that giant php based file sharing program, or that IoT camera, why not? They don’t have automated intrusion prevention, etc. They can’t understand the code to determine it’s quality, etc.
When the next 0day hits… will it be enough to protect them, yes. After all, they’re not a target and the automated attacks won’t affect them.
I don't understand how knocking in if itself is bad. It's just a technique to add a layer of protection.
In my case, all internal services in a kubernetes cluster have no path that allow it to be accessed from the outside. Occasionally, developers might want to do so, say to access a database or prometheus server.
The way to properly do this, imo, is to use a hardened service that functions as a networking proxy. Use proper encryption keys for access, and it should be quite hard to bust open.
Where does port knocking come in? That service should need to be exposed at all times. So, use port knocking to configure the infrastructure to temporarily allow access from your IP, to that proxy servers IP, on that particular port.
I'm more inclined to not take it serious, if such a simple mechanism isn't in place to protect infrastructure.
If you're exposing a developer instance to the network and it has port knocking deployed, why does it matter? The discoverability of such a service is basically zero.
What are the chances of the cracker finding the exact combination of ports to knock on, and then the exact key to use? If they're able to do that then they are a dedicated attacker and they're mitm'ing a presumably encrypted connection on your network, so you probably have more problems than just one bad machine, they already replicated or replaced a certificate on your machine, or worse.
And if you then expose a service that isn't via the port knocking algorithm, surely that would show up?
> We're not even comfortable with long-lived keys anymore
Can you not just change the key N number of logins and factor in 2FA as well?
I'm not sure how port knocking cannot, at least theoretically, be used in conjunction with the other measures you talked about.
The premise of your comment is that you're deploying dev instances on routable IP addresses on networks without default-closed filtering, in a configuration where it's theoretically possible that people could directly get a remote shell into that machine.
Don't do that.
In AWS (for example), have a dev VPC, and a WireGuard forwarder on it (or, if you're doing things 2010-style, an SSH bastion). If the machine needs to expose 443 directly to the Internet, give it an EIP; have the VPC prevent traffic to anything but 443 (and WireGuard).
What, in that architecture, would port knocking even be accomplishing? Keeping the wrong developer off your machine?
As for how attackers would break port knocking: if you believe attackers can't passively watch traffic, either directly or through redirection, I have good news for you about how much money you need to spend on encrypting traffic!
Re: sniffing, if I were implementing port knocking I would use the "single packet authorization" variant like in knockknock, which makes sniffing much less useful to an attacker.
I just prepend a secret letter to every possible ssh account on my server ('root' becomes 'jroot') and so that way "ssh root@myserver.com" can never work even if you know my root password. And this way my defense is opaque to attackers passively monitoring my network traffic (the username is encrypted in the ssh protocol).
Oh shit, I just gave away my secret on a public forum...
Ha ha, fooled you! I use a different secret letter in actual practice!
(Or do I?)
p.s. Pretty sure port-knocking offers less protection than this scheme.
You're telling people not to do a simple thing, instead telling them to do a far more complex thing.
You do not give a single argument on why the complex thing is meaningfully safer in practice.
If security is equal for all practical purposes in either case, this would be the wrong thing to do, because it is easier to fuck up complex things and it's more expensive to manage them.
Not just this, but they're assuming that everyone's server setups are enterprise-grade! People regularly still put raspberry pis and other kinds of low-cost computers on the public internet (William Gibson, for example, hosts hackers.town on a server setup in his (probably metaphorical) basement), and their answer to that is: "Don't do that".
In 2020, it's gone past "silly" and is now a design smell, in the same way that actually relying on fail2ban would be. Whatever port knocking is doing to help you is a a description of something you're doing wrong with your architecture.
We're not even comfortable with long-lived keys anymore; modern networks are built with short-lived certificates issued off 2FA from an IdP. We have good VPNs right now for the other weird cases. Our networks default to all-ports all-hosts closed. Arguably, port knocking is literally setting your security back, by making it harder for automated tooling to scream bloody murder if you've managed to expose a dev instance unexpectedly to the Internet.
Don't bother. If you've got a single system you're managing outside of a cloud provider with its own decent network firewall, just set up WireGuard and filter everything but that. If it helps, think of WireGuard as the evolution of SPA port knocking.