Cisco ASA Access Lists Concepts and Configuration
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Overview
For those just getting into the network security arena or into Cisco network security specifically, it can be a little interesting to wrap the mind around all the different technologies and features that can be used to secure the network. Along with these different tools comes a great amount of control that can be used to secure the intended target network (or networks). Of course, like anything else, it is easy to misconfigure a network security device; however, the difference between misconfiguring a router and a network security firewall is risk. Although the effects of misconfiguring a router can be felt by many, it typically affects the use of an authorized network; the misconfiguration of a network firewall can affect the unauthorized use of a private network, which greatly increases risk. This is what makes the correct configuration of these devices even more important.
The purpose of this article is to review Cisco’s Adaptive Security Appliance (ASA) implementation of access control lists (ACL or access list). This article covers ASA access list types, what they control, and a basic review of what the configuration syntax is to use them.
ASA ACL Types
Because many of the people who transition into Cisco network security have some amount of router experience, much of the review of available ASA ACL types will sound familiar. There are some differences, though; so, pay attention to the little things.
Standard ACLs
Unlike on other platforms, the ASA does not support the use of standard ACLs for controlling traffic. They are used only in some limited Open Shortest Path First (OSPF) configurations.
Extended ACLs
The majority of ACLs that will most likely be implemented on an ASA are using the extended ACL type. As with other platforms, the extended ACL is used to specify both source and destination and can include information about the specific protocol being matched.
Note that when you are configuring an ASA the ASA does not, by default (implicit rule), allow traffic to flow from a lower-security interface to a higher-security interface. Unless a specific extended ACL is configured, no traffic can flow in this direction (although it is allowed in the other direction). The exception to this is when the traffic is returning from a connection established within the higher-security interface, but this is valid only when the traffic protocol is TCP or UDP. (Internet Control Message Protocol [ICMP] requires a defined rule for both outgoing and returning traffic.)
EtherType ACLs
EtherType ACLs are used to control traffic that matches a specific EtherType. Note that when configuring an EtherType ACL there is an implicit deny attached. This EtherType ACL statement does not affect IP traffic that was already allowed through an extended ACL.
ASA ACL Configuration
Because the majority of ASA ACL configurations are going to be using an extended ACL type, this section focuses on the configuration of this type and shows an example of how they can be used to control some basic traffic. Table 1 shows the commands required to set up an extended ACL.
Table 1 - Extended ACL Configuration
1 |
Enter privileged EXEC mode. |
asa>enable |
2 |
Enter global configuration mode. |
asa#configure terminal |
3 |
Create and configure an extended ACL entry(ACE) – Repeat as needed. |
asa(config)#access-list acl-name extended {deny | permit} {protocol-name | protocol-number} {any | host source-ip-address | source-ip-address source-netmask} {any | host destination-ip-address | destination-ip-address destination-netmask} [operator port [port]] |
4 |
Apply the ACL to the appropriate interface. |
asa(config)#access-group acl-name {in | out} interface interface-name |
ASA ACL Configuration Example
To clarify the configuration of an extended ACL, this section goes over an example of how they can be used to control traffic, along with their interaction with implicit ACL rules.
The purpose of the sample configuration is to allow all IP (including ICMP) traffic to be allowed from IP 172.16.1.10, which currently resides off of the Left interface to IP 192.168.1.100, which currently resides off of the Right interface; this is shown in Figure 1.
)
Figure 1 ASA ACL Topology Example
An important thing to keep in mind is the current configuration of the security levels. Remember that the traffic going from a higher-security level to a lower-security level is permitted by default. The steps shown in Table 2 include all the steps that are required to put this ASA into this configuration.
1 |
Enter privileged EXEC mode. |
asa>enable |
2 |
Enter global configuration mode. |
asa#configure terminal |
3 |
Enter interface configuration mode. |
asa(config)#interface e0 |
4 |
Configure an interface IP address. |
asa(config-if)#ip address 172.16.1.1 255.255.255.0 |
5 |
Configure an interface name. |
asa(config-if)#nameif Left |
6 |
Configure an interface security level. |
asa(config-if)#security-level 50 |
7 |
Enable the interface. |
asa(config-if)#no shutdown |
8 |
Enter interface configuration mode. |
asa(config-if)#interface e1 |
9 |
Configure an interface IP address. |
asa(config-if)#ip address 192.168.1.1 255.255.255.0 |
10 |
Configure an interface name. |
asa(config-if)#nameif Right |
11 |
Configure an interface security level. |
asa(config-if)#security-level 75 |
12 |
Enable the interface. |
asa(config-if)#no shutdown |
13 |
Create and configure an Extended ACL entry (ACE). |
asa(config-if)#access-list Left-to-Right extended permit ip host 172.16.1.10 host 192.168.1.100 |
14 |
Apply the ACL to the appropriate interface. |
asa(config)#access-group Left-to-Right in interface Left |
Note that an ACL entry was needed for traffic going from Left to Right. This is because the Left interface was configured with a security level that was lower than that of the Right interface. Remember, again, that traffic is permitted by default (this behavior can be altered) from higher-security levels to lower-security levels.
Summary
For those with little or no experience, the idea of an ACL can be quite overwhelming. Ensure that enough time is taken when studying to understand how they work and how they are configured to get the intended results. For those looking for additional hands-on ASA experience, check out GNS3, which does have the capability to emulate an ASA environment (similar to Dynamips/Dynagen).
For those just getting into network security but who have some amount of Cisco device knowledge, the transition into the ASA platform is not quite as hard. Although a number of small differences exist between the routing/switching platforms and the ASA platform, they are certainly close enough that the learning curve should not be too steep. From this article, you should now have a basic understanding of ACLs on the ASA platform that you can call on when needed.