Upgrading to ProFTPD



Last updated on February 1st 2002


Contents

Introduction
Features
Getting and Installing ProFTPD
Testing the Install
Configuration and Use
Authentication
Bandwidth Throttling
Useful Utilities
Important Links

Introduction

What is ProFTPD?

ProFTPD is an FTP server, like the stock Solaris FTP server - but the similarities stop right about there. The stock Solaris FTP server is based on the relatively ubiquitous wu-ftpd software found on many Unix-based operating systems these days, whereas ProFTPD is a replacement for wu-ftpd, and in my opinion, it's also an "upgrade." You gain features, security and flexibility.

ProFTPD is Open Source and released under the GPL license and as such, the source code is freely available to you.

Why would you want to use it, when Solaris already has a working FTP server?

Well, the answers are many but perhaps primarily is the feature set of ProFTPD which outclasses wu-ftpd and is very easily configurable - if you've used Apache, then you're already familiar with the syntax.

Another big reason and one that should be of the utmost importance to you is security. Wu-ftpd has had a long history to be sure, but dotted with various exploits that could seriously compromise your system. ProFTPD takes a much more secure approach over wu-ftpd by allowing you, for example, to run the daemon as a non-root user which has little rights as opposed to root - limiting what a potential cracker can do with the system. Other features with security in mind include changing access characteristics based on user or group information, hiding or changing publically visible server messages (including software used and version number). Security through obscurity is never a good policy in it's own right - but not giving potential crackers more information than they need isn't a bad idea, either.

Just be careful, because NOT giving out information may be just as bad as telling the world what you ARE using - because not all software lets you hide this information. Through deduction, crackers can narrow down the potential candidates. Yes, crackers think this way - and so should you!

Flexibility is also a strong point for ProFTPD. Based on user or group for example, you could have one way of dealing with regular users, while having another way of dealing with staff - or anonymous users. For example, anonymous and even regular users should have rather restrictive rights and are best "sandboxed" into their home directory or an anonymous FTP area. They should only be given the absolute least necessary access to the system, yet not impede access to their own files. Staff on the other hand, especially system administrators - often need access to entirely different and broad-ranging areas of the system. Of course, you could and probably should use secure shell's (ssh) "scp" command for stuff of this nature, but that's something for another time.

From the ProFTPD Website, the folks behind it like to describe ProFTPD thusly:

"ProFTPD grew out of the desire to have a secure and configurable FTP server, and out of a significant admiration of the Apache web server. There are currently a very limited number of FTP servers running on Unix (or Unix-like) hosts. The most commonly used server is wu-ftpd. While wu-ftpd provides excellent performance and is generally a good product, it lacks numerous features found in newer Win32 FTP servers and has a poor security history. Many people, including the developers who work on ProFTPD, have spent a great deal of time fixing bugs and hacking features into wu-ftpd. Unfortunately, it quickly became clear that a complete redesign was necessary in order to implement the configurability and features desired. ProFTPD is not a hack based on any other server, it's an independent source tree from the ground up. A number of well known and high traffic sites use ProFTPD.

In addition to wu-ftpd, there are a few of other FTP servers available which are designed to be light-weight and secure at the expense of configurability. For example, Troll FTP is an excellent FTP daemon which is considerably more secure and less resource-intensive than wu-ftpd. Unfortunately, while it is quite suitable for basic FTP services, it does not offer the feature set required for more sophisticated FTP sites."

ProFTPD runs on a good variety of platforms, and as such you can easily have the same FTP server on all your boxen so that you don't need to support multiple, different implementations and software. Some of the platforms currently supported include the following, but aren't necessarily limited to same:

AIX BSD/OS Cygwin
DG/UX Digital Unix FreeBSD
HP/UX IRIX Linux
MacOS X NetBSD OpenBSD
SCO Solaris SunOS

Features

The features that ProFTPD offers is just one of the reasons to use it. It's simplicity in configuration, yet at the same time the flexibility allowed make it a great choice. Below are some of the major features that ProFTPD offers:

Getting and Installing ProFTPD

Getting ProFTPD is much like most Unix software, and is available both as a source code tarball, or as a binary package. It should be noted that as with any critical system software, you should be running the very latest, stable production release codebase. As such, often times pre-compiled binary packages may not offer you that - and it's simply not a luxury you should afford.

If you are in a hurry, or want to take the fast approach to getting ProFTPD installed on your system, you can get a binary package from places such as Freeware for Sun Solaris (sunfreeware.com). As mentioned above, and at the time of this writing, the current release of ProFTPD is v1.2.4 and the version available via the above link is for v1.2.1 of ProFTPD. Know this going in...

The case may also be that you don't have any compilers set up and installed on your servers with which to compile the source code. I usually have an older workstation around with the same exact environment as the servers handy for just this reason. In this case, your only solution will be one of the aforementioned binary packages. What's nice about the Freeware for Solaris binary package is just that - it's a Solaris package - and can be installed using the "pkgadd" command. This is admittedly a great feature which allows for simply install, removal or upgrade. Other binary packages may come in the form of pre-compiled source code but in the same format as a normal source code package - you just have to run the "make install" command, for example and not have to compile it first. In any event, it depends on the exact binary package you end up with, and you should follow the instructions that should be included with it.

In any case, you can skip past the following text to the next section unless you want to read about installing from source code - which is the preferred method that I would advise.

If all your ducks are in a row and you're ready to proceed with a source code install, start with obtaining the latest source code tarball. You can do this several ways, and the easiest way is to probably just hit the ProFTPD Website and download from one of the links on the left hand side. There are two versions listed and one of which is the stable, released production code (the one you should get) and another, pre-release or beta version containing new, untested features or bug fixes that may make the software unstable.

A utility I like to install on all my systems is wget or curl. These little utilities allow you to retrieve/mirror Web pages and links. This way, you could for example copy the link location from your browser on the above mentioned Website and simply go to the command line of your server/workstation and issue commands such as: 

wget ftp://ftp.proftpd.org/distrib/source/proftpd-1.2.4.tar.gz

curl -O ftp://ftp.proftpd.org/distrib/source/proftpd-1.2.4.tar.gz

...and just have the source code tarball downloaded to your current directory from which you can uncompress and compile. Another option is to just use whatever FTP client you like to use, and hit the ProFTPD ftp site (ftp.proftpd.org).

No matter how you get it, you'll be left with the source code tarball named something like "proftpd-1.2.4.tar.gz" that you'll want to expand using a command similar to this, if you're using GNU's version of "tar." 

tar -xzf proftpd-1.2.4.tar.gz

If you're not using GNU's "tar" and instead using the stock Sun tools, you will have to "un-gzip" outside of the "tar" command. One way of doing it is like this: 

gzip -d proftpd-1.2.4.tar.gz
tar -xf proftpd-1.2.4.tar

Once you've uncompressed the source code, you'll be left with a directory called something like "proftpd-1.2.4" depending on the version you've downloaded. Change into that directory and run the following "configure" command: 

./configure --help

This will give you a list of available compile-time options and chances are, you'll want to specify at least one or two, if not more of them. The two we're mainly concerned with are the "--prefix" and "--enable-shadow" flags. The former allows you to tell "make" where to install ProFTPD and for this I prefer the /usr/local filesystem. Whether you want to integrate ProFTPD into that filesystem or keep it in it's own separate directory is up to you and how you specify the path with this option. The second option enables the use of "shadow passwords" which is not only a Good Thing (TM) it's also what we want for Solaris.

Therefore, the command you want to issue would be similar to the following: 

./configure --prefix=/usr/local --enable-shadow

You'll see a lot of stuff scroll by as "configure" does it's magic, hopefully without any errors. Once this is done, simply run "make" at the command line to compile the source code. If you have GNU's "make" installed and have multiple CPUs, use "make -j3" (for two CPUs) for faster compiles at the expense of more CPU and memory utilization. Again, this should hopefully complete without any incident.

Once the source code is built, simply run "make install" at the command line to perform the final installation of ProFTPD. With the prefix specified as above, you can find the bits of ProFTPD installed under the /usr/local filesystem, with "proftpd" itself found in /usr/local/sbin/proftpd and the configuration file is found in /usr/local/etc/proftpd.conf for example. The latter file is what we'll focus on in the next section.

Configuration and Use

Configuring ProFTPD is one of its nicest features and very intuitive to those that have used the Apache Web server. There is only one configuration file and its syntax is very similar to Apache's "httpd.conf" file. This was one of the design specifications of ProFTPD authors as outlined above.

While we won't cover all the options available here, the most common and interesting ones will be to point out some of the unique features of ProFTPD. On the ProFTPD Website there are several pages that may be of interest and certainly worthy of reading to get the full scope of what is possible. They will be listed below under "Important Links."

One distinction I like to make on my systems is between normal users and staff. The two usually have completely different needs and nearly always have different security models. You don't want to have your users, especially if they are not employees of your company - such as customers - roaming your server's filesystems. These types of users may simply want to access their own files and not remember long or odd pathnames as opposed to in-house staff like system administrators or Webmasters which often hop around to various areas on the system and need access to wider-ranging areas.

With this distinction between your users, which isn't limited to just the scenario above with two classes of users - you can apply custom environments, features and restrictions to each. Forcing a user to their home directory, or any other for that matter is very simple to configure and also very flexible in how you can control it. This is known commonly as "chrooting" or "to chroot." With one statement in the ProFTPD configuration file you can say, "all my users are to be chrooted to their home directories while staff start off there, but have access to the entire server as per their user rights." This can be expressed with a line similar to: 

DefaultRoot                     ~ users, !staff

Performing this under wu-ftpd was often difficult, a kludge or ill-documented. In any case, much more difficult than it should be!

Let's dissect a common portion of the configuration file, which shows some of the nice things about it. The following is the main section of the configuration file and controls the most basic functions: 

ServerIdent                     On "FTP Server"
ServerName                      ""
ServerType                      inetd
ServerAdmin                     root@domain.com
Bind                            192.168.0.1
ExtendedLog                     /var/adm/proftpd read,write,auth
ScoreboardPath                  /usr/local/var/proftpd
RequireValidShell               Off
User                            proftpd
Group                           nobody

From the example above, we can see that you can change things like the identity that the server presents to the users, if any - with the ServerIdent directive. In this case, it's been enabled and changed to simply say "FTP Server" rather than the default of "ProFTPD 1.2.4 Server" (also "on") which not only gives away the FTP server you're using but also the version. With the ServerName directive, you can change the common name presented such as "Company XYZ's FTP Customer Server." You can have users receive a message prior to login, after login and customize both.

The ServerType directive tells ProFTPD whether it's run in "standalone" mode or fired off via "inetd." If you plan on running a busy FTP server, you'll definitely want to use stand-alone mode as this incurs much, much less system overhead than being launched and subsequently destroyed for each user's connection. In stand-alone mode, ProFTPD stays running constantly, ready to answer requests immediately. This depends on your FTP needs and should be adjusted accordlingly. If you use ProFTPD with inetd/xinetd, then you should also modify the current line in the "/etc/inetd.conf" file (commented out below) to read: 

ftp   stream  tcp  nowait  root  /usr/local/sbin/in.proftpd  in.proftpd
#ftp  stream  tcp  nowait  root  /usr/sbin/in.ftpd           in.ftpd

If you chose to run ProFTPD in this fashion and have made the above change to your inetd.conf file, then you'll need to restart your inetd daemon so that your changes are put into effect. This is done simply by running the following commands, waiting a second or two in between them: 

/etc/init.d/inetsvc stop
/etc/init.d/inetsvc start

Otherwise, if you wish to run ProFTPD in stand-alone mode, you should comment out the line in your inetd.conf file for FTP services (as the stock line above is) so that you don't end up launching the stock Solaris FTP daemon instead of ProFTPD. To start ProFTPD, simply run the following command from the command-line, and consider putting it in your system start-up scripts: 

/usr/local/sbin/proftpd &

The ServerAdmin directive lets you specify an Email address that should receive any Emails from your users about the FTP server in case they forget their password, are having problems, etc. and is similar to the concept behind "webmaster@domain.com."

The Bind directive lets you attach ProFTPD to specific IP interfaces on your sever. If for example, you have a public, front-end interface that should never be able to FTP vs. having a private, back-end interface for staff use. Simply tell ProFTPD which interface(s) to listen to in addition to the default interface. Note that there is currently a bug report filed about this as you can't change the default interface behavior - only that of additional interfaces. Normally, this shouldn't be an issue but you should be aware of it.

The ExtendedLog and ScoreboardPath directives let you configure ProFTPD's extensive logging capabilities and where the statistics file (again, much like Apache's) is kept. In this case, we are logging "read,write,auth" which means "all reads and writes and authentication attempts (successful or not)."

RequireValidShell is a very useful option. In many cases, you wish to have users that might have FTP access, but not necessarily shell access, or being able to log into the system. With this set to "off" you could do just that, and ProFTPD won't balk at a user shell of "/bin/false" for example. If this were set to "on" in this case, then the users wouldn't be able to FTP, either - making for a simple method of granting/revoking this type of access en masse.

The last directives above, User and Group allow you to set the user/group that the ProFTPD daemon runs as, and is an important security feature! In this example, we've set it to run as the "proftpd" user and of the group "nobody" - which is an unprivilged system user and group. Apache uses "nobody" as well. You could use "nobody" as the user, but I prefer to create unique users for each of these types of services for additional, finer-grained control. Also, if you do a "ps" listing for example, you can clearly see these services by the users they run as, and can sort these listings accordingly and simply. Remember that if you use "proftpd" as the user that a user by that name actually exists. Use a shell of "/bin/false" and do not enable a password on that account for further "no login, ever" protection.

Not shown above is a nice way to limit anonymous logins to a certain number of users, with or without a related message - or you can disable anonymous logins altogether - with one of the following lines. As it is, anonymous logins are denied with a message: 

#MaxClients                  1 "Maximum users reached - try again later"
#MaxClients                  1 "Sorry, max %m users -- try again later"
MaxClients                   None "Go away, luser."

There's actually a bit more to the configuration file, especially relating to user and anonymous access (as above) but we won't get into such depth here. Again, peruse the links listed below for all the available options and directives as well as several example configuration files which are commented heavily.

It really is this easy to set up and configure and it's in plain English. Imagine that!

Testing the Install

Once you've installed ProFTPD as above, the easiest way to test it is to simply FTP to your server! Depending on how you set things up as far as users, authentication and other options you should try each situation and make sure that it works as expected. Also try to "break" your installation by trying unexpected things just to make sure everything is good to go before going live with the service. It's better to find out now and in privacy if something isn't right than later on when someone might use this knowledge for dubious reasons.

If you think you have anonymous FTP turned off, make sure it is. If it's still running than all the script kiddies out there will turn your server into a warez site in short order.

At the command line, you can simply try the following and see what happens: 

ftp localhost

This most basic test will tell you right away, right at the command line - if ProFTPD is launching properly under inetd/xinetd or stand-alone mode. You can also try various user accounts to perform the tests mentioned above. Either this way, or through the use of a GUI client, will allow you to perform these tests. You may even want to try various clients on differing platforms if you really want to vigorously test your installation to make sure that it is bulletproof. Remember, security shouldn't be an afterthought!

Authentication

In our case, authentication is done using the normal Solaris files /etc/passwd, /etc/shadow and /etc/group - shadow password support was enabled with the "configure" option above. This can be extended to include a number of additional methods that are in common use today such as PAM, LDAP or a database back-end utilizing a SQL server or DB files. For large scale installations, this may be the best way to proceed, and gives you the hooks to have a centralized management scheme where other user aspects are also stored.

Of course, anonymous FTP is also fully supported and configurable with ProFTPD. For public access to things like documentation or software drivers for your customers, this is important. However, if you don't need this kind of service, you should definitely disable it - or at the very least turn off anonymous write access!

Lastly, the Unix-level access controls also apply to ProFTPD. If a user coming in under FTP doesn't have permissions suitable to what they wish to do (overwrite, create or delete a file for example) then ProFTPD won't allow it, either.

ProFTPD can be further extended by custom and contributed modules, further extending it's customizability. All these options are another good reason to choose ProFTPD because they allow it to scale well.

Bandwidth Throttling

ProFTPD also offers another great feature which lets it scale well, and that is "bandwidth throttling" or being able to limit your users to specific data rates so that they don't consume all your available bandwidth or impact other users on a busy server.

During the ProFTPD v1.2.x series, this has changed quite a bit and even further refinement is scheduled for the v1.3.x series. For the latest information, you should check out the ProFTPD Website and related documentation. However, to give you an idea of what is possible, consider the following configuration file snippet: 

RateReadBPS                  81920
RateReadFreeBytes            5120
RateReadHardBPS              on

This would limit your user's bandwidth using a formula of "RateReadBPS x MaxClients = Total Bandwidth allocation." There is no way at the moment to specify a virtual server to have a maximum total bandwidth of that is shared between all connections to it. Per-virtual, per-user and global limits are still not finalized and for now, in the v1.2.x series, there is only one global control that can be utilized and affects the whole server: 

Bandwidth                    81920

Nevertheless, this is a nice control to have available so that you can protect yourself from bandwidth consumption and forms of DoS attacks. In the coming versions of ProFTPD, expect this capability to be refined more.

In a similar vein, you can apply quotas to users using the "mod_quota" and "mod_ratio" modules with ProFTPD. These are two additional methods of controlling system resources such as bandwidth and storage space. It should be noted that "mod_ratio" only maintains per-session statistics and not on an on-going basis.

Useful Utilities

ProFTPD also comes with a few other programs, or utilities - that are useful in day-to-day maintenance of your FTP server. They are "ftpwho" and "ftpcount" and are located under /usr/local/bin/ in our example installation.

The "ftpwho" command shows process information for all active proftpd connections, and a count of all connected users off of each server. Proftpd sesssions spawned from inetd are counted separately from those created by a master proftpd stand-alone server.

The "ftpcount" command shows the current number of connections per server and virtualhost/anonymous configuration defined in the proftpd.conf file. Connections spawned by inetd are counted separately from those created by a master proftpd stand-alone server here as well.

Important Links
ProFTPD Website
ProFTPD Documentation Index
ProFTPD FAQ
ProFTPD Userguide
Example Configuration Files
Download and Mirror Sites
Sunfreeware.com pre-compiled binary packages
Search for ProFTPD related software on freshmeat.net

Content and images are copyright 2001 by Michael Holve