John shared a great idea in his comment to my “FTP: a trip down the memory lane” post: when using some FTP servers you can specify the range of passive ports, allowing you to tighten your router ACL (otherwise you’d have to allow inbound connections to all TCP ports above 1024).
If you’re using wu-ftpd, the port range is specified with the passive ports configuration directive in the ftpaccess configuration file. ProFTPD uses PassivePorts configuration directive and recommends using IANA-specified ephemeral port range. Pure-FTPd takes a more cryptic approach: the port range is specified in the –p command-line option.
A while ago I’ve bitterly complained about the FTP protocol design. I have decades-long grudge with FTP. If you’re old enough to remember configuring firewalls before stateful inspection or reflexive access lists became available, you probably know what I’m talking about; if not, here’s the story.
When enterprises started using the Internet 15+ years ago, most desktop FTP clients did not support passive mode (although it was part of the FTP standard). When configuring “firewalls” (one or two routers with long access lists), you had to allow all inbound TCP session to ports higher than 1024 just to support FTP data sessions. No problem ... unless you were using Sun workstations or NetBIOS over TCP (both of them use dynamic server ports above 1024), in which case those services were totally exposed to the Internet.
Did you know that you could do server-to-server file transfers with FTP? I didn’t; this little gem (usually known as FXP – File eXchange Protocol) was described by davro and g in comments to the FTP Butterfly Effect post.
If you’re using FXP, please write a comment; although I am well aware why it was extremely useful 25 years ago, I’m wondering how many people are actually using it today.
Anyone dealing with FTP and firewalls has to ask himself “what were those guys
smoking?” As we all know, FTP is seriously broken :
- Command and data streams use separate sessions.
- Layer-3 addresses and layer-4 port numbers are carried in layer-7 messages.
- FTP server opens a reverse session to a dynamic port assigned by the FTP client.
Once upon a time, there was a very good reason for this weird behavior. As Marcus Ranum explained in his Internet nails talk @ TEDx (the title is based on the For Want of a Nail rhyme), the original FTP program had to use two sessions because the sessions in the original (pre-TCP) Arpanet network were unidirectional. When TCP was introduced and two sessions were no longer needed (), the programmer responsible for the FTP code was simply too lazy to fix it.
Today I've got the bad news: I already knew there were "a few" bugs in the IOS FTP server that you could exploit. Instead of fixing them, Cisco simply decided to remove the FTP server altogether.
Why is this so bad? Look at the list of protocols that you can use to transfer files to and from the router that I've put together in my IP Corner article Using a Web Server to Manage Your Router Configurations. As you cannot transfer a file into the router's flash with the embedded HTTP server, the only protocol that you could use to get a new IOS image to the router from a Windows workstation with no additional software installed was FTP, and now that option is gone.
To enable FTP server in Cisco IOS, use the ftp-server enable configuration command followed by the ftp-server topdir directory command which specifies the top-level FTP directory (for example, flash:). To authenticate FTP users, define local usernames with the username user password password configuration command.