ACL Configuration Examples
To help illustrate the use of ACLs, let’s take a look at some examples. I’ll start easy with an example of an appliance that has two interfaces and proceed to an example with an appliance that has three interfaces.
Appliance with Two Interfaces—Example 1
This simple example involves an appliance that has only two interfaces. Take a look at the network shown in Figure 6-1. In this example, the internal network is using a private class address (192.168.1.0/24) and has been assigned the following public address space: 200.200.200.0/29. Here are the security policies that you need to set up with ACLs:
- Allow all outbound traffic (this is the default).
- Restrict inbound traffic to only the internal servers.
Listing 6-1 shows the address translation and ACL configuration of the appliance.
Listing 6-1: Configuring ACLs for the appliance in Figure 6-1  |
ciscoasa(config)# nat (inside) 1 0.0.0.0 0.0.0.0
ciscoasa(config)# static (inside,outside) 200.200.200.2 192.168.1.2
ciscoasa(config)# static (inside,outside) 200.200.200.3 192.168.1.3
ciscoasa(config)# static (inside,outside) 200.200.200.4 192.168.1.4
ciscoasa(config)#
ciscoasa(config)# access-list PERMIT_IN permit tcp
any host 200.200.200.2 eq 80
ciscoasa(config)# access-list PERMIT_IN permit tcp
any host 200.200.200.3 eq 25
ciscoasa(config)# access-list PERMIT_IN permit udp
any host 200.200.200.4 eq 53
ciscoasa(config)# access-list PERMIT_IN deny ip any any
ciscoasa(config)#
ciscoasa(config)# access-group PERMIT_IN in interface outside
|
Before I discuss the ACL configuration in Listing 6-1, notice that the appliance is performing PAT (using 200.200.200.1) when users’ traffic heads out to the Internet. Also, there are three static commands to perform the address translation for the three internal servers.
Look at the ACL named PERMIT_IN in Listing 6-1; the first line allows TCP traffic from any source if it is headed to 200.200.200.2 and only if this traffic is for port 80, the web server process running on the web server. Notice that I used the public address as the destination address. Remember that ACLs are processed before address translation is performed (the static and nat/global commands). One other thing to point out about the ACL is that I have added a deny ip any any statement at the end of the ACL—this is unnecessary because there is an implicit deny at the end of every ACL; however, I want to see the hit counts for each dropped packet, which this statement accomplishes. The last thing that was configured in this configuration is the activation of the PERMIT_IN ACL on the outside interface, which filters traffic as it comes inbound from the Internet.
Appliance with Two Interfaces—Example 2
In this example, I want to expand on the example in Figure 6-1 and Listing 6-1. Assume that you have two groups of internal devices, as is depicted in Figure 6-1: GroupA (192.168.1.128–192.168.1.191) and GroupB (192.168.1.192–192.168.1.254). Here are the filtering rules that will be set up for GroupA:
- Deny access to all devices on network 131.108.0.0/16.
- Deny access to the following web servers: 210.210.210.0/24.
- Allow access to all other Internet sites.
Here are the filtering rules to set up for GroupB:
- Allow access to all devices in network 140.140.0.0/16.
- Allow access to the following web servers: 210.210.210.5/32 and 211.211.211.3/32.
- Deny access to all other Internet networks.
I’ll assume that the inbound policies remain the same; therefore I can build upon the example in Listing 6-1. Listing 6-2 shows the commands to accomplish the additional policy restrictions.
Listing 6-2: This example filters outbound traffic. |
192.168.1.128 255.255.255.192
131.108.0.0 255.255.0.0
ciscoasa(config)# access-list PERMIT_OUT deny tcp
192.168.1.128 255.255.255.192
210.210.210.0 255.255.255.0 eq 80
ciscoasa(config)# access-list PERMIT_OUT permit ip
192.168.1.128 255.255.255.192 any
ciscoasa(config)#
ciscoasa(config)# access-list PERMIT_OUT permit ip
192.168.1.192 255.255.255.192
140.140.0.0 255.255.0.0
ciscoasa(config)# access-list PERMIT_OUT permit tcp
192.168.1.192 255.255.255.192
host 210.210.210.5 eq 80
ciscoasa(config)# access-list PERMIT_OUT permit tcp
192.168.1.192 255.255.255.192
host 211.211.211.3 eq 80
ciscoasa(config)# access-list PERMIT_OUT deny ip
192.168.1.192 255.255.255.192 any
ciscoasa(config)#
ciscoasa(config)# access-group PERMIT_OUT in interface inside
|
In Listing 6-2, I’ve broken the ACL called PERMIT_OUT into two sections—one for GroupA and one for GroupB. Remember that ACLs are processed top-down, and the order of your statements does matter. One other item to point out is that the source IP addresses listed in the ACL statements are the addresses before translation, because the appliance processes ACLs before any address translation policies.
Take a look at the GroupA statements first. The very first entry in the ACL denies all IP traffic from 192.168.1.128/26 if it is destined for 131.108.0.0/16. The second statement denies all traffic from 192.168.1.128/26 if it is destined for TCP port 80 on any web server in network 210.210.210.0/24. The third statement allows any other IP traffic from 192.168.1.128/26 to go anywhere else on the Internet.
In the GroupB configuration (the second half of the ACL), the first permit statement (after the GroupA statements) allows any IP traffic from 192.168.1.192/26 to 140.140.0.0/16. The second and third statements allow all traffic from 192.168.1.192/26 to reach the two web servers: 210.210.210.5 and 211.211.211.3. The last statement in the ACL denies any other traffic from 192.168.1.192/26. The last part of the configuration in Listing 6-2 shows the application of the ACL (PERMIT_OUT) to the inside interface as traffic comes into this interface.
Appliance with Three Interfaces
To help you understand how flexible ACLs are, I’ll show a more complicated example: you have an appliance that has three interfaces, and you want to control traffic between these interfaces, as shown in Figure 6-2.
Listing 6-3 shows just the address translation configuration on this appliance.
Listing 6-3: The basic configuration of the PIX with three interfaces |
192.168.5.0 0.0.0.255
ciscoasa(config)# access-list NONAT permit ip 192.168.0.0 0.0.255.255
192.168.5.0 0.0.0.255
ciscoasa(config)# nat (inside) 0 access-list NONAT
ciscoasa(config)# nat (inside) 1 0.0.0.0 0.0.0.0
ciscoasa(config)# nat (dmz) 1 0.0.0.0 0.0.0.0
ciscoasa(config)# global (outside) 1 200.200.200.10-200.200.200.253
netmask 255.255.255.0
ciscoasa(config)# static (dmz,outside) 200.200.200.1 192.168.5.5
ciscoasa(config)# static (dmz,outside) 200.200.200.2 192.168.5.6
ciscoasa(config)# static (inside,dmz) 192.168.5.0 192.168.5.0
netmask 255.255.255.0
|
Explanation of the Basic Configuration
Before I go into the configuration of the ACLs, I will first discuss what the network in Figure 6-2 and the configuration shown in Listing 6-3 are doing. As you can see from this example, you are dealing with an appliance that has three interfaces—outside, dmz, and inside. The outside interface is connected to the perimeter router, which, in turn, is connected to the ISP. A default route points to the router’s inside interface. The dmz interface has some user devices, as well as two servers: an e-mail server and a web server. The inside interface is connected to an inside router, which, in turn, is connected to two subnets: 192.168.3.0/24 and 192.168.4.0/24. I’ll assume that two static routes are already configured for these two subnets.
Listing 6-3 has one global command and three nat commands. I’ll look at these from the perspectives of both the inside interface and the dmz interface. If a device from the inside interface tries to access a device on the dmz interface, it will not have its address translated—this is based on the static and access-list NONAT commands in the configuration. With the exception of the 192.168.1.0/24 subnet, any other 192.168.0.0/16 subnet that sends traffic to 192.168.5.0/24 is exempted from translation. If a device on the inside interface tries to access the Internet, its address is translated to a public address: 200.200.200.10 through 200.200.200.253.
If a device on the dmz interface tries to access a device on the outside interface, its addresses will be translated to the same public address space as the devices on the inside interface. The exceptions to this translation are the two Internet servers. Two static commands perform the address translation statically. These static commands change the e-mail server source address from 192.168.5.5 to 200.200.200.1, and the web server address from 192.168.5.6 to 200.200.200.2. The reverse process takes place when Internet users send traffic to the servers: they use destination addresses of 200.200.200.1 and 200.200.200.2, which are translated to 192.168.5.5 and 192.168.5.6 respectively.
Configuring Filtering Policies
Now that I have discussed the basic configuration of the appliance shown in Listing 6-3, I’ll talk about configuring some filtering policies for this appliance. As I mentioned in the previous section, the two servers located on the dmz interface need to access the internal network. Here’s a list of all the policies that need to be implemented for users/servers on the DMZ segment:
- Users should not be allowed to access anything on 192.168.1.0/24.
- Device 192.168.5.5 and 192.168.5.6 should be allowed access to 192.168.2.0/24.
- Devices on the DMZ segment should be allowed to access any destination on the Internet.
Here’s a list of the policies that need to be implemented for internal users:
- Users should be allowed access to the e-mail and web server on 192.168.5.0/24, but not to other devices on this segment.
- Users should not be allowed access to 192.168.1.0/24.
- Devices on 192.168.2.0/24 and 192.168.3.0/24 should be allowed access to any destination on the Internet.
- Devices on 192.168.4.0/24 should only be allowed access to 131.108.0.0/16, 140.140.0.0.16, and 210.210.210.0/24 out on the Internet.
Here’s a list of all of the policies that need to be implemented for external users trying to access resources in your network:
- Users should be allowed access specifically to the e-mail server.
- Users should be allowed access specifically to the web server.
- All other types of access should be denied.
To enforce these policies, you need to create three ACLs and to apply them to the three respective interfaces of the appliances. Listing 6-4 shows the configuration of the policies for the DMZ.
Listing 6-4: The configuration for security policies for the DMZ segment |
192.168.1.0 255.255.255.0
ciscoasa(config)# access-list DMZ permit ip host 192.168.5.5
192.168.2.0 255.255.255.0
ciscoasa(config)# access-list DMZ permit ip host 192.168.5.6
192.168.2.0 255.255.255.0
ciscoasa(config)# access-list DMZ deny ip any
192.168.2.0 255.255.255.0
ciscoasa(config)# access-list DMZ deny ip any
192.168.3.0 255.255.255.0
ciscoasa(config)# access-list DMZ deny ip any
192.168.4.0 255.255.255.0
ciscoasa(config)# access-list DMZ permit ip
192.168.5.0 255.255.255.0 any
ciscoasa(config)# access-list DMZ deny ip any any
ciscoasa(config)#
ciscoasa(config)# access-group DMZ in interface dmz
|
Listing 6-4 is fairly straightforward. The first ACL statement denies access to the 192.168.1.0/24 segment. The second and third ACL statements allow all IP traffic from 192.168.5.5 and 192.168.5.6 to travel to 192.168.2.0/24—this is denied by default because of the security levels of the two interfaces involved. The fourth, fifth, and sixth ACLs deny any traffic from the DMZ headed to the three internal subnets. This prevents other devices on the dmz interface from accessing resources on 192.168.2.0/24 and also prevents any device on this segment from accessing the two networks on the internal router: 192.168.3.0/24 and 192.168.4.0/24. These statements are needed because of the statement that follows this (the seventh statement), which allows traffic from any device on 192.168.5.0/24 to go anywhere—you need to deny the specifics before you permit everything. The second to the last statement in the configuration drops all packets. I’ve added this so that I can see a hit count of all dropped packets—this greatly facilitates the troubleshooting of connectivity problems when the appliance is dropping packets based on its filter(s). The last command in this configuration is activation of the ACL on the dmz interface.
| Tip | |
Here is an interesting question: based on the ACL in Listing 6-4, if a device from 192.168.3.0/24 accesses the web server and the web server responds, is the return permitted through the firewall? One important point about these filtering policies is that the appliance will be performing two tasks to determine if the traffic is allowed or dropped. The appliance first looks into its conn table to see if there is a connection already there. In this situation, the device from 192.168.3.0/24 initiated the connection, and because the DMZ is a lower-security-level interface, and no ACL is configured on the inside interface, the appliance permits the connection and adds the temporary connection to its conn table. Thus, when the return comes back through the appliance, the appliance examines its conn table, sees the entry that was just created, and allows the response back to the 192.168.3.0/24 network. The only time the ACL is used is when there is no entry in the conn table—then the appliance examines the ACL to determine whether a hole in the firewall should be opened to allow the traffic. If you wanted to deny this traffic, you would need to create an ACL and apply it to the inside interface.
Look at the configuration for the filtering policies for the internal users, shown in Listing 6-5.
Listing 6-5: The configuration of security policies for the internal segments |
host 192.168.5.5 eq 25
ciscoasa(config)# access-list INTERNAL permit tcp any
host 192.168.5.6 eq 80
ciscoasa(config)# access-list INTERNAL deny ip any
192.168.5.0 255.255.255.0
ciscoasa(config)# access-list INTERNAL deny ip any
192.168.1.0 255.255.255.0
ciscoasa(config)# access-list INTERNAL permit ip
192.168.2.0 255.255.255.0 any
ciscoasa(config)# access-list INTERNAL permit ip
192.168.3.0 255.255.255.0 any
ciscoasa(config)# access-list INTERNAL permit ip
192.168.4.0 255.255.255.0
131.108.0.0 255.255.0.0
ciscoasa(config)# access-list INTERNAL permit ip
192.168.4.0 255.255.255.0
210.210.210.0 255.255.255.0
ciscoasa(config)# access-list INTERNAL deny ip any any
ciscoasa(config)#
ciscoasa(config)# access-group INTERNAL in interface inside
|
The first and second commands allow all users on the inside interface to access the web and e-mail server on 192.168.5.0/24, and the third statement denies all other internal traffic to this network. The fourth statement denies all internal traffic destined to 192.168.1.0/24. The fifth and sixth statements allow 192.168.2.0/24 and 192.168.3.0/24 to access any other network. The seventh and eighth statements allow devices from 192.168.4.0/24 to 131.108.0.0/16 and 210.210.210.0/24. Any other traffic not matching any of the permit statements in this list will be dropped (including access to 192.168.1.0/24). The last statement in the configuration activates the ACL on the inside interface.
Listing 6-6 shows the configuration for the filtering policies that affect the external users (the ones on the Internet, or located on 192.168.1.0/24).
Listing 6-6: The configuration of security policies for external users |
200.200.200.1 eq 25
ciscoasa(config)# access-list EXTERNAL permit tcp any
200.200.200.2 eq 80
ciscoasa(config)# access-list EXTERNAL deny ip any any
ciscoasa(config)# access-group EXTERNAL in interface outside
|
Of the three ACLs, the one for the external users is the simplest. The first and second statements allow internal users access to the e-mail and web servers on 192.168.5.0/24—notice that the destination addresses are the public addresses, because this is what the appliance sees. The third statement drops all traffic, and the last statement activates the ACL on the outside interface.
As you can see from this example, the configuration of ACLs can be a very complex process. You should always test any changes you make to your ACLs to ensure that you are not inadvertently opening any unnecessary holes in your appliance.
| Tip | |
