Hardening checklist overview — frameworks, scope, and the discipline of defence in depth

Hardening is the discipline of making the firewall harder to compromise, easier to monitor, and more predictable in failure. Hardening is not a one-time project; it is an ongoing discipline applied at provisioning, at every change, and at every review. Hardening is also not a checklist of arbitrary settings; it is a structured framework that maps each setting to a threat, a control, and an evidence trail.

This lesson covers the hardening framework: the three planes (management, control, data), the baselines (CIS and NIST), the discipline of defence in depth, and the trap of hardening theatre.

The three planes

The OPNsense firewall has three planes, each with its own hardening concerns:

1. Management plane. The plane the operator uses to configure and monitor the firewall. The GUI (HTTPS on port 443), the SSH service (port 22), the console (serial, BMC SOL, KVM-over-IP), the API (REST on port 443, authenticated with an API key/secret pair over HTTP Basic), the audit log.
2. Control plane. The plane the firewall uses to learn routes, exchange state, advertise services. The routing protocols (BGP, OSPF), the high-availability protocols (CARP, pfsync), the dynamic routing advertisements, the DNS, the NTP.
3. Data plane. The plane the firewall uses to forward user traffic. The firewall rules, NAT, IDS/IPS, traffic shaping, VLAN tagging, the wire-level encapsulation.

Each plane has different threats, different controls, and different evidence. A hardening that addresses only the data plane (firewall rules) leaves the management plane exposed (anyone can reach the GUI from anywhere). A hardening that addresses only the management plane leaves the data plane exposed (the rules allow everything). Production hardening addresses all three.

$ pfctl -s rules 2>/dev/null | wc -l && sockstat -l -P tcp | grep -E ':22|:443|:80|:53' | head -10

847
root sshd       1234 4 tcp4  192.0.2.1:22      *:*
root lighttpd   1456 5 tcp4  *:443              *:*
root lighttpd   1456 6 tcp4  *:80               *:*
root unbound    1678 8 tcp4  127.0.0.1:53      *:*
root unbound    1678 9 udp4  127.0.0.1:53      *:*

CIS and NIST baselines

Two external baselines are commonly applied to OPNsense deployments: CIS Benchmarks and NIST Special Publications.

CIS Benchmarks

The Center for Internet Security publishes community-developed benchmarks for many systems. The OPNsense benchmark is a checklist of recommended settings: services to disable, ports to close, authentication requirements, logging posture. The benchmark is updated as the OPNsense project evolves; the operator consults the latest version when planning a hardening pass.

The CIS benchmark is a starting point, not a destination. The benchmark’s recommendations are general; the operator’s environment is specific. The operator applies the benchmark, then adjusts for the environment — some recommendations may not apply, some may need to be tightened, some may need supplementary controls.

NIST SP 800-41r1

NIST Special Publication 800-41r1, “Guidelines on Firewalls and Firewall Policy”, is the canonical reference for firewall policy. The document covers policy design, rule review, logging, and architecture. The 800-41r1 recommendations are more architectural than the CIS Benchmarks; the document is the reference for why the firewall is configured the way it is, not just what the configuration should be.

A hardening pass that follows both the CIS Benchmarks and the NIST 800-41r1 guidelines covers most of the configuration-level hardening concerns. The remainder — operational hardening, organisational hardening — is covered by other frameworks (ITIL for change management, ISO 27001 for information security management, SOC 2 for service organisations).

Defence in depth vs hardening theatre

Defence in depth is the discipline of independent layers, each catching what the previous layer missed. A firewall with defence in depth has multiple controls that fail independently: even if one control is bypassed, the next control catches the attack.

Hardening theatre is the discipline of checkboxes that look secure but produce no security. The operator who disables ICMP for “hardening” has checked a box but has broken Path MTU Discovery; the firewall looks hardened but is actually less reliable. The operator who logs every dropped packet has checked a box but has filled the disk; the firewall looks audited but cannot keep logs. The operator who enables every Suricata rule has checked a box but has filled the state table; the firewall looks protected but cannot pass traffic.

The difference between defence in depth and hardening theatre is the operator’s ability to name the threat each control addresses and the evidence each control produces. The control that has a threat and an evidence trail is defence in depth. The control that has neither is theatre.

What hardening is not

Hardening is not the same as compliance. A firewall can be compliant (it meets the auditor’s checklist) without being hardened (it has controls that match the threats). The compliance audit verifies that the configuration matches the documented baseline; the hardening verification checks that the baseline addresses the actual threats.

Hardening is not the same as lockdown. A lockdown removes features to reduce the attack surface; hardening configures features to be secure in their default state. The lockdown that disables the API to “harden” the firewall has removed a feature the operator uses; the hardening that puts the API behind source restrictions and authentication has secured the feature without removing it.

Hardening is not a substitute for monitoring. A hardened firewall that is not monitored is a hardened firewall whose compromises are not detected. The hardening provides the controls; the monitoring provides the evidence the controls are working.

Summary

• Three planes: management (operator access), control (routing, HA, services), data (user traffic). Each has its own threats and controls.
• Two external baselines: CIS Benchmarks (configuration checklist) and NIST 800-41r1 (architectural reference). Both are starting points, not destinations.
• Defence in depth is independent layers; hardening theatre is checkboxes that look secure but produce no security.
• Hardening is not compliance, not lockdown, not a substitute for monitoring. Hardening is a discipline applied to the change process, not a one-time project.