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.

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.

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

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.

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/

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.