By 1999, FTP was already a quarter-century old (the original spec, RFC 114, dates to 1971), and the wider world had finally noticed that it was riddled with attack surface. Rather than try to fix FTP itself — a Sisyphean task given how much deployed software depended on its exact quirks — Mark Allman and Shawn Ostermann wrote RFC 2577 as an operator's playbook: a catalogue of every known way FTP could be abused, with concrete mitigations. It is one of the more honest documents the IETF has published, essentially saying "this protocol is full of holes, here is how to live with them."

The headline attack is the FTP bounce attack. FTP uses two channels: a control connection (port 21) and a separate data connection. In active mode, the client tells the server where to deliver data via the PORT command — which specifies an arbitrary IP address and port. Nothing in the original spec required that address to be the client's own. So an attacker could connect to ftp.victim.com, issue PORT pointing at internal.target.com:25, and have the FTP server happily open a TCP connection to a host behind a firewall — using the FTP server as a proxy. Worse, attackers could stage arbitrary bytes on the FTP server (uploaded as a file), then bounce them at an SMTP port to send forged mail, or scan internal networks one port at a time. RFC 2577 mandates that servers refuse PORT commands whose IP doesn't match the control connection's peer — the fix nearly every FTP daemon ships today.

The document then enumerates a parade of other issues:

• Restricted-access attacks: servers should refuse data connections to privileged ports (<1024) to prevent bouncing into NFS, syslog, or rsh.
• Port stealing: because PASV data ports are often allocated sequentially, an attacker can predict the next port and connect first, hijacking or denying the legitimate transfer. The fix: randomize port selection.
• Brute-force passwords: FTP transmits credentials in cleartext and historically had no rate-limiting. RFC 2577 recommends delays after failed logins, capped attempt counts, and disconnecting after N failures — basic hygiene that wasn't universal in 1999.
• Username enumeration via USER/PASS timing: servers should respond identically whether the username exists or not.
• Anonymous FTP pitfalls: writable directories enable warez staging; ~ftp permissions are easy to misconfigure into a root-readable filesystem.

What makes RFC 2577 quietly important is that it's still the canonical reference for FTP hardening 27 years later. Modern FTP servers — vsftpd, ProFTPD, pure-ftpd — implement essentially this checklist. If you've ever wondered why vsftpd.conf has knobs like port_promiscuous=NO or pasv_min_port/pasv_max_port, you're looking at RFC 2577 enforcement.

The broader lesson is architectural. FTP's sins flow from one design decision: using a separate data channel whose endpoint is negotiated in-band over the control channel. That choice makes NAT traversal painful (every NAT needs an FTP ALG to rewrite PORT commands), makes TLS retrofit awkward (FTPS exists, but the dual-channel TLS dance is famously fiddly), and creates the bounce attack as a near-direct consequence. SFTP — which is just file operations over SSH — sidesteps every one of these problems by using a single authenticated channel. RFC 2577 is, in a sense, the document that finally made the case for replacing FTP, even as it taught us how to keep it limping along.