8.2 PACKET-FILTERING RULES

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