The short list of real-life TCP ports we looked at a few moments back contained, among other things, FTP, the classic file transfer protocol. FTP is a relic of the early Internet, when experiments were the norm, and security was not really on the horizon in any modern sense. FTP actually predates TCP/IP,[17] and it is possible to track the protocol’s development through more than 50 RFCs. After more than 30 years, FTP is both a sad old thing and a problem child—emphatically so for anyone trying to combine FTP and firewalls. FTP is an old and weird protocol, with a lot to dislike. Here are the most common points against it:
Passwords are transferred in the clear.
The protocol demands the use of at least two TCP connections (control and data) on separate ports.
When a session is established, data is communicated via ports selected at random.
All of these points make for challenges security-wise, even before considering any potential weaknesses in client or server software that may lead to security issues. As any network graybeard will tell you, these things tend to crop up when you need them the least.
Under any circumstances, other, more modern and more secure options for file transfer exist, such as SFTP and SCP, which feature both authentication and data transfer via encrypted connections. Competent IT professionals should have a preference for some other form of file transfer than FTP.
Regardless of our professionalism and preferences, we sometimes must handle things we would prefer not to use at all. In the case of FTP through firewalls, we can combat problems by redirecting the traffic to a small program that is written specifically for this purpose. The upside for us is that handling FTP offers us a chance to look at redirection.
The easiest way to handle FTP is to have PF redirect the traffic for that service to an external application that acts as a proxy for the service. The proxy then interacts with your packet filter through a well-defined interface.
Enabling FTP transfers through your gateway is amazingly simple, thanks to the FTP proxy program included in the OpenBSD base system. The program is called—you guessed it—ftp-proxy.
FTP being what it is, the proxy needs to dynamically insert rules in your rule set. ftp-proxy interacts with your configuration via an anchor (a named rule set section) where the proxy inserts and deletes the rules it constructs to handle your FTP traffic.
To enable ftp-proxy, you need to add this line to your /etc/rc.conf.local file:
ftpproxy_flags=""
You can start the proxy manually by running /usr/sbin/ftp-proxy if you like, and you may want to do this in order to check that the changes to the PF configuration you are about to make have the intended effect.
For a basic configuration, you need to add only three elements to your /etc/pf.conf: the anchor and two pass rules. The anchor declaration looks like this:
anchor "ftp-proxy/*"
In pre-OpenBSD 4.7 versions, two anchor declarations were needed:
nat-anchor "ftp-proxy/*" rdr-anchor "ftp-proxy/*"
The proxy will insert the rules it generates for the FTP sessions here.
Then you also need a pass rule to let FTP traffic in to the proxy:
pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port 8021
Note the rdr-to part. This redirects the traffic to the local port where the proxy listens.
Here is the pre-OpenBSD 4.7 version of this rule:
rdr pass on $int_if proto tcp from any to any port ftp -> 127.0.0.1 port 8021
Finally, add a pass rule to let the packets pass from the proxy to the rest of the world:
pass out proto tcp from $proxy to any port ftp
$proxy expands to the address to which the proxy daemon is bound.
Reload your PF configuration:
$ sudo pfctl -f /etc/pf.confBefore you know it, your users will thank you for making FTP work.
This example covers a basic setup where the clients in your local network need to contact FTP servers elsewhere. The basic configuration here should work well with most combinations of FTP clients and servers.
You can change the proxy’s behavior in various ways by adding options to the ftpproxy_flags= line. You may bump into clients or servers with specific quirks that you need to compensate for in your configuration, or you may want to integrate the proxy in your setup in specific ways, such as assigning FTP traffic to a specific queue. For these and other finer points of ftp-proxy configuration, your best bet is to start by studying the man page.
If you are interested in ways to run an FTP server protected by PF and ftp-proxy, you could look into running a separate ftp-proxy in reverse mode (using the -R option), on a separate port with its own redirecting pass rule.
Note
If your PF version predates the ones described here, please look up the first edition of this book and the documentation for your operating system for information on how to use some earlier FTP proxies.
[17] The earliest RFC describing the FTP protocol is RFC 114, dated April 10, 1971. The switch to TCP/IP happened with FTP version 5 as defined in RFCs 765 and 775, dated June and December 1980, respectively.