Knocker, a knock based access control system for your homelab

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.

I mostly agree.. there’s a couple of very specific scenarios where maybe something like knockd makes sense I think but they are all scenarios where you’re doing things covertly, not as a general authentication mechanism.

As a side note I just happen to be reading a book at the moment that contains a fairly detailed walkthrough of the procedure required to access the Russian SVRs headquarters in New York in 1995.

Think of this as an analogue version and in no way a perfect analogy but it does include a step that has more or less the same security properties as this… anyways here’s a relevant quote:

“After an SVR officer passed through various checkpoints in the mission’s lower floors, he would take an elevator or stairs to an eighth-floor lobby that had two steel doors. Neither had any identifying signs.

One was used by the SVR, the other by the GRU. The SVR’s door had a brass plate and knob, but there was no keyhole. To open the door, the head of the screw in the lower right corner of the brass plate had to be touched with a metal object, such as a wedding ring or a coin.

The metal would connect the screw to the brass plate, completing an electrical circuit that would snap open the door’s bolt lock and sometimes shock the person holding the coin.The door opened into a small cloakroom. No jackets or suit coats were allowed inside the rezidentura because they could be used to conceal documents and hide miniature cameras.

SVR officers left their coats, cell phones, portable computers, and all other electronic devices in lockers. A camera videotaped everyone who entered the cloakroom. It was added after several officers discovered someone had stolen money from wallets left in jackets. Another solid steel door with a numeric lock that required a four-digit code to open led from the cloakroom into the rezidentura.

A male secretary sat near the door and kept track of who entered, exited, and at what times. A hallway to the left led to the main corridor, which was ninety feet long and had offices along either side. ”

Excerpt from Comrade J by Pete Earley

As another funny side note… I once discovered years ago that the North Koreans had a facility like this that they used to run a bunch of financing intelligence operations using drugs in Singapore where I was at the time and thought it would be funny to go and visit. It was in a business complex rather than a dedicated diplomatic facility from memory. But as I recall it was a similar scenario of unmarked door with no keyhole.

WireGuard is designed to be silent preceding a cryptographically authenticated INIT message. It's a superset of whatever security features you'd get from "knocking".

I’m not arguing with you or pretending to not know the difference. I’m saying that is the right answer 999/1000 but there are other scenarios as well.

In fairness, most of the fervor for these kind of knock-based flows predate Wireguard existing. They come from the era where OpenVPN and friends were the common practice in that space, and I would not have considered "add OpenVPN" to be a rational way to improve the security of anything I was doing.

Fail2ban is not in the same realm as port knocking, and to "bin it" would be foolish security posture at best, and negligent at worst.

Every door you close, is one less someone can break.

Every complex services running, is a door someone can potentially break. Even with the most secure and battle tested service, you never know where someone fucked up and introduced an exploit or backdoor. Happened too often to be not a concern. XZ Utils backdoor for example was just last year.

> Your network authentication should not be a fun game or series of Rube Goldberg contraptions.

If there is no harm, who cares...

Enjoyed the read, thanks for passing along. What book is it from?

Comrade J by Pete Earley

Just to be super clear.. using this in place of something like WireGuard is absolutely not an improvement. It’s actively worse in the majority of scenarios assuming you can manage to secure your keys.

I’m not super familiar with the intricacies of fail2ban and don’t currently understand why op made that claim but would very much like to know more because he is talking about a topic he is highly regarded for and I respect that. I just don’t have the context.

Yes, of course, should this just be an optional gadget for a setup, which is already as safe as possible for the situation. After all, when the port has been opened, your setup is also open for attacks. The knockers purpose is to reduce the timeframe of when your system is accessible for attackers.

No, fail2ban is cargo cult security, and if you actually "need" it, you've misconfigured your system. Don't allow password authentication.

Port-knocking mainly mitigates slow distributed-brute-force login attacks, and works best when ports are interleaved with several tripwire black-hole and knock-port-close firewall rules.

Use-cases:

1. helps auto-ban hosts doing port-scans or using online vulnerability scanners

2. helps reduce further ingress for a few minutes as the hostile sees the site is "down". Generally, try to waste as much of a problem users time as possible, as it changes the economics of breaking networked systems.

3. the firewall rule-trigger delay means hostiles have a harder time guessing which action triggered a IP ban. If every login attempt costs 3 days, folks would have to be pretty committed to breaking into a simple website.

4. keeps failed login log noise to a minimum, so spotting actual problems is easier

5. Easier to forensically analyze the remote packet stream when doing a packet dump tap, as only the key user traffic is present

6. buys time to patch vulnerable code when zero day exploits hits other hosts exposed services

7. most administrative ssh password-less key traffic should be tunneled over SSL web services, and thus attackers have a greater challenge figuring out if dynamic service-switching is even active

People that say it isn't a "security policy" are somewhat correct, but are also naive when it comes to the reality of dealing with nuisance web traffic.

Fail2ban is slightly different in that it is for setting up tripwires for failed email logins, and known web-vulnerability scanners etc. Then whispering that IP ban period to the firewall (must override the default config.)

Finally, if the IP address for some application login session changes more than 5 times an hour, one should also whisper a ban to the firewalls. These IP ban rules are often automatically shared between groups to reduce forum spam, VoIP attacks, and problem users. Popular cloud-based VPN/proxies/Tor-exit-nodes run out of unique IPs faster than most assume.

Have a nice day, =3

If a slow brute force attack is working on your system, all the port knocking and tripwires and whatever are just gimmicks.

Don’t waste resources putting lipstick on the pig.

Stolen password-less key bots are also common these days, and again it is more about reducing log noise.

"Don’t waste resources putting lipstick on the pig."

I would never kink-shame someone that ignored the recent CVE-2025-48416, that proved exposing unprotected services is naive =3

If somebody has a stolen credential, they aren’t going to be brute forcing at all. Likewise that CVE wouldn’t be attacked by a brute force attack.

But I see you’ve backpedaled to this being about log noise, not security.

This is a metric ton of completely pointless theater.

Your services should simply be unreachable over anything but wireguard (or another secure VPN option).

I recently wrote a deception / honeypot service that does some similar stuff so that all makes sense to me and I think the general strategy of impose costs on attackers by making them expose more of their infrastructure etc are actually a really good move especially in the context of developing an early warning signal.

I had some additional logic that gave me a really easy but unintuitive way to tell with an incredibly high degree of confidence the difference between a bot and a human on keyboard scenario and for what it’s worth I think that is the specific thing that makes it worth the effort.

If I have reasons to suspect it’s a bot I just drop the request and move on with my day. The signal to noise ratio isn’t worth it to me.

OpenVPN was a perfectly reasonable answer to this problem for many years.

“Port knocking” et al were most definitively not.

Just to clarify: it's actively worse in every scenario. It's engineering malpractice.

Eh. I've used OpenVPN over many years for many kinds of problems. I'm hesitant to call it perfectly reasonable even for the most mundane use case of "running an entirely vanilla virtual private network". For the use case of securely wrapping services in the way Wireguard can do, it's hilariously bad.

OpenVPN is basically 1000 configuration options and magic incantations wearing a trenchcoat, and if you get any of them wrong the whole thing crumbles (or worse, appears to work but is not secure).

Threat detection is a higher security priority than prevention in my experience.

One may believe whatever they like, as both our intentions are clear friend.

Have a wonderful day =3

It's weird to assign them comparatively like that but also, what does that have to do with fail2ban?

The roving spam it blocks are not threats, and stolen credentials aren't going to be detected by it.

Depends on the use-case, IPsec is often not supported by many LANs. Also, network crossing is 1 badly configured client away from full infrastructure worming.

At some point, the idealism of white-listed pears and VPN will fail due to maintenance service costs. Two things may be true at the same time friend. =3

https://www.poetry.com/poem/101535/the-blind-men-and-the-ele...

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 would simply bounce these users to a video game site, that paid us for referrals.

So we made coffee-money wasting spammers time, and attacks stayed rudimentary. =3

"We had a secure VPN option set up, but then we had to replace our Ivanti VPN solution so we switched to Fortigate. Then there were some concerns so we jumped to Sonicwall. After that debacle we finally got the budget to go with Cisco and I'm sure everything will be fine now!"

I said a secure VPN option.

However, even with all those choices, “port knocking” still wouldn’t be a solution for anything.

[edit]

Are you just searching for random WireGuard CVEs now?

CVE-2024-26950 was a *local-only* DoS and potential UaF requiring privileged access to wireguard netlink sockets.

Yes, and those two true things are:

- You should be using WireGuard.

- “Port knocking” is pointless theater.

There is literally no value to cutting down on WireGuard attempts. Like, the exact same set of skbuffs are being created and destroyed in either case.

In general, bots/worms/clowns will first check if a host/router is already infected or vulnerable to a shim. Thus, tripwires on those checks or URI often auto-ban infected/hostile hosts before a scan fully escalates to a successful payload. Note, people don't want a VM delta-snapshot of their zero-day around for automated analysis.

99.98% of hostile traffic simply reuse already published testing tools, or services like Shodan to target hosts.

One shouldn't waste resources guessing the motives behind problem traffic. =3

I view port knocking as just a very, very poor form of an unencrypted PSK (replayable) authentication step.

Just skip the plaintext password (the sequence of ports transmitted) and use certificate based auth, as you note below.

It's part of a long line of cargo culted security things people do because it makes them feel on-the-ball; they're all anti-tiger rocks. Even before WireGuard, port knocking never made sense, and for most of its history it was actively harmful.

CVE-2024-26950 is also true, and while I respect your opinion... a VPN has a lot of additional links in the chain trivially broken by competent hostiles or incompetent client installations.

IPSec is simply a luxury unavailable on some LANs =3

You mean CVE-2024-26950 ? =3

<edit>

Firewall administrative network port traffic priority is important for systems under abnormal stress.

Do you have a guide to using wireguard in this way?

IMHO Fial2ban, just like port knocking, isn't cargo cult security. They are a single tool that can be included in a general system security arsenal, not the only tool you should use but one of a suite of tools that can be used depending on what you want to achieve.

Personally I use fwknop for port knocking as it doesn't suffer from replay attacks as it's an encrypted packet. But still serves the same niche

Using WireGuard in what way? WireGuard defaults to the security posture SPA/port knocking hopes to asymptotically achieve.

> Using WireGuard in what way?

Using WireGuard to gate access to a server. It looks like it's a VPN, not an access control mechanism. So I am curious how this works.

Set up WireGuard, filter everything but WireGuard (51820/udp) on en0, and then SSH in over the WireGuard connection.

WireGuard is sort of a VPN, but really its core is peer to peer links with simple, footgun-resistant configs.

The most mundane setup is two peers with each other’s public keys that let each peer talk to the other via the WireGuard link.

They can't get in but they can still fill my logs up, so fail2ban cuts them off after a few failures.

Also by collecting data on the IP addresses that are triggering fail2ban I can identify networks and/or ASes that disproportionally host malicious traffic and block them at a global level.

Why bother logging them at all? What is this doing for you? You can't meaningfully characterize attacker traffic this way. They'll come from any AS they want to.

Don't compliance regimes like NIST 800-53 require logging access attempts, whether successful or not, and especially for privileged users?

> To balance monitoring and auditing requirements with other system needs, event logging requires identifying the subset of event types that are logged at a given point in time. For example, organizations may determine that systems need the capability to log every file access successful and unsuccessful, but not activate that capability except for specific circumstances due to the potential burden on system performance.

It's possible that some compliance regimes exist that mandate keeping logs of all unsuccessfully authentication attempts. There's surely a compliance regime out there that mandates every possible permutation of thing.

But the far more common permutation, like we see with NIST, is that the organization has to articulate which logs it keeps, why those logs are sufficient for conducting investigations into system activity, and how it supports those investigations.

The point being made is that unless "what you want to achieve" is "run a tool that isn't improving your security posture", port knocking isn't providing value to the security model.

Hence the cargo cult.

You're just sort of loosely interweaving unrelated comments?

You're back on prevention instead of detection, but also no: an attacker with valid creds isn't going to run other checks first before using them.

And yes: by volume, most attacks on the internet are just spam reusing published tools and IP lists. And that traffic is zero percent risky unless your auth is already busted.

> Why bother logging them at all? What is this doing for you?

Logging both successful and failed requests is important for troubleshooting my systems, especially the client-facing ones (a subset of which are the only ones that are accessible to the open internet), and failed authentication attempts are just one sort of request failure. Sometimes those failures are legitimate client systems where someone misconfigured something, and the logs allow me to troubleshoot that after the fact. That it can also be fed to fail2ban to block attackers is just another benefit.

> You can't meaningfully characterize attacker traffic this way. They'll come from any AS they want to.

Obviously in a world full of botted computers, IoT devices, etc. it's true that an attacker can hypothetically come from anywhere, but in practice at least from the perspective of a small service provider I just don't see that happen. I'm aware that you are involved with much larger scale operations than I'm likely to ever touch so perhaps that's where our experiences differ. No one's targeting my services specifically, they're just scanning the internet for whatever's out there and occasionally happen to stumble upon one of my systems that needs to be accessible to wherever my clients happen to bring their devices.

Sure, I see random domestic residential ISP addresses get banned from individual servers from time to time, but I never see the organized attacks I see which are usually coming from small hosting providers half way around the world from my clients. I have on multiple occasions seen fail2ban fire off rapidly sequential IP addresses like xxx.xxx.xxx.1 followed by xxx.xxx.xxx.2 then xxx.xxx.xxx.3, or in other cases a series of semi-random addresses all in the same subnet, which then triggers my network block and magically they're stopped instead of just moving on to another network. If I were to be packet sniffing on the outside of the relevant firewall I'm sure I'd see another address in the blocked network trying to do its thing but I've never looked.

I can't agree that it's "a tool that isn't improving your security posture", if it's a layer on top of other tools, you might argue it's effectiveness isn't great but to say it's effectively nothing is a reach.

These are what I call, corporate solutions. They're used to make CEOs feel good while deflecting blame, not to actually do the job. See also how nobody gets blamed if AWS goes down, but everyone who used a different host with higher uptime did get blamed when that went down.

Open source tools are good at actually doing the job, as long as it's a programmer type of job. We've known how to do unbreakable encryption for decades now. Even PGP still hasn't been broken. Wireguard is one of those solutions in the "so simple it has obviously no bugs" category - that's actually what differentiates it from protocols like OpenVPN.

Think about the recent satellite listening talk at DEFCON and how that massive data leak could have been prevented by even just running your traffic through AES with a fixed key of the CEO's cat's name on a Raspberry Pi, but that's a non-corporate solution and so not acceptable to a corporation, who will only ever consider enabling encryption if it comes with a six figure per year license fee which is what the satellite box makers charged for it. Corporations, as a rule, are only barely competent enough to make money and no more.

Sure there is, if the attacker has to fulfil some basic obfuscation then it cuts down on the amount of crypto work you have to do before ignoring the packet.

It's not extra security but it is a little extra efficiency.

Wireguard has something like this built in though, the PresharedKey (which is in addition to the public key crypto, and doesn't reduce your security to the level of a shared-key system). It's still more work to verify that than a port knock however.

It is a VPN. The point was to block all external traffic except for VPN traffic. Then make sure your VPN is secure, and you're all set. When you want to connect to some service, connect to the VPN first and then connect to the service through the VPN. Then all your traffic has actual security and not just some light obfuscation via secret handshake.

IMO, "only wireguard" is too restrictive of a policy - I also trust openssh and nginx to be open to the internet, if configured moderately carefully. Most FOSS servers that are widely deployed on the internet are safe to be deployed on the internet, or we'd know about it. I reviewed something that's not widely deployed on the internet though (Apache Zookeeper) and couldn't convince myself that every code path was properly checking authentication. That would have to go behind a VPN.

It’s not nothing: it’s one more thing that can break or eat resources or have a vuln. And it’s not improving the thread model. It’s net negative.

This has no value at all. WireGuard assumes an adversary trying to make it do extra work doing handshakes; a big chunk of the WireGuard paper discusses it. I don't think this is as important a problem as Jason does (but it's his baby), but either way: part of the point of WireGuard is that it's safe to hang out on the open Internet this way.

PGP has very much had breaks, both in its authenticator and a full-on confidentiality break for the mail plugins, both traceable to the structure of the system itself, and that's before we get into the fundamental DOS flaw that killed the keyservers, which themselves are an antifeature. I don't think you can find a practicing cryptography engineer to stick up for PGP.

I don't like or trust OpenVPN. I'd sooner expose OpenSSH itself, which has really a pretty stunning security track record.

I was thinking of:

> The need to limit unsuccessful logon attempts and take subsequent action when the maximum number of attempts is exceeded applies regardless of whether the logon occurs via a local or network connection. Due to the potential for denial of service, automatic lockouts initiated by systems are usually temporary and automatically release after a predetermined, organization-defined time period.

https://csf.tools/reference/nist-sp-800-53/r5/ac/ac-7/

I don't understand what you think CVE-2024-26950 has to do with this thread. Do you understand what that vulnerability actually is, or did you just go search "WireGuard CVE" to find ammunition?

Cisco spent years marketing every solution as a router or appliance box.

A lot of VPN installations are simply done wrong, and it only takes 1 badly configured client or cloud side-channel to make it pointless. IPSec is not supported on a lot of LANs, and 5k users would prove rather expensive to administer.

Also, GnuPG Kyber will not be supported by VPN software anytime soon, but it would be super cool if it happens. =3

Firewall administrative network port traffic priority is important for systems under abnormal stress.

That’s almost always going to be a setting in your IDP, not based on log capture/retention.

The IDP will have some settings for max fails before lockout, and apply it by counting.

The key concept is accountability, and if only 7 people have access to a host instance... the damage done by malicious or incompetent actors is kept small.

The biggest weakness in VPN is client-side cross-network leaks.

IPSec is simply a luxury if the LAN supports it, but also an administrative nightmare for >5k users. =3

I don't know what this even means. Do you understand the vulnerability you cited? Can you explain it here?

The relatively benign legacy kernel level pointer-bug CVE chosen is hardly the worst thing from WireGuard or strongSwan over the years. However, it makes the point a priority reliable network side-channel administrative login is more robust under some use-cases.

Adding layers of complexity rarely improves security, and doesn't usually address the underlying issue of accountability. And I often ponder if a bastion host is even still meaningful in modern clouds. =3

The bug you cited is in Netlink. It's not exposed on the network. What's the "worse" thing you're referring to? I think you just searched "WireGuard CVE" and tried to play it off.

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.

In general, doing a qualitative summary of the projects impact is less helpful, and never as verbose as some would prefer on platform specific issues. Additionally, wireguard is now more popular than strongswan these days...

https://www.cve.org/CVERecord/SearchResults?query=ipsec

https://www.cve.org/CVERecord/SearchResults?query=wireguard

https://www.cve.org/CVERecord/SearchResults?query=strongswan

Best of luck, and straw-man arguments are never taken seriously. =3

This reads like a long-winded way of saying you aren't bothering to read what the vulnerabilities actually are.

>This reads like a long-winded way of saying you aren't bothering to read what the vulnerabilities actually are.

Almost, it is more that I don't care specifically why a IPSec option is often a liability, and would rather stick with something less silly.

Ad hominem attacks do not change the fact there are new issues in IPSec/VPN approaches found regularly. Pick any failure mode(s) on the list that applies to your specific use-case and platform.... or could find new ones if you are still bored.

Have a great day =3

https://www.youtube.com/watch?v=6vgoEhsJORU

> You can't meaningfully characterize attacker traffic this way. They'll come from any AS they want to

I'm not totally following what Fail2Ban has to do with Wireguard. Are we talking strictly about homelabs you don't expose to the internet?

Because I have a homelab I can connect to with Wireguard. That's great. But there are certain services I want to expose to everybody. So I have a VPS that can connect to my homelab via Wireguard and forward certain domain traffic to it.

That's a safe setup in that I don't expose my IP to the internet and don't have to open ports, but I could still be DDOS'd. Would it not make sense for me to use Fail2Ban (or some kind of rate limiting) even if I'm using Wireguard? I can still be DDOS'd.

How is it not improving the threat model to not have a service directly connected to the internet, but instead put behind a layer of protection?

> And that traffic is zero percent risky unless your auth is already busted

Well it's a waste of our time and resources. I'm not just going to let people make 100 requests per second for no reason?

I somehow doubt that it is quite truly worse in every single scenario, and that there is not one single scenario that port knocking may be better utilized than WireGuard.

I also find it hard to believe it is engineering malpractice to use one technology over another.

What happens if there is a vulnerability in WireGuard? Or if WireGuard traffic is not allowed in or out of a network due to a policy or security restriction?

A centralized IDP that touches every service is not mandated by NIST though. So while you are right that an IDP can handle that, the organization may not have the IDP integrated with a given system and you will still need compensating controls or mitigations. Outright incredulity over logging failed access attempts is surprising.