Device-Side Protection

Most of what NetDefense guarantees — signed commands, a fixed operation set, replay protection — is enforced by the control plane and by NDAgent’s verification of what it receives. This page is about a different, narrower layer: protections against configuration-sync content that live on the firewall itself, enforced independent of what the sync itself claims. Even a fully authenticated, correctly signed sync — including one issued by a compromised control plane — runs into these when it tries to touch a critical account or grant a new privilege.

This page does not cover remote sessions. A compromised control plane, or any credential with write access, can still open one — and a remote session is a shell. See Security for that boundary and what actually bounds it today.

Treat this page as defense-in-depth for configuration pushes, not a single mechanism and not a complete answer to every worst case. Each guarantee below holds on its own, and they don’t depend on each other to be effective.

Read-only sessions are enforced on the device

Read-only remote access to a device’s web administration interface is not a client-side restriction the browser happens to honor — the constraint is enforced by the firewall itself. In a read-only session, every service the agent could otherwise reach is refused except the web UI, and even within the web UI, writes are blocked by a dedicated OS-level read-only account rather than by hiding controls in the interface. There is no write capability sitting behind the UI for a modified or instrumented client to find, because the account the session runs as cannot perform one.

Critical accounts can’t be touched by a configuration sync

A handful of accounts on the device are structurally excluded from configuration sync, regardless of what a pushed configuration contains: root, OPNsense administrator accounts, the agent’s own service account, and the dedicated read-only account described above. A sync that somehow included instructions touching any of these accounts would have those instructions ignored at the device — this isn’t a validation rule that could be bypassed by constructing the sync differently, it’s a boundary the agent enforces on itself before it ever considers what a sync is asking for.

A local policy for privilege-sensitive changes — on by default since v1.14.0

The critical-account protection above is always on — it isn’t something you opt into. NDAgent also supports an additional guardrail on top of it: the reject_dangerous_snippets option in the agent’s local configuration, which makes the firewall reject configuration pushes attempting to grant new privileges, add SSH keys, or enable remote command execution on service accounts. When it’s active, even an authenticated, correctly signed configuration sync is refused if it tries to do any of those things — the device is the one deciding to say no, not the control plane deciding not to ask.

As of NDAgent v1.14.0, reject_dangerous_snippets defaults to enabled on new installations. The device starts closed, and an operator has to make an explicit, local decision to open it back up.

Existing installations are grandfathered on upgrade. If you never explicitly set reject_dangerous_snippets before upgrading to v1.14.0 or later, the upgrade writes an explicit false into your local configuration — your current behavior is preserved exactly, nothing changes silently, and no working sync starts failing because of the update. When you’re ready to move to the stricter default, set reject_dangerous_snippets=true in the agent’s local configuration and restart the agent.

Setting this is deliberately a local, on-device decision rather than something the platform can flip on your behalf — it lives in the agent’s own configuration, not the control plane, so enabling or disabling it is always an explicit choice the device operator makes.

Re-verified on every upgrade, not just first install

These protections aren’t something NDAgent sets up once and assumes stays true. They’re re-verified on every package upgrade, so a routine pkg upgrade doesn’t quietly regress a device back to a less-protected state — the same checks that applied on day one apply again after every update.

Why this layer exists

This page exists for one specific worst case: a configuration sync that is correctly signed and fully authorized — including one issued by a compromised control plane — but attempts something the device itself should refuse. Signing and the fixed operation set stop a different problem: they stop an attacker from inventing an operation type that doesn’t exist, or tampering with one in flight. They do not stop the control plane itself from legitimately requesting a privilege-granting sync, because a compromised control plane holds the signing key and needs no forgery — it can sign anything the vocabulary allows. That’s exactly why this layer exists: critical-account protection and reject_dangerous_snippets are the device’s own, independent refusal of specific sync content, regardless of who signed it or how validly.

This layer is scoped to configuration sync. It says nothing about remote session — one of the ten fixed operations — which a compromised control plane, or any write-scoped credential, can still request. Two layers that don’t depend on each other both having to fail is the point for the sync path; the remote-session path is a separate, currently open question addressed on the security page.