Open Source

We publish the small pieces of infrastructure we build for ourselves when the problem they solve is not specific to one customer. They are deliberately narrow. Each one does a single job, which is what makes it short enough to read and audit before you decide to trust it.

MFA Firewall Knocker

MFA Firewall Knocker keeps SSH, RDP, or any other administrative port closed by default. A user who proves who they are with a passkey gets a firewall rule opened for their source IP only, and that rule expires on its own. It is port knocking, except the knock is WebAuthn instead of a magic packet sequence.

It is MIT licensed, written in C# on .NET 10, and runs on Windows Server or Linux. We wrote it for our own network, and we run it. For a security tool that is the only endorsement that means very much.

The problem it solves

SSH and WireGuard authenticate a key. Neither can answer the question that actually matters: is the authorized user the one holding that key right now?

Possession is the entire test. A copied WireGuard profile or a leaked private key passes it forever, from anywhere, and the protocol has no way to notice. This is not a flaw in the cryptography, which is excellent. It is what a key file is — a password that happens to live on disk, with no second factor behind it.

The everyday version is more uncomfortable than the exotic one. Leave an unlocked laptop on a table in a coffee shop for two minutes and everything needed to reach an internal network is sitting there, already unlocked, requiring nothing further to use. Our developers work from the US and Ukraine, and a copied config file was the hole we could not close.

What the passkey changes

With the gate in front, that laptop is not enough. The port is closed, and opening it requires a WebAuthn passkey on the user's enrolled device, with a biometric or device PIN demanded at the moment of access — not once at enrolment. Someone holding your unlocked machine and all of your keys still cannot reach the service, because they cannot produce the second factor.

It moves the credential from something stored to someone present. It also shrinks the attack surface considerably: a closed port cannot be fingerprinted, enumerated, or attacked by anyone who has not already authenticated, so the service behind it is invisible to everything that has not passed the gate. Every grant is logged — who, from where, when — and every grant ends by itself.

Often a requirement, not just a good idea

Multi-factor authentication for remote network access turns up wherever somebody is checking: cyber-insurance questionnaires, NIST SP 800-171 (3.5.3) and therefore CMMC, PCI-DSS, and most SOC 2 programs. A WireGuard profile or an SSH key does not satisfy it. It is a single factor, something you have, and possession of the file is the whole test.

Whether it satisfies your particular auditor or carrier is a question only they can answer, and we make no compliance claim on your behalf. But if you have been asked whether remote access to your network sits behind MFA and the honest answer was "not really", this is a direct way to change that without replacing the VPN you already run.

How this differs from Tailscale and similar products

Tailscale, Twingate and Cloudflare Access address the same underlying problem, and they are mature, well-built things. This is not a drop-in replacement for any of them. It is a different place to bind a key to a person.

They bind at enrolment. The device generates its own key, the key never leaves it, and SSO ties it to a real identity — then they build a network on top: mesh routing, NAT traversal, DNS, ACLs. This binds at time of use. It never touches your SSH or WireGuard keys at all. It makes the port unreachable until a human proves who they are, right now, and then opens it narrowly and briefly.

The deeper difference is philosophical rather than featural. This is deliberately small, closer in spirit to WireGuard than to a platform. The whole mechanism fits in a sentence: prove you are a human with a passkey, a firewall rule appears for your IP, it expires. You can verify the state with iptables -S. There is no control plane, no coordination server, no agent, no overlay, and one person can read the source end to end in an afternoon.

Small also means it does less, and that is not a footnote. If you need a network — reaching machines behind NAT, routing subnets, naming hosts — or you need fleet management, SSO, SCIM, device posture and an ACL language, those products build all of it and this builds none of it. "You can read the whole thing" is not a substitute for having capabilities you actually need. Use one of them, and we would tell you to do so.

For us the deciding factor was the dependency, for a reason specific to what we do. We support systems our customers depend on, and when one of those is down we need to reach it now. Putting somebody else's control plane between us and a customer's server means accepting that their outage becomes ours. "We cannot get in to fix your site until a third party's service comes back up" is not a sentence that survives contact with a customer whose business has stopped, and it is not one we are willing to be in a position to say. If you do not carry that obligation, the platform is probably the easier answer.

What it does not do

The weaknesses are in the documentation because a security tool that hides them is worse than one that does less:

• Per-IP gating degrades behind CGNAT, corporate VPNs and iCloud Private Relay, where a user authenticates from one address and connects from another.
• Once a rule is open it is open to that IP for the window, with no per-connection authorization behind it.
• It does no encryption of its own and relies entirely on the protocol behind the port.
• It must not be your only way in. An expired TLS certificate locks everyone out completely — browsers refuse the passkey ceremony on an invalid certificate and will not let a user click through, so nobody authenticates and nobody opens a rule. Redundancy here is not paranoia. It is the difference between an incident and an outage you cannot remotely fix.

Design decisions worth knowing about

The privileged and unprivileged halves are separate processes. The internet-facing web app cannot write to the user database and cannot issue a firewall command; the privileged service is never exposed to the network and re-validates every policy decision instead of trusting its caller.

TOTP is compiled out rather than disabled by configuration. In the default build the routes do not exist, the IPC verb does not exist, and no shared secret is ever written — which means the user store holds nothing an attacker can use, because passkey credentials are public keys. There is no configuration key to get that wrong and no second code path for a reviewer to audit. A capability that is not there cannot be misconfigured.

It has been through the same AI-driven security review we run against everything we ship, described in this post on testing software against an AI attacker. For a tool that writes firewall rules on a privileged host that seems like the minimum bar rather than a selling point.

The source, prebuilt releases, and the install guide are on GitHub. Issues and pull requests are welcome.

Why we work this way

Publishing something means it has to survive being read. That is a useful constraint, and it is the same one we apply to work we do for customers: the design should be explainable, the trade-offs stated rather than buried, and the code short enough that the person maintaining it after us can follow it. If you would like the same approach applied to your systems, talk to us about your project.