WOMBATS Shield
Security

How we look after the appliance you put on your network.

Shield is a piece of hardware that sees a lot of your traffic. We treat that responsibility seriously, both in how the device is built, and in how we handle reports when something is wrong.

Reporting a vulnerability

If you believe you've found a security issue in WOMBATS Shield, the appliance, the local web management UI, the update path, or anything bundled with it, please tell us. We'll respond like adults: quickly, privately, and with credit if you want it.

We will not pursue good-faith researchers who follow this disclosure path. Please give us a reasonable window to investigate before public disclosure.

What's in the appliance

Shield is built on trusted open technology, hardened and tailored into a real appliance. We'd rather tell you what's underneath than pretend we wrote it all from scratch.

Raspberry Pi 5 hardware baseline+

Shield runs on Raspberry Pi 5 silicon (2 GB on Core and Edge, 4 GB on Vault). Real, repairable, well-documented hardware with a long supply life, not a one-batch custom board.

Debian 12 base system+

A long-term-support Linux base with a known security track record and a predictable patch pipeline. We track upstream Debian security where relevant.

AdGuard Home, hardened baseline+

Shield uses AdGuard Home as its DNS-layer filtering engine. We've intentionally restricted, disabled or redesigned features that conflicted with our privacy and security goals, including default query logging behaviour, remote-management exposure, and any ambiguous telemetry. AdGuard provides the engine. Shield's appliance behaviour is ours.

nftables enforcement+

Shield applies local nftables redirect, port-block and forward-chain rules to resist common DNS-bypass paths and Apple Private Relay traffic. Enforcement happens on the device, not on a vendor cloud.

Signed software updates+

Software bundles are signature-verified before they're applied. There is no ad-hoc file replacement, no remotely pushed unsigned change. The update path is the only way new code lands on Shield.

Hardware-assisted unlock+

Shield's encrypted partitions are unlocked at boot through a hardware-assisted key path using an ATECC secure element. The unlock key is bound to the device, it can't be lifted off and used elsewhere. This is the same family of crypto hardware used in premium identity and storage products.

Vault SSD, three independent key paths+

On Shield Vault, the encrypted storage SSD has three separate ways it can be unlocked. (1) An auto-unlock key bound to the device's ATECC secure element, used at boot so the SSD comes up cleanly on your network without prompting. (2) A user passphrase, for user-level access. (3) A recovery key, kept safely off the device for break-glass recovery if both of the above are unavailable. Lift the SSD into another machine and it stays dark, the auto-unlock key is bound to the original Shield.

Separate payload and storage partitions+

On Shield Vault, the encrypted payload partition that runs the system is kept separate from the encrypted storage partition that holds your files. Each is unlocked through its own ATECC-bound key path. A failure or a reset on one does not threaten the other.

Update philosophy

We update Shield deliberately, not constantly. New software lands as a complete, signed bundle that is verified before it's applied. We don't silently push unrelated changes through a back channel, and we don't use the update path to add new telemetry. If we ever need to change what Shield does in a meaningful way, you'll hear about it before the change ships.

What we don't do

Looking for the deeper architecture? See the threat model and how it works.