Packet Filtering and
Microsoft Routing and Remote Access Service

Firewalls to protect an organization's connection to the Internet or to protect extranets/intranets are commonplace today. 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 about the most common method of building a Transmission Control Protocol/Internet Protocol (TCP/IP) firewall. Whether managed by some sort of GUI or command line interface, this scheme filters IP packets based upon a set of rules that can be defined at a router or other packet forwarding device, such as an NT server. The implementation of the packet filtering ruleset will depend upon the specific equipment and the vendor.

The first part of this article will define packet filtering, relate it specifically to various TCP/IP protocols, and provide some guidelines for filtering IP packets. The second part will discuss a specific packet filtering application using the Windows NT-based Routing and Remote Access Service.

Figure 1 shows the layers of the TCP/IP protocol stack relevant to packet filtering. Despite the name, the protocol stack obviously refers to much more than a single protocol pair and much more than a single protocol layer. The TCP/IP stack comprises four layers:

• The Network Access Protocols define the underlying network infrastructure over which TCP/IP communications occurs. Protocols at this layer include all network topologies and technologies currently deployed, including dedicated and dial-up point-to-point links, asymmetric digital subscriber line (ADSL), Asynchronous Transfer Mode (ATM), frame relay, and all local area networks (LANs).
• The Internet Layer is roughly equivalent to the Open Systems Interconnection (OSI) Network Layer, primarily responsible for routing. IP is the protocol used for device-to-device communications, 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 communication. The communications protocols here are TCP and the User Datagram Protocol (UDP), which provide a connection-oriented (virtual circuit) and connectionless (datagram) service, respectively. A TCP segment or UDP datagram will be carried in an IP packet. (As the diagram suggests, some other protocols place their data directly in an IP packet although they are not Transport Layer protocols, per se; this is discussed in more detail below).
• The Application Layer defines the higher layer user application protocols, such as the Hypertext Transfer Protocol (HTTP) for the Web, and the Simple Mail Transfer Protocol (SMTP) and Post Office Protocol (POP) for e-mail. As the figure shows, application protocols are associated with a Transport Layer protocol.

Packet filtering is used to control the movement of IP packets based upon the contents of the packet. Packet filtering rules can be keyed to some combination of host address, protocol, type of application, direction of connection, and message type. To understand the operation of any packet filtering, the relationship between the protocol layers must first be understood.

For TCP/IP packet filtering, all packets have at least one thing in common -- specifically, all filtering starts with an IP packet. There are three fields of an IP packet that are critical for filtering purposes:

• Source Address: The 32-bit IP address of the host sending the packet and generating the information carried within the packet.
• Destination Address: The 32-bit IP address of the intended destination host, expected to receive the packet and the information carried within it.
• Protocol Identifier (PID): The identifier of the higher layer protocol information carried directly in the IP packet.

Packet filtering can be performed based on any of the fields listed above. It is relatively obvious how filtering can be done on an address basis; one can block, for example, all packets from a particular address or set of addresses, and/or can allow packets to enter and be routed to some set of addresses.

Of more interest is the PID field. There are many protocols for which data is carried directly in an IP packet, such as:

• Internet Control Message Protocol (ICMP): An essential part of IP, carrying IP-related error and informational messages (PID=1).
• TCP: Provides connection-oriented, reliable host-to-host communication (PID=6).
• UDP: Provides connectionless, unreliable host-to-host communication (PID=17).
• Generic Routing Encapsulation (GRE): An encapsulation protocol commonly used in virtual private networks, or VPNs (PID=47).
• IP Encapsulating Security Payload (ESP): Part of the IP Security Protocol (IPsec) suite, providing encryption of data and authentication of the origin of the data (PID=50).
• IP Authentication Header (AH): Part of IPsec, used for authenticating the origin of the packet's data (PID=51).
• Open Shortest Path First (OSPF): The primary routing protocol used today for internal IP network routing (PID=89).

The Internet Assigned Numbers Authority (IANA) maintains a list of all protocol numbers on the Web at http://www.isi.edu/in-notes/iana/assignments/protocol-numbers.

It is important to know which protocols you need to filter at your site and which are supported by your packet filtering device. Some packet filters will only allow filtering based upon higher-layer protocols already known to the filter's software; others allow you to specify the PID, allowing the definition of new or unknown protocols.

Presuming that you are performing packet filtering based on a TCP- or UDP-based application, you need to be familiar with ports. Host-to-host communication using either TCP or UDP is uniquely identified on an IP network by the four parameters (source IP address, source port number, destination IP address, destination port number).

The port number identifies the application that is running over TCP or UDP. Port numbers in the range 0-1023 are called Well Known Ports. These port numbers are assigned to the server side of an application and, on most systems, can only be used by processes with a high level of privilege (such as root or administrator). Port numbers in the range 1024-49151 are called Registered Ports, and these are numbers that have been publicly defined as a convenience for the Internet community to avoid vendor conflicts. Server or client applications can use the port numbers in this range. The remaining port numbers, in the range 49152-65535, are called Dynamic and/or Private Ports and can be used freely by any client or server. Some sample port numbers, and the protocol(s) with which they are most commonly associated, are:

By controlling the port numbers allowed through your packet filter, you can control which external applications and services your internal users can access, as well as which internal applications and services can be accessed by external users. The IANA maintains a list of TCP/UDP port numbers on the Web at http://www.isi.edu/in-notes/iana/assignments/port-numbers.

An additional factor to be considered when setting up packet filter rules for TCP is the "direction" of the connection. TCP hosts must establish a virtual connection before they can exchange data. This setup process uses a so-called three-way handshake because it requires the exchange of three TCP segments to synchronize the two hosts' sequence and acknowledge numbers. In general, the client initiates a connection to the server although there are some notable exceptions to this rule; while the FTP client initiates an FTP-control TCP connection with an FTP server, for example, it is the FTP server that initiates the FTP-data connection to the client.

FIGURE 2. Sample scenario using an NT server running RRAS between a user site and ISP.

Figure 2 shows a sample scenario where an NT server is acting in the role of a router, forwarding packets between a user site and an Internet service provider (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 configuring the packet filter, you can restrict not just applications, then, but also the direction of the connection. Thus, you can ensure, for example, that internal users can establish TCP connections to servers on the outside but restrict incoming connections.

There are two philosophical design issues that should form the basis for your packet filtering rules and policies:

• The packet filtering software should block everything that is not explicitly allowed.
• Your packet filters should be set up in such a way that they not only protect your site from an attack by an outside agent, but they should also block any packets that might be used to launch an attack against another site. If every site took this approach, the Internet would be a lot safer; after all, attacks are launched from someplace.

Using the protocol information presented so far, here are some basic guidelines for filtering IP packets and TCP/UDP applications:

• Block any inbound IP packet where the packet's source address (SA) field contains your network identifier (NET_ID). (If the SA field contains your NET_ID, it should have originated on your network rather than an external network; someone is attempting address spoofing.)
• Block any outbound IP packet where the SA field does not contain your network identifier. (If the SA field does not contains your NET_ID, someone on your network is attempting address spoofing on another network.)
• Block any inbound or outbound IP packet where the packet's destination address (DA) field contains a broadcast address (i.e., a host identifier with all 1s, or 255; e.g., 208.162.187.255).
• Request for Comments (RFC) 1918 defines IP addresses that may be used on a private network and will not be routed on the Internet; these addresses are 10.0.0.0, 172.16.0.0-172.31.0.0, and 192.168.0.0-192.168.255.0. Block any inbound or outbound IP packet where the DA or SA field contains any address in these ranges or the IP loopback address (NET_ID 127.0.0.0).
• Inbound packets directed to a network service such as HTTP, FTP, SMTP, POP, or NNTP, should be restricted to only connecting to a public server supporting that service. For example, an inbound TCP segment with a destination port number 80 (HTTP) should only be allowed to communicate with your Web server. (In this way, external users cannot connect to a "rogue" server that some internal user puts on your network.)
• The DNS requires particular care. Normal DNS queries run over UDP while DNS zone transfers (the transfer of an entire DNS data file) uses TCP. Set your firewall to allow DNS zone transfers only between your primary and secondary DNS servers. (This is a precaution against instances where an attacker transfers bogus information to the secondary DNS server and then knocks the primary DNS server off the air with some sort of denial-of-service attack.)

Although an integral part of IP, ICMP is a stand-alone protocol and ICMP messages are filtered separately from IP packets. The role of ICMP is to notify an IP host of some error or other information. There are several attacks that utilize 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 redirecting traffic away from a trusted site). All of the ICMP messages are useful (but not necessarily essential) for network operation, but nearly all of them can also be abused by an attacker. Some suggestions for ICMP message filtering are:

• Echo and Echo Reply should be enabled only if you want to support Ping, and many sites do not. Ping opens you up to a potential SMURF attack, but blocking IP address spoofing and the use of the broadcast address (described above) will help prevent a SMURF attack. Echo and Echo Reply messages are also used in the Windows implementation of tracert (traceroute).
• Destination Unreachable and Network Unreachable should be allowed both inbound and outbound, as should inbound Port Unreachable. Outbound Port Unreachable is more problematic; if enabled, you are susceptible to an attacker using UDP port scanning against you but disabling this will mean that incoming client connections to an invalid port will time out rather than close immediately. My preference is to block it but it's a tradeoff.
• Source Quench messages, used for flow control, should probably be allowed but they can also be used as part of some attacks.
• Redirect, Router Advertisement, and Router Selection messages should be blocked.
• Timestamp and Timestamp Reply should be allowed but a really sophisticated attack might be able to use Ping and/or timestamp messages to try to predict the value of quasi-random counters used, for example, to determine the initial sequence number (ISN) for TCP connections. If an attacker can guess the ISN, you become susceptible to various IP spoofing attacks.
• Time Exceeded messages (indicating that the packet lifetime or reassembly timer has expired) should probably be allowed.
• Traceroute messages should only be enabled if you want external users' traceroute (tracert in Win9x and NT) command to work.
• Parameter Problem messages should be allowed.

Be aware that ICMP defines message types and subtypes. The ICMP message type 3, for example, is Destination Unreachable. That message type has several subtypes specified by a code; code=0 is Network Unreachable, code=1 is Host Unreachable, and code=3 is Port Unreachable. Be sure that your packet filter can get down to the granularity that you require for your site's security policies. The IANA list of ICMP messages can be found at http://www.isi.edu/in-notes/iana/assignments/icmp-parameters.

There are several ways in which packet filtering can be implemented. One common approach is to use the packet filtering or access control list (ACL) capability of most routers. Windows NT servers can also do some rudimentary packet filtering as one of the advanced TCP/IP options and more sophisticated packet filtering if the Routing and Remote Access Service (RRAS) update is installed on the NT Server. RRAS has several features, including support for routing protocols such as RIPv2 for IP and OSPF, demand dial routing, server-to-server PPTP, and RADIUS client support. For our purposes, the packet filtering features of RRAS will be examined. Figure 2 showed one scenario where RRAS might be used. In this figure, an NT server acts essentially like a router, providing the interconnection between a user's site and an ISP. The NT server's packet forwarding capabilities allow it to act like a router; RRAS is employed for its packet filtering services to protect the site's connection to the Internet. In this scenario, one of the server's network interfaces connects to the Ethernet LAN (at 192.168.12.1) and the other network interface connects to some wide area network (WAN) access to the ISP (at 192.168.13.1) interfaces. (For reasons of security and privacy, actual IP network numbers are not shown in this diagram and have been replaced with RFC 1918 private IP addresses instead.)

FIGURE 3. Sample scenario using an NT server running RRAS between a user site and an ISP's on-premises router.

Another deployment scenario for a RRAS-based packet filter might be in the case where the user has no access to the router connecting the site to the ISP (Figure 3). In some cases, a small business might be connected to the Internet via an ISP which also provides the router. The router configuration cannot be modified by the user because the ISP owns the router, hence the router's packet filtering capabilities go unused. In this case, an NT server running RRAS might be setup with two LAN interface cards and sit between the router and the user's LAN.

In either case, as shown in Figures 2 and 3, the user's site has its own Web (HTTP), e-mail (SMTP/POP3), and primary DNS server (for convenience, all are at 192.168.12.20). A secondary DNS server, at 204.70.25.234, is hosted by the ISP. The paragraphs below show the steps for setting up the following packet filter rules (a subset of the packet filtering guidelines above):

1. Block any inbound IP packet where the SA field contains a NET_ID of 192.168.12.0. (Prevent source address spoofing.)
2. Block any outbound IP packet where the SA field does not contain a the local NET_ID 192.168.12.0. (Prevent someone on your network from address spoofing)
3. Allow incoming HTTP, SMTP, and POP3 connections to the server at address 192.168.12.20.
4. Allow local workstations too establish HTTP connections to external Web servers.
5. Allow local workstations to make DNS queries to external name servers.
6. Allow DNS zone transfers between the primary and secondary DNS servers.

The following steps were used to create the packet filtering to implement the ruleset above, using the NT Server Routing and RAS Admin utility:

Screen 1: Routing and RAS Admin main screen.

1. Start the RRAS Admin utility (Screen 1). Expand the IP Routing folder highlight Summary and view the two interfaces installed in the NT Server. In this scenario, "[1] Intel 8..." is the external WAN interface (192.168.13.1) and "[4] 3Com ..." is the internal LAN interface (192.168.12.1).
   
   

   Screen 2: IP Configuration dialog box.

   
   
   
2. Enable packet filtering on both interfaces by right clicking on the interface and selecting Configure IP parameters (Screen 2).
   
   

   Screen 3: IP Packet Filters Configuration screen for the input filters on the internal interface.

   
   
   
3. Set an input filter on the internal interface. Review this sentence carefully! Input filter on the internal interface refers to packets entering the RRAS server from the LAN side and are, therefore, outbound packets (i.e., they will go towards the external network). Set this filter by right clicking on the interface in the main admin screen, selecting Configure interface, and clicking the Input Filters button (Screen 3). Note that this is a "drop all except" type of filter, meaning that only these packets will be allowed to pass. Packets not conforming to these rules will be dropped. This list contains six rules:
   1. Allow any local workstation (NET_ID=192.168.12.0) to browse the Internet, by allowing TCP-based HTTP (port 80) traffic from all local workstations to any outside address.
   2. Allow the local WWW server (192.168.12.20) to be browsed from any external IP host using TCP port 80 (HTTP).
   3. Allow any local workstation to send DNS queries (UDP port 53) to any external address.
   4. Allow the local DNS server (192.168.12.20) to send DNS zone transfers (TCP port 53) to the secondary DNS server (204.70.25.234).
   5. Allow the local e-mail server to send SMTP (TCP port 25) messages to any external SMTP server.
   6. Allows the local e-mail server to send POP3 (TCP port 110) messages to any IP host.

   IP addresses spoofing is prevented by using specific source addresses or a range of local IP addresses, in all of the filters. By inference, any source addresses not explicitly allowed is blocked.

   
   

   Screen 4: IP Packet Filters Configuration screen for the input filters on the external interface.

   
   
   
4. Set an input filter on the external interface by right clicking on that interface in the main admin screen, selecting Configure interface, and clicking the Input Filters button (Screen 4). This filter acts on inbound packets. Note that this is also a "drop all except" type of filter and this list contains five rules:
   1. Allow any external IP host to access the local Web server using HTTP.
   2. Allow any external IP host to send e-mail to the local e-mail server using SMTP.
   3. Allow any external IP host to get e-mail from the local e-mail server using POP3.
   4. Allow any external IP host to reply to DNS queries from local workstations.
   5. Allow DNS zone transfers between the external secondary DNS and internal primary DNS.
   
   

   Screen 5: IP Packet Filters Configuration screen for the output filters on the internal interface.

   
   
   
5. Set an output filter on the internal interface by right clicking on that interface in the main admin screen, selecting Configure interface, and clicking the Output Filters button (Screen 5). This additional filter works on inbound packets and is used to prevent external IP hosts from IP address spoofing. This is a "transmit all except" type of filter, meaning that packets complying with this rule are blocked and all others are permitted. This rule will prevent any IP packet with a source address equal to the local NET_ID address to be forwarded onto the LAN.

Packet filtering can be implemented in a router, packet forwarding server, or firewall. A router, such as those from Cisco, Bay Networks, and Ascend, has its own operating system with its own command line interface. One of the downsides often cited about packet filtering is that it is not only difficult to correctly create a rule set, but it the difficulty is exacerbated by the arcane syntax of the router. A packet-forwarding server, such as an NT Server running the Routing and Remote Access Service (RRAS), or a firewall, such as Checkpoint's Firewall-1, provide a GUI to configure the packet filtering rule set and this greatly simplifies the task. Routers, of course, have specialized hardware and software that are optimized for high-speed, real-time operations. And the cost of quality routers continues to drop so that a good router today costs less than a good server.

Another approach to protecting the local network is via a proxy server. Proxy servers do not filter packets, per se. When a user on the inside attempts to connect to a server on the outside, a connection is established to the proxy server which, in turn, makes the connection to the external server. A similar operation occurs when an external user connects to an internal server. Most proxy servers have a GUI for configuration and are most beneficial when used in concert with packet filtering.

Packet filtering is very powerful security tool. But knowledge of the TCP/IP protocol suite, and how the individual protocols work and interact, is a requirement to build good packet filter rulesets that will work. One of the best books on packet filtering is Building Internet Firewalls by D. Brent Chapman and Elizabeth D. Zwicky (O'Reilly & Associates).

About the Authors: Gary C. Kessler is a senior network security analyst at SymQuest Group (http://www.symquest.com), a network integration consulting company in South Burlington, VT. His e-mail addresses is kumquat@sover.net. Rik Dayvie is a technical services coordinator and Craig Martin is a member of the technical staff at Hill Associates (http://www.hill.com), a telecommunications training and education company in Colchester, VT. E-mail can be sent to them at r.dayvie@hill.com and c.martin@hill.com, respectively.