Documentation > Professional+ > Firewall Orchestration Engine
⭐ PRO+

Firewall Orchestration Engine

Server-side, multi-platform firewall rule generation. Builds UFW, firewalld, pf, ipfw, npf, Windows Firewall, and macOS socketfilterfw plans from a unified PortRule schema. Adds role assignment, fleet policy deployment, rule conflict detection, and compliance reporting on top of the open-source basics.

Overview

The Firewall Orchestration Engine generates per-platform firewall configurations server-side and ships them to the agent as deploy plans. The agent runs the plan via the generic apply_deployment_plan handler — no firewall business logic lives on the agent (only the read-only firewall_collector.py stays for status reporting). All seven supported flavors share a single PortRule schema with source restrictions, in/out direction, and action (allow/deny).

Open Source vs Professional+

  • Community Edition: enable / disable / restart / deploy plus add / remove role ports per host via backend/services/firewall_plan_builder.py
  • Professional+: source-restricted rules (CIDR), in/out direction, named-rule descriptions, in-engine validation
  • Professional+: fleet-wide deployment with platform / approval-status filters
  • Professional+: pre-deploy rule conflict detection (allow/deny mismatch, source shadowing, multiple distinct sources)
  • Professional+: fleet compliance report comparing assigned roles vs actual firewall state

Supported Firewall Flavors

A host's flavor is detected from platform + platform_release:

  • UFW — Ubuntu, Debian (default Linux fallback)
  • firewalld — RHEL, CentOS, Rocky, Alma, Oracle, Fedora, AmazonLinux
  • pf — OpenBSD, FreeBSD (writes /etc/pf.conf via deploy_files, pfctl -nf validates, pfctl -f loads)
  • ipfw — FreeBSD alternative (kldload + sysrc preamble, rule numbering from 100/+10)
  • npf — NetBSD (writes /etc/npf.conf, npfctl validate then reload)
  • Windows Firewallnetsh advfirewall, RDP 3389 always preserved, source uses remoteip=
  • macOS Application Firewallsocketfilterfw, app-based rather than port-based; port-only rules surface in unsupported

Fleet Policy Deployment

Apply a role-set to many hosts in a single call. Supply either explicit host_ids or a host_filter (platform / approval_status, ANDed). Hosts on platforms with no builder are skipped with a reason.

POST /api/v1/firewall/fleet/deploy
{
  "role_names": ["web-server", "ssh-from-jumpbox"],
  "host_filter": {"platform": "Linux", "approval_status": "approved"},
  "replace_existing": false
}

200 OK
{
  "role_names": [...],
  "queued_hosts": ["uuid1", "uuid2", ...],
  "skipped_hosts": [{"host_id": "uuid", "reason": "..."}],
  "message": "Resolved fleet deploy: 47 queued, 2 skipped (out of 49 matched)"
}

Rule Conflict Detection

Before any plan is queued, detect_rule_conflicts() walks the flattened rule list and surfaces inconsistent intent:

  • An open allow on the same (port, proto, direction) as a source-restricted allow (the open rule shadows the restricted one)
  • An allow and a deny on the same triple
  • Two distinct source CIDRs on the same triple

Identical rules listed twice are not reported — they just deduplicate.

Compliance Report

Compares each host's role-derived expected port set against what FirewallStatus.tcp_open_ports reports as actually open. A host is compliant iff it has a status row AND actual_ports ⊇ expected_ports.

GET /api/v1/firewall/compliance/report

{
  "total_hosts": 47,
  "compliant_hosts": 44,
  "noncompliant_hosts": 3,
  "entries": [
    {
      "host_id": "...",
      "fqdn": "web-12.prod",
      "compliant": false,
      "expected_ports": [22, 80, 443],
      "actual_ports":   [22, 443],
      "missing_ports":  [80],
      "extra_ports":    []
    }
  ]
}

Lockout Protection

Every build_*_rules call always re-permits the management ports first — SSH (22), DNS (53), DHCP (67), plus any agent communication ports passed in host_info["agent_ports"], plus RDP (3389) on Windows. Removal builders skip preserved ports silently and surface them in skipped_preserved_ports so the operator can audit. This is non-bypassable; the engine refuses to emit a plan that would lock the agent out.

Feature Codes

  • firewall_role_define — create / edit roles
  • firewall_role_assign — assign roles to hosts
  • firewall_deploy — per-host or fleet apply
  • firewall_status — per-host status read
  • firewall_compliance_check — fleet compliance report

Architecture

The engine is a Cython-compiled binary (firewall_orchestration_engine.so) loaded by the open-source server's module_loader at startup. It exports the same get_module_info() + get_firewall_orchestration_router() contract as the other Pro+ modules. The agent retains zero firewall business logic after Phase 3 ships, except for the read-only firewall_collector.py which reports current state back.