8.2 PACKET-FILTERING RULES

Team-Fly

We saw in Chapter 7 that the service access policy defines the TCP/IP protocols and services that are allowed or denied to pass through a firewall, and that the firewall design policy describes how the firewall actually restricts access and filters TCP/IP protocols and services. Consequently, packet-filtering rules must adequately reflect and implement the service access and firewall design policies. Note that packet-filtering rules often are defined at firewall installation time, although they may be later modified, added, or deleted as well.

In essence, a packet-filtering rule consists of two parts: selection criteria and an action field.

The selection criteria of a packet-filtering rule use information typically found in headers to decide whether a particular IP packet should be selected or not, and whether the appropriate action specified in the action field of the packet-filtering rule should be taken.
The action field of a packet filter rule specifies the action to be taken if an IP packet meets the selection criteria and is selected by that rule. Two types of action are usually permitted:
- BLOCK (or DENY) implies that the selected IP packet should be rejected and discarded.
- PERMIT (or ALLOW) implies that the selected IP packet should be accepted and forwarded toward its destination IP address.

With regard to source and destination IP address, a selection criterion can work either with full IP addresses or address masks. Therefore, an address selection usually is accomplished by specifying two dotted-decimal IP addresses. In this case, the first IP address is the desired address and the second IP address is an address mask that selects the relevant bits in the address field. If a mask bit is 1, the corresponding bit in the address is ignored and any value is allowed. For example, suppose we want to select any packet with a source IP address that begins with 157.4.5. Therefore, we put 157.4.5.0 as the desired source IP address and 0.0.0.255 as the address mask for selecting the relevant bits. So, for this address mask, the first 3 bytes of the mask would select all of the 24 bits of the first 3 bytes of a packet's source IP address. Next, the selected 24 bits are compared against 157.4.5. If there is a match, the packet is selected. Obviously, an equal mechanism can be used for the destination IP address.

It is worth mentioning that most packet-filtering implementations apply the rules in the sequence specified by the administrator until they find a rule that meets the selection criteria for a particular IP packet. When an IP packet arrives at a packet filter, it is tested against the first packet-filtering rule. If the rule applies to the packet, the specified action for that rule is carried out (i.e., the packet is forwarded or discarded). If the rule does not apply to the packet, the second rule is checked, and so on. Note that for each rule, if the IP packet satisfies the selection criteria, the action specified for that rule is carried out and the filter processing for that packet is completed.

Suppose the IP packet is not selected by any of the rules, up to the last one. The last rule, however, specifies to discard all packets. So, the last rule takes effect, and the packet is discarded. Consequently, the default action for packet filtering in this case would be to discard the packet, unless otherwise specified by a previous packet-filtering rule. This is a strongly recommended policy that may help prevent unauthorized IP packets getting into the protected area of a corporate intranet. Unfortunately, there also are some packet-filtering implementations that enforce a particular order of rule application based on the selection criteria in the rules, such as source and destination IP address, regardless of the order in which the rules are specified. Some implementations, for example, apply packet-filtering rules in the same order as routing table entries; that is, they apply rules referring to more specific addresses before rules with less-specific addresses. In general, routers that apply packet-filtering rules in the order specified by the administrator, without reordering them, are easier to understand, configure, and manage, and are therefore more likely to yield correct and complete rulesets.

Packet filtering can be used in a variety of ways to block IP traffic from or to specific sites and network segments. For example, a site may wish to block connections from certain IP addresses that it considers to be untrustworthy or hostile. Alternatively, a site also might wish to block connections from all IP addresses external to the site (with certain exceptions, such as SMTP connections for handling e-mail traffic).

As an example of a packet-filtering scenario, consider a service access policy that permits only certain connections to a network of address 123.4.*.*. Telnet connections will be allowed to only one host, 123.4.5.6, which may be a Telnet application gateway. Similarly, SMTP connections will be allowed to two hosts, 123.4.5.7 and 123.4.5.8, which may be e-mail application gateways. NNTP traffic is allowed only from the site's feed system, 129.6.48.254, and only to the site's NNTP server, 123.4.5.9, whereas NTP traffic is allowed to all hosts. All other services and corresponding IP traffic must be blocked by default. An exemplary set of packet-filtering rules that implement this policy are summarized in Table 8.1. Note that each type of packet-filtering device usually has its own set of rules and syntax on how to program packet-filtering rules. Therefore, one must read the packet-filtering device documentation and learn the peculiarities of the syntax for that particular device. In our example of packet-filtering rules, we use an abstract syntax that is not usually found in commercial products.

Table 8.1: Exemplary Set of Packet-Filtering Rules
No.	Type	Source Address	Dest. Address	Source Port	Dest. Port	Action

1	TCP	*	123.4.5.6	> 1023	23	Permit
2	TCP	*	123.4.5.7	> 1023	25	Permit
3	TCP	*	123.4.5.8	> 1023	25	Permit
4	TCP	129.6.48.254	123.4.5.9	> 1023	119	Permit
5	UDP	*	123.4..	> 1023	123	Permit
6	*	*	*	*	*	Deny

The first rule allows TCP traffic from any source IP address and port number greater than 1,023 on the Internet to the destination address of 123.4.5.6 and port number 23 on the intranet. This port number is associated with the Telnet server, and all Telnet clients should have unprivileged source ports of 1,024 or higher. The second and third rules work in a similar fashion, except that traffic to destination addresses 123.4.5.7 and 123.4.5.8, and port number 25 for SMTP, is permitted. The fourth rule permits IP packets to the site's NNTP server, but only from source IP address 129.6.48.254 to destination IP address 123.4.5.9 and port number 119. Note that 129.6.48.254 is the only NNTP server that news should be received from, thus access for NNTP is restricted to only that IP address. The fifth rule permits NTP traffic, which uses UDP instead of TCP, from any source to any destination address on the intranet. Finally, the sixth rule denies all other traffic and corresponding IP packets. If this rule were not present in the ruleset, the router may or may not deny all subsequent packets.

In Chapter 2, we briefly mentioned the problem of IP fragmentation. Note that IP supports the notion that any router along a packet's delivery path may fragment that packet into smaller packets to accommodate the limitations of underlying transport media, to be reassembled into the original IP packet at the destination. For example, an FDDI frame may be much larger than an Ethernet frame. So, a router between an FDDI ring and an Ethernet network may split an IP packet that fits in a single FDDI frame into multiple fragments that fit into the smaller Ethernet frames. The problem with this, from a packet-filtering point of view, is that only the first of the IP fragments comprises the upper-layer protocol headers (i.e., TCP or UDP headers) from the original packet, which may be necessary to make a useful filtering decision concerning the fragment. Different packet-filtering implementations take a variety of responses to this situation. Some implementations apply packet-filtering rules only to the first fragment of an IP packet that actually contains the upper-layer protocol header, and simply route the remaining fragments. The assumption is that if the first fragment of an IP packet is dropped by the packet filter, the rest of the fragments cannot be reassembled into a full IP packet and will therefore cause no harm. Note, however, that it is dangerous to suppress only the first fragment of an outbound IP packet; one may still be leaking data in subsequent fragments that are routed out of the intranet. To defeat this problem, it is possible to keep a cache of recently seen first fragments and the filtering decision that was reached, and to look up subsequent fragments in this cache in order to apply the same decision. This approach is conceptually very closely related to dynamic packet filtering or stateful inspection, as discussed later.

The question on how to filter TCP/IP application protocols and services depends on the chosen service access policy (i.e., which systems should have Internet access and the type of access to permit). Many books have been written that focus entirely on that question. Again, we refer to the books that were referenced in Chapter 7. In particular, we refer to appendix B of [9], where the packet-filtering characteristics for various TCP and UDP ports are summarized.

In short, there are many TCP-based application protocols and services that can be effectively addressed with packet filters and screening routers. Examples include FTP, Telnet, SMTP, DNS, HTTP, and NNTP.

In regard to FTP, it is worth mentioning that two TCP connections are actually used between a client and a server: a control connection (port 21 on the server side) and a data connection (port 20 on the server side). It is up to the client to establish the control connection, whereas it is up to the server to establish backward the data connection. In an intranet environment, the data connection can generally be established. If, however, the FTP client is located on the intranet and the FTP server is located on the Internet, the data connection is inbound and may be rejected by a screening router controlling access to the intranet environment. We come back to this problem when we discuss dynamic packet filtering and stateful inspection later in this chapter. In the meantime, a bypass is available if the client and server both provide support for passive mode FTP [10]. In passive mode FTP, the data connection is also established from the client to the server (similar to the control connection). As such, both connections are outbound and may be easily handled by a screening router.

With regard to DNS it is also worth mentioning that the service can be based on TCP or UDP, and that it is usually provided at port 53 (in either case). The UDP-based service is usually used for queries, while the TCP-based service is used for server-to-server zone transfers. One implementation characteristic of the Berkeley Internet Name Daemon (BIND) is that server-to-server proxy queries are made by way of UDP, with both ends of a connection using port 53. Packet-filtering rules can take advantage of this characteristic, as DNS is sometimes the only UDP-based protocol that is allowed bidirectionally between internal machines and the outside world.

Not all systems require general access to all services. For example, restricting Telnet or FTP access from the Internet to only those systems that actually require it can improve the overall security at almost no cost to user convenience. Other protocols and services such as NNTP may seem to pose little threat, but restricting them to only those systems that actually require them may help to create a cleaner intranet environment and reduce the likelihood of exploitation from yet-to-be-discovered vulnerabilities and corresponding threats. Finally, TCP/IP protocols and services that are inherently vulnerable to abuse should generally be blocked by a screening router being part of a firewall configuration. Typical examples include the Trivial FTP (TFTP) and protocols used by the X11 window system.

Unfortunately, there are also some TCP/IP protocols and services that cannot be addressed effectively with packet filters and screening routers:

Protocols and services that are layered on top of UDP are generally hard to handle with packet filters. This is because UDP is a connectionless transport layer protocol that does not establish and make use of connections. Each UDP is sent individually and there is no possibility to decide whether the application it actually belongs to is used inbound or outbound. This makes it very difficult to intelligently filter IP packets. Unfortunately, UDP is used by an increasingly large number of applications and application protocols, mainly for real-time and multicast communications.
Similarly, protocols and services that use dynamically assigned port numbers are hard to handle with packet filters. For example, the actual port number of an RPC-based protocol and service is dynamically assigned by the portmapper service (typically running at the well-known port number 111). The portmapper service maps an RPC service number to the particular UDP or TCP port number that the service is currently using on the machine being queried. Because RPC-based protocols and services might be on any port, the filtering implementation has no sure way of recognizing what is and what is not RPC.

Obviously, protocols and services that combine the use of UDP and dynamically assigned port numbers are particularly hard to handle using packet-filtering techniques only.

We have mentioned the sequence number guessing and related IP spoofing attacks several times throughout the previous chapters of this book. We now have a brief look at the way a firewall and its packet-filtering component can be configured to protect against them. Remember that these attacks usually exploit the weakness that the source address of an IP packet header must not be authentic (since it is not authenticated). In fact, a host can very easily change the source IP address of a packet to appear as if it is coming from another host, such as a trusted host. In this case, the packet may include a system command that would be executed without prior authentication of the corresponding user.

To protect against this kind of attack, the packet-filtering rules must be designed to discard any packet arriving at an inbound network interface that contains an internal source IP address. The reason is that a packet originating from the outside with the source IP address of an internal machine implies that the packet is somehow fraudulent. Consequently, the packet-filtering rules must specify to discard the packet. Suppose the network or firewall administrator has detected that a certain host on the Internet is sending fraudulent packets by spoofing the source IP address. The administrator can then add a new rule to discard packets arriving from any host with that particular source IP address. Similarly, if a given host is under attack, the new filter rule can discard IP packets destined for that particular host. The new rule should be added at the beginning of the existing ruleset, thereby avoiding any impact to other network traffic.

Team-Fly