Built like the OS it runs on.
A firewall's management plane is the softest target on the network: it holds the keys to the thing that holds the keys. OgmaProtect is built so that owning one piece of it gets an attacker as little as possible — and so that everything that reaches your box can be checked before it runs.
The shape of the system
Five tiers. What each one holds is what an attacker who owns it gets.
- Your browser HTTPS with HSTS. No agent, no plugin, nothing to install.holds a session cookie
- one unix socket, root-only Web tier httpd + slowcgi, chrooted, unprivileged. Renders pages.holds no credentials · no secrets · no configuration
- authenticated, role-checked requests Gatekeeper — authd Sessions, roles, TOTP MFA, the secret store, and the audit trail for every privileged action.holds accounts, sessions and secrets — the tier everything else protects
- per-domain sockets · capability tokens 16 domain daemons netd · rtd · pfd · dnsd · dhcpd · 11 more. Each pledged and unveiled to the minimum it needs.holds one domain each — nothing else
- validate → apply live → atomic write → revision OpenBSD PF, CARP, pfsync, Unbound, WireGuard — the native tools, driven from canonical configuration.holds the running firewall
Least privilege, by construction
Compartments are the architecture, not a feature bolted onto it.
- 16 single-purpose daemons. Firewall, routing, DNS, DHCP, VPN, time, health — each domain is its own process with its own small remit. The web tier renders pages and can do nothing else.
- pledge and unveil on every daemon. Each process declares the system calls and the exact filesystem paths it needs; the kernel kills it if it steps outside them.
- Root-only sockets and per-request tokens. Domain daemons accept connections only from root — the gatekeeper and the root console, never the web tier — and every inter-daemon request carries a token minted for that specific target.
- A hardened authentication plane. Opaque session tokens in HttpOnly, Secure, host-locked cookies; CSRF tokens bound to the session; login rate-limiting; per-user TOTP with recovery codes — and an auth database that lives in a split child process able to run only immutable, pre-compiled SQL statements.
- HTTPS only. A per-host certificate is provisioned at first boot and HSTS is on in the shipped web-server configuration.
Fail closed, by default
Operator mistakes are the most common security incident on any firewall. The system is designed around them.
- It refuses to lock you out. Anti-lockout rules are built into every generated ruleset; management-plane guards refuse changes that would sever your own session; dangerous operations demand explicit confirmation.
- It reverts what you do not confirm. Firewall, tunnel, WireGuard and CARP applies run in commit-confirmed windows — if a change broke your access, the router restores the previous state on its own.
- An unconfirmed configuration never boots live. A change still inside its window is reverted on restart, and a bad firewall marker falls back to the last known-good ruleset rather than failing open.
- It tells you when reality diverges. Per-domain drift detection compares live state against configured intent continuously — and raises an alert.
- It sends us nothing. No telemetry, no licence checks, no cloud dependency. The update check is off until you turn it on, and even then it says nothing about your box. The box still talks to the OpenBSD mirror and to the NTP pool unless you change those defaults.
What reaches your box, and how you know it is ours
The release path, end to end. Nothing on it asks you to take our word.
- Built in CI Every tag produces an unsigned draft: the package and the appliance image.
- Signed offline An air-gapped machine signs one manifest with an Ed25519 key that exists only on offline media, held by two custodians. CI never sees it.
- Published together The manifest and its signature ship beside the files they cover — the package and, when a release carries one, the appliance image, under one signature.
- Verified on your box pkg_add checks the signature as it unpacks and refuses at the first bad chunk — nothing unverified is written. An update is re-verified the same way.
- The key never touches CI. The private half exists only on offline media, held by two named custodians. A compromised build runner can produce a broken draft; it cannot sign or publish one.
- The key is published out of band. It is a DNS record on a separate domain at a separate provider, and its fingerprint is printed on the download page. No single compromised account can hand you both a forged package and the key that vouches for it.
- One manifest, every artifact. Each published release carries one signed
manifest covering everything it ships — the package and, when the release carries one,
the appliance image.
pkg_addrefuses anything unsigned; an update is re-verified on the box before it is applied. - The source is available on request. Auditors and licensees can read the product code and the customer documents — ask us. What a release ships is built from a published allowlist, so nothing internal rides along.
- A dependency list that fits on one line. Beyond OpenBSD base: 2 packages and one vendored single-header parser. The direct dependencies are listed on the compliance page.
- Nothing installs itself. The update check is off by default and sends nothing about your box when it runs. Updating is two deliberate steps — stage and verify, then apply behind a typed confirmation with an automatic snapshot.
- Fuzzed and sanitised, continuously. The C test suites run under AddressSanitizer and UndefinedBehaviorSanitizer with leak detection on every change; the configuration parsers are fuzzed coverage-guided every day.
What the signature proves — and what it does not
It proves the package you hold is byte-for-byte the one we built and signed. Tampering
in transit, a compromised download host, a corrupted mirror: pkg_add checks
the signature as it unpacks and refuses at the first bad chunk, so nothing unverified is
ever written to disk.
It does not prove the key you hold is ours. The anchor zone is not DNSSEC-signed, so the first install is trust-on-first-use; the separation buys you that no single provider can forge both halves, and the fingerprint check on the download page is the cross-check. A genuine older release also still verifies — signatures do not expire — so check the version against the advisory. And a signing key can be retired, not revoked: if ours were ever compromised we would publish a successor and ask you to replace the anchor by hand.
Evidence, not adjectives
Before commercial launch the entire codebase went through an 8-lens structural audit — architecture, code quality, conformance, security, tests, supportability, the web tier, state and recovery. The findings drive the hardening programme landing now, durability-first: the failure modes that could brick a router get fixed before polish.
We publish the process and the aggregate numbers, and we describe what has been fixed once it ships. We do not publish details of open findings — transparency about method, discretion about anything an attacker could use first. Audit trails on the box carry integrity tags of their own, and an exported trail can be re-verified off the box with a standalone tool we provide to auditors. Advisories →
Researchers, auditors and sceptics
- Report a vulnerability: security@ogmaprotect.com. We acknowledge within three working days, practise coordinated disclosure, request CVEs from MITRE, and credit you if you want credit.
- Read the source. Available to auditors and licensees on request — ask us.
- Question our claims. Every feature statement on this site is tracked in a claims ledger tied to evidence in the source tree — if we cannot point at the code, we do not say it. The roadmap is generated from the same ledger.