Understanding ASA Access-Lists & Object-Groups

In this blog I want to cover understanding access-control lists (ACLs) on the Cisco ASA & different types of object groups for ACLs. First lets take a brief dive into the different ACL types relating to the ASA:


Extended ACL = used by the unit to permit/deny traffic through the device, and can match via many features, including service policies, AAA rules, DAP policies, VPN group, & Botnet traffic filtering.

Standard ACL = filter traffic by using the destination address of the pakcets only & can be used in route maps/VPN filters.

Ethertype ACL = apply to non-IP L2 traffic on bridge group member interfaces. Permit/deny based on EtherType value in L2 packet.

Webtype ACL = filter clientless TLS VPN traffic.


Note that ASA interface ACLs work in both routed & transparent modes. Here are some prime examples from Cisco:


Next, it is important to know that interface access rules control only transit traffic through the ASA unit. If interface access rules are not applied to an interface, then ASA will operate using the default access policy. The defaults include:

  • Connections arriving on an interface that are routed to interfaces with a lower security level than the incoming (ingress/receiving) interface are automatically permitted.

  • Connections arriving on an interface that are routed to interfaces with a high security level interface are automatically denied.


Here are a few of Cisco's recommendations for implementing Interface ACLs:

  • Consider applying interface access rules on all interfaces and permitting only the minimal required set of services.

  • Consider applying interface access rules on all interfaces and permitting only the minimal required set of services.

  • It is recommended that you place the most specific rules (that is, rules that govern specific hosts or services) toward the top of the ruleset

  • All interface access lists have implicit deny-all at the end of the list.

  • Using objects/object groups in the access rules makes the size of the ACLs much smaller in terms of access rules used.

  • Typically, you should consider using descriptive names (descriptive of their purposes) for the ACLs that you configure.

  • Decommission old networks if not needed; better management and removing those access rules that are not needed anymore


**NOTE: Cisco ASA appliance has no hardcoded limit on the number of access rules used in an ACL. The limit is based on the amount of memory that is available on the security appliance.**


Now I will breakdown Global ACLs & ACL usage for Stateful filtering.


Once a global ACL is defined, all default interface implicit rules are removed. This includes the permit traffic from high security level to lower security level interface.


Global ACL Benefits:

  • Using just a single global ACL instead of several interface ACLs make the overall configuration on the Cisco ASA appliance much simpler and easier to monitor, edit or update.

  • Global ACL and all the access rules included in it apply to all interfaces on the Cisco ASA appliance.

  • Once the global access rules are configured, they are not replicated on each interface, so they save memory space on the Cisco ASA appliance.

  • Global access rules provide additional flexibility in defining security policies on the Cisco ASA appliance, because you do not need to specify which interface a packet comes in on, as long as it matches the source and destination IP addresses.

  • When migrating to Cisco ASA appliance from another vendor firewall, you can maintain a global access rule policy without any need to apply specific access rules on each interface, thus eliminating any complexity in the migration process.

Global ACL Limitations:

  • Global access rules apply only to inbound traffic.

  • Global access rules cannot ideally cover all restrictions that you might have.

It is important to understand the ASA order of operations to match access rules:

  • When only interface ACLs are configured

  • Interface ACLs

  • Default implicit deny

  • When interface AND global policies are configured

  • Interface ACLs

  • For any BVI ACLs, BVI ACLs

  • Global ACLs if no match is found against interface ACLs

  • Default implicit deny

Next let's talk about ACL usage for Stateful Filtering. In regard to stateful filtering when ACLs are created they only need to permit the initial packet of a network application if the unit statefully inspects that application. This then means that interface access rules do not have to consider these conditions:

  • Any traffic flowing in the reverse direction of that connection: Because these packets belong to the same flow, the Cisco ASA automatically permits them if they match the properties that are expected from them by the connection table.

  • Any additional connections or flows that this application may establish: Because the Cisco ASA is application-aware, it automatically permits any additional connections of the same application session if the initial packet of the session is permitted.

The last topic I want to cover in this post are object-groups for ACLs. Object-groups allow us to essentially group objects. Objects can be a collection of IP addresses, network ranges, ports, etc. The main benefit here is that object-groups make ACLs smaller & typically easier to read/reverse engineer. Here is a list of the different types of object-groups we can configure on an ASA:

  • icmp-type = group of ICMP types, such as echo-reply

  • network = group of hosts or ranges

  • protocol = group of protocols, such as TCP

  • security = specify identity attributes

  • service = group of TCP/UDP ports

  • user = group of users which could be used for identity firewall

Configuring object-groups is pretty straight forward. Simply decide the type & configure to meet your needs:


Verify configured ACLs & Object-Groups:

#show object-group
#show access-list 
#show object-group <type>
#show access-list <name>

Now we both have a better understanding for Cisco ASA ACLs & Object-Groups, Cheers!

0 comments

Recent Posts

See All

Understanding ASA AnyConnect Webdeploy

In this post I want to cover the components & general understanding of how the ASA AnyConnect (AC) Webdeploy process works. First, it is important to understand that the AnyConnect client on an end no

Configuring & Upgrading ASA HA - Active/Standby

"The What?" - In this post I will cover ASA HA configuration for an Active/Standby deployment & briefly touch on an upgrade approach. Before diving in, if you want to gain a better understanding of A

Configuring ASA NAT

"The What?" - I want to breakdown network access translation (NAT) on the ASA. It is important to understand that NAT is processed by the rule order & section. Note that in both Section 1 & 3 you can