- HyperText Transfer Protocol (HTTP)
- File Transfer Protocol (FTP)
- Real Time Streaming Protocol (RTSP)
- Secure Sockets Layer (SSL)
File Transfer Protocol (FTP)
In Internet terms, The File Transfer Protocol, or FTP, has been around for a long time. First defined in RFC 172 written in June 1971, the protocol has been through several changes through to the current specification, which is defined in RFC 959. Again, while it's not the purpose of this book to describe every detail about FTP, it's worth looking at its basic operation to get a better understanding of how content switching can improve performance and reliability in FTP environments.
FTP exists primarily for the transfer of data between two end points. The RFC itself actually states that two of the objectives of the protocol are to "promote the sharing of files" and "transfer data reliably and efficiently." FTP differs from HTTP fundamentally as it is an application made up of two distinct TCP connections:
Control connection: This TCP-based connection is used to provide a communications channel for the delivery of commands and replies. This is effectively the mechanism that enables the user to tell the server which file is being requested, which directory it is in, and so forth.
Data connection: The second TCP-based connection is used for the actual transfer of user data. Once the Control connection has been used to exchange information on which file is required, the Data connection is used to transfer the file between the client and server.
Using these two communication connections, two distinct modes of operation determine in which direction the connections are established: Active mode and Passive mode.
Active Mode FTP
Within an Active FTP session, the Control connection is established from the client to the server, with the Data connection established back from the server to the client. In order to do this, the client issues a PORT command to the server that contains the IP address and source and destination TCP ports that should be used during the Data connection. Figure 3-5 shows the lifecycle of an Active FTP session.
Figure 3-5. An active FTP session example.
As we can see from Figure 3-5, once the user has logged on with a valid username and password, the very first "data" that is passed—in this case, a directory listing—is carried using a separate data channel. The format for communicating the IP and TCP information of the data channel is as follows:
PORT [Octet 1],[Octet 2],[Octet 3],[Octet 4], [TCP Port 8 Bytes],[TCP Port 8 Bytes]
Therfore, in the preceding example, the PORT command of PORT 10,10,10,10,15,199 equates to IP address 10.10.10.10 and TCP port 4039 [15×256 + 199×1].
In some instances, Active FTP can be considered a security risk mainly because there is often little control over the contents of the PORT command. Under normal usage, this information should be the IP address and listening TCP port of the client waiting for the Data connection. When used maliciously, however, the client could issue PORT commands with IP addresses and TCP ports of other machines either within the same network as the server or remotely. Many Application layer firewalls and proxies, or firewalls with support for FTP command parsing can be used to reduce the effectiveness of such attacks. One alternative is to implement the second method of FTP—Passive mode FTP.
Passive Mode FTP
Passive mode FTP works similarly to Active mode FTP with one major exception: both the Control and Data connections within a Passive mode FTP session are established from the client to the server. To implement this, rather than use the PORT command, Passive mode FTP implements the PASV command, which instructs the server that it should listen for the incoming Data connection. Figure 3-6 shows the Passive mode FTP in more detail.
Figure 3-6. A Passive FTP session example.
In Figure 3-6, we can see that rather than the client dictating the parameters of the Data connection, it simply requests this information from the server. Similarly to the PORT command in Active mode, the server's RESPONSE to the PASV request from the client can be interpreted as follows:
RESPONSE 227 (10,10,10,10,41,38)
which means open from client to server on IP address 10.10.10.10 and TCP port 10534 [41×256 + 38×1].
For further information on the detailed workings of FTP, it's worth looking at RFC 959.