FTP

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

•A control connection, initiated by the client to port 21 (typically) on the remote server; this connection is received and proxied by the Traffic Manager.

•One or more data connections that are created on-the-fly as a result of commands sent down the control connection; these connections may be initiated by the server to the client (“active mode”) or by the client to the server (“passive mode”).

The Traffic Manager’s ‘FTP’ virtual server type includes a full FTP proxy that intercepts and manages the requests to create additional data connections. The 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.

Consider source port should not be used with any Traffic IP Addresses that are used by FTP virtual servers (see the Creating a Traffic IP Group).

FTP Security

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 Traffic Manager – click Virtual Server > Edit > Protocol Settings and examine the settings in the “FTP-Specific Settings” section of that page:

Setting	Description
ftp_force_client_secure	Verify that all passive data connections originate from the client’s IP address. Default: ”yes”.
ftp_force_server_secure	Verify that all active data connections originate from the server’s IP address. Default: “yes”.
port_range	Specify the range of destination ports used for data connections; these ports might need to be permitted through intervening firewalls so that, for example, clients can make passive connections to the Traffic Manager.

FTP Source Ports

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 Traffic Manager will select high port numbers on a random basis for FTP data connections that originate from the Traffic Manager.

Specifying the Source Port

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 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 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.

SSL-Wrapped FTP (FTPS)

The 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.

Controlling the Control Channel

Use the following settings:

•ssl_decrypt (Virtual Server > Edit > SSL Decryption): Enables SSL decryption for client-side connections. For more information on configuring SSL decryption, see Setting Up SSL Decryption.

•ssl_encrypt (Pool > Edit > SSL Settings): Enables encryption of the control connection before the Traffic Manager sends it to a back-end server. For more information, see SSL Encryption.

The 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.

Controlling the Data Channel

The 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.

•If enabled, ftp!ssl_data will cause the virtual server to decrypt all data connections using the same public certificate as is used for the control port. Note that the FTP virtual server must also be configured to decrypt SSL with ssl_decrypt.

•If disabled, the virtual server will pass all data through unmodified. If the back-end server wishes to use SSL on the data connection, the client can negotiate directly with the back-end server, with the Traffic Manager as an intermediate proxy.

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

•The virtual server setting ssl_decrypt is disabled (the virtual server is not decrypting SSL), and the pool setting ssl_encrypt is enabled (the pool is encrypting the server-side of the data channel). In this case, data communications with the clients will be in plain text.

•The virtual server settings ssl_decrypt and ftp!ssl_data are both enabled (the virtual server is decrypting SSL), and the pool setting ssl_encrypt is enabled (the pool is encrypting the server-side of the data channel). In this case, data communications with the clients will be encrypted.

Use Cases for SSL-Wrapped FTP

Use Case 1: Servers and Clients Support SSL-Wrapped FTP

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

•Enable SSL decryption (virtual server: ssl_decrypt) and SSL encryption (pool: ssl_encrypt) so that the Traffic Manager can inspect and proxy the control channel, and create data connections dynamically.

•Optional: enable ftp!ssl_data. If disabled, clients and servers can negotiate whether or not to use encryption on the data connections. If enabled, the Traffic Manager will require clients to use SSL for data transfers.

Enabling ftp!ssl_data brings two benefits: First, certificate management is easier as all connections are encrypted and authenticated against the Traffic Manager virtual server certificate. Second, the Traffic Manager will force all clients to use SSL for their data connections.

Without ftp!ssl_data, you would need to synchronize certificates across the 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 Traffic Manager system.

Use Case 2: Clients Support SSL-Wrapped FTP; Servers Do Not

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

•Enable SSL decryption (virtual server: ssl_decrypt), but do not enable SSL encryption (pool: ssl_encrypt). The Traffic Manager will decrypt SSL-wrapped FTP from the client, and pass it in plain-text to the FTP servers in the pool.

•Recommended: enable ftp!ssl_data. If disabled, clients and servers will always use plain text (unencrypted) connections for data transfer. If enabled, the Traffic Manager will force clients to use SSL for data transfers.

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