How to Create and Manage Access-Control Lists on Cisco ASA and PIX Firewalls
Access Control Lists (ACLs) are sequential lists of permit and deny conditions applied to traffic flows on a device interface. ACLs are based on various criteria including protocol type source IP address, destination IP address, source port number, and/or destination port number.
ACLs can be used to filter traffic for various purposes including security, monitoring, route selection, and network address translation. ACLs are comprised of one or more Access Control Entries (ACEs). Each ACE is an individual line within an ACL.
ACLs on a Cisco ASA Security Appliance (or a PIX firewall running software version 7.x or later) are similar to those on a Cisco router, but not identical. Firewalls use real subnet masks instead of the inverted mask used on a router. ACLs on a firewall are always named instead of numbered and are assumed to be an extended list.
The syntax of an ACE is relatively straight-forward:
Ciscoasa(config)#access-list name [line number] [extended] {permit | deny} protocol
source_IP_address source_netmask [operator source_port] destination_IP_address
destination_netmask [operator destination_port] [log [[disable | default] | [level]] [interval seconds]] [time-range name] [inactive]
Here's an example:
asa(config)# access-list demo1 permit tcp 10.1.0.0 255.255.255.0 any eq www
asa(config)# access-list demo1 permit tcp 10.1.0.0 255.255.255.0 any eq 443
asa(config)# show access-list demo1
access-list demo1; 2 elements
access-list demo1 line 1 extended permit tcp 10.1.0.0 255.255.255.0 any eq www
access-list demo1 line 2 extended permit tcp 10.1.0.0 255.255.255.0 any eq https
In the above example, an ACL called "demo1" is created in which the first ACE permits TCP traffic originating on the 10.1.0.0 subnet to go to any destination IP address with the destination port of 80 (www). In the second ACE, the same traffic flow is permitted for destination port 443. Notice in the output of the show access-list that line numbers are displayed and the extended parameter is also included, even though neither was included in the configuration statements.
You can deactivate an ACE without deleting it by appending the inactive option to the end of the line.
As with Cisco routers, there is an implicit "deny any" at the end of every ACL. Any traffic that is not explicitly permitted is implicitly denied.
**Editing ACLs and ACEs**
New ACEs are appended to the end of the ACL. If you want, however, to insert the new ACE at a particular location within the ACL, you can add the line number parameter to the ACE:
asa04(config)# access-list demo1 line 1 deny tcp host 10.1.0.2 any eq www
asa04(config)# show access-list demo1
access-list demo1; 3 elements
access-list demo1 line 1 extended deny tcp host 10.1.0.2 any eq www
access-list demo1 line 2 extended permit tcp 10.1.0.0 255.255.255.0 any eq www
access-list demo1 line 3 extended permit tcp 10.1.0.0 255.255.255.0 any eq https
Notice in the first line of the example above that an ACE is added at line one in the ACL. Notice in the output from the show access-list demo1 command that the new entry is added in the first position in the ACL and the former first entry becomes line number two.
You can remove an ACE from an ACL by preceding the ACE configuration statement with the modifier no, as in the following example:
Asa04(config)#no access-list demo1 deny tcp host 10.10.2 any eq www
In my next article, I'll show you how to use time-ranges to apply access-control lists only at certain times and/or on certain days. I'll also show you how to use object-groups with access-control lists to simplify ACL management by grouping similar components such as IP addresses or protocols together.
<< Home