Knocker, a knock based access control system for your homelab

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.

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...

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.

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

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.

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.

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.

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 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.

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.

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

> 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?