Making FTP secure while keeping it fun

In the following we discuss the measures we took to implement transparently secure FTP for our users

The trouble with FTP

Everybody loves FTP. It's easy and FTP clients come bundled with lots of software, such a DreamWeaver. The problem is that anyone who happens to be between you and the machine your connecting to can listen in on the clear-text transmission of your username and password.

FTP is insecure because it dates to elder days when the 'net was a tight-knit community. Newer and better protocols exist that allow your
information (both authentication info and the data you are transfering) to remain private while providing additional advantages (such as good on the fly compression, which is hard to achieve at lower levels such as the IP layer). If you are lucky and can connect to the remote host using SSH, then you can surely use an SFTP client that allows you to transfer files in the same way as FTP but through an encrypted tunnel.

If you can't use SSH/SFTP, or others on your LAN don't have the ability/desire to do so, all is not lost--just read on

Possible solutions

It is possible to use FTP securely in a couple of ways, all of which involve encrypting the traffic between your computer or LAN and the remote system. To allow FTP clients on various types of systems (Linux, Mac and Windows) to work we examined:

• Using an IPSec VPN


• Using PPP over SSH


• Using FTPS (FTP over SSL)

IPSec

Using a VPN allows you to connect to the remote system or network as if it was on your local LAN, so FTP or any other connection will function normally while being transparently transported to the remote host over an encrypted channel.

I've always found setting up IPsec to be a nightmare (kernel recompile? ugh, gimme a break) so pretty much skipped it. The fact is that we need access to a number of different hosts and can't setup IPSec on a number of these...

PPP over SSH VPN

Using PPP over an SSH tunnel is actually pretty easy and the last distribution of the PPP package
I checked included the ppp-on-ssh script (and accompanying options-ssh-rem and options-ssh-loc files) in the scripts/ directory. This system was easy enough to warrant the time spent setting it up but some of our hosts are on "virtual servers" and use a special kernel without ppp support, so we needed another solution. If you're interested in this, see the ppp-on-ssh script or the very nice VPN HOWTO.

FTPS

FTPS is an extension to FTP that allows connections between clients and server to be encrypted using SSL. The mod_tls module adds FTPS support to the ProFTPD FTP server. FTPS is supported by others as well (like WU FTPD) but we use ProFTPD.

A number of FTP clients support FTP-SSL/FTP-TLS but of course, the whole point of this excercise was to find a means of transparently providing FTP security without getting on our web designers' nerves... So asking them to use another client is out of the question.

A complete solution

FTPS made most sense to us but in order to make it work for everyone transparently we needed an extra ingredient: Tomas Svensson's excellent TLSWrap. TLSWrap is:

a TLS/SSL FTP wrapper/proxy for UNIX and Windows, allowing you to use your favourite FTP client with any TLS/SSL-enabled FTP server

By installing TLSWrap on one of our LAN systems, we can fully encrypt all the FTP traffic that travels on the 'net for any of our FTP clients. As an example, an old FTP client configuration might have been:

username: ftpuser

password: secret

host: remotehost.example.com

port:21

When TLSWrap is setup and running on our "ftpproxy" system (safely within our LAN), the FTP client's config changes to:

username: ftpuser@remotehost.example.com:21

password: secret

host: ftpproxy

port:21

So, to the FTP client software, the connection is with the ftpproxy system on the local LAN. Behind the scenes, TLSWrap decomposes the new username (ftpuser@remotehost.example.com:21) and determines that it must make a secure connection to remotehost.example.com on port 21. It validates the username/password with the remotehost and proceeds to proxy FTP requests from the client through the SSL tunnel.

The only restrition is that the client support the passive FTP (PASV) or Extended Passive (EPSV) connections (this is the case for most FTP clients).

Installation

The installation is comprised of two components:

• TLSWrap on one of your internal systems (on your computer or somewhere on your LAN);


• An FTPS-enabled FTP server running on the remote hosts you wish to connect to.

TLSWrap installation

TLSWrap runs on a number of system types, including Linux, *BSD and even Windows 2k (see the TLSWrap
site for details). Installation is straightforward and involves a quick compile with:

        $ ./configure
        $ make
        # make install

In order to make starting and stoping the system easy, I setup this TLSWrap start/stop script by saving it to /etc/rc.d/init.d/tlswrap (RedHat system). You can then do any of the usual:

        
        /etc/rc.d/init.d/tlswrap start
        /etc/rc.d/init.d/tlswrap stop
        /etc/rc.d/init.d/tlswrap restart
        /etc/rc.d/init.d/tlswrap status
       

and on RedHat systems, use chkconfig to easily enable/disable TLSWrap on boot or when changing runlevels with:

        # chkconfig --add tlswrap
        # chkconfig --list tlswrap

Finally, edit /etc/rc.d/init.d/tlswrap and set LISTENON and PORT according to the IP address and port you want
TLSWrap to bind to and listen on.

ProFTPD with FTPS support installation

If you've elected to use the ProFTPD FTP server, download the latest current source and ensure you have the SSL libraries (do a locate libssl.so to find out) installed before proceeding (use the openssl devel RPMs or get them from OpenSSL.org). Then untar the ProFTPD source and do:

        $ LDFLAGS='-L/usr/local/ssl/lib' ; export LDFLAGS
        $ ./configure --with-modules=mod_wrap:mod_tls
        $ make
        # make install

The first line may not be required but, if you use it, make sure the LDFLAGS points to the location of your libssl.so installation directory.

Follow the mod_tls insturctions and setup the /usr/local/etc/proftpd.conf file with a mod_tls section, like:

  
    TLSEngine on
    TLSLog /var/log/ftpd-tls.log
    TLSProtocol TLSv1
 
    # Are clients required to use FTP over TLS when talking to this server?
    TLSRequired on
 
    # Server's certificate
    TLSRSACertificateFile /usr/local/apache2/conf/ssl.crt/psychogenic.crt
    TLSRSACertificateKeyFile /usr/local/apache2/conf/ssl.key/server.key
 
    # CA the server trusts
    TLSCACertificateFile /usr/local/apache2/conf/ssl.crt/root.cert.pem
 
    # Authenticate clients that want to use FTP over TLS?
    TLSVerifyClient off
  

Notice that we are re-using the SSL certificate issued for our website (TLSRSACertificateFile). You can generate a self-signed certificate using OpenSSL if you don't have one (discussed elsewhere, just make sure the ProFTPD config points to the right place.

If your site doesn't have too much traffic, you can use xinetd to start the FTP server. Just set "ServerType inetd"
in /usr/local/etc/proftpd.conf and stick:

# default: on
# description: The ProFTPD FTP server
service ftp
{
        flags           = REUSE
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/local/sbin/proftpd
        log_on_failure  += USERID
        disable         = no
}

into a file called /etc/xinetd.d/proftp. The FTPS server will be available (by default on port 21) as soon as you restart xinetd.

Testing your installation

Start by testing the remote server by connecting to the appropriate port (21 by default) using telnet:

        $ telnet remotehost.example.com 21

and you should see something like:

        220 ProFTPD 1.2.10rc3 Server (Psychogenic FTP) [remotehost.example.com]

See that banner? Good, type quit and hit enter. Now make certain tlswrap is started on the ftpproxy system and telnet over to the appropriate port (7000 if you used our /etc/rc.d/init.d/tlswrap default):

        $ telnet ftpproxy 7000

If everything is working all right, you should see:

        220 TLSWRAP FTP Proxy Server (Version 0.7) ready.

Now enter valid user and pass (password) lines and you should be able to connect to the remote server through SSL

        user ftpuser@remotehost.example.com:21
        331 Password required for hosted.
        pass secret
        230 User hosted logged in.
        quit
        221 Goodbye.
        Connection closed by foreign host.

Securing the system

A few tips to ensure a safe journey. If you can, make sure you set "TLSRequired on" in the ProFTPD config as in the example above--this forces SSL connections only to the server.

Also use the remote server's /etc/hosts.allow and /etc/hosts.deny files to your advantage. Add

        proftpd: ALL

to /etc/hosts.deny and put a specific line, such as:

        proftpd: 127.0.0.1 62.192.204.0/255.255.255.0

in /etc/hosts.allow to allow connections only from valid clients.

Also ensure that only LAN users can connect to the TLSWrap port on the ftpproxy, either by having the server listen on an internal IP/machine or by using an appropriate firewall config.