Configuring and Using an FTP Proxy

Mick shows you how to add a layer of security between the bad guys and your public FTP servers.
ftp-proxy.conf

And now, finally, it's time to configure your proxy dæmon. As I mentioned, this is done in the file ftp-proxy.conf, which resides either in /etc/proxy-suite or in /usr/local/etc/proxy-suite. You may be confused or annoyed by SuSE's use of the term “suite” to refer to a single application. Hopefully, additional proxies will be completed soon, and if they're as useful as ftp-proxy, I, for one, will forgive them for this minor conceit.

The quickest way to explain this file is to list a brief example and dissect it (see Listing 1).

Listing 1. ftp-proxy.conf

The first parameter, ServerType, determines whether to run ftp-proxy as a standalone dæmon or from inetd. Although I've been calling it a dæmon, ftp-proxy can be run either way. I personally avoid running inetd or even xinetd on my public servers, because that way I don't need to disable the unnecessary things that tend to get run by default, and because of the performance benefit of running things as dæmons. If your needs are different, you can set ServerType to inetd (which also works if you run xinetd rather than inetd).

User and Group, obviously enough, determine the UID and GID under which ftp-proxy runs after initialization. It's a good idea to set these to an unprivileged UID and GID in order to lessen the consequences of an attacker somehow hijacking an ftp-proxy process.

LogDestination specifies where ftp-proxy should send log messages. This can be either dæmon (the local syslog facility), a file or a pipe. LogLevel determines the quantity of information to be logged; for most users the default of INF is best, but DBG (the maximum setting) is useful for troubleshooting.

PidFile tells ftp-proxy where to store the process ID of its master process. This is used by the startup script when it's invoked with the stop command and upon system halt. It isn't used, however, if ftp-proxy is run in inetd mode.

ServerRoot specifies the path to ftp-proxy's chroot jail. Leave it commented out if you don't want to run ftp-proxy chrooted (see the “Problem with 1.9 and chroot” Sidebar).

Problems with 1.9 and chroot

Transparent Proxying

The next three commands in Listing 1 are important. They determine whether your proxy will be transparent. In most situations, a transparent proxy is preferable. End users won't need to configure their FTP client software to explicitly support the proxy. To achieve this, ftp-proxy works in conjunction with the kernel's Netfilter code, which redirects FTP packets to your proxy dæmon rather then sending them to the host to which they're actually addressed.

When ftp-proxy receives FTP client packets that have been redirected in this way, it uses their destination IP as the destination of the new FTP connection it initiates to the desired FTP server. The parameter DestinationAddress specifies the default destination to use.

If you want to allow users to use the proxy non-transparently, i.e., by initiating their FTP sessions directly to the proxy, set the parameter AllowMagicUser to “yes”, but I do not recommend doing so if your proxy is to be used by external users, as in the case of a public FTP. AllowMagicUser will cause your proxy to act as an open proxy that external users may use to connect to other, external FTP servers, possibly for the purpose of attacking them.

If you've configured Netfilter to accept connections to the proxy from trusted (internal) users only, however, and you set AllowMagicUser to “yes”, users will be able to specify their FTP destination by attaching it to their user name with an @ sign, e.g., mick@ftp.wiremonkeys.org. AllowMagicUser may be used regardless of whether AllowTransProxy is set to yes or no. But note that if it's set to no and AllowMagicUser is too, all FTP sessions will use DestinationAddress.

Other parameters include MaxClientsString and DestinationTransferMode. See the ftp-proxy.conf(8) man page for the complete list and for more information on the ones we've covered here.

Configuring Netfilter for Transparent Proxying

For transparent proxying to work you need to use iptables to redirect FTP packets to the local proxy (i.e., you need to run Netfilter on your proxy host, which this article assumes you're doing), and of course, you'll need rules allowing FTP connections to and from the proxy. You will not, however, need any rules in the FORWARD chain.

First, you'll need to load several modules for your Linux 2.4 firewall to support transparent proxying: ipt_conntrack_ftp and ip_nat_ftp are required for FTP connection tracking; ipt_REDIRECT is required for the REDIRECT rule target. Most distributions' stock 2.4 kernels include these modules.

Once the modules are loaded, you can add firewall rules like these to your Netfilter startup script (Listing 2).

Listing 2. iptables: Commands for Transparent FTP Proxying

The first two commands of Listing 2, instruct the firewall to redirect all packets received on its external and internal interfaces (eth2 and eth0, respectively) that have a destination port of TCP 21 (the FTP server port). Note that these packets won't be rewritten (mangled) in any way; they'll simply be redirected to the local FTP proxy dæmon.

The third and fourth commands in Listing 2 tell the firewall to accept all incoming packets sent to TCP port 21 of the public FTP server (where the variable PUBLIC_FTP contains its IP address) and all incoming FTP packets sent by internal users (where the variable INTERNAL_HOSTS contains an IP range in CIDR notation, e.g., 192.168.99.0/24). Per the first two lines, any packets matching lines three and four will be diverted to the local proxy.

The fifth and sixth lines in Listing 2 allow the local ftp-proxy dæmon to initiate proxied FTP connections to the specified public FTP server and to external FTP servers (i.e., hosts reachable from its external Ethernet interface, in this example, eth2).

The lines in Listing 2 do not form a self-contained Netfilter rulebase. They represent the lines you could add to an existing script already properly configured for NAT, etc., and already containing definitions for the variables PUBLIC_FTP and INTERNAL_HOSTS. It's good practice to use custom variables like this to make your rules more readable.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Commercial support for SuSE proxy-suite FTP proxy

Hafeez's picture

This is a great tutorial..I followed these steps and was able to configure this on our SuSe servers and its working great. However, wanted to confirm if there a commercial support for this product from SuSE or any other vendor? we need to convince our management that this is supported. Or is there any other FTP proxy solution out there which is supported..
Any help would be appreciated..

Thanks in advance

Great tutorial

proxy's picture

Thanks, great tutorial

Re: Paranoid Penguin: Configuring and Using an FTP Proxy

Anonymous's picture

Considering the posting date, can you please post the stock quotes of that day.

Thanx a lot,

Frank

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix