Email This List Email This List Print This List Print This List

What is the dif­fer­ence between Act­ive and Pass­ive FTP?

The Basics

FTP is a TCP based ser­vice exclus­ively. There is no UDP com­pon­ent to FTP. FTP is an unusu­al ser­vice in that it util­izes two ports, a ‘data’ port and a ‘com­mand’ port (also known as the con­trol port). Tra­di­tion­ally these are port 21 for the com­mand port and port 20 for the data port. The con­fu­sion begins how­ever, when we find that depend­ing on the mode, the data port is not always on port 20.

 

Act­ive FTP

In act­ive mode FTP the cli­ent con­nects from a ran­dom unpriv­ileged port (N > 1023) to the FTP server­’s com­mand port, port 21. Then, the cli­ent starts listen­ing to port N+1 and sends the FTP com­mand PORT N+1 to the FTP serv­er. The serv­er will then con­nect back to the cli­ent’s spe­cified data port from its loc­al data port, which is port 20.

From the serv­er-side fire­wall’s stand­point, to sup­port act­ive mode FTP the fol­low­ing com­mu­nic­a­tion chan­nels need to be opened:

  • FTP server­’s port 21 from any­where (Cli­ent ini­ti­ates con­nec­tion)
  • FTP server­’s port 21 to ports > 1023 (Serv­er responds to cli­ent’s con­trol port)
  • FTP server­’s port 20 to ports > 1023 (Serv­er ini­ti­ates data con­nec­tion to cli­ent’s data port)
  • FTP server­’s port 20 from ports > 1023 (Cli­ent sends ACKs to server­’s data port)

When drawn out, the con­nec­tion appears as fol­lows:

In step 1, the cli­ent’s com­mand port con­tacts the server­’s com­mand port and sends the com­mand PORT 1027. The serv­er then sends an ACK back to the cli­ent’s com­mand port in step 2. In step 3 the serv­er ini­ti­ates a con­nec­tion on its loc­al data port to the data port the cli­ent spe­cified earli­er. Finally, the cli­ent sends an ACK back as shown in step 4.

The main prob­lem with act­ive mode FTP actu­ally falls on the cli­ent side. The FTP cli­ent does­n’t make the actu­al con­nec­tion to the data port of the server–it simply tells the serv­er what port it is listen­ing on and the serv­er con­nects back to the spe­cified port on the cli­ent. From the cli­ent side fire­wall this appears to be an out­side sys­tem ini­ti­at­ing a con­nec­tion to an intern­al client–something that is usu­ally blocked.

 

Act­ive FTP Example

Below is an actu­al example of an act­ive FTP ses­sion. The only things that have been changed are the serv­er names, IP addresses, and user names. In this example an FTP ses­sion is ini­ti­ated from test​box1​.slack​s​ite​.com (192.168.150.80), a linux box run­ning the stand­ard FTP com­mand line cli­ent, to test​box2​.slack​s​ite​.com (192.168.150.90), a linux box run­ning ProFT­Pd 1.2.2RC2. The debug­ging (-d) flag is used with the FTP cli­ent to show what is going on behind the scenes. Everything in red is the debug­ging out­put which shows the actu­al FTP com­mands being sent to the serv­er and the responses gen­er­ated from those com­mands. Nor­mal serv­er out­put is shown in black, and user input is in bold.

There are a few inter­est­ing things to con­sider about this dia­log. Notice that when the PORT com­mand is issued, it spe­cifies a port on the cli­ent (192.168.150.80) sys­tem, rather than the serv­er. We will see the oppos­ite beha­vi­or when we use pass­ive FTP. While we are on the sub­ject, a quick note about the format of the PORT com­mand. As you can see in the example below it is format­ted as a series of six num­bers sep­ar­ated by com­mas. The first four oct­ets are the IP address while the last two oct­ets com­prise the port that will be used for the data con­nec­tion. To find the actu­al port mul­tiply the fifth oct­et by 256 and then add the sixth oct­et to the total. Thus in the example below the port num­ber is ( (14×256) + 178), or 3762. A quick check with netstat should con­firm this inform­a­tion.

testbox1: {/home/p-t/slacker/public_html} % ftp -d testbox2
Connected to testbox2.slacksite.com.
220 testbox2.slacksite.com FTP server ready.
Name (testbox2:slacker): slacker
---> USER slacker
331 Password required for slacker.
Password: TmpPass
---> PASS XXXX
230 User slacker logged in.
---> SYST
215 UNIX Type: L8
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
ftp: setsockopt (ignored): Permission denied
---> PORT 192,168,150,80,14,178
200 PORT command successful.
---> LIST
150 Opening ASCII mode data connection for file list.
drwx------   3 slacker    users         104 Jul 27 01:45 public_html
226 Transfer complete.
ftp> quit
---> QUIT
221 Goodbye.

 

Pass­ive FTP

In order to resolve the issue of the serv­er ini­ti­at­ing the con­nec­tion to the cli­ent a dif­fer­ent meth­od for FTP con­nec­tions was developed. This was known as pass­ive mode, or PASV, after the com­mand used by the cli­ent to tell the serv­er it is in pass­ive mode.

In pass­ive mode FTP the cli­ent ini­ti­ates both con­nec­tions to the serv­er, solv­ing the prob­lem of fire­walls fil­ter­ing the incom­ing data port con­nec­tion to the cli­ent from the serv­er. When open­ing an FTP con­nec­tion, the cli­ent opens two ran­dom unpriv­ileged ports loc­ally (N > 1023 and N+1). The first port con­tacts the serv­er on port 21, but instead of then issu­ing a PORT com­mand and allow­ing the serv­er to con­nect back to its data port, the cli­ent will issue the PASV com­mand. The res­ult of this is that the serv­er then opens a ran­dom unpriv­ileged port (P > 1023) and sends P back to the cli­ent in response to the PASV com­mand. The cli­ent then ini­ti­ates the con­nec­tion from port N+1 to port P on the serv­er to trans­fer data.

From the serv­er-side fire­wall’s stand­point, to sup­port pass­ive mode FTP the fol­low­ing com­mu­nic­a­tion chan­nels need to be opened:

  • FTP server­’s port 21 from any­where (Cli­ent ini­ti­ates con­nec­tion)
  • FTP server­’s port 21 to ports > 1023 (Serv­er responds to cli­ent’s con­trol port)
  • FTP server­’s ports > 1023 from any­where (Cli­ent ini­ti­ates data con­nec­tion to ran­dom port spe­cified by serv­er)
  • FTP server­’s ports > 1023 to remote ports > 1023 (Serv­er sends ACKs (and data) to cli­ent’s data port)

When drawn, a pass­ive mode FTP con­nec­tion looks like this:

In step 1, the cli­ent con­tacts the serv­er on the com­mand port and issues the PASV com­mand. The serv­er then replies in step 2 with PORT 2024, telling the cli­ent which port it is listen­ing to for the data con­nec­tion. In step 3 the cli­ent then ini­ti­ates the data con­nec­tion from its data port to the spe­cified serv­er data port. Finally, the serv­er sends back an ACK in step 4 to the cli­ent’s data port.

While pass­ive mode FTP solves many of the prob­lems from the cli­ent side, it opens up a whole range of prob­lems on the serv­er side. The biggest issue is the need to allow any remote con­nec­tion to high numbered ports on the serv­er. For­tu­nately, many FTP dae­mons, includ­ing the pop­u­lar WU-FTPD allow the admin­is­trat­or to spe­cify a range of ports which the FTP serv­er will use. See Appendix 1 for more inform­a­tion.

The second issue involves sup­port­ing and troubleshoot­ing cli­ents which do (or do not) sup­port pass­ive mode. As an example, the com­mand line FTP util­ity provided with Sol­ar­is does not sup­port pass­ive mode, neces­sit­at­ing a third-party FTP cli­ent, such as ncftp.
NOTE: This is no longer the case–use the -p option with the Sol­ar­is FTP cli­ent to enable pass­ive mode!

With the massive pop­ular­ity of the World Wide Web, many people prefer to use their web browser as an FTP cli­ent. Most browsers only sup­port pass­ive mode when access­ing ftp:// URLs. This can either be good or bad depend­ing on what the serv­ers and fire­walls are con­figured to sup­port.

 

Pass­ive FTP Example

Below is an actu­al example of a pass­ive FTP ses­sion. The only things that have been changed are the serv­er names, IP addresses, and user names. In this example an FTP ses­sion is ini­ti­ated from test​box1​.slack​s​ite​.com (192.168.150.80), a linux box run­ning the stand­ard FTP com­mand line cli­ent, to test​box2​.slack​s​ite​.com (192.168.150.90), a linux box run­ning ProFT­Pd 1.2.2RC2. The debug­ging (-d) flag is used with the FTP cli­ent to show what is going on behind the scenes. Everything in red is the debug­ging out­put which shows the actu­al FTP com­mands being sent to the serv­er and the responses gen­er­ated from those com­mands. Nor­mal serv­er out­put is shown in black, and user input is in bold.

Notice the dif­fer­ence in the PORT com­mand in this example as opposed to the act­ive FTP example. Here, we see a port being opened on the serv­er (192.168.150.90) sys­tem, rather than the cli­ent. See the dis­cus­sion about the format of the PORT com­mand above, in the Act­ive FTP Example sec­tion.

testbox1: {/home/p-t/slacker/public_html} % ftp -d testbox2
Connected to testbox2.slacksite.com.
220 testbox2.slacksite.com FTP server ready.
Name (testbox2:slacker): slacker
---> USER slacker
331 Password required for slacker.
Password: TmpPass
---> PASS XXXX
230 User slacker logged in.
---> SYST
215 UNIX Type: L8
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> passive
Passive mode on.
ftp> ls
ftp: setsockopt (ignored): Permission denied
---> PASV
227 Entering Passive Mode (192,168,150,90,195,149).
---> LIST
150 Opening ASCII mode data connection for file list
drwx------   3 slacker    users         104 Jul 27 01:45 public_html
226 Transfer complete.
ftp> quit
---> QUIT
221 Goodbye.

 

Oth­er Notes

A read­er, Maarten Sjouw, poin­ted out that act­ive FTP will not func­tion when used in con­junc­tion with a cli­ent-side NAT (Net­work Address Trans­la­tion) device which is not smart enough to alter the IP address info in FTP pack­ets.

 

Sum­mary

The fol­low­ing chart should help admins remem­ber how each FTP mode works:

 Active FTP :
     command : client >1023 -> server 21
     data    : client >1023 <- server 20

 Passive FTP :
     command : client >1023 -> server 21
     data    : client >1024 -> server >1023

A quick sum­mary of the pros and cons of act­ive vs. pass­ive FTP is also in order:

Act­ive FTP is bene­fi­cial to the FTP serv­er admin, but det­ri­ment­al to the cli­ent side admin. The FTP serv­er attempts to make con­nec­tions to ran­dom high ports on the cli­ent, which would almost cer­tainly be blocked by a fire­wall on the cli­ent side. Pass­ive FTP is bene­fi­cial to the cli­ent, but det­ri­ment­al to the FTP serv­er admin. The cli­ent will make both con­nec­tions to the serv­er, but one of them will be to a ran­dom high port, which would almost cer­tainly be blocked by a fire­wall on the serv­er side.

Luck­ily, there is some­what of a com­prom­ise. Since admins run­ning FTP serv­ers will need to make their serv­ers access­ible to the greatest num­ber of cli­ents, they will almost cer­tainly need to sup­port pass­ive FTP. The expos­ure of high level ports on the serv­er can be min­im­ized by spe­cify­ing a lim­ited port range for the FTP serv­er to use. Thus, everything except for this range of ports can be fire­walled on the serv­er side. While this does­n’t elim­in­ate all risk to the serv­er, it decreases it tre­mend­ously. See Appendix 1 for more inform­a­tion.

Related Post

This entry was posted in   IT.
Bookmark the   permalink.

admin has written 133 articles