Summary

  • FTP's separate control and data connections let a client arrange a file transfer directly between two servers, using PORT to name an alternate data destination.
  • RFC 2577 showed how the same destination choice could send an FTP server's data to an unrelated service; a low-port refusal reduced one class of bounce attack but left others.

The sales pitch was excellent: why make a file travel through the customer's slow connection when two servers could move it straight across the network? In 1985 that was an actual FTP design option. The customer held the clipboard; the servers did the hauling. The trouble began when the clipboard could name a building that was never part of the file-transfer arrangement.

FTP's 1985 specification, RFC 959, kept a control conversation separate from the data connection. The client could maintain control sessions with two FTP servers. One server would listen; the other would connect and send data directly. The client used PORT to give a server an alternate data address and port. The document even contemplated delivery to a third-party host or a line printer. If the client's own link was slow, skipping a round trip through that client was sensible engineering.

It also assigned considerable power to a small command. PORT did not merely say “I am ready.” It told the server where to open its next data connection. In a legitimate proxy FTP transfer, that address belonged to the other participating file server. If the operator treated any client-supplied destination as acceptable, the same server could become an unwitting courier to another network service. The packets would appear to come from the FTP server, while the person choosing the destination remained on the control connection.

Steve Bellovin's RFC 1579 in February 1994 approached the connection layout from the firewall side. Ordinary active FTP made the server call back to a client port, an awkward pattern for packet filters. Bellovin recommended that clients use PASV: the server listens for data and the client initiates the connection outward. He described a proposed APSV shortcut but said it had not been implemented to his knowledge. The important historical point is the direction of the call. Moving that choice changed which firewall had to admit a surprise connection.

The destination issue survived new address formats. RFC 2428, published in September 1998, extended FTP for IPv6 and NATs. Its EPRT command carried an address family, network address and TCP port; EPSV provided the passive counterpart. The document also defined EPSV ALL, a commitment to two-party transfers for the rest of that session. A later three-way transfer required a new session. These extensions did not invent the basic destination-delegation problem. They made the endpoint choice explicit in a changing network.

Then came RFC 2577, FTP Security Considerations, in May 1999. It laid out the bounce attack without ceremony. A client could put another machine's address and service port in PORT, then ask the FTP server to send data there. If those bytes were meaningful commands to that service, the FTP server became the apparent visitor. The RFC's example used SMTP commands in an uploaded file: the client could make the FTP server contact a third machine's mail service and potentially forge mail without connecting to it directly. A useful server-to-server handoff had become a way to borrow the server's network position.

The RFC offered several levers, each with a cost or limit. It suggested refusing data connections to TCP ports below 1024, answering a low-port PORT request with code 504. Services above that range still remained exposed. Protecting files could keep an attacker from uploading command material and sending it later. Disabling PORT could remove the third-party transfer path, while losing proxy FTP itself. PASV covered most ordinary file transfers, the authors said; the operator still had to decide whether the direct server-to-server trick was worth the risk.

There is a tidy irony in the timeline. FTP's separate data channel made remote file movement flexible. Firewalls made the direction of each connection matter. New address families demanded new endpoint syntax. A security memo then asked a very old shipping question: who may write the delivery address on someone else's truck? The clever 1985 shortcut survived as a design possibility. The blank destination card stopped looking harmless.