> Stuff like this is why I like port knocking, and limiting access to specific client IPs/networks when possible.
Indeed: I whitelist hosts/IP blocks allowed to SSH in. I don't use port-knocking but I never ever criticized those using port knocking.
I do really wonder if people are still going to say that port knocking is pointless and security theatre: we now have a clear example where people who were using port-knocking were protected while those who didn't were potentially wide open to the biggest backdoor discovered to date (even if it's wasn't yet in all the major distros).
> ... does the entire internet really need to be able to SSH to your box?
Nope and I never ever understood the argument saying: "Port-knocking is security theatre, it doesn't bring any added security".
To me port-knocking didn't lower the security of a system.
It seems that we now have a clear proof that it's actually helping versus certain type of attacks (including source-code supply chain attacks).
>It seems that we now have a clear proof that it's actually helping versus certain type of attacks (including source-code supply chain attacks).
So would have a vpn or using a bastion host with a custom non standard ssh implementation...
At some point you have to make the choice to not implement a security measure and I would argue that should stop at vpn+standard software for secure access.
If you are a bigger company, probably add SSO and network segmentation with bastion hosts and good logging.
Port Knocking doesn't add any security benefit in the sense that there are known non avoidable security risk aka your transmit your password(knocking) in clear text over the network.
You also add another program with potential vulnerabilities, and as port knocking is not as popular as e.g. sshd, wireguard, maybe it gets less scrutiny and it leads to a supply chain attack?
Security measures are also not free in the sense that somebody has to distribute them and keep the configuration up to date, even if that person is you, that means syncing that connect-to-server-script and keeping it in a secure location on your devices.
> Port Knocking doesn't add any security benefit in the sense that there are known non avoidable security risk aka your transmit your password(knocking) in clear text over the network.
This take is bordering on not even wrong territory. The point of port knocking isn't to increase entropy of your password or authentication keys per se, it is to control who can send packets to your SSH daemon, either to limit the noise in your logs or to mitigate an RCE in the SSH daemon. The vast majority of potential attackers in the real world are off-path and aren't going to be in a position to observe someone's port-knocking sequence.
Is VPN a better solution? Maybe, but VPNs, especially commercial VPNs have their own set of challenges with regard to auditability and attack surface.
>This take is bordering on not even wrong territory. The point of port knocking isn't to increase entropy of your password or authentication keys per se, it is to control who can send packets to your SSH daemon, either to limit the noise in your logs or to mitigate an RCE in the SSH daemon. The vast majority of potential attackers in the real world are off-path and aren't going to be in a position to observe someone's port-knocking sequence.
If you read my full sentence in the context it stands, I argue that authorizing access to your openssh instance is done by sending an authentication code in cleartext.
It does not matter if that authentication code is in the form of bits, tcp pakets, colors or horoscopes as long as your transmit that in clear text it is in fact no a secure mechanism.
Yeah but now you basically have to always run an vpn that only exists between your server and your client, because otherwise your clear text authentication code is visible and at that point just use wireguard and make a 1-1 tunnel only for ssh with no known attacks, even if the attacker is in the same network.
Yes a vpn that has no known reliably attack vector is definitely better than a protocol with a known working attack vector
> If you read my full sentence in the context it stands, I argue that authorizing access to your openssh instance is done by sending an authentication code in cleartext.
I did read your full post. Your claim that port knocking adds no security benefit is just simply incorrect. Even if you take for granted the scenario of an attacker who can recover the port knock sequence, there is still the benefit of shielding the SSH daemon from other attackers who cannot do so. Which is…a “security benefit.”
Describing the port knocking sequence as an extension of someone’s authentication key is where this goes off into not even wrong territory. A dynamically controlled firewall rule (port knocking) is not fungible with bits from an authentication token for the reasons I’ve already outlined - the benefit is limiting network access to the daemon at all.
> Yes a vpn that has no known reliably attack vector is definitely better than a protocol with a known working attack vector
You talk about recovering someone’s port knocking sequence as if that is trivial to do or in any way reliable. It is, in fact, neither of those things. An attacker would have to either:
1) sniff network traffic in front of the server
2) sniff network traffic in front of the client
3) compromise the server
4) compromise the client
5) brute force the port knocking sequence without getting locked out.
Most attackers are going to be in a position to try brute forcing — that’s it.
Meanwhile, you may not have noticed, but commercial VPNs have suffered a steady stream of high-impact CVEs for the last few years.
Wireguard is certainly better in this regard than any commercial VPN I know of, but it does have challenges with regard to key distribution/device enrollment, and thus from a practical standpoint limits access to pre-enrolled endpoints, which is a limitation someone using port knocking does not have.
You also add another program with potential vulnerabilities, and as port knocking is not as popular as e.g. sshd, wireguard, maybe it gets less scrutiny and it leads to a supply chain attack?
That other program is just a stateful firewall, aka the Linux Kernel itself. If you can't trust your kernel then nothing you do matters.
That other programm is knockd, which needs to listen to all traffic and look for the specified packets.
Granted, that program is really small and could be easily audited, but that same time could have been spent on trying apparmor/seclinux + a good vpn and 2fa
I much prefer the approach I read about in https://github.com/moxie0/knockknock (use a safe language, trust basically only the program you write and the language), to a random port daemon written in C which pulls libpcap to sniff everything.
To some extent knockknock also trusts the Python interpreter which is not ideal (but maybe OK)
In Linux, simple knocking (fixed sequences of ports) can be done entirely in the kernel with nftables rules. Probably could even have different knock ports based on day of the week or hour or source IP.
The advantage of port knocking to me is just reducing the amount of garbage script-kiddie scans. IMHO the design of `sshd` needs to just assume it will be slammed by garbage attempts and minimize the logging. I've heard of `fail2ban`, but banning does nothing as the bots have an unlimited number of IPs.
Indeed: I whitelist hosts/IP blocks allowed to SSH in. I don't use port-knocking but I never ever criticized those using port knocking.
I do really wonder if people are still going to say that port knocking is pointless and security theatre: we now have a clear example where people who were using port-knocking were protected while those who didn't were potentially wide open to the biggest backdoor discovered to date (even if it's wasn't yet in all the major distros).
> ... does the entire internet really need to be able to SSH to your box?
Nope and I never ever understood the argument saying: "Port-knocking is security theatre, it doesn't bring any added security".
To me port-knocking didn't lower the security of a system.
It seems that we now have a clear proof that it's actually helping versus certain type of attacks (including source-code supply chain attacks).