Which operating system can best secure an FTP site?

In this expert Q&A, platform security expert Michael Cobb explains how a secure FTP protocol can improve websites and Web services.

We need to set up a secure FTP server, 128-bit encrypted, so that our clients can upload their documents to it. We have an FTP site that can be accessed through the Web, but I do not believe that it is secure. How can I test its security, and which operating system would be best for it?
Nowadays, allowing clients to upload files to a website is a common business requirement. Unfortunately, thought is seldom given to how such a service should be set up and secured. FTP, like many other common Internet protocols such as HTTP and SMTP, was created before the introduction of SSL. It is inherently insecure, as data cannot be encrypted during transit. In the case of FTP, this means that usernames, passwords, FTP commands and transmitted files can be captured using a packet sniffer.

Say that you set up your FTP site so that it requires a username and password. When clients connect using their browsers, usernames and passwords are still sent in cleartext, as are the files being uploaded. In order to keep network sniffers from reading clients' passwords and files upon connection, you need to set up a secure FTP server.

Regarding the operating system that the FTP server should run on, it depends on what in-house expertise you have. It is no good setting up a Unix system to run your FTP site, for example, if nobody in your organization has in-depth knowledge of running the OS. The main concern is that the server is properly hardened for service on the Internet and is located on a secured DMZ (demilitarized zone) segment of the network.

The next issue to resolve is which secure FTP protocol to use. The two main choices are FTPS or SFTP.

FTPS uses an SSL/TLS layer below the standard FTP protocol to encrypt the control and/or data channels. The preferred method of use is Explicit FTPS. In this mode, the FTP client connects to port 21 on the server and starts an unencrypted FTP session as normal, but requests that TLS security be used. It then performs the appropriate handshake before sending any sensitive data. Data can be encrypted in the command channel, the data channel or ideally both. Because FTPS is just an extension of FTP, it is supported by most servers. Also, since it uses the same ports as FTP, there is no need to open any additional firewall ports.

SFTP is a newer protocol that uses Secure Shell (SSH) to provide a secure service where the server both encrypts the data and handles the file transfer. SFTP includes many file-management capabilities, such as deleting, renaming, interrupted transfer resumption and directory listings. However, the many functions make it important to set the correct permissions on your SFTP server, ensuring that least privilege access is maintained. If your website is one of several hosted on a shared server, be extra careful. If a hacker can compromise one of the other sites on the server, it's possible that the attacker could extend control to the server itself and to your site, too.

Most organizations would not want clients to be able to see the files that other clients have uploaded to the site. This requires that each client has its own username, password and directory where files are stored during the upload process.

Also consider the security of the files once they have been uploaded. Remember that they are sitting in the DMZ, and so they are at risk if the DMZ gets hacked. Some FTP server programs support file-integrity checks using cryptographic hashes. Files should be encrypted while at rest on the FTP server, and again when being transferred between the DMZ and the internal network.

Finally, to test whether your FTP service is secure, I would recommend penetration testing to validate the setup.

More information:
  • Learn how some companies are taking advantage of secure FTP servers.
  • A readers asks network security expert Mike Chapple, "Will FTP ever be a secure way to send files?"
  • This was last published in April 2008

    Dig Deeper on Web application and API security best practices