Eliminate Any-Any Firewall Rules and Move to Least-Privilege Rulesets

Every firewall audit finds them: rules with any as the source, any as the destination, or any as the service — often all three. They accumulate for predictable reasons: an application "didn't work" and someone opened everything to make the ticket go away, a vendor demanded broad access during an install and it was never tightened, or a temporary troubleshooting rule became permanent. Each permissive rule quietly converts your firewall from a security control into an expensive router. Removing them is unglamorous work, but it directly determines how far an attacker can move once inside.

Why any-any rules are dangerous

• They defeat segmentation: a single any-any rule between zones means the zones are effectively one network.
• They hide compromise: when everything is allowed, malicious traffic generates no denies and no alerts.
• They break compliance: PCI DSS, ISO 27001, and most frameworks explicitly require documented business justification for every rule — any has no justification by definition.
• They compound over time: broad rules mask which narrow rules would actually be needed, making every future cleanup harder.

Audit phase — build the evidence first

• Export the full ruleset and flag every rule containing any in source, destination, or service, plus disabled rules, expired rules, and rules with zero hits.
• Enable hit counters and logging on the flagged rules and collect data for a full business cycle — at least 30 days, ideally covering month-end processing, since some legitimate flows only occur monthly or quarterly.
• From the logs, extract the real traffic matrix: which sources actually talk to which destinations on which ports. This becomes the specification for the replacement rules.
• Vendor tools (FortiGate policy analytics, Palo Alto Policy Optimizer, Cisco Secure Firewall analytics) and third-party firewall audit tools automate much of this analysis.

Remediation approach

• Insert specific replacement rules above the permissive rule, modeled on observed traffic. Traffic migrates to the new rules; the hit counter on the old rule drops.
• When the permissive rule's hit count approaches zero, disable it — do not delete yet. Leave it disabled through one more business cycle as a rollback path, then delete.
• Work in small batches with change control. One rule migration per change window at first; speed comes with confidence.
• Require an owner, a business justification, and an expiry/review date for every new rule going forward — cleanup without a rule lifecycle policy just resets the clock.

Common pitfalls

• Backup, monitoring, and patching systems legitimately talk to almost everything — give them properly scoped rules early or they will generate most of your deny noise.
• Watch for asymmetric flows and return traffic assumptions, especially around NAT and dynamic ports; passive FTP and legacy RPC services are classic sources of surprise breakage.
• Do not forget the implicit rules: some platforms ship with permissive default policies or built-in allow rules that never appear in the visible ruleset.

The end state is simple to describe and powerful in practice: every rule has a documented purpose, an owner, and the narrowest scope that satisfies it — and the final rule in the policy is an explicit, logged deny-all.