Logging in WU-FTPD

Last updated: Dec 10, 1997


Table of Contents



WU-FTPD has many ways in which you can get information about what your FTP server is doing. Transfer logging, command logging, connection logging, wtmp-style logging and server debugging information are available.

The level of logging you need is highly site dependent. You might want to temporarily turn on everything when you set wu-ftpd up for the first time or during an upgrade.

Transfer logging is just that. It is the logging of transfers to and from your system. Transfer log records are recorded in the xferlog file.

Command logging allows you to log all FTP commands entered on your system. This gives you a pretty complete picture of what people are actually doing while logged in to your FTP server.

Syslog logging is where command logs are sent but it also used to log other types of logs. Some are informational only and some are error conditions that need to be addressed. This is the type of logging that many people overlook when setting up wu-ftpd.

Wtmp logging puts records into your system's utmp/wtmp accounting file. Session duration information can obtained from these files using system accounting commands and other commands such as 'last'.


Configuring logging into the wu-ftpd software

In order to take advantage of logging you need to edit a couple files and make sure that the software is compiled to log things as you want it to.


First edit the config.h file in the top level wu-ftpd source directory and make sure that the LOG_FAILED and LOG_TOOMANY defines are set as you want them.

The LOG_FAILED determines if you want to log failed attempts to login to your wu-ftpd server. This is good for showing "door knockers" but if you have a very busy site that is simply a public ftp server you might want to undef this.

#define LOG_FAILED

The LOG_TOOMANY define enables or disables logs generated by login attempts that fail because of class connection limits. This is useful if you are not sure if your class limits make sense. Quite often the initial limits are decided on in an arbitrary fashion. You can use this to see if the limits are set to low.

Busy servers may want to prevent this logging since it can fill up the log file and put a high load on syslog.


Second, you need to specify where you want transfer logs to be recorded. To do this, edit the src/pathnames.h and make sure the

#define _PATH_XFERLOG "/somewhere/xferlog"

points at the right place. After you have done a build you can verify that the xferlog appears in the proper place with the bin/ckconfig command.

Note: You will notice a define for lastlog in the pathnames.h file.

#define _PATH_LASTLOG "/usr/adm/lastlog"

While this appears in pathnames.h it is not used at present anywhere in Beta-15 sources. Ignore it.


ftpaccess file

OK, you've configured, built and installed your wu-ftpd software. Now before you turn it on you need to setup the appropriate logging directives in the ftpaccess file. If you are using Beta-15 virtual hosting capabilities of WU-FTPD you will need to specify where to log transfers.

If you are using Kent Landfield's newvirt virtual hosting capabilities, refer to http://www.landfield.com/wu-ftpd/newvirt for more specific information.


Setting up syslog.conf

In order to get more information from your WU-FTPD server you will need to setup the proper syslog entries. For other than transfer logging, WU-FTPD uses the syslogd system logger to log different types of events. If you want to log commands you must setup WU-FTPD related syslog entries. If you do not configure a certain type of message to be logged via syslog, that level of message is dropped on the floor and not recorded anywhere.

What follows is a sample of what you might use to setup syslog.conf to support logging of WU-FTPD.

  # FTP and other Daemon Servers
  daemon.debug                               /var/log/ftpd.log
  daemon.info                                /var/log/ftpd.log
  daemon.err                                 /var/log/ftpd.log
  daemon.notice                              /var/log/ftpd.log
  daemon.warning                             /var/log/ftpd.log
  daemon.err                                 /dev/console

The logfiles list in the column on the right should be something that makes sense for your site.

NOTE: You will need to make sure that the two columns are separated by at least one TAB character or most syslogd software will silently ignore the listed entries.

NOTE: Some syslogs require the file exist before it will be written to. You may have to create and empty file first for each entry specified in the syslog.conf entries.

SUGGESTION: See the syslogd and syslog documentation on your specific system.


Setting up inetd.conf

In order to properly turn on logging you will need to setup the inetd.conf file with the appropriate options on the wu-ftpd server comand line. Some of the options can only be specified on the command line while others can be specified on the command line and then overridden in the ftpaccess file.

Command Line Only:

If the -d or -v option is specified, debugging information is written to syslog.

If the -l option is specified, each ftp session is logged via syslog.

If the -a option is specified, the use of the ftpaccess(5) configuration file is enabled.

If the -A option is specified, use of the ftpaccess(5) configuration file is disabled. This is the default.

ftpaccess file Overrides:

If the -L option is specified, commands sent to the ftpd server will be logged to the syslog. If the -L flag is used, command logging will be on by default as soon as the ftp server is invoked. This will cause the server to log all USER commands, which if a user accidentally enters a password for that command instead of the username, will cause passwords to be logged via syslog. (log commands directive)

If the -i option is specified, inbound files received by the ftpd server will be logged to the xferlog. (log transfers xxx inbound directive)

If the -o option is specified, outbound files transmitted by the ftpd server will be logged to the xferlog. (log transfers xxx outbound directive)


Logging to a different syslog facility

It may be that you are not too happy having syslog messages use the default LOG_DAEMON syslog facility. One of the biggest problems with that is all your ftpd log records are intermixed with other system daemon processes (such as DNS). You can change this. To do so:
  1. ./build clean

    Execute this in the wu-ftpd top level source directory.

  2. Modify the appropriate src/config/config.xxx from:

    #ifndef FACILITY


    #undef FACILITY

    As stated in the syslog.conf man pages, local0-7 are for local use. LOG_LOCAL0 was selected for use as an example.

    xxx == what you use to do a build with (i.e. 'build sol' for Solaris so edit the 'src/config/config.sol' file).

  3. ./build xxx

    Build the wu-ftpd software as documented for your system.

  4. make install

    Install the wu-ftpd software as documented for your system.

Note: that in the config.xxx file the define has to be defined in CAPS, but in the syslog.conf file it needs to be in lower case. Now edit the file /etc/syslog.conf and add something like the following.
  # FTP and other Daemon Servers
  local0.debug                               /var/log/ftpd.log
  local0.info                                /var/log/ftpd.log
  local0.err                                 /var/log/ftpd.log
  local0.notice                              /var/log/ftpd.log
  local0.warning                             /var/log/ftpd.log
  local0.err                                 /dev/console
This tells wu-ftpd to log things to syslog.local0. Now all of your ftpd logging goes to the file /var/log/ftpd.log.



  1. I log all files transferred in the xferlog files. Is there a way to know if the transfer was aborted ? Is there a message in another log file ?

    Currently the only way to do this is to check the file sizes. WU-FTPD does not have any indicator that the transfer succeeded recorded in the xferlog. The only way to be sure would be to check the number of bytes that were transferred and compare that to the actual size of the files. Not really workable with an archive of any size...

Do you have an additional question you'd like to see answered here ? If so send mail to Kent Landfield <kent@landfield.com> and let me know. I'll be happy to add your question and answer.


Security Concerns

Warning: You want to make all logs readable only by root. Besides the generalized privacy information as to whom is doing what on your server, there is also the concern that if a user mistypes his password for his username, it could be compromised if anyone can read the log files.


Be careful what you ask for...

It is quite reasonable to setup logging as simply an insurance policy in the event the log records are needed. Some people do little with their logs other than gather statistics from them. Often they forget about them and wake up one morning to find that there is no disk space available on their system. Then comes the 'search in a panic' to see where the culprit files are while your facility is offline...

If you are going to turn on serious logging, take the time to think about how you are going to deal with the logfile growth. If your's is a busy site this becomes a critical problem quickly. If your site is not that busy it will be even easier to enable logging and forget it until that one morning... Think about what you plan to do and do it when you enable logging. Don't put it off.