Auditing an ACL for the permit any that should not be there

Access Control Lists are the first line of defense in network security, yet many production networks harbor permit any rules that should never have been deployed. These overly permissive statements often exist as temporary measures, legacy configurations, or the result of troubleshooting shortcuts that were never reversed. A systematic ACL audit can uncover these gaps and significantly reduce your attack surface.

Why permit any Rules Are Dangerous

A permit any statement allows all traffic matching the source and destination criteria to pass without restriction. When applied to sensitive interfaces or between security zones, permit any effectively disables access control for that traffic flow. The risk is especially acute when combined with any source or any destination wildcards, creating a rule that permits all protocols, all ports, and all hosts.

Even seemingly narrow permit any rules deserve scrutiny. For example, permit any any log might appear to serve a monitoring purpose, but it still allows unrestricted traffic. Similarly, permit tcp any any eq 443 with a destination of any permits all HTTPS traffic regardless of source or destination host, which may be intentional but often represents incomplete policy definition.

How to Audit Your ACLs

Start by exporting all ACLs from your network devices. On Cisco IOS, use show access-lists and show ip access-lists to capture the full policy. For each ACL, document its purpose, the interface where it is applied, and the direction (inbound or outbound). Then search for these red flags:

• →permit any any (all traffic, all protocols)
• →permit ip any any (all IP traffic)
• →permit any any log (unrestricted traffic with logging)
• →permit tcp any any (all TCP traffic)
• →permit any eq PORT (any source to a specific port)
• →permit host X any (a specific host to any destination)
• →permit any any range PORT1 PORT2 (unrestricted port ranges)

For each permit any rule found, verify whether it aligns with documented business requirements. Ask: Is this rule necessary? Does it apply to the correct interface? Could it be replaced with a more specific source, destination, or protocol? Document the business justification for every permissive rule. If no justification exists, the rule should be removed or tightened.

Tightening Overly Permissive Rules

Replace permit any statements with specific addresses or subnets whenever possible. This requires understanding the actual traffic requirements, which often means reviewing firewall logs, NetFlow data, or application documentation.

! BAD: Permits all traffic from any source
access-list 101 permit ip any any

! BETTER: Permits only the required subnet
access-list 101 permit ip 192.168.10.0 0.0.0.255 10.0.0.0 0.255.255.255

! BEST: Permits specific hosts and protocols
access-list 101 permit tcp 192.168.10.5 255.255.255.255 10.1.1.0 0.0.0.255 eq 443
access-list 101 permit tcp 192.168.10.6 255.255.255.255 10.1.1.0 0.0.0.255 eq 443

When defining specific subnets, use the correct wildcard mask. A wildcard mask of 0.0.0.0 matches a single host, while 0.0.0.255 matches a /24 network. Misunderstanding wildcard masks is a common source of unintended permit any behavior. Each bit set to 1 in the wildcard mask is treated as don't care, so 0.255.255.255 effectively permits any destination in the 10.0.0.0 divided by 8 space.

Documentation and Change Control

After identifying and tightening permit any rules, document the changes and implement them through your change control process. Include the business justification, the old rule, the new rule, and the expected impact. Test in a lab or staging environment first. Monitor the updated ACL for denied traffic that might indicate overly restrictive rules, then refine as needed.

Schedule quarterly ACL audits as part of your security posture maintenance. Many organizations find that permit any rules creep back in during emergency changes or vendor implementations. Automated auditing tools can flag new permit any statements for review before they reach production.