Anonymous FTP

A host which provides an FTP service may additionally provide Anonymous FTP access as well. Under this arrangement, users do not strictly need an account on the host. Instead the user typically enters 'anonymous' or 'ftp' when prompted for username. Although users are commonly asked to send their email address as their password, little to no verification is actually performed on the supplied data.

As modern FTP clients typically hide the anonymous login process from the user, the ftp client will supply dummy data as the password (since the user's email address may not be known to the application).

For example, the following ftp user agents specify the listed passwords for anonymous logins:

* Mozilla Firefox (2.0) — mozilla@example.com

* KDE Konqueror (3.5) — anonymous@

* wget (1.10.2) — -wget@

* lftp (3.4.4) — lftp@

The Gopher protocol has been suggested as an alternative to anonymous FTP, as well as Trivial File Transfer Protocol and File Service Protocol.

Technorati Tags: TFTP,Anonymous FTP,FTP,File transfer,Protocol,FTP Service,Access,Modern FTP,Login Process,Mozilla,KDE,Wget,Lftp,Gopher Protocol

FTP and NAT devices

The representation of the IPs and ports in the PORT command and PASV reply poses another challenge for NAT devices in handling FTP. The NAT device must alter these values, so that they contain the IP of the NAT-ed client, and a port chosen by the NAT device for the data connection. The new IP and port will probably differ in length in their decimal representation from the original IP and port. This means that altering the values on the control connection by the NAT device must be done carefully, changing the TCP Sequence and Acknowledgment fields for all subsequent packets.

For example: A client with an IP of 192.168.0.1, starting an active mode transfer on port 1025, will send the string "PORT 192,168,0,1,4,1". A NAT device masquerading this client with an IP of 192.168.15.5, with a chosen port of 2000 for the data connection, will need to replace the above string with "PORT 192,168,15,5,7,208".

The new string is 23 characters long, compared to 20 characters in the original packet. The Acknowledgment field by the server to this packet will need to be decreased by 3 bytes by the NAT device for the client to correctly understand that the PORT command has arrived to the server. If the NAT device is not capable of correcting the Sequence and Acknowledgement fields, it will not be possible to use active mode FTP. Passive mode FTP will work in this case, because the information about the IP and port for the data connection is sent by the server, which doesn't need to be NATed. If NAT is performed on the server by the NAT device, then the exact opposite will happen. Active mode will work, but passive mode will fail.

It should be noted that many NAT devices perform this protocol inspection and modify the PORT command without being explicitly told to do so by the user. This can lead to several problems. First of all, there is no guarantee that the used protocol really is FTP, or it might use some extension not understood by the NAT device. One example would be an SSL secured FTP connection. Due to the encryption, the NAT device will be unable to modify the address. As result, active mode transfers will fail only if encryption is used, much to the confusion of the user.

The proper way to solve this is to tell the client which IP address and ports to use for active mode. Furthermore, the NAT device has to be configured to forward the selected range of ports to the client's machine.

Criticisms of FTP

Passwords and file contents are sent in clear text, which can be intercepted by eavesdroppers. There are protocol enhancements that circumvent this, for instance by using SSL, TLS or Kerberos.

Multiple TCP/IP connections are used, one for the control connection, and one for each download, upload, or directory listing. Firewalls may need additional logic and or configuration changes to account for these connections.

It is hard to filter active mode FTP traffic on the client side by using a firewall, since the client must open an arbitrary port in order to receive the connection. This problem is largely resolved by using passive mode FTP.

It is possible to abuse the protocol's built-in proxy features to tell a server to send data to an arbitrary port of a third computer; see FXP.

FTP is a high latency protocol due to the number of commands needed to initiate a transfer.
No integrity check on the receiver side. If a transfer is interrupted, the receiver has no way to know if the received file is complete or not. Some servers support extensions to calculate for example a file's MD5 sum (e.g. using the SITE MD5 command) or CRC checksum, however even then the client has to make explicit use of them. In the absence of such extensions, integrity checks have to be managed externally.

No date/timestamp attribute transfer. Uploaded files are given a new current timestamp, unlike other file transfer protocols such as SFTP, which allow attributes to be included. There is no way in the standard FTP protocol to set the time-last-modified (or time-created) datestamp that most modern filesystems preserve. There is a draft of a proposed extension that adds new commands for this, but as of yet, most of the popular FTP servers do not support it.