ACL’s’ are vital to networking today. Everyone uses them, and proper usage is imperative.
Besides being difficult to use at times, the penalty for an ACL mistake is huge. In one swift swoop, you could incorrectly permit malicious attackers onto your network or incorrectly deny all valid users from your network. Either way, the consequences could be devastating to your company and to your career. So how do you prevent this from happening? If you follow these guidelines, you will be “feeling good again” about your ACL’s.
In the simplest of terms, a Cisco IOS ACL is used to define traffic. Once that traffic is defined, some action can then be taken on that traffic.
On routers, an ACL is usually associated with the filtering of IP packets (Network Layer 3 of the OSI Model) as they pass through a router. In other words, it is used to permit or deny traffic through a router. However, if you just define the ACL only and don’t apply it to an interface using the access-group command, nothing happens. Similarly ACL’s can provide Layer 2 functions on switches. Keep in mind some products support both Layer 2 and Layer 3 ACL functionality.
While ACL’s can be used for many functions like Traffic Engineering, QoS, route filtering, and allowing access to the router, for simplicity, we will focus on using ACL’s for filtering traffic in and out of the router.
When it comes to ACL basics, you need to know the principle of the three Ps. That is, you can only apply a Cisco IOS ACL:
- Per protocol (such as IP)
- Per interface (such as FastEthernet0/0)
- Per direction (such as inbound or outbound)
When traffic flows through a router, there’s one set of source IP address, destination IP address, and port numbers. When the response returns from that request, the IP source address, IP destination address, and port numbers have reversed. For this reason, the inbound and outbound ACL’s are usually a mirror of each other.
To configure an ACL you need to include some basic information about which packets to permit or deny.
The general syntax for a standard access list is:
access-list {list number} permit | deny | [source address} [source mask]
Note that the standard ACL can only permit or deny traffic based on the source of the traffic.
The general syntax of a TCP extended access list is:
access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny | permit} tcp source source-wildcard [operator [port]] destination destination-wildcard [operator [port]] [established] [precedence precedence] [tos tos] [log | log-input] [time-range time-range-name] [fragments]
You should also know that extended ACL can filter IP traffic, TCP, UDP, ICMP, and other types of traffic. The syntax above is to filter TCP traffic.
Cisco IOS ACL’s use wildcard masks. These wildcard masks are required anytime you enter an IP address in your ACL. The only way NOT to enter an IP address (thus, using a wildcard mask) is to enter a keyword like “any” or use the keyword “host” before the absolute IP address of a host on the network.
Wildcard masks are the binary reverse of a subnet mask. Thus, to calculate a wildcard mask, you take the subnet mask of a network address or IP address, convert it to binary, turn all the 1s into 0s and the 0s into 1s, and convert it back to decimal. Sounds complicated, but it really isn’t. If the subnet mask is masked at the 8-bit subnet boundaries, then a 0 will turn into a 255 and a 255 will turn into a 0. Here are a few examples:
- Subnetwork 255.0.0.0 = wildcard 0.255.255.255
- Subnetwork 255.255.255.0 = wildcard 0.0.0.255
- Subnetwork 255.255.128.0 = wildcard 0.0.127.255
- Subnetwork 255.255.255.224 = 0.0.0.31
Do NOT use a subnet mask in a wildcard mask on a Cisco IOS router or switch, or you will end up with unintended results. (On the other hand, if you are configuring an ACL on a Cisco PIX, use regular subnet masks, not wildcard masks).
For example, here’s how a sample configuration might look for access list 1:
Router(config)# access-list 1 permit 172.16.30.0 0.0.0.255
Router(config-if)# interface e0/0
Router(config-if)# ip access-group 1 out
The ip access-group command is used to apply an ACL to an interface and specify the direction that it applies.
The commands above permit any traffic going to IP network 172.16.30.0 from going OUT the router’s Ethernet 0/0 interface. Any traffic addressed to that network will still be allowed in, but it won’t be permitted to go out interface e0/0.
Let me ask you this: What is allowed through the ACL above?
Answer: Only the traffic to the 172.16.30.0 /24 network.
Why is that?
That is because at the end of every ACL, whether you see it or not, ALL TRAFFIC IS IMPLICITLY DENIED.
So, what traffic is allowed through the ACL below?
Router(config)# access-list 1 deny 172.16.30.0 0.0.0.255
That’s right – NO TRAFFIC is allowed because certain traffic is explicitly denied and ALL OTHER TRAFFIC IS DENIED by the implicit deny.
How do you see the traffic being denied? You can enter your own explicit deny with the log keyword, like this:
Router(config)# access-list 1 permit 172.16.30.0 0.0.0.255
Router(config)# access-list 1 deny any log
Cisco IOS ACL’s use top-down processing. This means that when a condition in the ACL is met, all processing is stopped. Thus, if there is a permit for network 1.1.1.0 in the fifth line of the ACL but it is denied in the third line of the ACL, then that traffic is denied.
Remember, you can only apply ONE ACL:
- Per Interface
- Per Protocol
- Per Direction
As most of us are applying IP ACL’s, the protocol doesn’t matter that much, but the important thing to know is that you can apply only ONE ACL on each interface in each direction. In other words, you can apply only one inbound and one outbound ACL per interface.
Showing what ACL’s are created and what ACL’s are applied is easy if you know just a few commands. These commands are:
- show access-lists
- show ip interface
- show running-config
The Cisco IOS supports IP Standard and Extended ACL’s in both named and numbered versions. Additionally, there are reflexive, dynamic, and lock-and-key access lists, among many others.
While you may understand the concept of ACL’s and how to configure them, it is important to know how to use them in the real world.
ACL Applications
Here are a few business applications for ACL’s:
- Basic packet filtering for security: Filter traffic from a host, a network, a protocol, or port.
- Packet filtering for bandwidth control: Say that a streaming audio or video application was using network bandwidth, and it was on a certain port number. With an ACL, you could discard those video and audio packets to prevent overutilization of bandwidth.
- Other functions with ACL’s: Route filtering, QoS, controlling access to the router, etc.
- Compiled (Turbo) ACL
Turbo ACL’s
If you have long and complex ACL’s, it is best to enable the Turbo ACL feature, available on newer routers with newer IOS versions. (The IOS disables this feature by default.)
With Turbo ACL, tables built into the router’s memory help the router speed the processing of traffic through ACL’s. Whenever you modify the ACL’s, this triggers the router to recompile the ACL. Here’s how you enable Turbo ACL’s:
Router(config)# access-list compiled
Time-range ACL’s
You can create ACL’s that apply only for a certain time range. For example, say you want to allow FTP traffic only from 8 A.M. to 5 P.M.. You could do this using time-based ACL’s using the time-range parameter. Here’s an example:
time-range ftp
periodic weekdays 8:00 to 17:00
ip access-list extended ftpacl
permit tcp any any eq ftp time-range ftp
permit tcp any any eq ftp-data time-range ftp
permit tcp any any eq www
Dynamic ACL’s
Another name for dynamic ACL’s is lock and key. With lock and key, you can trigger the creation of a dynamic ACL when you Telnet to the router. For example, say you want to allow HTTPS to a LAN switch through a router. Telnetting to the router creates a temporary/dynamic ACL to allow this traffic for a limited time.
To do so, you use the dynamic parameter. Here’s an example:
Router(config)# access-list 125 dynamic ….
In addition, using the autocommand access-enable command on the Telnet line will trigger the ACL. For more information, check out Cisco’s Configuring Lock-and-Key Security (Dynamic Access Lists) documentation.
ACL’s that only allow established TCP connections
Another interesting parameter for Cisco IOS ACL’s is the established option. With the established parameter, you can create an ACL that only allows TCP traffic matching the ACL that has an ACK or RST bit set. That would deny any TCP traffic trying to create a new TCP session. Here’s an example:
Router(config)# access-list 120 permit tcp any 1.1.1.0 0.0.0.255 established
This line, taken from a larger ACL, permits only TCP traffic going to the 1.1.1.0 network that’s already established. So, it only permits responses to connections already initiated (i.e., set up) in the opposite direction. This is similar to a stateless firewall that allows already-connected traffic; however, in this situation, we don’t know what that traffic actually is. We’re assuming that any TCP response we receive was a real request.
There is a lot to know about ACL’s, and we can’t cover it all in this short format. Click here for more on the Cisco web site.