PASV Ftp...a Definition?
William LeFebvre
Christopher L. Morrow <mor...@jrdmail.anser.org> wrote:
>I am having a problem with a client understanding what pasv ftp is...
>In my search for a decent answer I thought that maybe someone on this
>list might be able to provide a definition of the pasv ftp connection,
>it's security implications and maybe a few pointers on the net for
>further information about this topic...
In a normal FTP session, the server initiates the connection for the
data circuit, using as a destination either the default FTP data port
(20) or the last address/port specified by the client via the PORT
command.
The procedure goes like this:
client connects to server's port 21
client logs in (of course)
client sends "PORT" command referring to some random port (x),
usually on its own machine.
client sends "send" or "recv" command (or "list" or "nlst", etc.),
then listens on port x.
server connects to client's port x.
data transfer occurs (direction immaterial)
For those who understand the principles of packet filtering, this
poses a seemingly insurmountable obstacle to the construction of an
effective firewall. Enter the passive mode connection. Rather than
the server initiating the data connection, the client sends a "PASV"
command which instructs the server to enter passive mode. Then at the
appropriate time, the client initiates the data connection by
contacting the server.
The procedure goes like this:
client connects to server's port 21
client logs in (of course)
client sends "PASV" command
server responds with a random port number (x) on its own machine
client sends "send" or "recv" command (or "list" or "nlst", etc.)
server listens on port x
client connects to server's port x
data transfer occurs (direction immaterial)
By doing it this way, the client is initiating all connections and a
filtering firewall router can easily be configured to block all
incoming connection requests (i.e.: those TCP packets which do not
have the ACK bit set and thus are not part of an already established
connection).
As should be obvious by now there are two requirements to making this work:
1. an FTP client that can do passive mode
2. an FTP server which understands the PASV command
Most (nearly all) popular FTP sites on the Internet today are running
daemons which understand PASV. Also, many of the clients available
today can do passive connections, although some may not do them by
default (they may need to be explicitly reconfigured). Unfortunately,
many of the Unix vendors do not yet ship ftp client (or server)
programs which do passive mode as part of their standard Unix package.
You'll have to go and find them on the net.
A good place to start for both of these would be the archives at UUNet.
William LeFebvre
Decision and Information Sciences
Argonne National Laboratory
lefe...@dis.anl.gov
D. J. Bernstein
> server responds with the port number x
> server listens on port x
From RFC 959: ``The response to this command includes the host and port
address this server _is listening on_'' (emphasis added). The server has
to be listening before it responds. Otherwise you have a race between
the client and the server.
One reason the client shouldn't send its RETR before connecting, btw, is
that an attacker can casually connect right after the RETR and steal all
your data.
Another PASV difficulty is that the output format isn't specified. Some
clients (notably, Netscape 1.0) assume that the PASV response is in the
format used by the BSD ftpd; they misparse other PASV responses, in
violation of RFC 1123, section 4.1.2.6.
---Dan
