Archive for » February, 2011 «

Friday, February 25th, 2011 | Author: bmadsen

Introduction

So here’s a bit of wisdom for those interested in setting up FTP-TLS encrypted FTP services.  A very popular ftp server in the Linux world is ‘vsftpd‘.  It is found natively in most Linux distributions these days and is very secure and functional.

One situation I seem to keep running into is the need to securely communicate over FTP services.  There are a few ways to do this:

  1. Encrypt the files prior to transfer with a tool such as PGP
  2. Use a VPN connection and FTP over the VPN
  3. Use an SSH transport FTP such as SFTP
  4. Use FTP encryption, such as FTP-TLS

All of these methods have their place.  However, we will focus on #4 today as it seems to be the lightest weight in terms of administration and ease of use.

The FTP Firewall Fix

One of the ways that FTP (in normal, unencrypted mode) is configured to work over stateful packet inspection firewalls is through the use of the concept of an FTP Helper module.  This module is generally a feature of the firewall software.  It watches the FTP control channel on port 21 for commands issued to open a data connection using PASV mode (otherwise known as Passive Mode).  This means that the firewall configuration need only open TCP port 21 to enable firewall traversal of FTP connections.  Since the firewall can analyze the FTP control channel and dynamically open TCP ports for DATA connections as needed, you no longer have to worry about opening multiple ports to enable FTP communications over common firewalls.

Encryption Using FTP-TLS

Using a server such as “vsftpd” that has the ability to use TLS to allow “explicit” mode encryption through the use of the “AUTH SSL” command, one can enable encrypted communications using FTP style communications.  This feature is then implemented by various popular ftp clients such as FileZilla and Curl, as well as various programming libraries.  One of the major problems that happens, however, when you encrypt the FTP control channel, in addition to the data channel, is that you prevent the FTP Helper feature running on the firewall from being able to read the FTP control commands that request opening of the data connections.  Therefore, the firewall can no longer dynamically open ports to enable data channel connections and your happily functioning FTP server is not able to speak to networks on the other side of the firewall.

To fix this problem, ‘vsftpd’ uses a couple of configuration directives to allow specific configuration of PASV ports to a small range of ports.

pasv_min_port=#####
pasv_max_port=#####

This allows a system administrator to configure only a small range of ports for PASV use (encrypted or not).  This means that, for example, a range of 9000 through 9005 could be configured in ‘vsftpd’ and then specifically allowed through the firewall.  This alleviates the need for the firewall to watch and dynamically open the ports for communications, and your FTP-TLS communications can remain fully encrypted.

Considerations

Something to consider is that in picking the particular ports you bind to the ftp server for passive communications, you should consider a system’s configured “Ephemeral Ports“, or the ports that local clients use to open outbound connections.  You should also take care to put the range in an unused range where no system services are already using the ports.

Friday, February 18th, 2011 | Author: bmadsen

I’ve been working with Subversion a lot lately and had to revert a file deletion that occurred a year ago in my employer’s code-base.  Doing a quick Google search, I found this article:

http://www.canfield.com/content/svn-restore-deleted-file

The article got me on the right track, but I found that I could drop the “-r (revision)” parameter and just do this:

svn copy https://{URL}/canfield.conf@98 .
svn commit

This keeps the history of the file during the restore process, which some of the other methods may not do.  One important note is that you go back to the revision before the file was deleted.