To explain the difference between passive and active transfers it is necessary to cover some of the details of how the FTP protocol works.  The FTP protocol uses multiple channels for communication.  These channels are known as the command channel and the data channel.

Command Channel

The command channel is responsible for accepting commands from an FTP client and typically runs on port 21 for standard FTP and encrypted FTP using explicit SSL, or port 990 for encrypted implicit SSL connections.  The command channel is also responsible for sending replies back to the FTP client in response to client commands.  An example of a command sent by an FTP client might be “PWD” asking the server for the current remote directory.  The server will respond with a response code followed by the current remote directory such as “257 /home/users/jsmith”

Data Channel

The data channel is used for transferring files and for performing directory listings.  Unlike the command channel, the data channel does not run on a single persistent port.  Instead whenever a file transfer or directory listing is performed a new (typically random) port is is opened for sending the data (either by the client or server) and the data transfer is performed.  Once the data transfer is complete the port is closed.  The port on which the data channel is performed and additionally whether the client or server is responsible for opening this port depends on the data transfer mode used.  There are two data transfer modes available in FTP.  These data transfer modes are known as passive and active a.k.a non-passive.  These data transfer modes should not be confused with “binary” and “ASCII” which relates to the format in which data is transferred and not the method in which data is transferred.

Passive Mode

In passive mode the server is responsible for opening the listening port and telling the client what server-side listening IP/port to connect to in order to perform the transfer.  To start a passive transfer the client sends the “PASV” command.  The server then responds with the IP address and port that the client should connect to in order to perform the transfer.  Once the transfer is complete the port is closed by the server.

Active (Non-Passive) Mode

In active mode the client is responsible for opening the listening port and telling the server what IP/port to connect to in order to perform the transfer.  To start an active transfer the client sends the “PORT” command along with arguments telling the server what client-side listening IP/port the server should connect to in order to perform the transfer.  Once the transfer is complete the port is closed by the client.

Which one should I use?

This depends largely on the FTP server capabilities and configuration.  From the client perspective the first question you need to ask yourself is “Does the server support passive connections?”.  There are some FTP servers, especially those running on older mainframe systems that do not support passive connections.  It’s also possible that while the server supports passive connections the server may have this feature disabled.  This is usually due to an aggressive firewall policy on the server side that disallows passive connections.  Naturally, if the server doesn’t support/allow passive connections then you will be forced to use active mode.  The easiest way to test whether a server supports passive mode is to simply connect using passive mode and perform a directory listing to see what happens.  If you get back a directory listing without error then the server supports passive mode.  If however you get an error like “500 PASV command not supported” or “500 PASV command disabled” then you will need to use an active connection.  In general you should always default to using a passive connection when possible.  It is much more firewall-friendly to clients than active mode given that most Internet users today are behind firewalls using NAT software.

From the perspective of an FTP server administrator you should make it as easy as possible for your clients to connect.  This means enabling passive mode on your server so that clients who are behind a firewall or router that uses NAT software, can connect easily.

Demonstrates how to create encryption keys using the open-source GPG tools.  This is a flash tutorial.

Creating PGP keys using GPG

Demonstrates how to encrypt file automatically upon upload using triggers and PGP encryption.  This is a flash tutorial.

Encrypting files using PGP and JSCAPE Secure FTP Server

Demonstrates managed file transfer MFT using custom actions.

http://www.jscape.com/articles/writing_custom_actions_secure_ftp_server.html

http://www.jscape.com/secureftpserver/

This article demonstrates how to automate post file transfer processing for a fictitious printing press company using JSCAPE Secure FTP Server.

View Article

There are several data transfer commands which can be used during an FTP session. These include STOR (upload a file), RETR (download a file), LIST (get a full directory listing) and NLST (get a directory listing of filenames). Prior to a passive data transfer the client must send the PASV command to the server in order to request that the server open up a port for data transfer. The server will respond with the IP address and port the client should connect to in order to perform the data transfer. PASV connection theft occurs when the client requests that the server open a data port using the PASV command but before the original client can connect to this port another rogue client connects to this port thus hijacking the original client’s data connection. But how does the rogue client know what port to connect to you ask? The rogue client could use a brute force method of simply trying all available ports, or he could make an intelligent guess as to what ports may be opened next by looking at what ports were opened in previous sessions (many servers use a sequential method of opening ports for data transfer). What happens next depends on the following command issued by the original client.

If the original client issues a STOR command then the rogue client may then upload a file using the hijacked data stream, possibly overwriting a file or installing a trojan. If the original client issues a RETR command then the rogue client may receive the file requested for download. Both scenarios of course present a severe security risk. Most servers today, including JSCAPE Secure FTP Server, implement methods for preventing against PASV connection theft. These methods verify that the client who requested the PASV connection is the same as the client which eventually connects to the data port opened by the server.