Firewall Security Controls Reference#

Overview#

This document is the authoritative reference for the firewall security controls implemented in opnDossier. These controls are independently developed by EvilBit Labs based on general cybersecurity best practices for network firewalls and are designed for OPNsense configurations. They are not affiliated with, endorsed by, or derived from any third-party benchmark organization.

For the broader compliance standards overview (including STIG and SANS), see Compliance Standards.

Three-State Check Pattern#

Each firewall compliance check returns one of three states:

• Compliant: The configuration meets the control requirement. No finding is emitted.
• Non-Compliant: The configuration does not meet the control requirement. A finding is emitted with remediation guidance.
• Unknown: The data needed to evaluate the control is not available in config.xml (OS-level setting or model gap). The check is skipped entirely to avoid false positives.

Controls Summary#

FIREWALL-001: SSH Warning Banner Configuration#

Description#

An SSH warning banner should be configured to display before authentication. Warning banners provide legal notice to users connecting to the system and can aid in the prosecution of unauthorized access attempts.

Rationale#

SSH warning banners serve two purposes: they inform authorized users of acceptable use policies, and they establish a legal basis for prosecution of intruders by demonstrating that notice was given. Many compliance frameworks require login banners on all management interfaces.

What opnDossier Checks#

Always returns Unknown. SSH banners are configured at the OS level in /etc/ssh/sshd_config (the Banner directive), which is not part of the OPNsense config.xml export. opnDossier cannot determine whether a banner is configured from the configuration file alone.

Recommended Action#

Configure the SSH warning banner:

1. Edit /etc/ssh/sshd_config on the OPNsense appliance
2. Set Banner /etc/issue.net
3. Create /etc/issue.net with an appropriate legal notice
4. Restart the SSH service

FIREWALL-002: Auto Configuration Backup#

Description#

Automatic configuration backup should be enabled to ensure configuration changes are preserved and can be restored in case of failure or misconfiguration.

Rationale#

Automatic backups protect against configuration loss from hardware failure, accidental changes, or security incidents. The OPNsense os-acb (AutoConfigBackup) plugin provides automated, versioned backups that can be restored quickly.

What opnDossier Checks#

Searches for the os-acb package in two locations:

1. The Packages list on the CommonDevice (case-insensitive match on Name against "os-acb" with Installed == true)
2. The System.Firmware.Plugins comma-separated string (splits on commas, trims whitespace, case-insensitive exact match against each entry)

If neither source contains the package, a non-compliant finding is emitted.

Recommended Action#

Install and enable AutoConfigBackup:

1. Navigate to System > Firmware > Plugins
2. Install the os-acb plugin
3. Configure backup settings in Services > Auto Config Backup

FIREWALL-003: Message of the Day#

Description#

The Message of the Day (MOTD) should be customized to provide legal notice and consent for monitoring to users who access the system console.

Rationale#

A custom MOTD provides a legal notice similar to the SSH banner but for console access. It informs users that the system is monitored and that unauthorized access is prohibited, supporting legal and compliance requirements.

What opnDossier Checks#

Always returns Unknown. The MOTD is an OS-level file (/etc/motd) that is not part of the OPNsense config.xml export. opnDossier cannot determine whether it has been customized from the configuration file alone.

Recommended Action#

Customize the MOTD:

1. SSH into the OPNsense appliance
2. Edit /etc/motd with an appropriate legal notice
3. Include language about authorized use, monitoring, and consent

FIREWALL-004: Hostname Configuration#

Description#

The device hostname should be changed from factory defaults to a meaningful, custom value for proper asset identification and management.

Rationale#

A custom hostname is essential for asset identification in environments with multiple network devices. Default hostnames make it difficult to distinguish devices in logs, monitoring systems, and network management tools.

What opnDossier Checks#

Reads System.Hostname from the CommonDevice and checks it against known factory defaults (case-insensitive):

• opnsense
• pfsense
• firewall
• localhost

An empty hostname is also treated as non-compliant. Any other value is considered compliant.

Recommended Action#

Set a custom hostname:

1. Navigate to System > General Setup
2. Change the hostname to a meaningful name following your organization's naming convention
3. Save and apply changes

FIREWALL-005: DNS Server Configuration#

Description#

DNS servers should be explicitly configured rather than relying on DHCP-assigned or unconfigured defaults.

Rationale#

Explicit DNS configuration ensures reliable and predictable name resolution. Without configured DNS servers, the firewall may use DHCP-assigned servers that could be controlled by an attacker, or name resolution may fail entirely, affecting firewall rules that reference hostnames.

What opnDossier Checks#

Checks whether System.DNSServers contains at least one entry. If the list is empty, a non-compliant finding is emitted.

Recommended Action#

Configure DNS servers:

1. Navigate to System > General Setup
2. Add at least one DNS server (e.g., your organization's internal DNS or a trusted resolver)
3. Uncheck "Allow DNS server list to be overridden by DHCP/PPP on WAN" if you want to enforce your configured servers
4. Save and apply changes

FIREWALL-006: IPv6 Disablement#

Description#

IPv6 should be disabled if the network does not require it. Leaving IPv6 enabled when unused expands the attack surface unnecessarily.

Rationale#

IPv6 introduces additional complexity and potential attack vectors (e.g., router advertisements, neighbor discovery, dual-stack vulnerabilities). If IPv6 is not actively used in your environment, disabling it reduces the attack surface and simplifies firewall rule management.

What opnDossier Checks#

Reads System.IPv6Allow from the CommonDevice. A finding is emitted when IPv6 is enabled (IPv6Allow == true), since the control recommends disabling it when not required.

Note: This is an advisory check. If your environment requires IPv6, this finding can be accepted as a risk.

Recommended Action#

Disable IPv6 if not required:

1. Navigate to System > Advanced > Networking
2. Uncheck "Allow IPv6"
3. Save and apply changes
4. Review firewall rules for any IPv6-specific entries that can be removed

FIREWALL-007: DNS Rebind Protection#

Description#

The Unbound DNS resolver should have a non-empty private-address list configured. This blocks DNS responses that resolve public domain names to private IP ranges, mitigating DNS rebinding attacks against internal services.

Rationale#

DNS rebinding attacks exploit browser same-origin policy by resolving a public domain to a private IP — for example, attacker.com resolving to 192.168.1.1 to target a router admin interface. Unbound's private-address directive blocks responses that fall inside user-declared private ranges, closing this attack vector. Environments using split-horizon DNS should scope private-address entries carefully, not disable the protection entirely.

What opnDossier Checks#

opnDossier parses the OPNsense Unbound MVC configuration from <OPNsense><unboundplus><advanced> and extracts the <privateaddress> field (CIDR ranges or bare IPs). Each entry is validated via netip.ParsePrefix/netip.ParseAddr; invalid entries are dropped with a conversion warning.

The check evaluates whether DNS rebind protection is configured:

• Pass: Unbound is enabled AND the MVC <privateaddress> element was configured AND the list contains at least one valid entry.
• Fail: Unbound is enabled AND the MVC <privateaddress> element was configured, but the list is empty (operator explicitly cleared it, or every entry failed CIDR/IP validation).
• Unknown: Any of (a) Unbound is disabled — the install may be using DNSMasq, which has its own rebind-protection mechanism; (b) the MVC <privateaddress> element was never configured — common on older installs or minimal setups that have not touched the Unbound advanced block.

A finding is emitted when the check fails (cr.Known && !cr.Result in internal/plugins/firewall/firewall.go) — i.e., when Unbound is active AND the element was configured AND the resulting list is empty.

Recommended Action#

Enable DNS rebind protection:

1. Navigate to Services > Unbound DNS > Advanced
2. Populate the Private networks list with the CIDR ranges that should never appear in public DNS responses (commonly 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and any internal public allocations)
3. Save and apply changes
4. Verify the behaviour by resolving a test hostname that would rebind to a private address — Unbound should refuse to return it

FIREWALL-008: HTTPS Web Management#

Description#

The web management interface must use HTTPS to encrypt management traffic and prevent credential interception.

Rationale#

HTTP transmits credentials and configuration data in cleartext, making it vulnerable to interception on the management network. HTTPS provides encryption and server authentication, protecting against man-in-the-middle attacks on the management interface.

What opnDossier Checks#

Reads System.WebGUI.Protocol from the CommonDevice and performs a case-insensitive comparison against "https". If the protocol is not HTTPS (e.g., HTTP or empty), a non-compliant finding is emitted.

Recommended Action#

Enable HTTPS for web management:

1. Navigate to System > Advanced > Admin Access
2. Set the protocol to HTTPS
3. Ensure a valid TLS certificate is configured (self-signed at minimum, CA-signed preferred)
4. Consider restricting the management interface to a dedicated management VLAN
5. Save and apply changes

Severity Levels#

Future Controls#

The following controls are planned for future releases, organized by security domain. They are not implemented in the current audit engine. For the full cross-standard view (including SANS and STIG), see Compliance Standards.

Management Plane Security#

Authentication and Access Control#

Firewall Rule Hygiene#

Network Segmentation#

Anti-Spoofing and Traffic Validation#

Encryption and TLS#

Logging and Monitoring#

Time Synchronization#

SNMP Security#

VPN Configuration#

NAT Security#

Service Hardening#

Change Management#

High Availability#

Configuration Inventory#

Note: Configuration inventory controls use Type: "inventory" and are excluded from compliance evaluation. They are rendered in a separate "Configuration Notes" section of audit reports and do not affect pass/fail compliance status.

References#

• General network security best practices
• Industry-standard firewall security guidelines
• OPNsense documentation and security recommendations
• Network infrastructure security frameworks