Extended IP access control lists and configuration
Access-lists come in many flavors, including standard and extended IP access-lists as well as access-lists capable of identifying other characteristics in non-IP traffic. Access-lists, also known as ACLs, can be named or numbered. Identification or matching of traffic is a key concept of access-lists and is performed with each line in the ACL. These lines or entries are also known as ACEs or Access Control Entries. It is easy to think of access-lists as filters, but they are really a way to match or identify characteristics of a packet. How they are then applied can make them a filter or something else. If an access-list is identified, any traffic not matching an ACE will have an implicit deny or negative match applied to it. Therefore if the ACL is used for filtering, anything not matched will be dropped. This document will focus on IP Extended access-lists and how they are used to filter traffic going through a router. In the future, I may expand on the other uses for an access-list.
IP access-lists can be standard or extended as well as named or numbered. The key difference between a standard and extended IP access-list is that standard access-lists only have the capability to look at the source IP Address in the packet. Extended IP access-lists have the ability to look at source and destination IP addresses, layer 4 protocols, layer 4 specific information such as source and destination ports, and various protocol flags at layer 3 and layer 4. So when there is a requirement for destination IP Address matching or granularity, extended IP access-lists are the way to go.
Additionally, I mentioned that there are named and numbered access-lists. In most cases, the capabilities of these are the same. Named access-lists tend to be easier for me to use in a configuration due to the fact that I can name them something descriptive. There are a few cases when a numbered access-list must be used, as well as a few instances where a named access-list must be used. However, these cases are not directly related to the packet filtering example we will look at in this document. When using named access-lists, the name can be something of the engineer’s choosing. However when using numbered IP extended access-lists, the ranges of 100-199 and 2000-2699 are the only permitted values.
Prior to getting into a filtering example, let’s briefly look at traffic flow in a client server environment. For demonstration, consider a web client accessing a web server. There are generally multiple streams of communication that occur. For example, a DNS request may have to occur as well as images that are imbedded within the web page. To simplify the example, let’s just explore the IP, then the https communication that occurs to deliver the html page to the browser.
Using the above diagram as an example, we can see that we have a web client with an IP address of 192.168.0.50 and a web server with an IP address of 192.0.2.100. Additionally, we probably know that web servers typically use TCP port 80. An important thing to understand is that clients typically use a source port that is in the range of 1024-65535. In practice, there would be different addresses and/or NAT (Network Address Translation) involved. However for this discussion, I want to keep things simple and discuss this exactly as it is shown.
When the web client attempts to connect to the web server, an initial packet is sent. With TCP this is part of the TCP Three Way Handshake. This handshake is an important topic, but not really relevant to this discussion. What is relevant is understanding that traffic flows from client to server and from server to client. This traffic has characteristics that we can match and filter on. Whether or not the traffic is part of the three way handshake or not, the characteristics I will discuss today are more related to the direction of the traffic. I will mention that there are flags that are related that three way handshake that can be used for identification in extended access-lists. I hope to expand on this document and discuss these advanced features in the future.
Using the above example what does the traffic look like that is flowing from the client to the server? What about the traffic that is flowing from the server to the client? Let’s take a look.
So we can see that traffic from the client to the server has a source IP of 192.168.0.50 and a destination of 192.0.2.100. Traffic from the server to the client has a source IP address of 192.0.2.100 and a destination IP address of 192.168.0.50. In this example, it is fairly easy to see the “flip-flopping” of the source and destination IP addresses. If I wanted to construct an access-list to match only the layer three information, I could the following.
Client to Server (Numbered Example)
access-list 101 permit ip host 192.168.0.50 host 192.0.2.100
Client to Server (Named Example)
ip access-list extended Client2Server
permit ip host 192.168.0.50 host 192.0.2.100
Server to Client (Numbered Example)
access-list 102 permit ip host 192.0.2.100 host 192.168.0.50
Server to Client (Named Example)
ip access-list extended Server2Client
permit ip host 192.0.2.100 host 192.168.0.50
Now we have created our access-lists, the next thing we must do is attach them in a way that the appropriate traffic can be filtered. An access-list can be applied per protocol, per direction, per interface. Looking at the diagram, we are only using IP protocol and we know that an interface only has two directions, inbound and outbound. We can also see that we have two interfaces, FastEthernet 0/0 and Serial 0/0/0. To filter traffic from the client to the server, we can filter in two places. The first place is inbound on FastEthernet 0/0 and the second place is outbound on Serial 0/0/0. To filter the return traffic from the server to the client, we can filter inbound on Serial 0/0/0 or outbound on FastEthernet 0/0. The “ip access-group” interface command is used to attach an IP access-list to an interface. There is no difference in how this command is used with named or numbered access-lists. So in order to restrict outbound traffic (Client to Server) to only that shown in this diagram, I can do either of the following.
interface FastEthernet0/0
ip access-group Client2Server in
-or-
interface Serial 0/0/0
ip access-group Client2Server out
Note: Either of these methods achieves the goal of only permitting the traffic in the diagram from the Client to the Server. Instead of using “Client2Server”, the numbered ACL 101 could have also been used. No other IP communication would be permitted in the attached direction on the interface. Organizational goals and policies typically dictate the placement and direction of the acl attachment.
To restrict access from the server to the client to the traffic in the picture, we could attach the Server2Client access-list as follows.
interface Serial 0/0/0
ip access-group Server2Client in
-or-
interface FastEthernet 0/0
ip access-group Server2Client out
The same note would apply to this ACL attachment as well. Therefore 102, could be used in place of the named access-list. Additionally, inbound and outbound ACL’s can exist on the same interface. Therefore, the following would utilize Serial 0/0/0 to restrict traffic to and from the server and clients to the traffic shown in the diagram.
interface Serial 0/0/0
ip access-group Client2Server out
ip access-group Server2Client in
Let’s expand on this example a bit and include the layer 4 protocol and port information. We know that that web servers typically operate on TCP Port 80. We also know that clients typically source TCP requests from ports greater than 1023 (1024-65535). Below is a more detailed version of the diagram that shows the TCP information.
Notice how that not only the source and destination ip addresses are swapped with traffic flowing in the opposite directions. The TCP source and destination ports are also swapped. This would also be true if we were discussing UDP protocol . Another thing worth noting is that the source port in the client to server communication will not always be 1029. That number was given as an example, but is typically any number greater than 1023. These are known as unprivileged ports and do not require special permissions in the client operating system to open these sockets. Let’s expand on our previous example and create two new named IP extended access-lists that have the layer four information to allow the client to utilize the web server’s port 80. In our previous example, all IP communications between the client and server would have been permitted.
Client to Server
ip access-list extended C2S
permit tcp host 192.168.0.50 gt 1023 host 192.0.2.100 eq 80
Server to Client
ip access-list extended S2C
permit tcp host 192.0.2.100 eq 80 192.168.0.50 gt 1023
In this example, we can see that the keyword “ip” has been replaced by “tcp” for the protocol. We can also see that we have port information listed. The operator “gt” means greater than. The operator “eq” has the meaning of equal. So the C2S ACL has an ACE that can be read as follows:
MATCH TCP traffic with a source IP of 192.168.0.50 and a source port greater than 1023 (1024-65535) and a destination IP address of 192.0.2.100 with the destination port 80.
As with the previous example, the C2S ACL can be applied inbound to FastEthernet 0/0 or outbound on Serial 0/0/0. The S2C ACL can be applied inbound on Serial 0/0/0 or outbound on FastEthernet 0/0. An example of both ACL’s applied in the appropriate direction on Serial 0/0/0 is as follows:
interface Serial 0/0/0
ip access-group C2S out
ip access-group S2C in
Note that by applying these ACL's to this interface, any previously attached access-groups are no longer attached to this interface.
Access-lists can be used for many functions inside a router. One of the more common uses is for traffic filtering. One of the areas of confusion for those less experienced is how to properly build and apply an access-list. Traffic flows to and from sources and destinations typically mirror each other. Understanding how this traffic appears on the network is crucial to properly building access-lists. There are many other areas that I hope to address in the future concerning the appropriate constructions of masks and the use of more complex match criteria. Additionally, truly using a router as a firewall requires understanding CBAC, or ip inspects. However, understanding the key concepts outlined in this document are very important building blocks that should be understood prior to looking at more advanced features.
The main difference between Extended and Standard access lists is the variety of fields in the packet that can be compared for matching by extended access lists. A single extended ACL statement can examine multiple parts of the packet headers, requiring that all the parameters be matched correctly to match that one ACL statement. That matching logic is what makes extended access lists both much more useful and more more complex than standard IP ACLs.
Extended IP ACL Concepts
Standard and Extended IP Access Lists: Matching
| Type of Access List | What can be matched |
|---|---|
| Both standard and extended ACLs | Source IP address |
| Portions of the source IP address using a wildcard mask | |
| Only extended ACLs | Destination IP address |
| Portions of the destination IP address using a wildcard mask | |
| Protocol type (TCP, UDP, ICMP, IGRP, IGMP, and others) | |
| Source port | |
| Destination port | |
| All TCP flows except the first | |
| IP TOS | |
| IP precedence |
IOS checks all the matching information configured in a single access-list command. Everything must match for that single command to be considered a match and for the defined action to be taken. The options start with the protocol type, followed by the source IP address, source port, destination IP address, and destination port number.
| access-list Statement | What It Matches |
|---|---|
| access-list 101 deny ip any host 10.1.1.1 | Any IP packet, any source IP address, with a destination of IP address of 10.1.1.1 |
| access-list 101 deny tcp any gt 1023 host 10.1.1.1 eq 23 | Packets with a TCP header, any source IP address, with a source port greater than (gt) 1023, a destination IP address of exactly 10.1.1.1, and a destination port equal to (eq) 23 |
| access-list 101 deny tcp any host 10.1.1.1 eq 23 | The same as the preceding example, but any source port matches, because that parameter is omitted in this case. |
| access-list 101 deny tcp any host 10.1.1.1 eq telnet | The same as the preceding example. The telnet keyword is used instead of port 23. |
| access-list 101 deny udp 1.0.0.0 0.255.255.255 lt 1023 any | A packet with a source in network 1.0.0.0, using UDP with a source port less than (lt) 1023, with any destination IP address. |
Matching TCP and UDP Port Numbers
Extended IP ACLs allow for the matching of the IP header protocol field, as well as matching the source and destination TCP or UDP port numbers.
When considering any exam question that involves TCP or UDP ports, keep the following key points in mind:
* The access-list command must use protocol keyword tcp to be able to match TCP ports and the udp keyword to be able to match UDP ports. The ip keyword does not allow for matching the port numbers.
* The source port and destination port parameters on the access-list command are positional. In other words, their location in the command determines if the parameter examines the source or destination port.
* Remember that ACLs can match packets sent to a server by comparing the destination port to the well-known port number. However, ACLs need to match the source port for packets sent by the server.
* It is useful to memorize the most popular TCP and UDP applications, and their well-known ports.
For exam questions that require ACLs and matching of port numbers, first consider whether the question requires that the ACL be placed in a certain location and direction. If so, you can then determine if that ACL would process packets either sent to the server or sent by the server. At that point, you can decide whether you need to check the source or destination port in the packet.
Popular Applications and Their Well-Known Port Numbers
| Port Number(s) | Protocol | Application | Applications Name Keyword in access-list Command Syntax |
|---|---|---|---|
| 20 | TCP | FTP Data | ftp-data |
| 21 | TCP | FTP Control | ftp |
| 22 | TCP | SSH | – |
| 23 | TCP | Telnet | telnet |
| 25 | TCP | SMTP | smtp |
| 53 | UDP,TCP | DNS | domain |
| 67,68 | UDP | DHCP | nameserver |
| 69 | UDP | TFTP | tftp |
| 80 | TCP | HTTP(WWW) | www |
| 110 | TCP | POP3 | pop3 |
| 161 | UDP | SNMP | snmp |
| 443 | TCP | SSL | – |
| 16,384-32,767 | UDP | RTP-based voice (VoIP) and video | – |
Extended IP ACL Configuration
Extended IP Access List Configuration Commands:
| Command | Configuration Mode and Description |
|---|---|
| access-list access-list-number {deny | permit } protocol source source-wildcard destination destination-wildcard [log | log-input | Global command for extended numbered access lists. Use a number between 100 and 199 or 2000 and 2699, inclusive |
| access-list access-list-number {deny | permit} {tcp | udp} source source-wildcard [operator[port]] destination destination-wildcard [operator[port]] [established] [log] | A version of the access-list command with TCP specific parameters. |
The location and direction should be chosen first so that the ACL’s parameters can be planned based on the information in the packets flowing in that direction. The ACL should be configured with access-list commands. Then the ACL should be enabled with the same ip access-group command used with standard ACLs. The differences in configuration between standard and extended are summarized as follows:
* Extended ACLs should be placed as close as possible to the source of the packets to be filtered, because extended ACLs can be configured so that they do not discard packets that should not be discarded. So filtering close to the source of the packets save some bandwidth.
* All fields in one access-list command must match a packet for the packet to be considered to match that access-list statement.
* The extended access-list command uses numbers between 100-199 and 2000-2699, with no number being better than another.
The extended version of the access-list command allows for matching of port numbers using several basic operations, such as equal-to and less-than. These are: eq, neq, lt, gt, and range.
Following the permit or deny action, the protocol parameter defines whether you want to check for all IP packets or just those with TCP or UDP headers. When you check for TCP or UDP numbers, you must specify the TCP or UDP protocol.
With extended IP ACLs, Cisco suggest that you locate them as close as possible to the source of the packet. Standard ACLs, Cisco suggests as close as possible to the destination.