Understanding the FTP protocol

When one thinks of the Internet, the first thing that comes to mind is surfing from one Web site to another.

Being able to go from Web site to anothe, and view the contents is indeed the reason that the Internet is as popular as it is today. If we set Web surfing aside though, what do we have left in terms of actual usage going on while on the Internet?

One of the activities that takes place is the downloading of data files, movies, antivirus updates, and the like. What these acts have in common is one protocol, namely the FTP, or file transfer protocol.

It should be noted that FTP also observes the client/server model. Unlike HTTP, where there is a clear winner for Web browsers and Web servers, no such program can make the same claim as it relates to FTP. There is a large selection of FTP clients and servers out there today. It is worth noting that your version of Windows come with a built-in FTP client.

FTP itself uses the TCP transport protocol exclusively, or in other words, it never uses UDP for its transport needs. Typically an application layer protocol will use one or the other. One notable exception to that is DNS or Domain Name System. FTP also is odd in that it uses two ports to accomplish its task. It typically uses port 20 for data transfer and port 21 to listen to commands. However, having data transferred over port 20 is not always the case, as it can also be a different port as well.

That is where the confusing part for many people comes into play. There are two modes to FTP, namely active and passive mode. These two modes are initiated by the FTP client, and then acted upon by the FTP server.

Delving deeper

So how do active and passive FTP work? It all starts with the FTP client initiating a connection with the FTP server on its Port 21. Port 21 is where the server is listening for commands issued to it, and in turn, which it will respond to. So we will assume that the TCP/IP handshake is complete, and as normal, the client has done all of this on an ephemeral port.

At this point the client begins to listen on it's ephemeral port plus 1, and sends the PORT N+1 command to the server on its Port 21 i.e. if the ephemeral port in use by the client is 1026, then it would listen on Port 1027. Once this is done, the data transfer port (Port 20) on the FTP server would initiate a connection to the FTP client's ephemeral port plus 1, as indicated above. This is how an active FTP session is conducted by both the client and server. Though if the client has a firewall in place, this whole communication process will come to a grinding halt. The client's firewall would drop what it considers to be an unsolicited communication attempt on the ephemeral port plus one port for the data transfer. The way that FTP gets around this problem is by using passive FTP.

Taking the passive approach

By using the passive mode of FTP or as it appears in the ASCII content of a packet "PASV", FTP was able to neatly sidestep the firewall issue on the client side. It was done in the following fashion: The FTP client, let's say the built in FTP client that comes with a win32 operating system, will start up two connections to the FTP server.

We need to keep in mind as well that both connections that are initiated by the client are using ephemeral ports themselves, as it should be. By opening two connections, or sockets with the FTP server, the client is able to resolve the issue of its firewall denying access to the FTP server initiating contact on one of the client's high ephemeral ports.

One of the connections opened by the client will contact the FTP server on Port 21, and issue it the PASV (passive) command. Next, the FTP server opens an ephemeral port and issues the PORT command to the FTP client. With this in hand, the client then starts a connection back to the server port for the data transfer. It is a rather nifty way to deal with the aforementioned issue of Active FTP and client firewalls.

Much like other application layer protocols, FTP has its own set of status and error codes. Just like HTTP, these numerical values will tell you what is going on with an established session. Also much like HTTP status and error codes, they are broken down into five groups. It is always handy to have a link to a breakout of these nearby if you are investigating some traffic issues. With that said, what would an article about a protocol be without a packet showing it in action! So let's take a look at one of them.

Behold the FTP packet

14:01:25.561863 > P [tcp sum ok] 825:884(59) ack 367 win 65169 (DF) (ttl 118, id 61059, len 99)

0x0000 4500 0063 ee83 4000 7606 c5e7 c0a8 0164 E..c..@.v.......

0x0010 c0a8 01c8 0015 2bb7 8941 e301 1dc0 b76c ......+..A.....l

0x0020 5018 fe91 7d81 0000 3135 3020 4f70 656e P...}...150.Open

0x0030 696e 6720 4249 4e41 5259 206d 6f64 6520 ing.BINARY.mode.

0x0040 6461 7461 2063 6f6e 6e65 6374 696f 6e20 data.connection.

0x0050 666f 7220 4a72 412e 3139 3939 2e6a 7067 for.JrA.1999.jpg

0x0060 2e0d 0a ...

So what can you glean from looking at the packet above? You can see that the FTP server is located on on Port 21, and going to binary mode in order to facilitate the transfer of a picture to the client at on its Port 11191. If you look at the ttl value as seen above, you can reasonably say that the FTP server is a win32 operating system, as the default ttl values on Win32 operating systems are 128, and the fact that the DF bit is set pretty much seals the deal as to this being a Win32. There is a lot of information contained in a packet as you can see.


Now for a quick refresher on what protocol starts where. You know that the TCP header starts at bytes 0015 as underlined above, so you can infer from that the IP header ended at the bytes 01c8 preceding bytes 0015. Also seeing as there are no TCP options set as evidenced by the value of 5 (which is underlined in the above packet) you know where the TCP header ends and the FTP data begins. So you can see from the underlined portions in the above packet just where the FTP traffic is.

Don Parker, GCIA GCIH specializes in matters of intrusion detection, and incident handling. He has also enjoyed a role as guest speaker at various network security conferences, and writing for various online and print media on matters of computer security. He can be reached at don@windowsecurity.com.

Copyright © 2005 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon