Instead of using UDP he reads the firewall log. Also he prevents replay attacks (even though his implementation is apparently not secure in this regard). Unfortunately his code is ancient and in Python 2, so a rust implementation would be awesome.
> The request is encrypted using AES in CTR mode, with an HMAC-SHA1 using the authenticate-then-encrypt paradigm.
A mere three months later, he would publish The Cryptographic Doom Principle [2] (dated 2011-12-13).
[1]: https://github.com/moxie0/knockknock/commit/e24eb33f666fc092...
[2]: https://moxie.org/2011/12/13/the-cryptographic-doom-principl...
I used to use port knocking, but at some point found myself in a hotel where they blocked ALL ports, except TCP 80 and 443 (did not check UDP at the time).
My ssh port is on 80, so I can use all of my tools, even if the network I'm in blocks everything else.
Ultimately reading firewall logs to do port knocking is most secure way, because - as you said - there is virtually no attack surface.
I would argue that port knocking is extremely inconvenient and does not work in every scenario. So for me it's a tradeoff between "ultimate" security and convenience.
Instead of knocking on ports, send actual HTTP requests to different paths. Over TLS or just plain HTTP.
So where you’d port knock a sequence of ports here instead you send GET requests to some different, publicly known paths
GET /index.htm
GET /about_us.htm
GET /about_us.htm
GET /index.htm
GET /about_us.htm
GET /products.htm
You get the idea.
And now then the challenge is that if you’re on a network that does HTTP caching, it would interfere with this.
But we already have the well known cache-busting technique for that right, so
GET /css/main.css?ver=64729929
GET /js/bundle.js?ver=947367292
GET /js/bundle.js?ver=7483939
And so on. And version is for example current Unix time and is actually ignored in terms of “knocking”. Only the path matters.
Hah! I'd never seen this before, but in a fit of pique driven by ssh scanning one day I did a similar pattern on my OpenBSD router: I added a block in log to a high port in pf.conf, wired up a little shell script that did tcpdump on pflog0 and watched for a packet to come in, then added the IP to the allow port 22 table.
I knocked on the door three times, two of which were testing, and ended up throwing it all out in favor of wireguard & making SSH no longer listen on em0, which seems infinitely less silly.
I agree that ultimately, with wg in the kernel, this is a much simpler setup.
IOW, why ever down the connection? Why not start your tunnel immediately when the network comes up and leave it running until the network goes down?
Wireguard interfaces are _cheap and easy_ - there's no reason not to set up an interface for normal client traffic that sshd doesn't listen on, and an interface for just sshd with different ACLs and routing logic if you want.
This is why you sometimes have to enable PersistentKeepalive on peers that are behind NAT and are calling in to the server. Without them keeping up the connection NAT would simply close it down and you wouldn't be able to connect.
Why's that?
E: oh, if you aren't familiar with OpenBSD I might get the confusion – pflogd/the kernel (not me!) watches the actual network device and dumps to a file. So the actual "knocking" daemon I bodged together is one part running as a privsep user watching a log file and giving IPs to the other part which just adds to the pf table allowing access.
My threat model didn't include people who can fuck with pflog(4) to attack tcpdump(8) - I'm sure they're out there, and if they wanted to be they'd already be in my network (or already are).
ruroco DOES prevent replay attacks, by saving the deadline (which is in ns) in a blocklist. It does not matter if the deadline has "passed", the deadline is added to the blocklist as soon as the packet reaches the server and is deemed "valid". So each packet is only valid exacly ONCE
http://www.thoughtcrime.org/software/knockknock/ has been excluded from the Wayback Machine, and archive.is is captchawalled.