Firewall Forget-Me-Nots for Network Administrators: How to Avoid Common Pitfalls

John Kemp
Senior Security Engineer
kemp@ns.uoregon.edu

Network administrators who are setting up firewalls for the first time can sometimes encounter problems that they have never seen before. Because a firewall is usually deployed at a critical point within the network infrastructure, these problems can quickly take on a high degree of importance. In this article, we discuss a few of the more common pitfalls an administrator might encounter when performing a new firewall deployment.

Least Privilege

The concept of "least privilege" is one of the most important concepts in computer security. Simply put, the idea of least privilege is that you should provide no more access to a network resource than is absolutely necessary to perform the task at hand. In the case of firewall deployments, this concept is usually implemented by creating distinct network segments or zones: an outside zone, a DMZ or buffer zone, and a private zone.

The DMZ segment (demilitarized zone or buffer zone) is used to allow for access from the outside zone to services that are required by the public at large. Public websites and email relay servers are some of the things you would expect to see on a DMZ. To guarantee least privilege, only the incoming connections that are required to provide for those specific services are permitted to reach the DMZ, while all other incoming connections are blocked.

A private local network segment is also usually required, in order to provide a network segment that has even greater security than the DMZ. This is the local network segment. No incoming connections to this segment are allowed. If a public service is required, administrators must relocate that service to the DMZ. Administrators can significantly weaken their security when they punch holes in a firewall rule set that opens access to services on the private network. For example, if incoming connections are allowed for web servers on the private segment, a firewall loses much of its effectiveness.

Fig. 1: Standard topology for firewall with DMZ

Rule Set Specifications

Specifying firewall rules can be somewhat more complicated than simply specifying "source, destination, and port." First, a specific protocol needs to be specified. In this case, the TCP protocol is being used. In addition, the range of values allowed for the source port has been left unspecified. Typically this will be set to either 0-65535 or 1024-65535. And finally, direction needs to be specified. Direction can be incoming, outgoing, or reference specific zones created by the firewall. For example, direction can be FROM the private segment TO the external segment, or FROM the private segment TO the DMZ segment. Finally, the action taken by the rule needs to be specified. A rule action might be any of the following: accept, reject, deny, tunnel, log.

Most firewalls provide an interface that allows for the creation of these rules. In the absence of a hardware GUI interface, a spreadsheet can be used for drafting rule sets. All of the fields can then be specified: description, source zone, destination zone, protocol type, source address range, source port range, destination address range, destination port range, and action.

Firewalls typically also have an implicit set of capabilities that the administrator must be aware of. These kinds of behaviors can be confusing to someone who is not familiar with the particular brand of firewall that is being deployed. For example, there may be a "default DENY" rule that exists within the firewall, but which is not listed in the GUI. Additionally, the order in which rules are processed can sometimes be opaque. All of these things must be understood if policy is going to be implemented correctly.

Simple Network Protocols

A firewall is a device that filters network traffic. In order to understand if a firewall is operating correctly, one must also understand something about how network traffic travels across the network under normal circumstances. Some of the network protocols that should be understood are: ARP, ICMP, and DHCP.

ARP

The ARP protocol is a layer-2 protocol, that is, a protocol that operates below the IP layer. ARP stands for Address Resolution Protocol. ARP is used by the devices on a local network segment for communication; it is the mechanism that is used to translate 32-bit IP addresses into the 48-bit Ethernet hardware addresses that are hard-coded into network interfaces, and that are used for local Ethernet communication.

Problems relating to ARP usually occur during the initial deployment of a firewall, and they occur on devices that are not updating their ARP caches correctly. For example, if a firewall is deployed in routed mode, it may end up taking the place of the IP address that was previously in use by the router interface. In this case, the ARP mapping for all devices behind the router should automatically update their mapping for that particular IP address almost immediately after the new firewall is put in place. If a host behind the firewall has an old mapping stuck in its ARP cache, it may not be able to send packets through the firewall. It will be able to communicate with local hosts, but will not be able to send traffic through the firewall.

In almost every case, a reboot of a device will force the device to clear its ARP cache. In some cases, commands can be used to manually clear the cache of a device. This problem is usually seen on older machines, and on some networking equipment. In most cases, cache entries automatically time out, and are updated fairly quickly.

DHCP

DHCP is the Dynamic Host Configuration Protocol. DHCP is used to automatically assign network information to devices. This information usually includes IP address, subnet mask, gateway address, domain name, and the location of DNS servers. It is commonly the case that an organization will have a few DHCP servers that are centrally managed to enable handing out this kind of information. Not all machines require DHCP. Some machines rely on DHCP to be able to boot and to continue to retain a fully functioning IP address; other machines may have their network information statically configured and will not utilize DHCP.

During the design of a new firewall installation, the administrators will have to determine how they wish to handle DHCP. In a transparent firewall configuration, the firewall usually does not interfere with the operation of the DHCP protocol. In a routed firewall configuration however, the firewall is usually configured to operate as a DHCP relay agent--that is, an intermediary who passes on DHCP requests to the central servers. In a NAT configuration, the firewall itself may be configured to operate as a DHCP server, and will be configured to hand out private addresses to machines on the local subnet. Usually the mode of operation of the firewall will dictate which of the above choices is made with respect to the operation of DHCP.

The most interesting of these modes of operation is the transparent mode. Administrators must be careful to avoid crafting firewall rules that interfere with the operation of DHCP. Since initial client requests are sent to a broadcast address, such as 255.255.255.255, and may also contain a private address or an initial address such as 0.0.0.0, it is easy to mistakenly block these types of addresses in firewall rules. One of the first tasks that an administrator will perform after installing a new firewall is testing the correct operation of DHCP by booting a dynamic client machine.

Failure to allow for local DHCP relay agents is another common problem in transparent mode installations. The initial DHCP relay responses may come from either a virtual interface address of the router, or from the actual IP address of the router. This is a common occurrence in networks where redundant routers are being used. For example, a local client might expect to receive initial DHCP replies from the IP address 111.111.111.1, or from 111.111.111.2 or 111.111.111.3. Firewall rules need to be designed so that they allow for DHCP replies from the relay agents as well as the central DHCP servers.

ICMP

ICMP stands for Internet Control Message Protocol. ICMP messages are used to pass low-level operational messages across the network. ICMP messages are part of the normal, everyday operation of a network. There are a number of categories and sub-categories of messages, which are referred to as "types" and "codes." Some of the more common types of messages are listed below:

The most common application that uses ICMP is ping. The ping application is used to send ICMP Echo Request messages to remote hosts to see if they are reachable. In response, the host sends an ICMP Echo Reply message. Another popular application that utilizes ICMP is the trace-route program. Traceroute sends out UDP messages with TTL (time-to-live) settings that are chosen so as to expire at each hop along a network path. An ICMP Time Exceeded message is returned at each hop along the way.

ICMP has been implicated as a source of abuse in a number of situations. Ping can be used by an attacker to do reconnaissance, to send incoming ICMP Echo Requests which show which hosts are reachable on the network. In more serious cases, ICMP has been abused through the transmission of unusually crafted packets that can cause a remote host to crash, a ping-of-death. Other attacks have been performed that utilize spoofed source addresses and local network broadcast destination addresses to cause ICMP traffic flooding.

The most common error that a firewall administrator can make when dealing with ICMP is to assume that all ICMP should be blocked. Outgoing messages such as Echo Request are always allowed. But a number of incoming messages such as Echo Reply, TTL Exceeded, Port Unreachable, and Destination Unreachable need to be allowed for applications to continue to function normally. For this reason, ICMP is usually handled by selectively blocking a few, but not all, of the incoming message types. Blocking incoming ICMP Echo Requests is a common practice. And special features that are designed to prevent ping-of-death and directed-broadcast attacks can be enabled on most firewalls to deal with the most common sources of abuse.

Complex Network Protocols

Many network protocols operate in a very straightforward manner. A client sends a request, and a server sends a reply. Some network protocols, however, are more complicated than that. A client might send a request to one port, and the server might respond by asking to open a connection on a different port. In addition, more complex network protocols can include IP addresses within their data payloads, which creates a dependency not only upon the originating client address, but also upon the IP addresses contained within the protocol messages.

The most common example of protocol complexity is the FTP protocol. The original design of the FTP protocol operates in a mode known as ACTIVE FTP. The client opens a TCP connection to port 21 on the server, the command port. The server responds by opening a new connection with a source port of 20, the FTP data port, but targets a new destination port on the client. Early packet filters and firewalls were not able to recognize that these incoming connections were related to the original client requests. The creation of a PASSIVE FTP mode, where connections are always initiated from the client side, went a long way towards resolving this issue. At this point, most firewalls are capable of supporting either mode of FTP.

A particular brand of firewall may or may not support protocol filtering for one of the more complex protocols. For this reason, it pays to plan ahead when choosing a firewall platform. Administrators who plan on using NAT (network address translation) need to pay particular attention here since private addresses can add an additional layer of complexity to the handling of these types of protocols. Some of the protocol types to be aware of are: RTSP (Real-Time Streaming Protocol for RealAudio, QuickTime, and IPTV), SQL*Net (oracle), H.323 (Netmeeting, CU-SeeMe, and VOIP), SIP (Session Initiation Protocol), and TFTP.