8.7 Specific Protocol Considerations

Some protocols, for one reason or another, are particularly difficult to operate with firewalls. This section examines the most common problem protocols and explains how to work around these problems. Where appropriate, configuration tips are offered. You will want to understand that some firewall vendors fix these problems by offering preconfigured sets of rules that implement the solutions that we describe below.

8.7.1 File Transfer Protocol (FTP)

One of the most common problematic protocols to firewall is FTP (File Transfer Protocol). The normal operation of FTP does not lend itself to firewalls protecting remote clients due to its manner of operation.

Historically, FTP client/server relationships operated in what was known as normal mode. The method of operation is as follows. A remote client sends a connection request to the FTP server on a remote network on TCP port 21; this is also known as the control connection. With this connection, you can browse directories and see the contents of files. When you attempt to download something, however, the remote FTP server will then send your client computer a packet that says the server is about to send you data on a random high-order port with a source port of 20. That is, the client makes the first connection and the server makes the second connection back to the client. This separate connection is called the data connection because it is the one that actually transfers the files you are requesting.

The problem is the configuration of the firewall that is protecting the client PC. It is easy to configure the firewall to allow outbound TCP port 21 connections. The problem is that the data connection is initiated by the remote server and instructs the client to listen on a random port. From the point of view of the local PC firewall, this is unacceptable. The only way to allow the transfer of data is to accept inbound connections on all TCP ports higher than 1024 (see Exhibit 9).

Exhibit 9: Normal Mode FTP Operation

click to expand

Before revealing the solutions available, it is worthwhile to note that this two-connection behavior is one of the reasons that FTP scales so well. Through the use of multiple sessions, FTP using normal mode can be configured to have a single FTP server control any number of other FTP servers that contain the actual data to be transferred. It is a shame that this elegance interferes with our desire for information security on the client side.

The primary way to overcome this problem is through the use of passive-mode FTP. This is a configuration option that simply tells the server to wait until the client initiates the data connection rather than having the server perform this function. This simple concept has profound implications for our client-side firewall.

As in the previous example, the client PC connects to an FTP server through port 21. Using the control connection, the user can log in and browse directory contents. When the time to download data is at hand, in passive mode, the client then asks the server what ports will be used for the connection and initiates the outbound connection. From the point of view of the firewall, these outbound connections are preferable because the ports used for incoming traffic can now be correlated with outbound client connections.

All commercial FTP servers offer the option to operate in both normal mode and passive mode concurrently. Thus, the decision to use passive mode is a client-side request. Fortunately, most client programs, including Web browsers that support FTP allow themselves to be configured for passive-mode FTP.

Understanding the operation of these two modes of FTP is also helpful in troubleshooting a firewall installation. If you are allowed to browse FTP directories but not download files, this is typically an indication of conflicts between the client-side firewall wall and normal/passive settings on client software.