A firewall review finds an 'any source / any destination / allow' rule near the top of the policy. What's the issue and fix?
Short answer
Because firewalls evaluate rules top-down, a broad any/any allow near the top short-circuits every rule below it and permits all traffic — the firewall effectively stops enforcing anything. Replace it with explicit least-privilege rules for the flows actually needed, ordered so specific allows and denies take effect, ending in a default deny. Calling it efficient is wrong, moving it to the bottom can still shadow the default deny, and renaming changes nothing about what it permits.
Finding an any → any → allow rule near the top of a firewall policy is finding a firewall that, for all practical purposes, isn't filtering anything. The fix is to remove it and rebuild around least privilege with correct ordering.
Why a top any/any allow breaks everything
Firewalls evaluate rules top-down, first-match-wins. The first rule that matches a packet decides its fate, and evaluation stops there. A rule matching any source to any destination matches every packet — so it fires before any of the carefully crafted deny or scoped-allow rules below it ever get a chance. Those lower rules become shadowed: present in the config, but dead. The result is an implicit "permit all," which defeats the entire purpose of the device and typically violates baselines like NIST SP 800-41 and the CIS Controls.
The correct fix
Rebuild on default-deny, least-privilege principles:
- Inventory the flows that are genuinely required (source, destination, port, protocol) — use connection logs/NetFlow so you don't break production.
- Write explicit, narrowly scoped allow rules for exactly those flows.
- Order them so specific rules precede general ones, and place a default deny (with logging) at the bottom to catch everything else.
- Validate, then remove the any/any rule.
Why the distractors are wrong
- "It's efficient and fine" mistakes "matches fast" for "secure." It's efficient at allowing attacks.
- Moving it to the bottom is still dangerous: it now shadows the default deny, re-permitting everything the explicit rules didn't already allow. The any/any allow simply must be deleted, not relocated.
- Renaming is cosmetic — the packet-matching behavior is identical.
The interviewer wants to see that you understand evaluation order as a security control, can migrate to least privilege without an outage, and know that a clean policy ends in default-deny rather than a blanket allow.
Likely follow-ups
- Why does first-match, top-down evaluation make rule ordering a security control?
- How would you safely replace the any/any rule without an outage — what telemetry do you need first?
- What belongs at the very bottom of a well-formed policy, and why log it?