What is an Any-Any Rule?
An Any-Any Rule is a firewall or access rule that covers all sources and all destinations at the same time, often all services too. That makes it the broadest possible rule in a rule base. Its effect depends on the action: as an allow rule it opens up a great deal at once, as a final block rule it forms a sound default-deny baseline. What is risky is mainly broad allow rules, because they undercut the principle of least privilege, enlarge the attack surface, and blur reporting. Any-Any rules usually start out as a stop-gap and then stay in the rule base by accident.
Any-Any Rule in detail
The term comes from classic firewall practice and describes a rule whose conditions are deliberately left open: any source, any destination, often any service too. In a Zscaler rule base, for example in ZIA's Cloud Firewall, such a rule is quick to set up and immediately affects a great deal of traffic. What matters is what the rule does: a broad allow opens things up across the board, while a broad block at the end of the rule base catches everything that no more specific rule has matched.
So an Any-Any Rule is not inherently bad, it depends on context. It becomes a problem when a broad allow stays in place permanently and nobody remembers what it was for. Position matters too: a broad rule near the top can override more specific rules below it, because the rule base works on a first-match basis.
Why Any-Any rules matter in Zscaler operations
Broad allow rules are the opposite of Zero Trust. For how any-to-any access feeds into the overall score as its own metric, see our video on the configuration score. If you want access tied closely to roles and actual need, a blanket Any-Any allow is hard to justify. For security, that means more open paths than anyone actively tracks. For operations, it means every troubleshooting case takes longer, because a broad rule affects many cases at once and can overlay other rules.
On the evidence side, Any-Any rules are a classic audit point. If you need to demonstrate under NIS2 or DORA that access and filtering policies follow least privilege, you have to explain or dismantle broad allow rules. The order of the process matters here: first make every Any-Any rule visible and assess it, then tighten each risky allow as an individual, justified, and approved change, rather than in one bulk action.
Common sources of error
- Broad allow as a stop-gap: a rule set up for a migration stays in place and permanently opens more than necessary.
- Wrong position: a broad rule near the top hides more specific rules below it, so they never apply.
- Deleting too hastily: removing a broad allow without a dependency check risks an outage.
- Default block confused with a risky rule: a final Any-Any block is intentional, a broad allow is not.
Any-Any rules in practice: what CentaurNexus contributes
CentaurNexus's Policy Rule Map displays the ZIA rule base graphically and visibly highlights Any-Any rules, so broad rules do not get lost in long lists. The analysis is read-only and changes nothing: every finding stays a suggestion, and every adjustment happens as an individual, traceable change, optionally approved under the four-eyes principle and logged in the append-only audit trail. That turns a diffuse collection of broad rules into a workable, justified process. The guide below shows step by step how such a rule review works: Finding and cleaning up unused Zscaler rules.
Related terms
Frequently asked questions about the Any-Any Rule
An Any-Any Rule covers all sources and all destinations at the same time, often all services too. That makes it the broadest possible form of a firewall or access rule. Its effect depends on the action: as an allow rule it opens up a great deal, as a final block rule it forms a sound default baseline.
That depends on the action and the position. A broad allow rule enlarges the attack surface and blurs reporting. An Any-Any block at the end of the rule base, by contrast, is the classic default-deny safeguard. What is critical above all is broad allow rules that nobody can justify any more.
Often under time pressure: during migrations, tests, or incidents, a broad rule goes in as a stop-gap and is never rolled back later. Convenience plays a part too, when a broad allow is faster than clean, narrow rules. That leaves legacy rules in place that obscure the original purpose.
Make them visible first, then assess them: is the rule an intentional default block or a risky broad allow? Broad allow rules are narrowed step by step, justified, and changed individually, ideally under the four-eyes principle and with a snapshot taken beforehand. That lowers the risk without a rework triggering new incidents.
Least privilege requires granting only as much access as necessary. A broad Any-Any allow works against that, because it opens things up across the board instead of granting access selectively. Audits under NIS2 or DORA therefore watch for rules like this: they are hard to justify and a classic finding in a rule base review.
- NIST SP 800-41 Rev. 1: Guidelines on Firewalls and Firewall Policy - csrc.nist.gov
- BSI IT-Grundschutz, Baustein NET.3.2 Firewall - bsi.bund.de/.../NET_3_2_Firewall
- Zscaler Help Portal: ZIA Cloud Firewall Policy - help.zscaler.com
Note: CentaurNexus is an independent product of SourcingBlox GmbH and not an offering of Zscaler, Inc. Product and brand names belong to their respective owners.