MonthlySecurity

Firewall Rule Review

16 items ·8 critical ·6 warn ·2 info

The OPNsense rule set is a living artefact: every change adds, removes, or moves a rule, and over time even a tidy ruleset picks up dead entries and accidental any/any passes. A monthly review catches the things that a quarterly audit would miss and gives the operator a small, predictable workload that is far easier to defend than a six-month backlog.

When to use

Run this checklist on the first business day of every month against every production OPNsense firewall. It is also the right starting point after any incident where rule-set behaviour is in scope, after any contractor or consultant session that touched the firewall, and after every upgrade as a regression check.

How to use

Export the current rule set from Firewall > Rules per interface and diff against the last review. Walk the list top to bottom, mark each item, and capture follow-ups in the change system. Any critical finding must be raised as a security ticket the same day.

Critical8 items

No rule on WAN, DMZ, or guest interfaces has source = any and destination = any with action = pass.
```
Firewall > Rules > WAN; sort by Source.
```
Rules are ordered most-specific-first; no specific pass rule is shadowed by a broader pass above it.
Logging is enabled on at least the final pass and final reject rule of each interface.
Block-private-networks and block-bogons rules are present and enabled on WAN.
```
Interfaces > WAN; confirm both toggles are on.
```
Alias utilisation: every alias referenced by a rule is still defined and points at the intended hosts or networks.
```
Firewall > Aliases; cross-check against rules.
```
Outbound rules from server / DMZ VLANs are deny-by-default with explicit allow rules for required destinations only.
Inter-VLAN rules between user and server networks follow deny-by-default with documented allow rules.
No pass rule permits an RFC1918 source on the WAN interface.

Warning6 items

Each rule has a meaningful description so the next operator can understand intent without context.
No rule references the `any` alias when a more specific alias is appropriate (e.g. management, dns_servers).
Rules with last-used > 90 days are reviewed; disable or remove after confirmation.
ICMP rules are limited to required types (typically echo-request, echo-reply, time-exceeded, destination-unreachable).
Floating rules are minimal, well documented, and use quick = apply immediately only when intended.
Each pass rule that allows traffic from a routable source has a matching log entry sample from the last 30 days.
```
Firewall > Log Files > Live View; filter by rule.
```

Info2 items

Schedule-based rules use named schedules that are still valid and reviewed quarterly.
Group-based rules (if used) reference an authoritative group (local DB or remote) and members are reviewed.