Currently I am working on a project where I am going through and optimizing a large set of Access Control Lists (ACL) on a set of 5585 Firewalls. While going through each ACL I have noticed a few mistakes other engineers have made while configuring these rules. I have compiled a list of these common mistakes. The focus of this blog will be around ACLs on Cisco ASA’s; however these rules still apply to other devices as well.
Not Understanding the Data Flow
It is critical to understand how data flows through the network. I have seen on more than a few occasions where rules are included in an ACL that don’t make logical sense. A common example has to do with extended ACLs applied ingress on an edge-network interface. An engineer who doesn’t understand the data flow adds an ACL entry permitting a source address that does not live off the interface the ACL is applied. These rules will never be used because there isn’t ever a chance that legitimate traffic will be sourced outside its given subnet.
I should note that the ACLs I talk about here are not “BOGON” ACLs used in anti-spoofing on the outside edge of your network. These manually configured ACLs can provide static anti-spoofing protection against attacks that use known unused and untrusted address space. Commonly, these anti-spoofing ACLs are applied to ingress traffic at network boundaries as a component of a larger ACL. Anti-spoofing ACLs require regular monitoring because they can frequently change. Spoofing can be minimized in traffic that originates from the local network if you apply outbound ACLs that limit the traffic to valid local addresses.
On the opposite end of the spectrum, we have ACLs applied to transit interfaces; these are typical for an interface that caries WAN traffic. An engineer who doesn’t understand the data flow may forget to add a permit statement for a specific subnet, causing that traffic to be blocked. An example I’ve seen usually revolves around SSL VPN traffic. Many engineers forgot about the SSL VPN subnet because it isn’t tied to an interface and isn’t obvious in the configuration.
In general, having good documentation of your network can save you a major headache when trying to figure out the data flows and how they interact with ACLs
Not Looking Where the Rule is Placed in the Overall ACL
Beyond knowing how the data flows though the network, understanding how the ACL filters traffic is critical as well. ACLs filter in a top down fashion, and when there is a match the device follows that rule. This means that if a permit rule is placed below a deny rule that matches the same traffic, the traffic will be denied regardless of the permit rule below it.
This is where understanding the flow of the ACL is critical. Whenever a group of engineers start haphazardly adding rules we tend to see this mistake happen. By default, an ACL entry is added to the bottom of the list. An engineer who doesn’t read the whole ACL to determine where the new rule should be placed will most always run into issues. To move a rule, the command “line line-number” can be added after the ACL name or number. This will place the ACL on the corresponding line and push any ACL’s down the list.
Creating Redundant Rules or Objects
This mistake, unfortunately, can only be chocked up to laziness. Not checking to see if a rule or object already exists is the start of what always ends with what I would call a rat’s nest ACL. A common example is when there are a mixture of object oriented rules and non-object oriented rules. At a first glance an engineer doesn’t see the IP addresses they need to allow a data flow so they add it to the ACL, however all that need to do was look at the objects to see that their data flow is already allowed. This is a common scenario when troubleshooting an issue and someone suggests that maybe the firewall or router is blocking the traffic.
For ASA firewalls a good tool to check if a data flow is allowed is the packet tracer tool that is built into the ASA’s OS. It is a great tool for troubleshooting not only ACLs on the ASA but also NAT traversals and inspects as well. Check out the command reference here for more information: http://www.cisco.com/c/en/us/td/docs/security/asa/asa-command-reference/I-R/cmdref2/p1.html
On the same topic, adding a permit any any rule is also a common troubleshooting mistake engineers make. Depending on company policy adding a permit any any” rule to an ACL might work for troubleshooting purposes, however it should never be used as a permanent solution. Depending on where it is placed a “permit any any” negates the need for the ACL in the first place and is usually considered a major security breach. Using the packet tracer tool for troubleshooting and understanding the data flow is always the preferred method.
Not Following a Common Object Naming Convention
Solidifying a common object naming scheme is usually the first defense in stopping engineers from making the mistakes above. A good object naming convention should make each ACL entry read like a sentence. Engineers who do not follow a common naming convention will be at higher risk of creating redundant rules and contribute to the rats nest that will confuse future engineers. You should ask yourself, if someone new to your company saw your ACL entry would they understand the data flow it permits or denies?
Not Understanding Stateful vs Stateless Devices
Finally, the last common mistake I have seen engineers make is not understand if they are on a device that is stateful or stateless. A stateful device is a device that keeps a record of the data flows it allows in one direction so that it can identify and allow any return traffic. By default, most firewalls are stateful.
A stateless device is the opposite of a stateful device; it does not keep track of data flows. This means the engineer must explicitly allow the return traffic on any ACLs the return traffic may hit on the device. By default, most routers and switches are stateless, however inspection can be turned on, turning that device into a stateful device. Engineers who don’t recognize they are on a stateful device often add redundant rules to capture the return traffic, however these rules never get hit.ACL optimization can be a tedious task, however in today’s world where security is consistently being tested and scrutinized, a well written ACL is a must to quickly understanding what traffic is being allowed through your firewall, as well as identifying any unnecessary security holes.
Written By: Trevor Butler, LookingPoint Network Engineer - CCNP CMNA