8.9 Writing and Applying Filters

In many vendor firewall implementations, the question of which interface to apply access-lists to is taken care of for the network administrator by the firewall software itself. Thus, the question of whether to filter traffic as it enters or leaves the network interface is taken care of transparently. In this section, we examine the logic of access-list placement and apply it to manual firewall configuration and at the same time shed some light on the operation of all firewall products.

Thus far we have discussed quite a bit about packet filters and stateful packet filters, but we have not discussed how to write them or where to apply them. How to write them is generally well documented on the vendor's Web site or in the documentation that has been included with the product. Although the syntax from product to product will vary, the effect and operators of the filtering statements have several characteristics in common no matter what the product.

8.9.1 There Is Some Method of Ordering the Rules

This may be as simple as having rule numbers or creating a list that is read from top to bottom. The important thing to remember is that all firewalls process rules in order.

8.9.2 There Is a Way of Defining the Source and Destination of the Packet

This is the most common filtering option and allows the network administrator to define what to apply the rules to. Sometimes, the network definition can be very large, as in "all IP networks;" narrower in scope, "My LAN only;" or very specific, "The HTTP server only."

Source and destination addresses are also relevant to the directionality of rules. Thus, you can apply different rules to packets from the "inside" destined to the "outside" than packets from the "outside" destined to the "inside." Each source and destination pair may also have different operations performed in each rule. So you may have multiple lines defining how packets from the "outside" to the "inside" are to be filtered. Each line has a different action to check or perform on the packets.

8.9.3 There Is a Way of Defining the Protocol to Be Checked

Firewalls can make filtering decisions based on virtually any field in the network and transport layer headers. One of the very important characteristics of a packet and a protocol is which transport layer protocol is being used. Typically, values here will include IP, UDP, TCP, and ICMP. TCP, UDP, and ICMP, however, are not the only protocols that have their own IP protocol value. Other protocols that may be commonly checked are some routing protocols and IPSec protocols.

Unlike IP addresses or ports, which may have a different source or destination values in normal operation, there is generally only a single protocol in use per session.

8.9.4 There Is a Way of Defining Which Port to Check For

If TCP or UDP is checked by the filter list, we must also define which port to check for, as ports are the way that application layer processes are identified in an IP packet. Generally, only the well-known ports are checked for as part of the destination of a packet. This is because when a client creates a connection to a remote host, the source port of the packet sent from the client to a remote host is a random port above 1024. Because port selection is essentially random, it is difficult to filter or identify which ports a client will pick.

8.9.5 Other Protocol Options May Be Present

Most firewalls will also have syntax to filter based upon other network or transport layer information. For example, there is generally a syntax that will allow the firewall to check for fragmented packets. Another common option is the option bits of a TCP session.

8.9.6 What to Do with the Packet Is Part of the Configuration

It is presumed that you are creating a firewall rule because you either want to permit the traffic, drop (deny) it, or forward it to some other location. It then stands to reason that there must be some way to define what to do with the packet in the rule. Generally, access-lists start with a rule that defines what traffic to always drop, such as clearly invalid traffic, then have a bunch of permit statements that define what traffic to allow through, then everything else is denied by the default "deny all" that is assumed at the bottom of every access-list.

8.9.7 An Option to Log Rule Matches Is Included on a Rule-by-Rule Basis

After finally creating a rule, you will then have the option to log matches to the rule. This is not the same as logging the contents of the packet; this is simply a way to tally the rules that are being matched the most. This can serve as a warning system if many deny packets are being matched or assist in the tuning of the firewall by placing the most often matched rules at the top of the list.

Based on these common features in all firewall rule configurations, we can now analyze a rule set enforcing the same policy from each vendor and describe the syntax used to implement the policy.

Below there are three rule sets for the same rule. Each of these pairs of rules allows clients on the internal network of 192.168.1.0/24 to access HTTP and HTTPS servers on the Internet. The first example is from the IPchains firewall software that is included by default on most Linux distributions. The second example is the same rule set created using a Cisco access-list and then applied to an interface. The third set is the same rule set included from a Check Point firewall. Relevant details from each rule set will be included following the example.

Linux IPchains example.

     ipchains -A output -p tcp -s 192.168.1.0/24 1024:65535     — destination-port 80 -j ACCEPT     ipchains -A output -p tcp -s 192.168.1.0/24 1024:65535     — destination-port 443 -j ACCEPT

Rules for IPchains are added one at a time to a rule set through the command line. The program used to do this is unsurprisingly called "ipchains;" thus, each rule above begins with a call to the ipchains program. The "-A" adds the rule to the rule set named "output." If you wish to delete or insert rules, a different argument would be included at this point. Once this framework is established, the rule set seems pretty straightforward; the protocol (-p) to examine is TCP and the source of the packet (-s) is matched at anything from the 192.168.1.0/24 network with a source port in the unprivileged range of 1024 through 65535. As the syntax of the statement indicates, another element of the TCP header is checked, and that is the destination port of the packet. It must match either the well-known HTTP server port of 80 or the well-known HTTPS server port of 443. While there is nothing prohibiting a Web site from running on port 81 or 82, the rules we are examining now would not allow traffic from our site to connect to them. Finally, the statement ends with the "-j" argument that informs us of which action the firewall is to accept when a packet matches a rule. In this case, the rule is clearly marked as accepting the packet. Other common options may be to deny the packet, redirect it, or address translate the packet, a term the Linux community describes as "masquerading" the packet.

Defining the source port for these rules is optional, but does reflect a long-held tradition that client processes, such as a request from a Web browser should only have source ports in the "unprivileged range," so called from the other long-standing tradition of server processes such as HTTP, SMTP, FTP, and others listening on ports lower than 1024. With the number of services available on the Internet today, the rule of server ports always being less than 1024 has long been abandoned, but clients still generally make requests with the higher order ports. In the Cisco example below, the source ports can also be defined but generally are not.

The example above would be what was entered from the command prompt to include these rules in a live server. The problem, of course, would be that if the server were power cycled, the rules would have to be reentered. In almost all instances, our rule set is going to be much more complicated than that above and thus the reentering of the rules from the command line is clearly an unacceptable option. In response, all Linux firewall operators instead create scripts that are run when the server is restarted that automatically re-add the firewalling rules each time the server is restarted.

The next list to examine is the same rule set as implemented on a Cisco router:

     access-list extended INPUT-LAN     permit tcp 192.168.1.0 0.0.0.255 any eq 80     permit tcp 192.168.1.0 0.0.0.255 any eq 443     interface eth0     description LAN side interface     access-group INPUT-LAN in

Just as in the IPchains example, we create a list that will serve as the reference point for our rules. In this case, our first statement creates an extended access-list named "INPUT-LAN" to remind us that we are going to place this list on our LAN interface to filter traffic as it enters the interface from the LAN. The list could be called anything we wish, but descriptive names are much more helpful in avoiding configuration errors on the part of memory-challenged humans.

Cisco routers support many types of access-lists for many types of protocols. In fact, if a layer 2 or layer 3 protocol can be sent across a Cisco router, there is most likely an access-list of some sort that can be configured for it. For IP protocols, the most common access-list types are standard or extended protocols. Of the two, the extended access-list is the most common. Standard access-lists only let you match IP packets according to the source of the packet. These are useful when configuring routing tables, but of only limited use for network security. Extended access-lists, on the other hand, allow you to match almost any IP or transport layer protocol and header information you would reasonably want to. This, of course, explains their usefulness in the configuration of filter lists.

The second line of the access-list defines that it will permit TCP traffic with a source of the 192.168.1.0/24 network to any destination address with a destination port of 80. This is the only section where those new to the Cisco way of thinking get confused. How does "192.168.1.0 0.0.0.255" relate to 192.168.1.0/24? In a Cisco extended access-list, the source and destination addresses must always be listed. Normally, when describing an address to be relevant, we must also include the subnet mask that defines the actual network. This is not the case in the Cisco operating system. Instead, we will define what is known as an "inverse mask," which is just the opposite of a subnet mask when written in decimal notation. So if a/24 subnet in decimal notation is known as 255.255.255.0, we will just turn all the 1s in that subnet mask to 0s and all the 0s to 1s and we will be left with the inverse mask of 0.0.0.255.

The third line applies the same rules, but this time to destination ports of 443, the HTTPS well-known port.

To understand the logic of an inverse mask, we must remember how a host uses a subnet mask. Normally, the 1s of a subnet mask are used by a host to do a logical "AND" to reveal what the network portion of an IP address is. This is used to determine if the destination of the packet is on a local or remote network from the perspective of the sending host. The same process is used in a Cisco access list, but this time we are interested in the hosts, not the networks. So to check the hosts for a particular network, we must place the 1s of the inverse mask to match the location of the host bits in a network mask.

The example here is known as a "named access-list," so called because an access-list called "INPUT-LAN" has been created. This replaces and is much easier to work with than the traditional way of creating an access-list on Cisco devices — that is, using numbered access-lists.

A numbered access-list that reflects the above rules would read as:

     access-list 101 permit tcp 192.168.1.0 0.0.0.255 any eq 80     access-list 101 permit tcp 192.168.1.0 0.0.0.255 any eq 443

Notice that the name has been removed, along with the identifier that the list is an "extended" access-list and replaced with the number 101. The list number 101 identifies the list as extended instead, as does any list between the numbers 100 and 199. After entering the number, the actual rules are included. While both named and numbered access-lists are equivalent in operation from the point of view of router software, it is generally easier to work with named access-lists.

Consider the following scenario: you have a router with 16 interfaces, each of which requires different rules applicable to the downstream networks. If you have an inbound and outbound list for each interface, you will have at least 32 access-lists to keep track of. While it can be done, it generally requires quite a bit of knowledge about the network environment or extensive note-keeping. You are looking at interface 0/1/4 and you see that access-list 186 has been applied to it. You scroll through the configuration, past the first 86 access-list entries and finally get to 186. What was it you were looking for again? It is so much easier to be able to scan through a router configuration and see a descriptive name applied to an interface or the list itself. In very large installations, it is also worthwhile noting that named access-lists are not limited to 100 per router as are numbered extended access-lists.

Cisco access-list rules are applied during normal router configuration and are automatically applied when the router restarts. Technically speaking, the actual application of the rules is much the same as the Linux IPchains (The Cisco IOS and Linux share the same UNIX roots), but the process is hidden from the user. From the point of view of the network administrator, the rules are written, applied to the appropriate network interface, and then automatically applied each time the router is restarted.

The screenshot in Exhibit 12 is a very simple configuration for the Check Point firewall that was created using the Check Point policy editor and matches the rules we have created above for the Linux and Cisco operating systems. The policy editor is the Check Point GUI that allows users to easily create rules and apply them to the firewall application. The major difference between the Check Point and the other examples we have seen is that Check Point allows users to create objects such as "lan1," "Internet," and "http" that describe the elements that we are configuring. Thus, in our example, "lan1" has been configured to represent the IP address range 192.168.0.0/24 while "http" has been configured to represent the TCP port 80. Once these objects have been defined, it is a straightforward matter to create rules using these objects.

Exhibit 12: Check Point Policy Editor

click to expand

One of the primary advantages of using Check Point is that a great number of objects are predefined for the advantage of users. Check Point can also determine the likely network objects, such as the address range of the LAN network. While this example does not show it, these objects are particularly handy for complicated protocol groups such as those that are used to firewall multimedia and real-time protocols.

For instructional purposes, Check Point further reinforces the basic concepts of firewall operation. The "from" and "to" networks are defined, along with the protocol service. From here a decision must be made to accept or drop the packet and options are provided to log it.

In Exhibit 12, note that there is also an "Install On" option. This is another particularly useful feature of Check Point (although this functionality is found on many firewall products). The firewall administrator can define and manage multiple rule sets for distributed firewalls and update them from a single location. While the Check Point, Linux IPTables, and Cisco methods of packet filtering are very similar between vendors, it is the additional features that ease configuration and management that make dedicated firewall products, like Check Point and others, the more popular option for large deployments.