End of an FTP era

I just turned off anonymous FTP service on ftp.eyrie.org.

It's bittersweet, since I've been running an anonymous FTP server since some time around 1996 (longer than HTTP has been a widely-used thing), and at ftp.eyrie.org for nearly that long. The original service was wu-ftpd, as one did at the time, but it's been vsftpd for the past decade plus. (Amusingly, I now work for the author of vsftpd.)

All of the data is still there, at archives.eyrie.org as has been the case for more than a decade. I doubt anyone but me and a few people with ancient bookmarks will ever notice. The whole world switched over to HTTP many years ago, and about the only thing that ever connected to the anonymous FTP server was search engines. I was keeping it running out of nostalgia.

Explaining why I finally pulled the plug requires a bit of background on the FTP protocol. Many of those reading this may already be familiar, but I bet some people aren't, and it's somewhat interesting. The short version is that FTP is a very old protocol from a much different era of the Internet, and it does things in some very odd ways that are partly incompatible with modern networking.

FTP uses two separate network connections between the client and server: a control channel and a data channel. The client sends commands to the server (directory navigation and file upload and download commands, for example) over the control channel. Any data, including directory listings, is sent over the data channel, instead of in-line in the control channel the way almost every other protocol works.

One way to do the data transfer is for the client to send a PORT command to the server before initiating a data transfer, telling the server the local port on which the client was listening. The FTP server would then connect back to the client on that port, using a source port of 20, to send the data. This is called active mode.

This, of course, stopped working as soon as NAT and firewalls became part of networking and servers couldn't connect to clients. (It also has some security issues. Search for FTP bounce attack if you're curious.) Nearly the entire FTP world therefore switched to a different mechanism: passive mode. (This was in the protocol from very early on, but extremely old FTP servers sometimes didn't support it.) In this mode, the client would send the PASV command (EPSV in later versions with IPv6 support), and the server would respond with the ephemeral port on the server to use for data transfer. The client would then open a second connection to the server on that port for the data transfer.

Everything is now fine for the client: it just opens multiple connections to the same server on different ports. The problem is the server firewall. On the modern Internet, you don't want to allow any host on the Internet to open connections to arbitrary ports on the server, even ephemeral ports, for defense in depth against exposing some random service that happens to be running on that port. In standard FTP implementations, there's also no authentication binding between the ports, so some other client could race a client to its designated data port.

You therefore need some way to tell the firewall to allow a client to connect to its provided data port, but not any other port. With iptables, this is done by using the conntrack module and a related port rule. A good implementation has to look inside the contents of the control channel traffic and look for the reply to a PASV or EPSV command to extract the port number. The related port rule will then allow connections to that port from the client for as long as the main control channel lasts.

This has mostly worked for some time, but it's complicated, requires loading several other kernel modules to do this packet inspection, and requires using conntrack, which itself causes issues for some servers because it has to maintain a state table of open connections that has a limited size in the kernel. This conntrack approach also has other security issues around matching the wrong protocol (there's a ton of good information in this article), so modern Linux kernels require setting up special raw iptables rules to enable the correct conntrack helper. I got this working briefly in Debian squeeze with a separate ExecStartPre command for vsftpd to set up the iptables magic, but then it stopped working again for some reason that I never diagnosed.

I probably could get this working again by digging deeper into how the complex conntrack machinery works, but on further reflection, I decided to just turn the service off. It's had a good run, I don't think anyone uses it, and while this corner of Linux networking is moderately interesting, I don't have the time to invest in staying current. So I've updated all of my links to point to HTTP instead and shut the server down today.

Goodbye FTP! It's been a good run, and I'll always have a soft spot in my heart for you.

Posted: 2017-12-17 13:08 — Why no comments?

Last spun 2022-02-06 from thread modified 2017-12-17