8.7. Filtering by ServiceBlocking incoming forged packets, as discussed previously, is just about the only common use of filtering solely by address. Most other uses of packet filtering involve filtering by service, which is somewhat more complicated.From a packet filtering point of view, what do the packets associated with particular services look like? As an example, we're going to take a detailed look at Telnet. Telnet allows a user to log in to another system, as if the user had a terminal directly connected to that system. We use Telnet as an example because it is fairly common, fairly simple, and from a packet filtering point of view, representative of several other protocols such as SMTP and NNTP. We show both outbound and inbound Telnet service. For detailed discussions of the packet filtering characteristics of other protocols, see the chapters in Part III, "Internet Services". 8.7.1. Outbound Telnet ServiceLet's look first at outbound Telnet service, in which a local client (a user) is talking to a remote server. We need to handle both outgoing and incoming packets. (Figure 8-3 shows a simplified view of outbound Telnet.)Figure 8-3. Outbound TelnetThe outgoing packets for this outbound service contain the user's keystrokes and have the following characteristics:
Why is the client port -- the source port for the outgoing packets, and the destination port for the incoming packets -- restricted to being greater than 1023? This is a legacy of the BSD versions of Unix, the basis for almost all Unix networking code. BSD Unix reserved ports from to 1023 for local use only by root. These ports are normally used only by servers, not clients, because servers are run by the operating system as privileged users, while clients are run by users. (The major exceptions are the BSD "r" commands like rcp and rlogin, as we'll discuss in Section 18.1, "Terminal Access (Telnet)".) Because TCP/IP first became popular on Unix, this convention spread to other operating systems, even those that don't have a privileged root user (for instance, Macintosh and MS-DOS systems). No actual standard requires this behavior, but it is still consistent on almost every TCP/IP implementation. When client programs need a port number for their own use, and any old port number will do, the programs are assigned a port above 1023. Different systems use different methods to allocate the numbers, but most of them are either pseudo-random or sequential.
8.7.2. Inbound Telnet ServiceNext, let's look at inbound Telnet service, in which a remote client (a remote user) communicates with a local Telnet server. Again, we need to handle both incoming and outgoing packets.The incoming packets for the inbound Telnet service contain the user's keystrokes and have the following characteristics:
8.7.3. Telnet SummaryThe following table illustrates the various types of packets involved in inbound and outbound Telnet services.
[18]The TCP ACK bit will be set on all but the first of these packets, which establishes the connection.Note that Y and Z are both random (from the packet filtering system's point of view) port numbers above 1023. If you want to allow outgoing Telnet, but nothing else, you would set up your packet filtering as follows.
8.7.4. Risks of Filtering by Source PortMaking filtering decisions based on source port is not without its risks. There is one fundamental problem with this type of filtering: you can trust the source port only as much as you trust the source machine.Suppose you mistakenly assume that the source port is associated with a particular service. Someone who is in control of the source machine (e.g., someone with root access on a Unix system, or anyone at all with a networked PC) could run whatever client or server he or she wanted on a "source port" that you're allowing through your carefully configured packet filtering system. Furthermore, as we've discussed previously, you can't necessarily trust the source address to tell you for certain what the source machine is; you can't tell for sure if you're talking to the real machine with that address, or to an attacker who is pretending to be that machine. What can you do about this situation? You want to restrict the local port numbers as much as possible, regardless of how few remote ports you allow to access them. If you only allow inbound connections to port 23, and if port 23 has a Telnet server on it that is trustworthy (a server that will only do things that a Telnet client should be able to tell it to do), it doesn't actually matter whether or not the program that is talking to it is a genuine Telnet client. Your concern is to limit inbound connections to only ports where you are running trustworthy servers, and to be sure that your servers are genuinely trustworthy. Part III, "Internet Services" discusses how you can achieve these goals for various services. This problem is particularly bad for servers that use ports above 1023 because you need to allow packets in to those ports in order to let in traffic bound for clients. For instance, in the preceding example, we allow inbound packets for any port over 1023 from source port 23. This would allow an attacker to run anything at all on port 23 (for instance, an X Window System client) and send packets to any server above port 1023 (for instance, an X Window System server). We avoided this problem in our example by using the ACK bit to accept inbound packets but not inbound connections. With UDP, you have no such option, because there is no equivalent to the ACK bit. Fortunately, relatively few important UDP-based protocols are used across the Internet. (The notable exception is DNS, which is discussed further in Section 20.1, "Domain Name System (DNS)".)
|
|