Packet Filtering via ACLs

As you probably already know, all information that flows across the Internet uses TCP/IP and, in turn, this information is sent in small pieces known as packets. In the early days of the Internet, filtering based on packets was common and, in many cases, routers in many networks still use packet filtering. Packet filters are often used as a first defense in combination with other firewall technologies. Today, their most common implementation is seen in the ACLs of routers at the perimeters of networks.

Packet filtering is one of the oldest and most common types of packet inspection technologies available. It begins by inspecting a packet’s contents and applying rules to determine whether a packet should be dropped or allowed. Although many characteristics are possible within a TCP/IP packet’s header (that is, protocol, port, and so on), this discussion refers to filtering based on the source or destination IP address, as shown in Figure 5-3.

Figure 5-3 Packet Filtering at Layer 3 of the TCP/IP Model

The two main types of ACLs are standard ACLs, which filter based on IP address, and extended ACLs, which look further into a packet header, if so configured.

Packet filters inspect each packet individually, examining source and destination IP address and ports as defined in the filter. Only the beginning of each packet header is examined; for this reason, they can quickly decide packet flow because the packet is read only enough to determine whether it is a match. The characteristics of each of these inspection points determine whether the given packet should be allowed or denied. The use of ACLs is how packet filtering is conducted on Cisco devices; they are one of the focal points of this section.

Because every packet of every connection is checked against the access control rules, larger, complex packet-filtering rule bases could decrease performance of the device upon which they are applied. In addition, because packet filters can check only low-level attributes, they are not secure against malicious code hiding in the other layers.

The use of ACLs is one of the most confusing topics to many. As you see in the following section, a good understanding of ACLs can be less confusing when superimposed over a good analogy that relates to real life.

Grocery List Analogy

This analogy based on going grocery shopping is just one way to introduce and explain the concepts behind packet filtering via ACLs. You must consider certain key principles while considering this grocery list analogy. Table 5-1 begins the analogy by comparing packet filtering via ACLs with creating a grocery list.

Table 5-1 Access List/Grocery List Analogy Overview

In planning a turkey dinner, my wife and I discovered that we needed some things to finish cooking; we decided to make a list. This way, I would not forget what we needed when I went to the store. We knew that we had the following things, so they are not going on the grocery list:

• Turkey

• Stuffing

• Bread

• Cheese

In other words, I cannot buy these ingredients because my wife says that we do not need them. When I make a list of the things I am allowed to buy, my list is rather broad. I am happy with the list; it will do the job, so I am ready to head to the grocery store to get the following items:

• Milk

• Pie

• Potatoes

• Gravy

• **Buy nothing else**

This list is broad because there are many types of milk and many types of pies and because of how the list is written, I can buy any sort of pie I want because they are all allowed. She just might be in trouble because I happen to enjoy mincemeat pies and she does not! Because we need these ingredients, I can buy them. This broad grocery list analogy can relate directly to a standard ACL when expressed as follows:

[standard acl] Regular Grocery List
[deny] Turkey
[deny] Stuffing
[deny] Bread
[deny] Cheese
[permit] Milk
[permit] Pie
[permit] Potatoes
[permit] Gravy
[implicit deny all else] **Buy nothing else - end**

Notice the last line; my wife imposes this restriction on me because I have a great deal of affection for chocolate ice cream and on-sale items. Now, she does not need to actually say the words to me because I implicitly understand that I am not allowed to buy anything else.

I decide to show my list to my wife to make sure I did not miss anything. She reviews the list and decides I need more specific instructions because it is important to buy the right “kind” of groceries. She begins writing on my list:

[extended acl] Extended Grocery List (that is, wife’s version)
[deny] Turkey
[deny] Stuffing
[deny] Bread
[deny] Cheese
[permit] Milk – 2% White
[permit] Pie – Mrs. Smith’s Pumpkin
[deny] Potatoes – Red because a guest is allergic to this type
[permit] Potatoes – Any potatoes other than red is okay
[permit] Gravy - White Country
[implicit deny all] **Buy nothing else - end**

This type of list allows for a more granular level of filtering or, in my case, a more rewarding return home with the ingredients I was permitted to buy. Did you notice the difference between the two lists? The first list was rather broad and not specific at all, whereas the second list was extremely specific and told me not only exactly what not to buy, but more specifically what I was permitted to buy. Ultimately, the implicit understanding is that everything else is denied. You probably relate to the challenges of shopping when you are married and are also wondering how this relates to ACLs and packet filtering.

Packets have identifiable characteristics that access lists use to classify them and take an action—either permit or deny. Consider Example 5-1, which shows what a standard access list based on my analogy might look like.

Example 5-1 Analogy as a Standard Access List

access-list 10 deny any turkey
access-list 10 deny any stuffing
access-list 10 deny any bread
access-list 10 deny any cheese
access-list 10 permit any milk
access-list 10 permit any pie
access-list 10 permit any potatoes
access-list 10 permit any gravy

The standard access list in a Cisco device is primarily used to filter packets based on IP addresses. In addition, numbering them identifies a standard access list; specifically, they use 1–99 and 1300–1399 as identification numbers. If you were to take this example a technical level deeper and use IP addresses and subnets, it would look like Example 5-2 in a Cisco device’s configuration.

Example 5-2 Standard Access List Filtering Packets

access-list 10 permit any 192.168.10.0
access-list 10 permit any 192.168.20.0
access-list 10 permit any 192.168.30.0
access-list 10 permit any 192.168.40.0

You are probably wondering what happened to the deny statements. With Cisco ACLs, there is that implicit deny everything else at the end, which you do not “see” in the configuration. Thus, you do not have to enter the deny statements. You could take the standard ACL and expand it to be even more specific by using an extended ACL; this is what my wife did when she gave me more specific instructions.

Because they are designed to identify packets, ACLs fulfill many roles in the world of networking. After a packet is identified, it can be acted upon in some manner. This action might include sending it after a more important packet, or perhaps filtering the packet. Figure 5-4 shows the placement of an ACL to filter packets.

Figure 5-4 Placement of Packet Filters

If you consider the analogy of the entrance to my local grocery store to where the packets are entering the router, you can understand that nothing is getting in without permission! A secure router at the edge or perimeter of your network might be your first step/layer in a strong defense-in-depth methodology.

Limitations of Packet Filtering

It is time to talk about the drawbacks of using packet filtering. Certainly, you can stop many things with their use. Consider that you have a web server in a DMZ; all web/HTTP traffic must be able to reach this server. This server happens to run Microsoft’s IIS web server software, and an attacker decides to directly attack the web server using web/HTTP traffic. Because the attack targets vulnerabilities in IIS, the packets are allowed. So, although packet filtering is not enough security (on its own), it most certainly is another technique that will increase the depth of your networks security by creating another layer of protection.

The next section takes packet filtering a step further by discussing stateful packet inspection.