Managed Infrastructure

What It Is

FortrOS manages not just its own nodes but also the supporting network infrastructure: routers, switches, access points, firewalls, and other devices that aren't running FortrOS. These devices are brought under the org's declarative management by regularly exporting their configuration, comparing it to the desired state, and re-importing the desired configuration. This is clobber-based declarative management for devices that don't natively support it.

Why It Matters

The org's security depends on the network infrastructure between its nodes. A compromised router can redirect traffic, intercept packets, or create covert channels. A misconfigured switch can break VLAN isolation. A rogue access point can serve a fake captive portal.

Traditional network management relies on one-time configuration: an admin SSHes into the router, makes changes, and hopes nobody modifies them later. There's no continuous enforcement. A compromised device stays compromised until someone notices.

FortrOS's approach: declare the desired configuration, regularly verify it matches reality, and clobber it back to the desired state if it doesn't. A compromised router's malicious config survives until the next reconciliation cycle (minutes), then gets overwritten with the declared state.

How It Works

The Clobber Model

The org's CRDT config tree is the source of truth for every managed device's configuration. The device's running config is a derivative, not an authority. The management cycle:

Clobber: Push the org's declared config to the device. This is the primary operation -- not export-then-compare, but assert-desired-state. As long as the device's firmware version hasn't changed, the config format is known and the import is safe to apply unconditionally.
Drift check (security signal): Before clobbering, export the device's current running config and compare it to what we last pushed. If they differ, something changed the device since our last cycle -- log the diff and alert. This is a security indicator, not the primary mechanism. The clobber happens regardless of whether drift was detected.
Firmware version check: If the device's firmware version has changed (auto-update, manual update), pull the current config to check if the format changed. Adapter updates may be needed before clobbering can resume.
Verify: After clobber, export and confirm the config matches. If it doesn't (device rejected part of the import), alert.

Clobber vs apply-changes: Some devices apply config changes gracefully (individual settings updated without restart). Others require a full config import that causes a brief restart or service interruption. Some require an explicit reboot after certain changes (VLAN changes on some switches, for example). The adapter for each device type knows which approach the device supports:

Graceful: Apply individual setting changes (preferred when possible). No service interruption.
Full import: Replace the entire config atomically. Brief interruption during apply (some devices restart network services). The clobber cycle schedules these during maintenance windows when possible.
Reboot required: Some changes only take effect after reboot. The adapter queues these and alerts the admin. Automated reboot is policy-controlled (auto-reboot at 3 AM, or require human approval).

The cycle runs on a configurable interval (default: every few minutes for drift detection, immediate push on config change in the CRDT).

Device-Specific Adapters

Different devices have different management interfaces:

Device Type	Management Interface	Config Push	Drift Export
MikroTik	SSH + RouterOS CLI	`/import` from org config	`/export` for drift check
UniFi	REST API (controller)	PUT config	GET config
OpenWrt	SSH + UCI	`uci import` / `uci commit`	`uci export`
Cisco IOS	SSH + CLI	`configure terminal` + commands	`show running-config`
Generic	SNMP	SNMP SET	SNMP GET

Each adapter translates between the org's desired state representation and the device's native config format. Adding support for a new device type means writing an adapter that can push config and export for drift checking.

OOB Management Ports

Many managed switches and routers have a dedicated management port (separate from data ports). FortrOS connects to these via the overlay or a dedicated management VLAN:

MikroTik: Dedicated management Ethernet port, accessible via SSH
Cisco: Console port (serial) or dedicated management Ethernet
UniFi: Management via the UniFi controller running as a FortrOS org service

Using the OOB management port means the management traffic is separate from the data traffic. A compromised data port doesn't give access to the management channel.

Pseudo-Declarative Management

Most network devices aren't natively declarative (you can't just say "the config should be X" and have them converge). FortrOS makes them pseudo-declarative by treating the export/import cycle as a reconciliation loop:

Desired state is stored in the org CRDT (same as any other config)
Observed state is the exported config from the device
Reconciliation is the diff + clobber
Three-state tracking applies: the device config is confirmed (matches desired), pending (just clobbered, not yet verified), or drifted (doesn't match, needs clobber)

Config changes to managed devices are made in the org's CRDT, not on the device directly. The next clobber cycle applies the change. This means all config changes are auditable, reversible (roll back the CRDT), and propagated through gossip (all management nodes see the same desired state).

Security Benefits

Compromise Recovery

A compromised router gets its malicious configuration overwritten on the next clobber cycle. The attacker must either:

Compromise the FortrOS management service (protected by the overlay + conn_auth)
Modify the org's CRDT desired state (requires org membership + auth)
Re-compromise the device faster than the clobber cycle

This raises the cost of persistence significantly. A one-time exploit becomes a recurring re-exploitation requirement.

Drift Detection

Every clobber cycle that finds a diff is a potential compromise indicator. Expected drift (scheduled maintenance, firmware update) is distinguished from unexpected drift (unauthorized change). Unexpected drift triggers an alert.

Insider Protection

An insider with credentials to a managed device can make changes, but those changes are overwritten within minutes. The clobber loop's report shows what changed and when. Combined with the Topology Map, the admin can see which devices were modified and correlate with access logs.

Configuration Audit

The org's CRDT state tree is the single source of truth for all managed device configs. Want to know what every MikroTik router's firewall rules are? Query the CRDT. Want to know if any device has been modified since the last clobber? Check the reconciliation reports. No SSH-ing into each device individually.

How FortrOS Uses It

Network infrastructure as code: Router, switch, and AP configs live in the org CRDT. Changes propagate via gossip. The clobber loop enforces them.
Part of the monitoring map: Managed devices appear on the topology map alongside FortrOS nodes. Health, config drift, and management status are visible.
Defense in depth: Even if the overlay is the primary data path, the underlying physical network must be correctly configured. Managed infrastructure ensures it stays that way.
Supports the Device Obfuscation mission: In adversarial environments, managed routers are configured to support the transport profile (no DNS leaks, correct VLAN isolation, traffic shaping to match expected patterns).