FTP Reviewed
The File Transfer Protocol (FTP ) is one of the oldest and most often used protocols on the Internet. Because it is often integrated into our browsers, however, it is easy to forget that it is even there. FTP facilitates the vast majority of file transfers across the Internet, and though we all know and use FTP applications every day, every once in a while it's good to go back to the RFC s and see what FTP is actually doing. This paper does just that.
FTP was designed to allow people to copy files between two different host computers. These separate hosts could potentially be running different operating systems, using different file storage systems, and using different character sets.
FTP works using two different TCP connections. The first connection is called a control connection, and the second is called the data connection. The control connection is established at the beginning of the FTP session and is maintained for the duration of the session. Commands issued by the client, and replies originating from server are exchanged along this connection. The data connection on the other hand is transient and brought up and torn down as needed. This data connection is used to transfer files and directory listings to and from the client at the client's request.
Glossing over the gory details
Before I continue any further I want to stress that this is just a simple review of FTP . The primary RFC for FTP (RFC 959 ) is sixty-nine pages long. If you want the last word on FTP I would suggest you go straight to the source and read the RFC yourself. My intent here is to cover the basics so that you can be more aware of the security implications of setting up or using FTP services.
A typical FTP session goes like this. Initially the FTP server opens port 21 and waits for a connection from an FTP client. A client will then opens a connection from an ephemeral port to port 21 on the server. Once this connection has been established it remains open for the duration of the FTP session.
Upon establishing a control connection to the server, it is up to the client to log in. The client does this by sending the "USER " command along with the user id it wishes to log in with. Typically the server then replies with a response code of 331 (a so-called "positive intermediate reply") which indicates that the server is waiting for a password. As you might expect, the client then completes the login process by sending the "PASS " command along with the password for the given account.
Many FTP servers are set up to disseminate information freely to the public. Often these servers allow anonymous logins. Though usersames are essentially irrelevant in this case, the actual identification takes place in the same manner. The client sends "USER anonymous", the server responds with "330 " (send the password), and the client then sends "PASS your@email.address". Occasionally FTP servers will do a reverse DNS lookup on your IP to record the server you connected from. If the server can not establish a host name for your IP address using a reverse DNS lookup then it often won't let you log in.
Once you have logged in to the FTP server, the client establishes how the data is to be transported between the two hosts. The following table briefly enumerates the choices. The data representation is described by choosing one item from each column in the table.
| Type | Format (text only) | Structure | Mode |
| ASCII | Nonprint | File | Stream |
| EBCDIC | Telnet | Record | Block |
| Binary | Fortran | Page | Compressed |
| Local |
Now that the two hosts have established how they will speak with each other, the client may issue commands to either change the current working directory on the server, get directory listings from the server, get files from the server, or put files on the server. Recall that these commands are sent over the command connection. All directory listings and files sent as a result of these comannds, on the other hand, are transferred over the data connection. The data connection is the trickiest part of FTP .
There are two possible ways of establishing a data connection: active, and passively-initiated connections. In the active technique, the client first issues a PORT command to the server. This indicates to the server which port the client wishes to receive the data on. The server acknowledges this PORT command and then opens a data connection from port 20 on the server to the previously established ephemeral port on the client. Any data requested by the client is then exchanged on this TCP connection. When the transfer is complete, the server closes the data connection by transmitting a FIN packet and the TCP connection is torn down. The next time the client requests data, a new data connection is built and the whole process repeats.
The second way of creating a data connection is called a passively-initiated data transfer. Instead of issuing a PORT command, the client can issue the PASV command. The effect of this is that the server picks an ephemeral port to listen on and transmits this value to the client.The client then opens a connection to this port, and the data transfer proceeds as explained above. The original use for the PASV command was to facilitate data transfers initiated by a client between two remote hosts. (This third-party file transfer is not explained in this article, but suffice to say that it can happen.) As you will see on the next page, however, the advent of packet filters and firewalls has caused almost all data transfers over FTP to be initiated passively.
Bring on the paranoia!
After reading the above I would hope the little rotating red "I see some security concerns here" light was going off in your head. The description on the previous page raises a whole series of potential security issues, some of which I'll look at now.
Most obviously, the password issued by the client using the "PASS " command is sent in clear text. This packet - looking somewhat like "PASS secret" - is transmitted via TCP to the FTP server. Along the way this packet could pass through any number of routers, bridges, hubs, and NIC s. It follows that at many points along this trip this packet could have been captured, examined, and then re-sent along its merry way by an attacker. Assuming they had also captured the previous "USER " packet, the passive listener now has access to the FTP server using your account. It doesn't always end there. Since most people like to reuse passwords, by tracing the FTP session back to your computer, this enterprising intruder has now significantly increased his or her odds of compromising your system in other ways.
Another potential problem is the very act of getting FTP through a firewall. Regulating data transmissions with FTP can be very tricky, particularly if the data is being actively transmitted. With active data transmissions the server makes inbound connections to unknown ports on machines behind your firewall. Without statefull packet inspection, FTP sessions require you to allow inbound connections from port 20 on the outside to all ephemeral ports behind your firewall. This situation is probably best described with a picture:
FTP Port Connections
There are other problems with FTP as well. FTP doesn't account for host verification, data authentication, or data protection. With basic FTP , the server doesn't really have any means of verifying that the client is who the client says they are. Similarly, the client never really is sure the server is who they say they are. Both ends of this transaction are open to man-in-the-middle attacks by a hacker capturing the hosts packets, and spoofing responses. In addition, the data can be viewed in transit, and modified or substituted.
Finally, the complexity in the number of different types of data transmission (compressed paged nonprinting ASCII versus streaming local files), commands, and handshaking makes for a fairly complex server daemon. This imposes additional difficulty on the software developer when they try to implement this protocol properly. Inevitable, difficulty results in bugs. This coupled with the fact that FTP is typically an external service accessible from other networks goes a good distance to explaining why there are so many FTP exploits and attacks. Need proof? See the Recent Exploits section, below.
Chris Grant
Recent FTP Exploits
CERT
CIAC
- SUN ftpd Vulnerability
- ftpd Signal Handling Vulnerability
- SGI IRIX ftpd Signal Handling Vulnerability
- Sun Solaris Vulnerabilities ftpd/rlogind
- IBM AIX ftp client Vulnerability
- FTP Bounce Vulnerability
IBM
SUN
Digital UNIX
References
If you want to find out more information about FTP I would refer you to three primary sources.
- RFC 959 "File Transfer Protocol (FTP )" – the definitive resource on FTP
- RFC 1579 "Firewall-Friendly FTP "
- RFC 2228 "FTP Security Extensions"
- TCP/IP Illustrated, Volume 1 pages 419 to 439 – the TCP/IP bible (this should be on your bookshelf)
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
