Setting up an FTP Server

For this demonstration, we are using Proftpd instead of the widely known and used WU-Ftpd daemon. The main reason for this is security. We will go through the follwing steps that will show you how to set up your own ftp server.

• Download
• Installation
• Configuring Linux for Proftpd
• Configuring Proftpd

• Complete list of directives that can be used to configure Proftpd
  
• The official Proftpd User's Guide
  
• Joey's Proftpd Setup Guide
  

The best place to get Proftpd is at the official Proftpd website located at www.proftpd.org. You can find a link to download the software right on the main page of their website. At the time of this writting the most current version of the software is v1.2.4.

First, you need to extract the files for Proftpd from the archive you downloaded.

tar -zxvf proftpd-1.2.4.tar.gz

Next, you need to change into the directory created during the unextraction

Compilation:

Now you will have to compile the sorce and install the executables by typing the following three commands. The make process can be long depending on how fast your system is. It took my Pentium-II 400Mhz machine about 3 or 4 minutes to complete this step.

./configure
make
make install

Ok, so you want to run an ftp server. Well, in most cases, anyone wanting to run any type of server will want the server to be accessible at all times. Well, there are two ways to do this with Proftpd. You can use the inetd daemon to spawn instances of the Proftpd server as they are needed, or you can just start Proftpd everytime the computer boots Linux. We are going to choose to just start the Proftpd daemon everytime Linux boots. Proftpd will be running in what is known as a "Standalone" server mode. Here are the steps to enable this.

NOTE: In the following cp command, make sure that you replace /install/ with whatever directory you extracted the downloaded file to.

cp /install/proftpd-1.2.4/contrib/dist/rpm/proftpd.init.d /etc/init.d/proftpd
cd /etc/init.d
chmod 0755 proftpd

Another thing you will want to be sure and do is make sure that Linux will allow incomming ftp connections. You can do this by running lokkit.

lokkit

In lokkit, select Customize, make sure that you set eth0 as a trusted device, and also make sure that FTP is checked along with whatever else you want to use. If you are not sure, then select SSH, DHCP, and FTP.

PAM is a nifty setup that allows people to log in to your ftp server using their accounts that they have on the machine. If you wish to set this service up, follow these steps.

cd /etc/pam.d touch ftp

Now you need to edit /etc/pam.d/ftp with your favorite text editor and make in contain the following lines:

auth required /lib/security/pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed
auth required /lib/security/pam_pwdb.so shadow nullok
account required /lib/security/pam_pwdb.so
session required /lib/security/pam_pwdb.so

Make sure you have a user called ftp, and a group call ftp. You will need them if you are following our example installation. Redhat Linux has these users already created by default but you will have to change the home directory of the user ftp. To do this, sinply edit your /etc/passwd file and change the home directory listing for user ftp from /var/ftp to /home/ftp. Then don't forget to create the /home/ftp directory.

mkdir /home/ftp

Upon installation, the config file can be found here: /usr/local/etc/proftpd.conf. This file holds the master configuration for your ftp server. This is where you specify access types and read/write permissions, and lots of other neat things. In this section, you'll walk you through a sample config file step by step and explain how we are setting the server up.

ServerName                      "Jason and Steve's FTP Server" 
ServerType                      standalone 
Port                            21

ServerName - Sets the name of the server. This is what will be displayed to the connecting users.

ServerType - Sets the server to standalone because that is the type of server we are running. If you do not understand this, please refer back to the "Server Type" section of this document. The alternative to "standalone" is "inetd".

Port - Determines which port on which to accept ftp connections. This is best left at it's default of 21 unless you have a good reason to change it.

AuthPAM                         on
Umask                           022

MaxInstances                    30

User                            ftp
Group                           ftp

DefaultRoot ~

AuthPAM - Used to set whetheror not users with accounts on the host machine can ftp in to their home directories. This is on by default so if you want to disable this type of access, you must specifically do so.

Umask - This sets the default permissions of any file uploaded through the ftp server. More info can be found in the online User's Guide.

MaxInstances - The maximum number of simultaneous connections you want to allow.

User/Group - These two lines set which user and group you want to run the server as.

DefaultRoot - Note this for security reasons. This line tells the server to force any user who has logged in to see their home directory as the root directory. This will stop people from having access to the entire file system.

<Directory /*>
    AllowOverwrite                on 
</Directory>

<Limit LOGIN>
    Order allow,deny
    Allow from .clarkson.edu
    Deny from all
</Limit>

<Limit WRITE>
    Allow from all

</Limit>

The Directory directive specifies that the options within it are to be applied to the aforementioned directory. In this case, we are looking at /* which encompasses the entire file system. Inside this directive, we have AllowOverwrite set to "on". This will allow all uses the overwrite files in all directories that they have WRITE permission.

Order allow,deny states the precedence of the allow and deny directives. We have set up this example server to only allow connections from someone comming from the domain .clarkson.edu. We then Deny access to everyone. You may be wondering how people at Clarkson can access this server if we have denied access to all. Well, because allow is of higher precedence than deny, when someone tried to connect from clarkson they are allowed because they fit the "Allow from .clarkson.edu" rule. However, when someone comes from .aol.com they will not fit the Allow rule, and will then be checked against the deny rule and since it is set to "Deny from all" the AOL user will be denied.

This directive, as we've set it up, allows all users of ther server to write. This is known as a global directive because it is not found inside another directive such as a user directive or a directory directive. This means that it applies to ALL users who do not have their own Limit WRITE directive. If you do not set this globaly, your users will not be able to do anything but read files on your server.

<Anonymous /home/ftp>
  User                          ftp
  Group                         ftp
  UserAlias                     anonymous ftp
  MaxClients                    10
  RequireValidShell             no
  AccessGrantMsg                "Welcome to my FTP Server!"

  <Limit WRITE>
    Deny from all
  </Limit>

</Anonymous>

This directive sets up an anonymous login and sets the default directory for anonymous login to be /home/ftp/. The User/Group directives here just specify who you want an anonymous user to log in as. root is OBVIOUSLY a horrible choice for this one!! UserAlias just says "Treat the user called ftp as if he were the user anonymous". MaxClients states that only 10 anonymous users are allowed to connect at a time. RequireValidShell is off. This is so that anonymous users will not need a login name and password to connect. AccessGrantMsg just shows the anonymous users a message after they have logged in. You can also point this to a file by simply using a filename with (no quotes) instead of a message.

The Limit directive here prevents ANY anonymous user from writting to anything. This ensures that they cannot mess anything up.

Starting and stopping the server

RedHat 7 provides a program, chkconfig, that is used to configure start up daemons. The easiest way to have ProFTPD start is to do the following:

chkconfig --level 345 protftpd on

This will turn ProFTPD on in run-levels 3, 4 and 5. Similarly, you can disable the service:

chkconfig --level 345 proftpd off

Basically, all you have to do is add a link to /etc/init.d/proftpd in the run-level. This is because RedHat 7 uses System V init scripts which reside in /etc/rc?.d (and /etc/init.d). In order for the FTP server to start when the system boots, you must place a symlink (or hardlink) in one of the run-levels such as rc3.d .

Starting the server: ln -sf /etc/init.d/proftpd /etc/rc3.d/S99proftpd

Stopping the server: ln -sf /etc/init.d/proftpd /etc/rc2.d/K01proftpd

Notice the capital S and K. S means Start and K means Kill while the numbers reperesent the order. Services that are in the 01 class start before those in the 99 class and the same is true for stopping services

Performance, Security and Configurability

ProFTPD was designed to be a highly configurable, secure FTP server that compares to the newer Windows based servers. The most common alternative, wu-ftpd, did not have the configuration features or security history necessary for most FTP servers.

Security: /etc/ftpusers

Controlling who logs in to the FTP server is very easy with ProFTPD. The file /etc/ftpusers contains a list of accounts that are NOT allowed to log in to the machine through the FTP daemon. There are a few reasons for this, first the user may have too many priviledges to FTP in. FTP servers have a bad track record when it comes to security. If root was allowed to log in to a poorly written server the machine could be easily compromised. Second, you can ban problem users or inherently insecure users (such as anonymous) in a policy decision. Here is an example /etc/ftpusers:

#
# ftpusers      This file describes the names of the users that may
#               _*NOT*_ log into the system via the FTP server.
#               This usually includes "root", "uucp", "news" and the
#               like, because those users have too much power to be
#               allowed to do "just" FTP...
#
#
# Version:      @(#)/etc/ftpusers       3.00    02/25/2001 volkerdi
#
# Original Author:  Fred N. van Kempen, 
#
# The entire line gets matched, so no comments or extra characters on
# lines containing a username.
#
# To enable anonymous FTP, remove the "ftp" user:
ftp
root
uucp
news

# End of ftpusers.

Security: The DefaultRoot directive

Another method that will increase the security of your FTP server is to seperate users in to groups based on how much trust they have. The users with the least amount of trust have the least amount of access to the filesystem. This prevents them from downloading system files and analyzing them for exploits. To do this you use the DefaultRoot configuration directive:

DefaultRoot ~ users,!geeks

This limits all users who belong to the users group to their home directory. If someone was in geeks or another group they could FTP any file off of the system in which they had read permissions to. Limiting the users to their home directory is also a great way to provide FTP access for the webmaster. Create a webmaster account on the machine and have the home directory be the web tree. Then, make their DefaultRoot the web tree.

Security: .ftpaccess

Just like in Apache, ProFTPD provides per-directory access controls in files called .ftpaccess. These files behave in the same manner as their Apache counterparts but use ProFTPD's configuration directives.

Summary:

• Configurability - Apache like configuration file, .ftpaccess, .ftpuser
• Security - The authors of ProFTPD used to patch bugs in wu-ftpd
• Performance - A lot of high traffic sites use ProFTPD (ftp.kernel.org, SourceForge)

Alternatives

• wu-ftpd - The standard, insecure and often broken FTP server
• sftpd - A new service to OpenSSH

Examples of recent exploits

There have been many FTP vulnerabilities in the past that have caused serious harm to servers. wu-ftpd is by far the worst FTP server to run when it comes to security. Recently, there was an exploit that allowed the intruder to gain root priviledges by taking advantage of a bug in anonymous FTP. I worked on the following machines that had seen the exploit at one point:

• heron and tinman
• pixies

Example person trying to anonymous FTP to my machine: