Rule cleanup and hygiene — the discipline that keeps the ruleset maintainable

Cleanup is the part of firewall operations nobody schedules. The operator who is asked “when is the next cleanup?” often says “we should do one” — and the cleanup is deferred until the next incident reveals rot. Cleanup is the discipline that converts the rot into a maintainable ruleset. Without cleanup, the ruleset grows; without a schedule, the cleanup is never done.

This lesson covers rule cleanup as a recurring operation: dead-rule removal, alias cleanup, group cleanup, schedule cleanup. The procedure that turns a maintenance task into a change-managed operation, and the trap of cleanup that turns into feature work.

The four cleanup operations

Cleanup is not one operation. It is four distinct operations, each with its own scope, its own evidence, and its own rollback path.

Dead-rule removal

Rules that have not matched in 60-90 days. The removal procedure is the safe rule change procedure applied to a batch of dead rules at once.

The batch is important. A single-rule removal has the same overhead as a batch removal; batching amortises the overhead. The operator groups dead rules by interface, builds a single change ticket per interface, peer-reviews the batch, and applies the batch as one change.

Alias cleanup

Aliases that are no longer used by any rule. The cleanup removes the alias and the unused entries in aliases that are still referenced.

The alias cleanup is the most error-prone of the four. Removing an alias that is still referenced by a rule produces a rule that fails to compile; PF refuses to load the ruleset; the operator loses all filtering until the alias is restored. The disciplined alias cleanup first checks every alias for references (in rules, in NAT, in schedules), confirms the alias is unreferenced, then removes it.

$ configctl filter show | grep -oE '<[a-z_]+>' | sort -u | wc -l && configctl filter show | grep -oE '<[a-z_]+>' | sort | uniq -c | sort -rn | head -10

87
142 <operator_hosts>
98 <dns_servers>
76 <noc_subnets>
54 <backup_targets>
41 <dmz_servers>
29 <dev_subnets>
18 <partner_ranges>
12 <guest_subnets>
5 <admin_jump>
2 <legacy_ftp>

Group cleanup

Groups (alias folders in the GUI) that contain aliases which have all been removed. The cleanup removes the empty groups.

Group cleanup is the easiest operation. Empty groups do not affect filtering; removing them is purely cosmetic. The cleanup is still change-managed (a peer-reviewed ticket, before/after evidence), but the risk is low.

Schedule cleanup

Schedules (time-based rules) that have expired or are no longer referenced. The cleanup removes the schedule and any rules that depended on it.

Schedule cleanup is similar to alias cleanup. Removing a schedule referenced by a rule breaks the rule. The disciplined schedule cleanup first checks every schedule for references, confirms the schedule is unreferenced, then removes it.

The cleanup procedure

Cleanup is a change. Cleanup gets the change procedure. The cleanup procedure is the same as the safe rule change procedure, scaled to a batch:

1. Identify the cleanup. The list of rules, aliases, groups, schedules to remove. The list is produced by the monthly hygiene review.
2. Take a backup. Configuration backup, immediately before the cleanup.
3. Peer-review the cleanup list. The peer reviews each item — is the rule really dead? Is the alias really unreferenced? Is the schedule really expired?
4. Verify the recovery path. Console access, break-glass SSH, backup restore.
5. Apply the cleanup as a batch. Single change, single ruleset reload. The batch is one ticket.
6. Test from a second session. Verify the traffic patterns that should still work still work. Verify the traffic patterns that should be blocked are still blocked.
7. Document the cleanup. Ticket with the list of removed items, peer reviewer, before/after evidence.

The cleanup procedure differs from a single-rule change in three ways:

• Batching. Many rules removed in one change. The operator groups by interface, by category, by cleanup type.
• Reference checking. Aliases and schedules must be checked for references before removal. Dead rules and empty groups do not.
• Verification scope. The verification covers all production traffic patterns, not just the traffic the change directly affected. The cleanup is broad; the verification must be broad.

The trap of cleanup that turns into feature work

The cleanup is supposed to be removal. The cleanup is not supposed to be addition. The cleanup is not supposed to be a refactor of the rules into a new structure. The cleanup is not supposed to be a reorganisation of aliases into new groups.

The trap: the operator opens the ruleset to remove dead rules and notices that three rules could be combined into one, that two aliases could be merged, that the ruleset would be cleaner with a different structure. The operator makes the cleanup bigger — adds the combination, the merge, the reorganisation. The change is no longer a cleanup; it is a refactor. The peer reviewer who signed off on a cleanup is now reviewing a refactor.

The cleanup that turns into feature work is dangerous. The peer reviewer signed off on a different change; the rollback procedure documented is for the smaller change; the verification covers the smaller change. The expanded change has no peer review, no rollback, no verification.

The disciplined operator resists the trap. The cleanup is removal. The combination, the merge, the reorganisation go on a separate ticket; they are scheduled for a future change; they get their own peer review, their own rollback, their own verification.

Verifying post-cleanup behaviour

The verification after cleanup has three parts:

1. Configuration verification. pfctl -s rules matches the expected post-cleanup state. The removed rules are absent; the kept rules are unchanged. The alias and schedule references resolve correctly.
2. State verification. The state table returns to its expected size. New connections are evaluated against the post-cleanup ruleset.
3. Behaviour verification. Each production traffic pattern (each rule category, each alias-referenced service, each schedule-bound flow) behaves as before. The operator runs a checklist of representative flows and confirms each.

The behaviour verification is the most labour-intensive but the most important. The configuration can look correct while the behaviour is wrong — a misordered rule that compiles but produces wrong state, an alias removal that compiled but is referenced elsewhere, a schedule removal that compiled but leaves a stale reference. The behaviour verification catches what configuration verification misses.

Summary

• Four cleanup operations: dead-rule removal, alias cleanup, group cleanup, schedule cleanup. Each has its own scope and its own risk.
• Alias and schedule cleanup must check references before removal. A reference left dangling causes the ruleset to fail to compile.
• Cleanup is a change. The procedure is the safe rule change procedure scaled to a batch: identify, backup, peer-review, verify recovery, apply as a batch, test, document.
• The trap of cleanup that turns into feature work: scope creep that turns a removal into a refactor. The disciplined operator resists; the refactor gets its own ticket.
• Verification covers configuration, state, and behaviour. Behaviour verification is the most labour-intensive but the most important.