Live data from Hacker News

Knocker, a knock based access control system for your homelab

github.com

121–130 of 175 posts

Re: Knocker, a knock based access control system for your homelab

#121
post #74

Earlier quoted context omitted.

If you're running a homelab, the likelihood that you're interested in removing cloud-dependencies from your stack is above average. If that's the case, Tailscale is out. Tailscale is just an added unnecessary external dependency layer (& security attack surface) on top of vanilla Wireguard. And in 2025 it's easier to run vanilla Wireguard than it's ever been.

Normally I'd agree with the philosophy, but I don't really see how you can say this about vanilla Wireguard in particular considering how involved it is, especially if you have more than 2 devices that you want to connect together. Not only do you need to manually manage the keys for each device and make sure they're present in every other device's configuration, but plain Wireguard also cannot punch through NATs and…

> trying to argue that Tailscale is entirely unnecessary is just wrong

Tailscale is great if it meets your requirements, & it probably does for most - I wasn't arguing that at all. Only that it won't be an option for everyone: in particular a non-tiny subset of home server hosters.

Re: Knocker, a knock based access control system for your homelab

#122
post #118

Earlier quoted context omitted.

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?

Re: Knocker, a knock based access control system for your homelab

#125

Earlier quoted context omitted.

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.

Re: Knocker, a knock based access control system for your homelab

#126
post #71

Earlier quoted context omitted.

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

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

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.

Re: Knocker, a knock based access control system for your homelab

#127
post #91

Earlier quoted context omitted.

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.

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 li…

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.

Re: Knocker, a knock based access control system for your homelab

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

Re: Knocker, a knock based access control system for your homelab

#129
post #2

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. The idea itself sounds fun though

I guess I have to implement the habit of checking such things, since I never assume such a possibility. I prefer this info to be at the top of the readme, though – much more information value than the logo that deceived me into thinking this is a mature project. Regardless; what benefits this would have over Wireguard?

Perhaps not requiring a wireguard client installed on the machine you are accessing from. There are several circumstances where installing a VPN client isn't possible or practical

Re: Knocker, a knock based access control system for your homelab

#130
post #127

Earlier quoted context omitted.

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 li…

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.

[flagged]
Post reply on HN