Without a firewall of some sort, an organization's network is wide open to access by anyone connected to the same public network. Packet filtering is one of the most common methods of building a TCP/IP firewall. This technique lets you control the movement of IP packets according to the packet contents.
Packet filtering filters IP packets based on a set of rules you define at a router or other packet-forwarding device, such as a Windows NT server. You can key packet-filtering rules to a combination of host address, protocol, application, direction of connection, and message type. The specifics of implementing packet-filtering rules depend on your particular equipment and vendor.
To understand packet-filtering operation, you need to understand the relationship between the TCP/IP protocol layers. You also need to know how packet filtering relates specifically to various TCP/IP protocols and have some guidelines for filtering IP packets.
The TCP/IP Protocol Stack
Figure 1, page 84, shows the three layers of the TCP/IP protocol stack involved in packet filtering. The entire TCP/IP stack comprises four layers.
The network access protocols define the network infrastructure over which TCP/IP communication occurs. Protocols in the Network Access layer include all deployed network topologies and technologies, including dedicated and dial-up point-to-point links, asymmetric digital subscriber line (ADSL), asynchronous transfer mode (ATM), frame relay, and all LANs. Figure 1 doesn't include the Network Access layer because the layer is irrelevant to the discussion of packet filtering.
The Internet layer is roughly equivalent to the Open System Interconnection (OSI) Network layer and is responsible primarily for routing. IP is the protocol for device-to-device communication, such as host-to-router and router-to-router. Packet-filtering rules typically apply to IP and the protocols carried in IP datagrams.
The Transport layer is roughly equivalent to the OSI Transport layer and is responsible for host-to-host communications. The communications protocols for this layer are TCP and UDP, which provide a connection-oriented (virtual circuit) and connectionless (datagram) service, respectively. An IP packet carries a TCP segment or UDP datagram. (As Figure 1 shows and we discuss later, some non-Transport layer protocols also place their data directly into an IP packet.)
The Application layer defines the higher-layer user application protocols, such as HTTP for the Web and SMTP and POP for email. Each application protocol is associated with one or both of the Transport layer protocols.
Packet Filtering and IP
All TCP/IP packet filtering starts with an IP packet. Three IP packet fields are crucial to filtering. The source address is the 32-bit IP address of the host that sent the packet and generated the information in it. The destination address is the 32-bit IP address of the intended destination host expected to receive the packet and the information the packet carries. The Protocol Identifier (PID) is the identifier of the protocol information the IP packet carries. You can base packet filtering on any or all of these fields. Using the source or destination address, for example, you can block all packets from an address or set of addresses, and you can route to a set of addresses those packets you let enter.
Of interest is the PID field. An IP packet carries data directly for many protocols, including
- Internet Control Message Protocol (ICMP)—an essential part of IP that carries IP-related error and informational messages (PID=1)
- TCP—connection-oriented, reliable host-to-host communication (PID=6)
- UDP—connectionless, unreliable host-to-host communication (PID=17)
- Generic Routing Encapsulation (GRE)—an encapsulation protocol commonly used in VPNs (PID=47)
- IP Encapsulating Security Payload (ESP)—part of the IP Security (IPSec) protocol suite that provides data encryption and authentication of data origin (PID=50)
- IP Authentication Header (AH)—part of IPSec that authenticates the origin of the packet's data (PID=51)
- Open Shortest Path First (OSPF)—the primary routing protocol for internal IP network routing (PID=89)
The Internet Assigned Numbers Authority (IANA) maintains a list of all protocol numbers at http://www.isi.edu/in-notes/iana/assignments/protocol-numbers.
You need to know which protocols you need to filter at your site and which your packet-filtering device supports. Some packet filters allow filtering based only on higher-layer protocols already known to the filter's software; others let you specify the PID and thus filter based on new or unknown protocols.
Packet Filtering and TCP/UDP
If you filter packets based on a TCP- or UDP-based application, you need to be familiar with ports. On an IP network, four parameters uniquely identify host-to-host communication using TCP or UDP: source IP address, source port number, destination IP address, and destination port number.
The port number identifies the application running over TCP or UDP. Port numbers from 0 to 1023 are called well-known ports. These port numbers are assigned to the server side of an application. On most systems, only processes with a high level of privilege (e.g., root, administrator) can use well-known ports.
Port numbers from 1024 to 49151 are called registered ports and, as a convenience to the Internet community, are publicly defined to avoid vendor conflicts. Server and client applications can use registered ports.
The IANA calls the remaining port numbers, from 49152 to 65535, dynamic and/or private ports. Any client or server can freely use dynamic ports. Table 1 lists some common port numbers and the protocols usually associated with them.
By controlling the port numbers allowed through your packet filter, you can control which external applications and services internal users can access and which internal applications and services external users can access. The IANA maintains a list of TCP/UDP port numbers at http://www.isi.edu/in-notes/iana/assignments/port-numbers.
Another factor to consider when you set up packet filter rules for TCP is the direction of the connection. TCP hosts must establish a virtual connection before they can exchange data. The connection setup process uses a three-way handshake, so called because setup requires the exchange of three TCP segments to synchronize the two hosts' sequence and acknowledge numbers. The client typically initiates a connection to the server, but some notable exceptions exist. For example, although the FTP client initiates an FTP-control TCP connection with an FTP server, the FTP server initiates the FTP-data connection with the client.
Figure 2 shows a scenario in which an NT server acts as a router, forwarding packets between a user site and an ISP. In this context, inbound refers to packets coming into the user network from the outside and outbound refers to packets leaving the user network for the outside. When you configure the packet filter, you can restrict not only applications but also the direction of the connection. So, you can restrict incoming connections, for example, while ensuring that internal users can establish TCP connections to outside servers.
Packet-Filtering Guidelines for TCP, UDP, and IP
You need to base your packet-filtering rules and policies on two guidelines. First, have your packet-filtering software block everything it doesn't explicitly allow. Second, set up your packet filters so that they not only protect your site from an attack by an outside agent but also block all outbound packets that an agent might use to launch an attack against another site. If every site took this approach, the Internet would be much safer. More specific strategies for filtering IP packets and TCP/UDP applications include the following.
Block all inbound IP packets whose source address field contains your network identifier (NET_ID). Packets whose source address field contains your NET_ID should originate on your network; if such a packet originates on an external network, someone is attempting address spoofing. In addition, block all outbound IP packets whose source address field doesn't contain your NET_ID. If the source address field doesn't contain your NET_ID, someone on your network is attempting address spoofing on another network. You also need to block all inbound and outbound IP packets whose destination address field contains a broadcast address (i.e., a host identifier whose value is all 1s or 255—for example, 208.162.187.255).
The Internet Engineering Task Force (IETF) Request for Comments (RFC) 1918 (http://www.ietf.org/rfc/rfc1918.txt) defines the following IP addresses that you can use on a private network but that won't route on the Internet: 10.0.0.0, 172.16.0.0 through 172.31.0.0, and 192.168.0.0 through 192.168.255.0. Block all inbound and outbound IP packets whose destination or source address field contains an address in these ranges or the IP loopback address (NET_ID 127.0.0.0).
Allow inbound packets directed to a network service such as HTTP, FTP, SMTP, POP, or Network News Transfer Protocol (NNTP) to connect only to a public server that supports that service. For example, permit an inbound TCP segment with a destination port number of 80 (HTTP) to communicate only with your Web server. This practice prevents external users from connecting to a rogue server that an internal user has put on your network.
DNS requires particular care. Typical DNS queries run over UDP; DNS zone transfers (the transfer of an entire DNS data file) use TCP. Set your firewall to allow DNS zone transfers between only your primary and secondary DNS servers. This procedure is a standard precaution against attacks that first send bogus DNS information to the secondary DNS server, then follow up with a Denial of Service (DoS) attack that knocks the primary DNS server off the air.
Packet Filtering and ICMP
Although ICMP is an integral part of IP, it is a standalone protocol, and ICMP messages are filtered separately from IP packets. ICMP's role is to notify an IP host of errors or other information. Several attacks use ICMP messages, including the Ping of Death (gigantic ping messages that overflow buffers), Smurf (using ping messages and the IP broadcast address to flood a victim's Internet access link), and ICMP Redirect attacks (sending bogus messages that redirect traffic away from a trusted site). All ICMP messages are useful (but not necessarily essential) for network operation, but attackers can also abuse nearly all ICMP messages. The following suggestions will help you filter ICMP messages.
Enable Echo and Echo Reply only if you want to support ping, which many sites don't. Ping exposes you to potential Smurf attacks, but blocking IP address spoofing and use of the broadcast address (as we described earlier) help prevent Smurf attacks. The Windows implementation of traceroute (i.e., tracert) also uses Echo and Echo Reply messages.
Allow inbound and outbound Destination Unreachable and Network Unreachable messages, and allow inbound Port Unreachable messages. Outbound Port Unreachable is more problematic. If you enable this option, you're susceptible to an attacker using UDP port scanning against you. But disabling outbound Port Unreachable means that incoming client connections to an invalid port will time out rather than close immediately. We prefer to block the option, but you need to be aware of the trade-off and make your own decision. You probably need to allow inbound and outbound Source Quench messages (which you use for flow control). However, you must recognize that malicious users can also use these messages as part of some attacks. You'll want to block Redirect, Router Advertisement, and Router Selection messages.
Allow Timestamp and Timestamp Reply, but realize that a sophisticated attacker might be able to use ping or timestamp messages to predict the value of quasi random counters such as those that determine the initial sequence number for TCP connections. If an attacker guesses the initial sequence number, you become susceptible to various IP spoofing attacks.
You probably need to allow inbound and outbound Time Exceeded messages (identifying that the packet lifetime or reassembly timer has expired) and Parameter Problem messages. You need to enable Traceroute messages only if you want external users' traceroute commands to work.
Be aware that ICMP defines message types and subtypes. ICMP message type 3, for example, is Destination Unreachable. That message type has several subtypes that a code specifies: code=0 is Network Unreachable, code=1 is Host Unreachable, and code=3 is Port Unreachable. Be sure that your packet filter provides the granularity you need to implement your site's security policies. The IANA list of ICMP messages is at http://www.isi.edu/in-notes/iana/assignments/icmp-parameters.
Packet Filtering in the Real World
You can implement packet filtering in a router, packet-forwarding server, or firewall. Routers, such as those from Cisco Systems, Bay Networks, and Ascend, have their own OSs and command-line interfaces. One downside to packet filtering is that correctly creating a rule set is difficult, and a router's arcane syntax exacerbates that difficulty. A packet-forwarding server, such as an NT Server machine running RRAS, or a firewall, such as Check Point Software Technologies' FireWall-1, provides a GUI to configure the packet-filtering rule set, which greatly simplifies the task.
Of course, packet filtering isn't the only way to protect a local network. Another approach is to use a proxy server. Proxy servers don't filter packets per se. When a local user attempts to connect to an external server, a connection establishes to the proxy server, which in turn connects to the external server. A similar operation occurs when an external user connects to an internal server. Most proxy servers benefit from use with packet filtering. (For more information about proxy servers, see Mark Minasi, "Get Wired," July 1998.)
Packet filtering is a powerful security tool. But to build good packet-filter rule sets that work, you must understand the TCP/IP protocol suite and how the individual protocols work and interact. An informative book about packet filtering is D. Brent Chapman and Elizabeth D. Zwicky, Building Internet Firewalls (O'Reilly & Associates, 1995).
