This chapter is provided on an “as is” basis as part of the Apress Beta Book Program. Please note that content is liable to
change before publication of the final book, and that neither the author(s) nor Apress will accept liability for any loss or
damage caused by information contained.
Copyright © 2004. For further information email [email protected]
All rights reserved. No part of this work may be reproduced in any form or by any means, electronic or mechanical, including
photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the
copyright owner and the publisher.
Chapter 10
Securing an FTP Server
File Transfer Protocol or FTP is one of the original core protocols of the Internet and was
first documented in 1971. It was designed to provide the functionality to exchanges files over
the Internet and is specified in RFC 959.
1
It is still currently used for a number of purposes,
including running user and anonymously authenticated FTP servers for the provision of files
and applications for download. For example, it is utilized by software vendors to provide
updates or patches to clients. It is also used to transfer of files between disparate systems, for
example many non-Unix systems also support the FTP protocol. One of the most common
uses of FTP is by ISPs to provide customers with the ability to upload files to their web sites.
At first look FTP would seem to fulfill a useful and practical function. Unfortunately
FTP is also inherently insecure. The only security available to most FTP sessions is a
username and password combination. By default FTP transactions are conducted
unencrypted and all traffic is sent in clear-text across your network. This includes the
transmission of user names and passwords. This exposes you to a considerable level of risk
that is difficult to mitigate with available tools.
Due to the inner workings of FTP it is not possible to use tools such as Stunnel to secure
FTP traffic and we'll explain why this is so in the next section. Additionally many of the
available open source and commercial FTP servers have proven to be subject to
vulnerabilities. Many FTP servers are easily compromised and thus can provide a point of
access for an attacker into your system. Or they have vulnerabilities that could allow Denial
of Service (DoS) attacks on your systems. In addition to these other potential insecurities
component of FTP. FTP is a stateful protocol, meaning that connections between client and
server are created and kept open during an FTP session. Commands that are issued to the
FTP server, for example a file upload or a directory listing, are executed consecutively. If a
command arrives while another command is being executed then the new command is
queued and will execute when the current command has completed.
NOTE: FTP is a TCP only protocol. There are no UDP elements to FTP.
When making an FTP connection two types of connections are initiated. A control, also
called a 'command', connection and a data connection. When you connect an FTP client to an
FTP server a single control connection is established by default using the TCP port 21. This
connection is used for the authentication process, for sending commands and receiving
response messages from the remote server. It does not do the actual sending and receiving of
information or files. The sending and receiving of files is handled by the data connection. A
data connection is established only when a file needs to be transferred and is closed at the end
of the transfer.
There are two types of data connection, active mode connections and passive mode
connections. Active connections use the PORT command and are initiated by the remote
server and the client listens for the connection. Passive connections use the PASV command
and the client initiates the connection to the remote server and the server listens for the data
connections. When the client starts a transfer it tells the server what type of connection is
wishes to make. In modern FTP clients and servers the most common connection type is
passive connections.
In active mode the client connects from a random source port in the ephemeral port range
(see Chapter 2) to the FTP control port 21. All commands and response codes are sent on
this control connection. When you actually want to transfer a file the remote FTP server will
initiate a connection from the FTP data port 20 on the server system back to a destination port
in the ephemeral port range on the client. This destination port is negotiated by the port 21
control connection. Often the destination port used is one port number higher than the source
port on the client. You can see an illustration of an active mode connection in Figure 10-1.
Insert 4444ch10f1.tif
Figure 10-1 Active mode FTP connection
securing application needs to know which ports to secure. As this port choice is random, the
securing application has not means of determining what port needs to be secured.
Firewalling your FTP server
There is a method of further locking down your FTP connections. To this we can use iptables
with a module called ip_conntrack_ftp. The ip_conntrack_ftp module uses connection state
tracking to correlate and track FTP transactions. We first introduced connection state
tracking in Chapter 2. Let's look at creating some iptables rules for our FTP server.
We have discussed in the How Does FTP Work? section that in order for the FTP server
to function you will need a combination of the ports 20, 21 and the range of ephemeral ports
open on both the client and server. This combination is partially dependant on the connection
mode we are running on our FTP server. We're going to assume we are creating firewall
rules for an FTP server running on interface eth0 and bound to IP Address, 192.168.0.1. We
will assume we only want FTP connections into the system and we don’t want to allow
outgoing FTP connections.
The first rules we are going to create are for the FTP server's control connection, which
uses TCP port 21. As these rules address the control connection they are identical for active
and passive mode FTP, as the control connection is required for both modes.
puppy# iptables –A INPUT –i eth0 –p tcp --dport 21 –d 192.168.0.1 –m state --state
NEW,ESTABLISHED,RELATED –j ACCEPT
puppy# iptables –A OUTPUT –o eth0 –p tcp --sport 21 –s 192.168.0.1 –m state --state
ESTABLISHED,RELATED –j ACCEPT
In the two rules we've just specified, incoming traffic on interface eth0 to IP Address
192.168.0.1 and TCP port 21 in the connection state of NEW, ESTABLISHED or RELATED
is allowed to enter the host. Outgoing traffic on the same interface, IP Address and port in
the connection states ESTABLISHED and RELATED is allowed to exit the host.
The control connection is not the whole story though. The FTP server also needs the data
connection opened in our firewall for the server to correctly function. As we have discussed
this data connection can run in two modes: active and passive. For example, the active mode
connection requires a substantial port range open. To function correctly the active mode
requires port 20 open on the FTP server and additionally on the server we need to accept
interface eth0 to IP Address 192.168.0.1 and port 20 in the ESTABLISHED and RELATED
states. This prevents new connections being made to this port. The only incoming
connections should be the data connection portions of existing FTP connections. This
increases the level of security on your host firewall. The second rule allows outgoing traffic
in the ESTABLISHED and RELATED states outbound from the host to destination ports
higher than 1024.
Passive mode FTP is very similar. Using the ip_conntrack_ftp module we can track the
state of the connections and the port numbers used and thus can use the RELATED state for
our iptables rules. Example 10.2 shows an INPUT and OUTPUT rule for passive mode
connections.
Example 10.2 Rules for passive mode connections
puppy# iptables -A INPUT -i eth0 -p tcp --sport 1024: --dport 1024: -d 192.168.0.1 -m state --
state ESTABLISHED,RELATED -j ACCEPT
puppy# iptables -A OUTPUT -o eth0 -p tcp --sport 1024: --dport 1024: -s 192.168.0.1 -m state --
state ESTABLISHED -j ACCEPT
The first rule in Example 10.2 allows incoming traffic from the ephemeral ports (which we've
defined as all ports greater than 1024 in our rules) to interface eth0 and IP Address
192.168.0.1. The second rule provides the same functionality for outgoing traffic.
Neither Example 10.1 nor Example 10.2 are ideal solutions. These rules leave your
firewall comparatively quite open compared to the models we proposed in Chapter 2. But
they are the securest possible rules we can create on a host system for an FTP server. This
again highlights that there are risks involved in running an FTP server that simply cannot be
mitigated.
TIP: When we look at vsftpd we'll look at refining the range of ephemeral ports that
the FTP server can use. This can further limit the range of ports you need to open on
your host.
What FTP server to use?
There are a number of FTP servers available, both commercial and open source products.
We're going to look at vsftpd, which is an open source FTP server. The vsftpd package has a
reputation for security and is a compact but also fully featured and well performing
We're going to download the source package to ensure we are using the most up to date
version of the package.
puppy# wget ftp://vsftpd.beasts.org/users/cevans/vsftpd-2.0.1.tar.gz
After downloading the package, unpack the source package and change into the resulting
directory. Vsftpd doesn't use a configure script but rather has a file called builddefs.h which
contains the compilation variables. Example 10.3 shows the contents of this file.
Example 10.3 Initial builddefs.h
#ifndef VSF_BUILDDEFS_H
#define VSF_BUILDDEFS_H
#undef VSF_BUILD_TCPWRAPPERS
#define VSF_BUILD_PAM
#undef VSF_BUILD_SSL
#endif /* VSF_BUILDDEFS_H */
You can enable SSL, PAM and TCP Wrappers in this file. To enable features in vsftpd you
need to change each definition line for the feature you wish to enable from,
#undef VSF_BUILD_SSL
to,
#define VSF_BUILD_SSL
We are going to enable SSL and PAM in vsftpd. Example 10.4 shows our final builddefs.h
file.
Example 10.4 Final builddefs.h
#ifndef VSF_BUILDDEFS_H
#define VSF_BUILDDEFS_H
#undef VSF_BUILD_TCPWRAPPERS
#define VSF_BUILD_PAM
#define VSF_BUILD_SSL
#endif /* VSF_BUILDDEFS_H */
Now you can make the vsftpd binary.
puppy$ make
This will create a binary called vsftpd in the package directory. You can then install vsftpd
command-line option, which allows you to specify the location of the vsftpd.conf
configuration file.