Introduction to Extended IP Access Lists Application

This blog entry is a little bit different than other recent posts.  The original intent of Packetu.com was to help people understand how networks operate and function.  During my recent studies, it morphed into a CCIE blog.  This article is a bit more basic, but contains some really good foundational information that should be understood prior to implementing features including access-lists and CBAC (ip inspects).

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 article 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 article.  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 http 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 article 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

 ipermit 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 to point out 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 article are very important building blocks that should be understood prior to looking at more advanced features.

No related content found.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in How-To. Bookmark the permalink.