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'.
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.
config.h: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.src/pathnames.h:
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.
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.
#define LOG_TOOMANYSecond, 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.
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.
- log commands <typelist>
Enables logging of individual commands by users. <typelist> is a comma-separated list of any of the key words "anonymous", "guest" and "real". If the "real" keyword is included, logging will be done for users using FTP to access real accounts, and if the "anonymous" keyword is included logging will done for users using anonymous FTP. The "guest" keyword matches guest access accounts (see "guestgroup" for more information).
Examples:log commands anonymous
log commands real,guest,anonymous
- log transfers <typelist> <directions>
Enables logging of file transfers for either real or anonymous FTP users. Logging of transfers TO the server (incoming) can be enabled separately from transfers FROM the server (outbound). <typelist> is a comma-separated list of any of the keywords "anonymous", "guest" and "real". If the "real" keyword is included, logging will be done for users using FTP to access real accounts, and if the "anonymous" keyword is included logging will done for users using anonymous FTP. The "guest" keyword matches guest access accounts (see "guestgroup" for more information). <directions> is a comma-separated list of any of the two keywords "inbound" and "outbound", and will respectively cause transfers to be logged for files sent to the server and sent from the server.
Example:log transfers anonymous,guest,real inbound,outbound
- virtual <address> <root|banner|logfile> <path>
Enables the virtual ftp server capabilities. The <address> is the ip address of the virtual server. The second argument specifies that the <path> is either the path to the root of the filesystem for this virtual server, the banner presented to the user when connecting to this virtual server, or the logfile where transfers are recorded for this virtual server. If the logfile is not specified the default logfile will be used. All other message files and permissions as well as any other settings in this file apply to all virtual servers.
Example:virtual 10.10.10.10 logfile /var/log/domain1/xferlog
If you are using Kent Landfield's newvirt virtual hosting capabilities, refer to http://www.landfield.com/wu-ftpd/newvirt for more specific information.
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.
This type of log entry is generated when WU-FTPD encounters an error condition that the administrator should be alerted to. This normally is a configuration error or a resource error. Note: Not all error messages are critical errors. Some are temporary resource errors.
This type of message is generated in an effort to notify of a condition. Access denied, repeated failures, successful virtual hosting connections, pending password expiration, etc. appear when LOG_NOTICE is enabled.
Normally only used for debugging the server, LOG_DEBUG provides additional information as to the flow of the software.
These messages appear when there are connection level problems setting socket options, SITE or PORT refusals.
If you want to log commands users enter then you must configure LOG_INFO into syslog. Connection start and end logging requires you use LOG_INFO. SITE EXEC usage is also logged using this.
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.
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)
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:
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.
- ./build clean
Execute this in the wu-ftpd top level source directory.
- Modify the appropriate src/config/config.xxx from:
#define FACILITY LOG_DAEMON
#define FACILITY LOG_LOCAL0
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).
- ./build xxx
Build the wu-ftpd software as documented for your system.
- make install
Install the wu-ftpd software as documented for your system.# # 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/consoleThis tells wu-ftpd to log things to syslog.local0. Now all of your ftpd logging goes to the file /var/log/ftpd.log.
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 <email@example.com> and let me know. I'll be happy to add your question and answer.
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.
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.