FTP

The FTP protocol is used to transfer files from client to server. An FTP session consists of:

The Virtual Traffic Manager’s ‘FTP’ virtual server type includes a full FTP proxy that intercepts and manages the requests to create additional data connections. The Virtual Traffic Manager proxies the data connections just as it proxies the control connection, supporting both the active and passive modes of data transfer.

The proxy fully supports all commonly used FTP data connection commands, including the long (RFC 1639) and extended (RFC 2428) versions. The proxy does not support the RFC 4217 encryption control statements (“AUTH TLS”, “AUTH SSL”, “CCC”), and removes these commands from the control stream.

FTP is not a secure protocol. Passwords are not used for “anonymous” file transfers which are common across the public Internet, but where passwords are needed, they are sent in plain text and vulnerable to eavesdropping. If this is of concern, alternative protocols such as SCP, WebDAV or SSL-wrapped FTP (see the SSL-Wrapped FTP section of this chapter) must be used.

A second concern is the ease with which an eavesdropper can snoop on the dialog that prepares the client and server for a data connection, and can then step in and initiate the connection to the listening party.

For example, when an Active FTP connection is set up, the client informs the server of the local client port that the server should connect to in order to establish the data connection. An eavesdropper could step in and connect to the client’s local port before the server does, and then capture any data the client sends (or return a fake file to the client).

The FTP protocol does not have any built-in security measures to authenticate connections and to prevent this from happening, but many modern FTP clients and servers will check the source IP address of incoming connections to verify that they originate from the remote FTP agent they are communicating with. This behavior is enabled by default in the Virtual Traffic Manager – click Virtual Server > Edit > Protocol Settings and examine the settings in the “FTP-Specific Settings” section of that page:

The FTP specification recommends that FTP server data connections should use a source port one below the FTP service port. The typical FTP service port is port 21, so the data source port is recommended to be port 20.

In practice, the vast majority of FTP clients and servers ignore this recommendation because it has security implications and does not provide any additional assurance or authentication. By default, the Virtual Traffic Manager will select high port numbers on a random basis for FTP data connections that originate from the Virtual Traffic Manager.

To specify a source port that a virtual server must use, use ftp_data_source_port (in Virtual Server > Edit > Protocol Settings > FTP Settings). This is often required when an upstream firewall is used to block outgoing connections, other than those permitted with an explicit policy (for example, source port and IP).

FTP software in a Unix/Linux environment requires certain permissions to issue requests from low ports (lower then 1024), such as port 20. By default, the Virtual Traffic Manager drops these permissions early (principle of least privilege), so attempts to configure ftp_data_source_port to a low value will fail. If you wish to use low ports, enable the setting ftp_bind_data_low in System > Global Setting > System Settings; this will cause the Virtual Traffic Manager relinquish fewer permissions so that it retains the ability to bind to low ports.

On modern Linux platforms only the privilege to bind to low ports is kept, while on UNIX variants full root privileges is retained.

The Virtual Traffic Manager supports the pre-RFC 4217 use of FTPS (referred to as “Implicit FTPS” or “SSL-wrapped FTP”). In this implementation, the control port is encrypted from the very beginning; the data connections are generally encrypted but can operate in plain text if desired.

The virtual server protocol type for SSL-wrapped FTP is “FTP”; the virtual server and pool can be independently configured to decrypt or encrypt the control channel communications.

Use the following settings:

The Virtual Traffic Manager’s FTP proxy disables the encryption control statements (“AUTH TLS”, “AUTH SSL”, “CCC”) in RFC 4217 so that they cannot interfere with the established SSL-wrapped FTP session.

The Virtual Traffic Manager can decrypt the data channel or leave it unmodified: this behavior is controlled by the Virtual Server > SSL Decryption setting ftp!ssl_data.

Note that on the server side, the Virtual Traffic Manager will encrypt the data connection if either:

In this use case, all parties support and use SSL-wrapped FTP and the Virtual Traffic Manager acts as a load-balancing proxy, connecting clients to servers. The Virtual Traffic Manager decrypts and re-encrypts the control connection internally so that it can be inspected, and the Virtual Traffic Manager can optionally decrypt and re-encrypt the data connection.

Without ftp!ssl_data, you would need to synchronize certificates across the Virtual Traffic Manager and the back-end servers, and you could not prevent clients and servers from using plain text (unencrypted) data connections. However, these benefits come at the cost of additional SSL processing on the Virtual Traffic Manager system.

This configuration can be used with FTP servers that do not support SSL or in situations where the Virtual Traffic Manager and FTP servers are in close proximity and there is no need to secure the network connections between them:

This use case illustrates an easy way to upgrade your FTP services to SSL-wrapped FTP without requiring any server modifications.