When setting up packet filters, you must first determine what filtering capabilities your router has and where you want to filter. If your router has one or more LAN ("inside") ports and/or one or more WAN ("outside") ports, you probably want to filter on the outside, to protect the router (Fig. 1). Most routers do, in fact, allow you to build packet filters and apply them on a per-port basis.

In the discussion below, the rules are stated in a simple, general form that does not follow any particular router vendor's format; readers are urged to consult their vendor and/or vendor's literature for specific information about their own system. In each filtering rule below, we can specify:

• Dir: Whether this rule is being used to filter an inbound or outbound packet, from the perspective of the router.

• Action: Whether this rule is being used to allow or block a particular packet type.

• Protocol: The protocol to which this rule applies (IP, TCP, UDP, or ICMP).

• Address/Port Information: An optional source and/or destination IP address (from/to) to identify the relevant hosts, and an optional source and/or destination port address (source/destination) to identify the application to which this rule applies (see Table 1). For this example, assume that the local network's FTP server and mail server have IP addresses 254.1.1.1 and 254.1.1.2, respectively; we will also pretend that this is a Class C address, so that this domain's network identifier is 254.1.1.0. (In most rule formats, the portion of the address to which applies may be specified with a subnet mask or by indicating how many bits are significant. Thus, to refer to only the network identifier portion of a Class C address, the rule would indicate a mask of 255.255.255.0 or a value of 24.)

• Flags: Used here to indicate whether this rule pertains to a TCP virtual circuit that is being initiated with this packet or to a TCP connection that has already been established (estab). This can usually be determined by examining the setting of the Flags field in the TCP segment Header. In particular, the Acknowledgement (ACK) flag is used to indicate whether the Acknowledgement Number in this segment is valid or not; it is usually set except in the first segment used for connection establishment. The Reset (RST) flag is used to force an immediate termination of a TCP connection. For filtering purposes, a TCP connection is considered to be established if the ACK or RST flag is set.

The next four rules deal with the File Transfer Protocol (FTP), another protocol that operates over TCP. When a user (the client) opens an FTP session with a remote host (the server), the client sets up an FTP-control connection to the server on TCP port #21. When the client sends FTP commands to obtain directory listings or to initiate file transfers, for example, the FTP server establishes an FTP-data connection with the client using TCP port #20; the FTP client is assigned some TCP port number greater than 1023. Note that the server sets up a new FTP-data connection for each dir, get, or put command and that the client is assigned a new TCP port number for each new FTP-data connection. Rule 2, then, allows outgoing FTP-control packets, but limits incoming FTP-control packets to existing connections, while Rule 3 allows incoming and outgoing FTP-data packets. These two rule-pairs allow our users to establish an FTP connection with any FTP server on the Internet.

Rules 4 and 5 also deal with FTP; they limit new incoming FTP-control connections and new outgoing FTP-data connections only between the LAN's FTP server (IP address 254.1.1.1) and a remote host. These rule-pairs, then, allow any Internet host to establish an FTP connection to the designated FTP server but to no other host on the LAN.

Rules 6 and 7 are very similar to Rules 4 and 5. These two rule-pairs allow incoming and outgoing SMTP packets (TCP port #25) between the mail server (IP address 254.1.1.2) and any Internet host. (This rule, although common, may be too broad since now any Internet host can attempt to establish an SMTP connection to the local mail system. To limit the scope, some networks only allow SMTP connections between their own mail system and a designated mail relay; a problem can arise, however, if the mail relay goes down, although the rule could still limit connections to a known network.)

Rule 8 allows incoming and outgoing Domain Name Server (DNS) query packets (UDP port #53). Rule 9 allows inbound and outbound Internet Control Message Protocol (ICMP) packets. Other similar rules can be applied for other ports and applications, such as Gopher, http, Whois/NICNAME, Finger, Netnews, RIP, and SNMP; only allow packets that are relevant to your system.

Network administrators may want to carefully consider why some common applications are supported at all. In today's environment, for example, why respond to Finger requests with full system and/or user information? Password guessing is the first type of attack that may be tried on your system and Finger helps attackers by giving them a list of valid user names; it also provides a way that an attacker can find accounts that have been inactive for some time. An increasing number of sites limit Finger by not providing a Finger daemon, filtering external Finger requests, limiting the information supplied in the response, or employing a Finger daemon that responds to all requests with a standard banner message from the network administrator.

Be careful that you have permitted all of the protocols that you want before you shut the door. Be aware also that this type of blanket denial will block some legitimate uses of non-standard ports; some experimental Gopher and WWW servers, for example, use ports other than 70 and 80, respectively.

Rules 10 and 11 are also an example where rule ordering can be very important. The packet filter routine will usually process rules in order until either a rule is matched or the rule list exhausted. Consider what would happen if these last two rules were accidently inserted before, say, Rule 6. In that case, no SMTP or DNS packets would ever be allowed to enter or leave through the router.

Another type of packet filtering that should be employed blocks IP spoofing, a form of attack where an intruder replaces their own IP address with a valid IP address from another network. IP spoofing takes advantage of those applications that use authentication based upon the source IP address, possibly leading to unauthorized use of data base, commercial, and/or system resources. IP spoofing was a major part of the intrusion widely publicized in early January 1995. As an aside, the "holes" in TCP/IP that made it possible were described in papers written as much as 7 or more years ago.

A combination of inside and outside filtering might also be used when resources on two different LANs attached to the same router are to be given different levels of protection. Alternatively, a common configuration is to place an application gateway on a LAN with two routers, where one router is connected to the WAN and the other router to the internal corporate LAN, as shown in Figure 2; the packet filtering rules on the different sides of the Internal Router and Firewall Router will certainly be different.

Packet filtering is clearly not the final word on security. While this capability exists with almost all routers today, there is still debate whether packet filtering provides sufficient protection or merely yields a false sense of security (literally and figuratively!). Application-level filters probably provide better security but are harder to build and maintain. Yet, almost any system can be broken through without continued vigilance by users; firewalls cannot, for example, protect a site from attacks in which something is legitimately mailed or transferred to an internal host and then executed (such as attacks against Sendmail).

There is much more involved in setting up a packet filtering router than described here, not to mention setting up more powerful firewalls and taking stronger security measures. Some additional information may be found on the Internet, of course! One good starting place may be accessed by pointing your WWW browser at www.greatcircle.com/firewalls or www.tis.com for a list of frequently asked questions (FAQ) and other firewall-related topics. The FAQ is particularly informative and discusses such topics as what a firewall can and cannot do; setting up proxy FTP, Telnet, Finger, and DNS servers; and problems with source routed packets. A firewall discussion list is also available on the Internet at firewalls@greatcircle.com; subscribe to the list by sending e-mail to majordomo@greatcircle.com and place the line "subscribe firewalls" in the body of the message.

Two Request for Comments (RFC) documents are directly related to these issues as well. RFC 1244 ("Site Security Handbook") is an excellent guide to the purpose and creation -- and enforcement -- of security guidelines; it also includes an extensive bibliography and list of resource materials and help centers. RFC 1281 ("Guidelines for the Secure Operation of the Internet") suggests guidelines for users, service providers, and equipment vendors.

Network administrators responsible for Internet access should be on the electronic distribution list for advisories from the Computer Emergency Response Team (CERT). CERT's charter is to act as a clearinghouse for break-ins to computer systems via the Internet or security holes reported in vendor's software; they disseminate appropriate information about such events and how to prevent or fix them. To automatically receive CERT advisories, send e-mail to cert-advisory-request@cert.org and place the word "subscribe" in the body of the message. Past CERT advisories can be obtained via anonymous FTP in the /pub/cert_advisories directory at info.cert.org. CERT may be contacted at the Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania 15213-3890 (Telephone: +1 412 268-7090; Fax: +1 412 268-6989; E-mail: cert@cert.org).

Finally, contact your router vendor. Many have on-line WWW and/or ftp sites, as well as electronic mailing lists.