How FTP port requests challenge firewall security

The File Transfer Protocol (FTP) is one of the most popular, but also most misunderstood, protocols in use today. I get many questions every day from router and firewall administrators asking why a particular FTP client or server configuration isn’t working. If these administrators understood how FTP worked and how typical firewalls augment the protocol’s sometimes dicey security demands, they would be able to easily solve the FTP-related problems they encounter.

In this article, we’ll look at the following issues:

• How the FTP works
• Challenges created by the FTP
• Solving FTP problems

How FTP works
FTP is a messy protocol because it requires multiple connections, sometimes in both directions. How your clients and servers make these connections depends on the FTP mode. There are two FTP modes:

PORT mode (also known as Normal or Active mode)

PASV mode (also known as Passive mode)

Let’s look at these two modes in more detail.

PORT-mode FTP
The traditional FTP mode is referred to as PORT (or Normal or Active) mode FTP. The sequence of events for a PORT FTP connection goes like this:

1. FTP client: Opens random response ports in the high number range. (For the purposes of this example, we’ll assume ports TCP 6000 and TCP 6001.)
2. FTP client: Sends a request to open a command channel from its TCP port 6000 to the FTP server’s TCP port 21.
3. FTP server: Sends an “OK” from its TCP port 21 to the FTP client’s TCP port 6000 (the command channel link). The command channel is established at this point.
4. FTP client: Sends a data request (PORT command) to the FTP server. The FTP client includes in the PORT command the data port number it opened to receive data. In this example, the FTP client has opened TCP port 6001 to receive the data.
5. FTP server: The FTP server opens a new inbound connection to the FTP client on the port indicated by the FTP client in the PORT command. The FTP server source port is TCP port 20. In this example, the FTP server sends data from its own TCP port 20 to the FTP client’s TCP port 6001.

In this conversation, two connections were established: an outbound connection initiated by the FTP client and an inbound connection established by the FTP server. Note that the information contained in the PORT command (sent over the command channel) is stored in the data portion of the packet.

PASV-mode FTP
The most popular FTP implementation is the Passive or PASV mode. PASV-mode FTP connections are the default on most popular browsers. One of the major advantages of PASV mode is that the server does not need to create a new inbound connection to the FTP client. As we’ll see later, this makes PASV-mode FTP a bit more firewall-friendly.

A PASV mode FTP sequence of events would go like this:

1. FTP client: This opens random response ports in the high number range. (For the purposes of this example, we’ll assume ports TCP 6000 and TCP 6001.)
2. FTP client: This sends a request to open a command channel from its TCP port 6000 to the FTP server’s TCP port 21.
3. FTP server: This sends an “OK” from its TCP port 21 to the FTP client’s TCP port 6000. The command channel is now established.
4. FTP client: This sends a PASV command requesting that the FTP server open a port number that the FTP client can connect to establish the data channel.
5. FTP server: This sends over the command channel the TCP port number that the FTP client can initiate a connection to establish the data channel. In this example, the FTP server opens port 7000.
6. FTP client: This opens a new connection from its own response port TCP 6001 to the FTP server’s data channel 7000. Data transfer takes place through this channel.

Note that the PASV-mode FTP client initiates all connections. The FTP server never needs to create a new connection back to the FTP client.

Firewalls and FTP
FTP modes pose distinct security challenges, depending on whether you’re the client-side or the server-side firewall administrator.

PORT-mode FTP client-side firewall
How do you handle PORT-mode requests made from your FTP clients? You need to allow both inbound and outbound connections to support PORT-mode FTP client requests made from behind your firewall:

Outbound: TCP port 21

Inbound: TCP ports 1025 and above

As you can see, packet filters required to support PORT-mode FTP clients don’t lead to a very secure firewall/router configuration simply because such a wide range of ports is left standing open to the masses. Another significant problem is that you must give new inbound connections (non-ACK packets) access to the internal network. Allowing new, unsolicited inbound connections to such a wide range of ports represents a definite security hazard.

One way of dealing with this problem is to allow inbound connections to the high-number ports only from source port TCP 20. Using this approach, you limit access to what is assumed to be the FTP server data port. However, there are a number of tools available that allow administrators—and hackers—to set the source port manually. So you can’t be sure that incoming connections from TCP port 20 actually are sourcing from an FTP server.

You can improve on these restraints somewhat by limiting inbound access to the high-number ports only from TCP port 20 and from a limited number of IP addresses of trusted FTP servers. The major drawback here is that you must be able to identify the trusted FTP server addresses in advance, and you still have to be concerned by hackers spoofing a source port and IP address.

PORT-mode FTP server-side firewall
What if you’re the firewall/router administrator who has to deal with an FTP server behind your device? In this case, you need to open the following ports:

• Outbound: TCP ports 1025 and above
• Inbound: TCP port 21

This situation is a bit less hazardous than the one the client-side firewall/router administrator has to handle. However, allowing such a wide array of ports outbound access just to support a single server application is still a poor security practice. Any internal network client may have access to network services on the Internet that use the high-number TCP ports for a primary connection.

You can tighten up security a bit by allowing outbound access to the high-number ports only when the source port is TCP port 20. In this way, you can safely assume that only FTP servers are able to connect to these high-number ports on the Internet. You could strengthen this approach even more by limiting TCP port 20 access to the high-number ports to a limited number of IP addresses on your internal network. However, you still have to deal with problems of spoofed IP addresses and manipulated port numbers.

PASV-mode FTP client-side firewall
If you’re the firewall/router administrator on the PASV-mode client side, you’ll need to open the following ports:

• Outbound: TCP port 21 and TCP ports 1025 and above
• Inbound: TCP ports 1025 and above

Note that the PASV mode FTP client requires outbound access to TCP ports 1025 and above. While this doesn’t seem like a big difference from the PORT-mode FTP client requirements, it is in fact a tremendous difference from a security point of view. To allow the PASV-mode FTP client outbound access to the FTP server, you must let these clients have outbound access to all high-number ports. Since you have no way of determining in advance what high-number port the FTP server will assign to the data channel, you must open all the high-numbered ports.

This configuration might be fine if you had some way to assure that only FTP clients would be accessing an FTP server on these ports. Unfortunately, you can’t easily control what applications can access what ports. And even if you did limit just FTP clients to these ports, you would be blocking other applications access to the high-number ports.

To further complicate matters, you must also allow inbound access to all high-number ports. The result is that you must allow inbound and outbound access to all high-number ports. Needless to say, this is an untenable security configuration.

One way you can improve the packet-filtering situation is to limit access to outbound TCP port 21 from certain clients. However, you still run into the spoofing problem.

PASV-mode FTP client-side firewall
These are the ports you need to open on the server side of the PASV-mode connection:

• Outbound: TCP ports 1025 and above
• Inbound: TCP port 21 and TCP ports 1025 and above

This is the flip side of the packet-filter configuration for the FTP client. TCP ports 1025 and above must be opened for inbound and outbound access. Again, you could get a modicum of control by limiting what IP addresses have access, but you run into the same problems you do with the PASV clients.

Solving the FTP problem
Fortunately, most of us use firewall/routers that have a bit more smarts in them than basic packet filtering. Stateful packet filtering firewalls/routers do not require you to open static response port ranges because they include mechanisms that read the data portion of FTP packets, which include the details of the PORT- and PASV-mode commands.

For example, when the FTP client sends a PORT-mode command to the FTP server, the firewall/router can temporarily open a response port and allow the FTP server to create a new (non-ACK) connection on that port. The port will close after the communication is complete. This approach prevents the need to open static inbound packet filters for the high port range on the firewall/router.

Another example of improved firewall security is when the PASV client sends a PASV command to the FTP server. The firewall will intercept the information in the PASV command and allow outbound access to the high-number port on the FTP server from the FTP client until the communication is complete. This prevents the need to open outbound access to all high-number ports for PASV-mode FTP clients.

Computations get a bit more complex when the firewall/router also is performing Port Network Address Translation (PNAT) services for FTP clients and servers. The firewall/router cannot use the IP address and port number of the FTP client or server (included in the PORT or PASV command) because these addresses are not directly routable and the firewall/router cannot guarantee that the port in the PASV or PORT command will be available on its external (Internet connected) interface. In the case of the PNAT firewall/router, the device must re-create the communication (proxy the request) and replace the IP address and ports contained in the PORT and PASV commands with those that are valid on the external interface of the firewall/router. In effect, the firewall/router becomes the FTP client or server on the behalf of the internal network FTP client or server. Most firewalls and PNAT routers can perform this proxying of FTP requests.

Summary
The FTP protocol is a somewhat messy protocol that definitely wasn’t designed with firewall security in mind. FTP clients can use one of two modes: PORT and PASV mode. While PORT mode has been around longer, PASV mode is more popular because it doesn’t require a new inbound connection to be made to the FTP client from the FTP server. Modern firewalls and routers have components that are able to handle the connection request details contained in the PORT and PASV commands to improve on the security issues related to the FTP.