Earlier in this chapter we mentioned FTP and its use of two TCP connections to actually transfer a file (i.e., an FTP control connection and an FTP data connection). We also said that because of the nature of the FTP data connection, it is quite difficult to set up appropriate packet-filtering rules. The problem is related to the fact that the data connection is typically established inbound (i.e., from the FTP server to the FTP client) and that inbound connections are very likely to be rejected by a properly configured packet filter or screening router.
For example, imagine a situation in which an intranet client wishes to establish an outbound FTP session to a server located somewhere on the Internet. According to the normal FTP specification, the client would first establish an outbound TCP connection from a randomly chosen port X to the FTP control port (i.e., port 21) of the server. Among other things, this connection would be used by the client to inform the server on which port Y it is going to listen for the incoming FTP data connection (using the PORT command of the FTP protocol). The server, in turn, would establish an inbound TCP connection from its FTP data port (i.e., port 20) to port Y on the client side. A file requested by the client would then be transferred on this TCP connection to the client.
Now imagine what happens if Internet connectivity is mediated through a screening router and the corresponding packet-filtering rules are configured in a restrictive way (meaning that inbound TCP connections are not allowed and rejected). In this situation, the second TCP connection (i.e., the FTP data connection) would be denied and the corresponding file transfer would not be able to take place. The underlying problem is that due to the stateless nature of (static) packet filtering, it is not possible to recognize that the second TCP connection (i.e., the FTP data connection) logically belongs to the first TCP connection (i.e., the FTP control connection), and that the two connections collectively represent an FTP session. Consequently, the screening router simply sees an Internet server trying to establish an inbound TCP connection from server port 20 to client port Y. According to its policy and configuration, it is very likely that the screening router is going to refuse this TCP connection establishment request.
We have also already mentioned that passive mode FTP as specified in [10] provides a simple solution for this particular problem. Note, however, that the problem is more fundamental and that an increasingly large number of network applications use multiple connections and randomly chosen port numbers. For these applications, it is getting increasingly difficult to specify appropriate packet-filtering rules.
Remember that packet filters are stateless, meaning that each IP packet is examined isolated from what has happened in the past, forcing the packet filter to make a decision to permit or deny each packet based upon the packet-filtering rules. Contrary to that, the notion and technology of stateful inspection or dynamic packet filtering was created by the developers of the FireWall-1 at CheckPoint Software Technologies, Ltd.[7] In short, stateful inspection refers to a technology in which a packet filter maintains state information about past IP packets to make more intelligent decisions about the legitimity of present and future IP packets. For example, a dynamic packet filter compares the first packet in a connection to the packet-filtering rules, and if the packet is permitted, state information is added to an internal database. One might think of this state information as representing an internal virtual circuit in the stateful inspection device on top of the transport layer association. This information permits subsequent packets in that association to pass quickly through the stateful inspection device. If the rules for a specific type of service require examining application data, then part of each packet must still be examined. As an example, FireWall-1 can react to seeing an FTP PORT command by creating a dynamic rule permitting a connection back from the FTP server to that particular port number on the client's side.
In summary, stateful inspection provides much better possibilities to define packet-filtering rules and to filter IP packets accordingly (as compared to static packet filtering). Whenever possible (and available in products), stateful inspection should therefore be used to improve the capabilities of packet-filtering devices.
[7]The technology is covered by U.S. patent US 5,606,668 that specifies a "system for securing inbound and outbound data packet flow in a computer network." The patent was granted to Checkpoint Software Technologies, Ltd., on February 25, 1997.
Team-Fly |