[Techie] FTP 'ls' Command Disconnects Session

Watch this:

C:\>ftp ftp.someserver.duh
Connected to ftp.someserver.duh.
220 FTP Service
User (ftp.someserver.duh:(none)): someuser
331 Password required for someuser.
Password: somepass
230 User someuser logged in.
ftp> ls
Connection closed by remote host.

The red parts are what I typed in. Now why would the simple 'ls' (list) command cause the server to kill the connection? Well, the answer has to do with the way the FTP protocol works and how it is affected by NAT. The short answer is this: An active mode client (such as the ftp.exe that comes with Windows) will probably not work if it connects to a server through a dumb NAT device. By dumb, I mean something other than an intelligent application proxy or a stateful inspection firewall.

For the long answer, let's start by looking at a packet trace of the conversation above:



The interesting part of the trace is the last two lines. This is the part where I typed "ls" at the command prompt. But see what the client did? Instead of sending an "ls" command, it sent a "port" command. This indicates that the client is running in active mode for file transfers. This means that, in addition to connecting to the server on the TCP control connection (port 21), the client opens a listening port for the transfer and tells the server to actively push the data to that open port on the client side. This may sound confusing, so here's a step-by-step:

1. The client connects to the server on port 21 (the control connection).
2. The client opens a listening port on the local side (the data connection), which is kind of a like a reverse of the client-server relationship.
3. The client tells the server which port is the listening port using the "PORT" command.
4. The server connects to the client according to the information in the "PORT" command.
5. The client tells the server which files to push across the data connection.

Because an "ls" is actually an ascii (text) file transfer, the FTP client treats it just like any other file transfer.

Now here's the pickle: My client is behind a simple NAT router, which changes (hides) my client's IP address en route from me to the server. So the client is telling the server to connect on an IP address that the server sees as different from the address the client is connected to on the control port. This can fail for any number of reasons:

• The NAT device doesn't allow incoming connections, such as in a Hide NAT scenario. In this case, the server fails to connect back to the client on the data port.
• The FTP server sees the active mode request as an attempt to hijack the FTP session - a security threat. The FTP server kills the connection in response. This looks like what happened in the trace above, since the server immediately issued a TCP Reset (RST) packet as soon as it received the PORT command.

So how to resolve? A couple of ways. The easiest is to change the FTP client's transfer mode from active to passive. Passive mode FTP works the opposite of active mode. In passive mode, the client tells the server to open a listening port (usually port 20 Correction: port 20 is used as the source port by the FTP server in the active mode data connection.) for the data connection. So it's kind of like two traditional client/server TCP connections running in parallel. Unfortunately, some FTP clients (such as ftp.exe) don't support passive mode. So the only option would be to change to one of the FTP clients that does support it. Most of the freeware FTP clients on the web (AceFTP, etc.) support passive mode and add an easy-to-use graphical interface to boot.

Another way to make this work is to upgrade to a more intelligent NAT device. Most modern firewalls actually use an application proxy or stateful inspection for FTP connections. In other words, they watch the FTP conversation and when they see the PORT command, they modify it on the fly and then dynamically open the firewall to allow the reverse connection on the client's data port. This is a more expensive option, obviously, but depending on the nature and number of connections, it may be worth it.

The final solution would be to complain to the FTP client software vendor that passive mode is an integral function of FTP and any client that doesn't support it is not complete. I'm sure Microsoft will immediately respond to that request, right?

Some related links:

FTP PASV mode
The FTP RFC (959)