Load Balancing FTP

Our next application of Layer 7 server load balancing is somewhat subtler than those we saw previously. Some protocols are more complex than a single TCP connection from the client to the server and require multiple interoperating, bidirectional TCP connections to operate correctly. One good example of such an Application layer protocol is FTP. In Chapter 3, Understanding Application Layer Protocols , we saw the fundamentals of how FTP operates in its two modesActive mode and Passive modeso now let's apply what we already know and see how the protocol scales in a content-switched environment.

The issues of implementing FTP into content-switched architectures can be loosely summed up by two main points. First, as there are two separate TCP connections operating in conjunction, the details and control of these separate sessions must be combined within the content switch to ensure that mechanisms such as address translation and server selection are common between the two. Second, FTP is an example of an Application layer protocol that embeds IP address details within the Layer 7 application data payload between client and server. For any Layer 7 aware device performing NAT between the two end points in an FTP conversation, the challenges are common, so the issues that we'll see in the next few pages for content switching also hold true for other NAT devices such as stateful inspection firewalls. Let's look at both modes of FTP operation in turn Active mode and Passive mode.

Load Balancing FTP in Active Mode

In Active FTP, the client opens an FTP Control connection to the server to carry control commands, and the server opens an FTP Data connection to the client to carry the actual data being transferred, which might be anything from a directory listing to a large file. To initiate this return connection from the server, the client issues a PORT command across the established FTP Control connection showing the server the IP address and TCP to which it should connect for the FTP Data connection. Once this command has been issued, the server will establish the FTP Data connection using the details provided by the client and begin the data transfer.

In Active mode operation, the responsibilities of the content switch are as follows :

• Perform delayed binding between itself and the client to establish the initial part of the FTP Control connection.

• Select a real server, open a TCP connection between itself and the real server, and splice the two together.

• Receive the client PORT command and forward to the real server.

• Allow the server to establish the FTP Data connection through the content switch to the client, ensuring that the source IP address for the TCP session is translated to the same VIP to which the client has established its FTP Control connection.

It's really this last point that is important in making the solution work. Imagine a scenario where the content switch is front-ending multiple VIPs for many different FTP services. The content switch must be able to parse the PORT commands from various clients attaching to all of these services and correctly translate the source IP addresses of the FTP Data connection to ensure that the clients see this coming from the same source they are attached to for FTP Control. Failure to do this would result in an application failure for most FTP clients . Figure 6-14 shows the process in more detail.

Figure 6-14. The traffic flow, parsing and address translation for an Active FTP session through a content switch.

Let's look at the four stages of the example in more detail:

1. The client opens the FTP application and enters the site URL or IP address. This causes the application to open an FTP Control connection to the VIP on the content switch, which will in turn be load balanced to one of the real servers. Once the client-to-server connection has been established, the client will be challenged for a username and password to authenticate. At this point, the client has a full FTP Control connection to the real server.

2. The client will issue a command within the FTP application that will require the use of an FTP Data session. Within FTP, all data transfer between client and server is carried over the FTP Data connection. whether it is a file download or simply a directory listing. In many GUI FTP applications, the directory listing for the home directory will be requested , automatically triggering this process. The result is that the client will issue a PORT command instructing the server which IP address and TCP port the FTP Data connection should be opened to.

3. The server now initiates the FTP Data connection back to the client. When the clients FTP PORT command was issued and parsed through the content switch, session information was recorded that can now be used to correctly map the source IP address of the real server FTP Data connection to the VIP the client is talking to. This ensured that if the client opened its FTP Control connection to 10.10.10.100, the resulting FTP Data connection will also appear to originate from this address. As the FTP Data session is initiated, the content switch will perform the required source NAT on this connection.

4. All subsequent frames in the FTP Data session will be translated (destination IP address from client to server and source IP address from server to client).

Load Balancing FTP in Passive Mode

Passive mode FTP works differently from Active mode. In Passive mode, the FTP Data connection is established from the client to the server, meaning that both channels in the FTP session are established in the same direction. The reason that Passive mode FTP is popular within secure environments is because of the way the PORT command in Active mode opens a number of attacks commonly known as "FTP Bounce attacks." These Bounce attacks have several variations and can be used to perform subsequent intrusions such as portscans and even the bypassing of filtering or stateful firewalls. These attacks are based around the fact that an FTP client operating in Active mode can send a PORT command with a different IP address (and TCP ports) to that that initiated the FTP Control connection. Imagine if the client issued a PORT command with an IP address of a machine that is on the same subnet as the FTP server, and consequently on the inside of a firewall. This would give the attacker the ability to open a TCP connection to any IP address and TCP port by simply placing that information inside the PORT command. Other, more elaborate attacks can be formulated based on these principles, which are outside the scope of this book.

It is for this reason that Passive mode FTP is popular in Internet facing environments where security requirements are typically higher than in simple internal networks. For Passive mode FTP within a content switched environment, the content switch must perform the following functions:

• Complete a delayed binding with the client on the FTP Control connection.

• Select a real server, open a TCP connection between itself and the real server, and slice the two together.

• Parse the FTP Control connection for the PASV command, which the client uses to indicate to the server that it wishes to initiate a Passive FTP mode connection for data transfer.

• When the server issues its command 227 "Entering Passive Mode" argument, showing the client which IP address and TCP port to connect to, the content switch must change the Layer 7 information in the command and replace the IP address (and optionally the TCP port) to the VIP.

• For Passive FTP parsing, the last point is very important. If the real server is located on an internal subnet with a nonroutable IP address, this will be passed in the PASV response. If the content switch does not successfully translate the PASV response from the server, the client will try to open an FTP Data connection to this incorrect address. Figure 6-15 shows the packet flow and translations for a Passive mode FTP session through a content switch.

  Figure 6-15. The traffic flow, parsing and address translation for an Active FTP session through a content switch.

  

Let's look at the five stages of this Passive FTP example in more detail:

1. As with Active FTP, the client FTP application will open an FTP Control connection to the VIP on the content switch. The content switch will perform a delayed binding on the connection and select a real server based on the Layer 4 distribution metric or other criteria. Once the real server has been selected, the content switch will open a TCP connection to the server and splice the two connections together.

2. The client will issue a PASV command to indicate to the real server that a Passive mode FTP session is required or preferred.

3. The real server will respond to the client's PASV command with a response code of 227Entering Passive Mode (192,168,10,10,11,150)indicating that the client should open an FTP Data connection to the IP address 192.168.10.10 on TCP port 3543. As the packet containing this FTP response passes through the content switch, the response code and argument will be translated to 222Entering Passive Mode (10,10,10,100,11,150)replacing the server's IP address in the Layer 7 payload with the VIP on the content switch. The content switch will also create some form of session reference to allow the expected client-initiated FTP Data connection on TCP 3543.

4. The client will then open an FTP Data connection to the VIP on TCP port 3543, which will be directed to the correct FTP server dealing with this client session.

5. All subsequent packets in the FTP Data connection will be translated based on this session information, transparently to the client and the server.

In summary, FTP load balancing is a good example of an Application layer protocol that typically does not need explicit configuration in the sense of URLs and so forth like many HTTP configurations, but requires some subtle Layer 7 information manipulation within the content switch to address the problems of a multiconnection application. We'll see another example of a multiconnection protocol that requires similar manipulation later in this chapter.