I don't want to be a hater, but exposing access to your homelab through a "fully vibe coded" application (it's mentioned at the bottom of the README) is probably not a good idea.
It’s getting scary how many security related apps are being vibe coded by people with very little security experience (not a knock heh on op, they could very well be experienced).
I mean it's just using firewalld.
You can't inspect the rules.
For me it's simple enough that it shouldn't be a big security issue, but I understand and that's why I wrote that in the readme.
I implemented something similar as a caddy module, then I realized that if I was connected to a public wifi network I was actually authorizing the whole bunch of people that were connected to it with me. How do you avoid this, or is it just not important?
It's a compromise.It's not as secure as using a VPN, but it's way more convenient, since only one device has to have a knocker client on it without needing any sort of VPN.
The likelihood of someone is on the same network as you noticing your servic, try to hack it, before the TTL expires again is IMO quite low.
This is without taking into account that the services themselves have their own security and login processes, getting a port open doesn't mean the service is hacked.
> This is ideal for homelab environments where you want to expose services to the internet without a persistent VPN connection, while minimizing your public-facing attack surface.
To an untrained eye, the wording here could be construed to imply that this is more secure than a VPN. Might be worth a reword to clarify why one might prefer it want to over a VPN.
Sorry if i wasn't clear.
It isn't more secure, it's just more convenient because it works in every network, without needing to set up a VPN connection on each device.
I created this because I always have a VPN on my devices, and I can't have tailscale running with that, in addition to tailscale killing my battery life on android.
The authentication part does not look much different from password authentication (key ≈ password), and the "Configurable TTL" bit is somewhat confusing, the first part of the sentence assigns the TTL to API keys but the second part says it applies to IPs being whitelisted. I would expect that TTL for a key means that after the TTL expires the key itself becomes unusable.
Port knocking is a very hacky technique that was used:
1- In the 90s were security was whatever
2- In modern days as a way to keep your logs squeaky clean ( although you get 99% there with custom ports)
3- As a cute warm up exercise that you code yourself with what's available in your system. (iptables? a couple of python scripts communicating with each other?)
It's not a security mechanism, and downloading external dependencies or code (especially if vibecoded) is a net loss (by a huge margin).
It's also a waste of time to overengineer for the reasons noted above, I've seen supposedly encrypted port knocking implementations. It feels as if someone had a security checklist and then a checklist for that checklist.
Nowadays public facing client IPs are often shared by thousands of users behind CGNAT. IP based firewall rules are useful when the peers have their own static IP address, but provide no real security when the IP address is shared.
This is vibe coded security through obscurity, i. e. quite useless. Use Tailscale or a self hosted VPN.
Neat project, thanks for sharing. I'll stay away since it was vibecoded, but I appreciate the honesty.
Though this is not technically a "knocker", but a typical token-based auth gateway. I experimented with something similar recently as well, and think it has its use cases.
But I would agree with some of the comments here. If you need to expose many services to the internet, especially if their protocols are not encrypted, then a tunneling/mesh/overlay network would be a better solution. I was a happy tinc user for several years, and WireGuard now fills that purpose well. As much as people use solutions like Tailscale, ZeroTier, etc., I personally don't trust them, and would prefer to roll my own with WG. It's not that difficult anyway.
There's also Teleport, which is more of an identity-aware proxy, and it worked well last time I tried it, but I wouldn't use it for personal use.
I had hoped this would allow me to use various patterns of knocking on my desk to perform system actions. Do the cut-and-a-hair-shave knock to log in, or taptaptaptap-wait-tap to lock the screen, etc. Maybe with two microphones you could even distinguish between left and right handed knocks.
I use fwknop in a similar manner, the main advantage it has is it's using an encrypted UDP packet. It's ability to call shell scripts for more advanced uses is its best feature. I have a packet set up for a rolling restart of all my services as well as ssh access
I use this thing called sshd that listens on only a single port and its main advantage is that it uses actual cryptography to authenticate using a client keypair.
I will never, ever understand this "single-packet authentication" "port knocking" fetish. It has never made sense. Bin it, along with fail2ban, and just set up WireGuard.
Your network authentication should not be a fun game or series of Rube Goldberg contraptions.
Knocking can cut down on grinding. I have in the past created setups where you had to knock prior to establishing a VPN connection, and given the semi-regular problems with VPN implementations I really don't feel bad about that. Fortigate, Sonicwall, Cisco, Ivanti, etc - sure a big part of it is "don't run VPNs based on big legacy codebases" but who's to say there won't be implementation problems found (or introduced given "Jia Tan" style attacks) in Wireguard?
Is knocking incredibly weak security through obscurity? Sure, but part of what it does is cut down on log volume.
I use tailscale for this.
But I can't have two vps running at the same time on android, nor do I want to install tailscale on every device I own.
I created knocker exactly for this reason.
Sorry, but I felt a bit of nostalgia here; I wrote some port knocking code a couple decades ago, this is straight-up "neat" and I'm surprised it is still around.
The way I see it, port knocking may not be a valid security measure but it can be a good filter. It will allow you to filter out port scanning and other mass cracking attempts.
My opinion is that being able to filter out noise and false positives from authentication logs allows you to improve your actual security measures.
An other advantage is that it may hide information about your system making it harder for an attacker to target you based on a broad scan without doing some (usually detectable) targeted reconnaissance first. For example imagine someone found a 0-day in one of the services behind the port-knock and is scanning for the vulnerable version.
It does however add another cog in the machine that may break.
The "port knocking" has surfaced often since the early 2000s, but it continues to be a rather silly exercise in making security-by-obscurity look more complicated while not really helping all that much.
Briefly looking at the diagram at the top of the repo, it looks like you "knock" with an API key. Why not just run a reverse proxy in front of (whatever service you're trying to protect) and use the API keys there? To harden further, do some sort of real authentication (PKI, client certs). If you want your logs to look cleaner, install and actually configure fail2ban.
If you need to manage risk for a legacy service that has a requirement to be internet exposed, I suggest checking out https://knocknoc.io/ for a self-hosted and/or cloud based solution that was not built with vibe coding, but actual customer security use cases.
They provide 2FA and/or single sign-on to allow just in time access to internet
exposed applications which remain hidden from unauthenticated/approved users.
Hey I'm the creator of knocker!
I actually wanted to write a blog post about it before posting, but OP already did that.
If you have any questions just let me know!
Will go into more details why I created in the blog post coming very soon! Just doing the final touches right now.
38 comments
[ 2.6 ms ] story [ 55.8 ms ] threadThe idea itself sounds fun though
The likelihood of someone is on the same network as you noticing your servic, try to hack it, before the TTL expires again is IMO quite low.
This is without taking into account that the services themselves have their own security and login processes, getting a port open doesn't mean the service is hacked.
To an untrained eye, the wording here could be construed to imply that this is more secure than a VPN. Might be worth a reword to clarify why one might prefer it want to over a VPN.
I created this because I always have a VPN on my devices, and I can't have tailscale running with that, in addition to tailscale killing my battery life on android.
1- In the 90s were security was whatever
2- In modern days as a way to keep your logs squeaky clean ( although you get 99% there with custom ports)
3- As a cute warm up exercise that you code yourself with what's available in your system. (iptables? a couple of python scripts communicating with each other?)
It's not a security mechanism, and downloading external dependencies or code (especially if vibecoded) is a net loss (by a huge margin).
It's also a waste of time to overengineer for the reasons noted above, I've seen supposedly encrypted port knocking implementations. It feels as if someone had a security checklist and then a checklist for that checklist.
This is vibe coded security through obscurity, i. e. quite useless. Use Tailscale or a self hosted VPN.
Though this is not technically a "knocker", but a typical token-based auth gateway. I experimented with something similar recently as well, and think it has its use cases.
But I would agree with some of the comments here. If you need to expose many services to the internet, especially if their protocols are not encrypted, then a tunneling/mesh/overlay network would be a better solution. I was a happy tinc user for several years, and WireGuard now fills that purpose well. As much as people use solutions like Tailscale, ZeroTier, etc., I personally don't trust them, and would prefer to roll my own with WG. It's not that difficult anyway.
There's also Teleport, which is more of an identity-aware proxy, and it worked well last time I tried it, but I wouldn't use it for personal use.
This is what it feels like people using AI for everything.
AI is not good at telling you best solution but it will tell you that you can build it yourself since that approach is what AI is good at.
Using self hosted vpn, cloudflare zero trust or Tailscale is the easiest way to go.
I self host extensively and have multiple self hosted VPN(OpenVPN and WireGuard) along with Tailscale and cloudflare protecting my infra.
And it will not work on mobile if you already use another VPN.
...now I'll have to make this myself.
Your network authentication should not be a fun game or series of Rube Goldberg contraptions.
Is knocking incredibly weak security through obscurity? Sure, but part of what it does is cut down on log volume.
Just skip the plaintext password (the sequence of ports transmitted) and use certificate based auth, as you note below.
My opinion is that being able to filter out noise and false positives from authentication logs allows you to improve your actual security measures.
An other advantage is that it may hide information about your system making it harder for an attacker to target you based on a broad scan without doing some (usually detectable) targeted reconnaissance first. For example imagine someone found a 0-day in one of the services behind the port-knock and is scanning for the vulnerable version.
It does however add another cog in the machine that may break.
With xz backdoor owning ssh, I wouldn’t completely trust ssh public key authentication either.
Briefly looking at the diagram at the top of the repo, it looks like you "knock" with an API key. Why not just run a reverse proxy in front of (whatever service you're trying to protect) and use the API keys there? To harden further, do some sort of real authentication (PKI, client certs). If you want your logs to look cleaner, install and actually configure fail2ban.
Will go into more details why I created in the blog post coming very soon! Just doing the final touches right now.