In this chapter the WU-FTPD Server for the FTP protocol is explained, and the steps to follow to configure it for many common tasks are listed.
|Note:||As modern FTP-clients support SSH, consider to use an SSH Server instead of an FTP Server, for (much) more security than any FTP server can promise|
- 1 Introduction to WU-FTPD
- 2 The WU-FTPD Server module
- 3 Limiting who can login
- 4 Setting up anonymous FTP
- 5 Managing user classes
- 6 Denying access to files
- 7 Setting up guest users
- 8 Editing directory aliases
- 9 Message and readme files
- 10 Configuring logging
- 11 Limiting concurrent logins
- 12 Restricting clients by IP address
- 13 Restricting access to FTP commands
- 14 Configuring the WU-FTPD Server module
Introduction to WU-FTPD
WU-FTPD (the WU stands for Washington University) is probably the most popular Unix FTP server on the Internet, and is included by default with most Unix and Linux operating systems. It's large number of configurable options make it superior to the ‘classic' or BSD FTP server that is still used by some flavours of Unix, but it is not in my opinion as flexibly or cleanly implemented as ProFTPD, covered in chapter 40. That chapter also has a brief introduction to the FTP protocol, which you should read before going further if you are unfamiliar with concepts such as FTP clients and servers.
In its normal default configuration, WU-FTPD will allow any Unix user (except for system users) to login with their standard usernames and passwords and upload, download and manipulate files on the server system with the same permissions that they would have if connected via telnet or SSH. It can also be set up to support anonymous logins, so that anyone can connect without needing a valid Unix account – although anonymous clients are typically restricted to a certain directory and prevented from uploading files.
WU-FTPD's primary configuration file is called /etc/ftpaccess, but it also makes use of several other files such as /etc/ftpusers and /etc/ftphosts. The ftpaccess file contains a series of directives, one per line, each of which has a name and several values. Each directive sets a single option such as the path to a message file, or a directory alias.
Like ProFTPD, WU-FTPD can be run either as a permanent stand-alone daemon process or from a super-server like inetd or xinetd. Typically the latter option is used, as this removes the need for an additional server process to be running at all times waiting for an FTP connection. As far as clients and the configuration file is concerned, there is no difference between either mode apart from performance.
The WU-FTPD Server module
To configure the FTP server from within Webmin, click on the *WU-FTPD Server* icon under the Servers category. If it is properly installed and working, the module's main page as shown in Figure 41-1 will be displayed. Each of the icons will take you to a form for setting a class of configurable options, such as those related to logging or messages and banners.
Figure 41-1 “The WU-FTPD Server module”
If the module cannot find the WU-FTPD server executable, an error message like *The FTP server /usr/sbin/in.ftpd could not be found on your system* or *The FTP server configuration file /etc/ftpaccess does not exist* will be displayed. This usually means that the program is not installed – check your Linux distribution CD or website for wu-ftpd package and install it using the Software Packages module, covered in chapter 12. It can also mean that the module is looking in the wrong location for the server program or configuration file. If you are certain that WU-FTPD is installed, see the “Configuring the WU-FTPD Server module” section later in this chapter for information on adjusting the paths that Webmin looks for them at.
Sometimes even though WU-FTPD is installed, it will be disabled by default. If you run ftp localhost at the command prompt and get back the error message Connection refused, no FTP server is running. This may be because no inetd or xinetd service has been created for FTP yet, or because one exists but it is disabled. Follow the instructions below the explain how to set up or activate a super-server service for ProFTPD.
If WU-FTPD really does need to be installed, you must first remove any other FTP server (such as ProFTPD or PureFTP) that is currently installed on your system. Make sure that you kill all of its processes as well, so that nothing is left listening on the FTP port. You can verify that the other server has been fully shut down by running ftp localhost at the command prompt – the error message Connection refused should be displayed, indicating that nothing is listening on port 21.
After installing WU-FTPD, you will need to configure inetd or xinetd to listen on the FTP port and run the server program. Before you can do this, find out where the program has actually been installed on your system – typically it will be at /usr/sbin/in.ftpd, but this may differ depending on your operating system.
If your system uses the superior xinetd super-server, follow these instructions to set up the FTP service. Because many packages include an /etc/xinetd.d configuration file for the server, some of the fields explained below may be already filled in correctly.
- Go to Webmin's Networking category and click on the *Extended Internet Services* icon. If it does not exist, xinetd is not installed and you will need to set up the server using inetd instead.
- On the module's main page, check for an existing service named ftp or wu-ftpd. If one exists, click on it – otherwise, follow the Create a new internet service link above or below the table.
- In the Service name field, enter ftp (unless it has already been filled in).
- Make sure the Yes option is selected in the Service enabled? field.
- Leave the Bind to address field set to All, and the *Port number* to Standard or 21.
- Select Stream from the Socket type menu, and Default or TCP from the Protocol list.
- In the Service handled by field, select the Server program option and enter the path to the WU-FTPD executable with the arguments –l –a (such as /usr/sbin/in.ftpd –l -a) into the adjacent text box.
- In the Run as user field, enter root.
- Select No for the Wait until complete? field.
- Leave all the other fields set to their defaults, and hit the Save or Create button at the bottom of the form.
- Back on the module's main page, click the Apply Changes button below the list of services.
Alternately, to set up an inetd service for WU-FTPD using the Internet Services and Protocols module, follow these steps :
- Go to Webmin's Networking category and click on the *Internet Services and Protocols* icon. If it does not exist, your system is probably using xinetd.
- On the module's main page, click on ftp in the *Internet Services* table. If it is not visible, enter ftp into the *Edit service* field and hit the button. Either way, the same page for editing the FTP protocol service will be displayed.
- In the Server Program section, select Program enabled.
- In the Program field, select the Command option and enter the full path to the WU-FTPD server executable into the field next to it, such as /usr/sbin/in.ftpd. In the Args field, enter in.ftpd –l -a.
- Set the Wait mode to Don't wait, and enter root in the Execute as User field. All others can be left unchanged.
- Click the Save button, and then back on the module's main page hit Apply Changes.
Once WU-FTPD has been setup to run from inetd or xinetd, you can test it by using the command-line Unix FTP client to connect to your own system. Just run ftp localhost, and make sure that you can login as some user other than root. If not, check your log files (using the System Logs module, covered in chapter 13) for any message from inetd or xinetd that may explain what went wrong.
Limiting who can login
In its normal configuration, WU-FTPD will allow any Unix user to login with the exception of system accounts such as root, bin and daemon. The root user is almost always denied by default because the FTP protocol does not encrypt passwords as they are sent over the network, which means that a remote login as root could expose its password to attackers. To change the users and groups who can login to your system, follow these steps:
- On the module's main page, click on the Users and Classes icon to bring up the form shown in Figure 41-2.
- Add to the Unix users to deny field any accounts that you want to prevent using your FTP server, or remove those that you want to allow. This will update the /etc/ftpaccess file, which is used by other FTP servers such as ProFTPD in case you one day decide to switch.
- To deny users whose UIDs lie within a certain ranges, fill in the Unix users and UIDs to deny field. You can enter a UID range like %3000-4000, which would block all users with UIDs between 3000 or 4000. Or you can enter ranges like %-100 or %5000- which will deny users with UIDs less than 100 or greater than 5000 respectively. Multiple ranges can be entered, separated by spaces. Normal usernames can be used in this field as well, although this has the same effect as putting them in the Unix users to deny field.
- To deny users whose primary group IDs are within certain ranges, fill in the Unix groups and GIDs to deny field. Again, you can enter ID ranges like %100-200 or %-10, as well as group names like users. Only primary group membership counts – if a user is a secondary member of one of the listed groups, he will not be blocked.
- To exclude some users or groups from the deny lists defined in the previous two steps, fill in the Unix users and UIDs not to deny and Unix groups and GIDs not to deny fields. The first field will accept UID ranges or usernames, and the second group ID ranges or group names. These fields are useful if you want to allow just a couple of users while blocking everyone else with a UID range that covers all accounts.
- Hit the Save button at the bottom of the page to save and activate the new user restrictions.
Figure 41-2 “The users and classes page”
WU-FTPD will also normally prevent users whose shell is not listed in the /etc/shells file from logging in. This is normally done to allow the creation of accounts that can login to a POP3 server, but cannot connect via telnet, SSH or FTP. Unfortunately, there is no WU-FTPD configuration option that can be changed to turn off this shell check. It is either hard-coded into the program, or enforced by the ftp PAM service that is really used to authenticate users.
If WU-FTPD on your system uses PAM (as it does on most Linux distributions), follow these steps to turn off /etc/shells checking:
- Go to the PAM Authentication module, which can be found under the System category on the Webmin main menu.
- Click on the ftp or wu-ftpd service on the main page.
- On the editing form that appears, click on pam_shells.so in the PAM module column in the Authentication steps section.
- From the Failure level menu select Optional, so that the success or failure of the shells file check is ignored for authentication purposes.
- Click the Save button. Users with an invalid shell will not be able to login to your FTP server.
On other operating systems the steps above are useless, as the PAM Authentication module is only available on Linux.
Setting up anonymous FTP
Configuring WU-FTPD to accept anonymous logins is slightly more complex that you would expect, due to its use of the ls command to generate directory listings. So that this command (and others used by server) cannot escape the directory to which anonymous clients are restricted, the server uses the Unix chroot system call to restrict itself and all programs that it runs to that directory. This means that the root directory must contain all the programs, files and shared libraries that WU-FTPD and the ls command need to run.
By default, the home directory of the special Unix user ftp is used as the anonymous FTP root, but different roots can be assigned to different client classes. However, whatever directory is chosen must contain a bin subdirectory with the ls, gzip, tar, recompress, cpio and zcat commands. It must also have a lib subdirectory containing any shared libraries needed by those commands, an etc subdirectory with passwd and group files, and a pub directory in which downloadable files are stored.
As you can imagine, copying all these files into place and making sure that they work is quite tricky. Fortunately, many Linux distributions that include a wu-ftpd package also have a package named anonftp that places all the needed files in the home directory of the ftp user. In most cases, all you need to do is install this package and WU-FTPD will allow clients to login anonymously.
Regardless of the permissions on the root directory, WU-FTPD will always prevent anonymous clients uploading, renaming or deleting files. All they will be able to do is download the files that you place in the pub subdirectory for public distribution.
Anonymous logins can be further configured by following these steps:
- Click on the Anonymous FTP icon on the module's main page.
- The Anonymous FTP root directories table allows you to specify different roots to be used for different classes of client. Any existing directories (apart from the default of ~ftp) are listed in the table for editing, and there will always be one empty row for adding a new one. As soon as an entry is added it will replace the default, so be sure to explicitly add it if you want it to continue working. If you want to add more than one directory, you will need to save and re-open this page so that a new blank row appears. Each row has two fields, namely: Directory In this field you must enter full path to a valid anonymous FTP directory (one that contains etc, bin, lib and pub subdirectories and all the needed programs). For class From this menu you must choose a client class to that the directory should be used for, assuming that clients in that class login anonymously. If Any is selected it will be used for clients not in any other class in this table. See the “Managing user classes” section for details on how to define your own classes.
- When a user logs in to your FTP server anonymously, they must still supply a password even though it is not used for authentication. Typically this password is the user's email address, which can be used to get a rough idea of what domain clients are coming from. However, for privacy reasons many modern FTP clients and browsers do not send a real email address anymore, instead logging in with a fake one like firstname.lastname@example.org. You can configure WU-FTPD to check the format of anonymous login passwords to make sure that they look like email addresses using the Anonymous FTP password check field on this page. If Default is selected, no checking will be done. However, if the second option is chosen the level of checking depends on the choice that you make from its menu: Allow anything Any password is allowed, even a blank one (this is the same as the default mode). Must contain @ The password must contain the @ symbol. Must be an RFC882 email address The password must look like a valid email address, with letters and numbers before and after an @. The second menu determines whether the FTP server just warns clients that violate the check (if Warn only is chosen), or blocks them altogether (if Deny login is selected).
- To block certain anonymous passwords altogether (even if they are valid), fill in the Anonymous FTP passwords to deny field with a list of complete or partial email addresses. This can be useful for blocking FTP clients that are configured by default to use a fake address. However, I recommend against using this feature as it will block a lot of people, especially those using web browsers.
- Hit the Save button at the bottom of the page to activate the new anonymous FTP settings.
Managing user classes
The FTP server categorizes clients into classes based on their source addresses and types of login. Classification can be used in several different places in the WU-FTPD configuration to define settings that apply only to certain clients. It can also be used to block non-anonymous logins (or even all logins) from outside your network. This can be useful if you only want to allow certain trusted hosts to upload data to your server, but let anyone on the Internet login anonymously to download.
Each class has a name, a list of login types and a list of client addresses, hostnames or networks. Only clients that match both the login types and the addresses are considered to be in the class, and if more than one class is matched the first one is used. Clients that do not fall into any class are not allowed to use the FTP server.
The following three types of login are recognized by WU-FTPD:
- Normal Unix users who can login via telnet or SSH, and access all files on the system with their regular permissions.
- Unix users who have been designated as guests, and this are limited to a directory (usually their home) in the same way that anonymous users are. See the “Setting up guest users” section for more details.
- Users who login anonymously and thus are limited to a certain directory.
To define and edit classes using the module, follow these instructions:
- Click on the Users and Classes icon in the top-left corner of the module's main page. The form shown in Figure 41-2 will appear in your browser.
- At the top of the page is table labeled User classes. Each row defines a class, and there will always be at least one listed already (typically the all class which matches all clients). The table always has a single empty row at the bottom for you to add a new class – if you want to add more than one, you will need to create them one at a time. You can edit existing classes by changing their fields, or delete a class by clearing out its name field. Make sure you don't delete them all though, as this will prevent all users from logging in. The fields for each class are: Class name A short name for this class that should consist of only letters and numbers, such as homenet or trusted. More than one row can have the same class name, and a client that matches the user type and addresses in any row will be considered a member of the class. *User types *The types of login that this class matches, as explained above. You must select at least one of the three checkboxes. Matching addresses This field is where you get to enter the client addresses that the class matches. You can enter single IPs (like 192.168.1.1), hostnames (like www.foo.com), wildcard IPs and hostnames (like 10.254.1.* or *.example.com) or even paths to files containing more such addresses and hostnames. Multiple entries must be separated by spaces. Negated entries like !*.foo.com are even allowed, which would match all clients whose hostnames are outside the foo.com domain. Be careful when using hostnames, as WU-FTPD must lookup clients' hostnames from their IP addresses, the result of which can be faked by an attacker.
- When you are done defining classes, hit the Save button at the bottom of the form. You can now use them in other pages in the module.
Denying access to files
Sometimes it is useful to restrict the types of files that users can download, especially for un-trusted anonymous clients. You can block access to a filename in any directory (like secret.txt), an absolute path (like /etc/passwd) or even a directory and all its contents (like /var/log). The shell wildcards characters * and ? can be used in file and path names as well, which provides extra flexibility. This can be useful if you want to protect files containing secret information, or limit clients to downloading from a certain directory (like /home). However, there is no way to prevent the listing of directories using this feature.
To set up filename download restrictions, the steps to follow are:
- On the main page, click on the Limits and Access Control icon to bring up the form shown in Figure 41-4.
- Each row in the Deny access to files table defines a single filename restriction. As with other tables in this module, at the bottom of the table is a single blank row for adding a new filename or path – and if this is the first time you have used this feature, a single row is all the table will contain. Otherwise, existing restrictions will be listed, allowing you to edit or delete them. The fields in each row and their meanings are: Files to deny A list of relative or absolute filenames or patterns to deny access to, separated by spaces. The wildcard characters * and ? can be used for both, allowing you to enter files like secret.* or /home/*/public_html. Relative to chroot? If Yes is selected, any absolute path entered in the first field is considered to be relative to the anonymous FTP root directory. If No is chosen, paths are taken to be relative to the real root directory. Deny for classes In this field you must select the checkboxes for classes that the restriction applies to. See the “Managing user classes” section for more information on how to add classes of your own. This can be useful if you want to block access by anonymous clients to some file, but allow real Unix users.
- The Allow access to files even if denied table has exactly the same structure as the denial table, but is for entering filenames and paths to which access should be allowed even if it they are denied by an entry in the table above. This can be used to deny access to everything (by entering _*_ in a Files to deny row) and then granting back download rights on only files matching a pattern (like *.html for example).
- Click the Save button at the bottom of the page to save and activate any new file restrictions. If you want to add more than one entry in either table, click on the *Limits and Access Control* icon again to re-display the form and fill in the new empty rows that appear.
Figure 41-4 “The limits and access control form”
There is also a similar feature for restricting the names of files that clients can upload. This can be useful for blocking the creation of hidden files or directories whose names start with a dot, or hard to comprehend names containing spaces and control characters. These are often used by sneaky people to hide files on your anonymous FTP server if you allow uploading. Because trusted people may have good reasons for creating such files, you can define restrictions that apply only to anonymous or guest users.
To add and edit upload filename limits, follow these steps:
- On the main page of the module, click on the Permissions icon.
- In the form that appears, the Disallowed upload filenames table at the bottom lists filenames that are allowed and denied for different types of users. Existing restrictions can be edited by just changing their fields in the table, and a new one created by filling in the final blank row (which will be all the table contains if you haven't used this form before). The columns in the table and the meanings of their fields are: Allowed characters A single Perl regular expression that all uploaded files must match. For example, if you entered ^[a-z]+$, only filenames made up of lower-case letters would be allowed. File regexps to deny A space-separate list of regular expressions that are not allowed in filenames. A good example is ^\., which blocks any name starting with a dot, which hides the file. User types The types of users that this restriction applies to. Often you will want to place stricter limits on anonymous clients than real or guest users. Error message file The full path to a file that will be sent to any client which tries to upload a file whose name does not match the allowed expression, or does match one of the denied expressions.
- As usual, click the Save button at the bottom of the page to activate any new restrictions when you are done.
If more than one restriction is defined for the same type of user, they will all be checked to determine if an uploaded filename is allowed.
Setting up guest users
A guest FTP user is a real Unix user who is limited by WU-FTPD to a certain directory, just as anonymous clients are restricted. They still have full privileges within that directory though, including the rights to upload files, rename and chmod files. Limiting a user to guest access can be useful if you want to prevent him seeing parts of your filesystem outside his home directory or some parent directory like /home.
Every user who is designated as a guest by the FTP server configuration can have a different root directory, or some can be the same. However, the chosen root directories must be set up in the same way as the anonymous FTP root is – with bin, lib and etc subdirectories containing all the programs and files needed by WU-FTPD. You can just copy those directories across from the anonymous root though, so the setup process is not that hard.
To set up a user as a guest his home directory must be specially modified. The steps below explain how to do this using Webmin:
- Go to the Users and Groups module (covered in chapter 4) and click on the name of the user that you want to restrict.
- Change his home directory to guestroot_/./_homedir, in which guestroot is the root directory that you have prepared, and homedir a subdirectory under it. If you are using /home as the root, /home/./jcameron could be the directory for the user jcameron. This special /./ entry in the path tells WU-FTPD where the root is, but should not confuse other programs.
- Click the Save button at the bottom of the page. Webmin will move his home directory to the new location if necessary.
Of course, you can specify such a home when creating a new user as well. This is only the first step though – to configure WU-FTPD to treat certain users as guests you will need to follow these steps:
- In the WU-FTPD Server module click on the Users and Classes icon to bring up the form shown in Figure 41-2.
- In the Unix users and UIDs to treat as guests, enter a space-separated list of usernames, UIDs or UID ranges (like %1000-2000 _or %5000-_) of users to be designated as guests. You can also enter a list of group names, IDs and ID ranges in the *Unix groups and GIDs to treat as guests* field to have all their primary members treated as guests as well.
- To stop some users from being converted to guests even if they are in the lists or ranges set in step 2, fill in the Unix users and UIDs not to treat as guests and Unix groups and GIDs not to treat as guests fields. This can be useful if you want to make everyone a guest except a few trusted users.
- Click the Save button at the bottom of the page to activate the new guest designations.
If a user has been configured as a guest but does not have /./ in his home directory, he will not be restricted to any root directory.
Editing directory aliases
To simplify life for users that frequently need to access directories with long paths, WU-FTPD allows you to define directory aliases that can be used when changing to a different directory. This means that someone using a command-line FTP client can enter cd stuff: instead of cd /usr/local/etc/stuff, assuming that a suitable alias has been created.
To set up aliases, follow these steps:
- On the module's main page, click on the Aliases and Paths icon.
- The CD directory aliases field is actually a table that lists existing aliases (if any) and always has one blank row for adding a new one. In the first empty field under the Alias name column, enter the name for a new alias like stuff: or junk:. There is no requirement that an alias end with a colon – however, this is a good idea as it reduced the risk of an alias name being the same as an actual relative directory. In the corresponding field under Alias to directory, enter a full directory path like /usr/local/junk that the alias is equal to. If you want to add more than one alias, you will need to save and re-open this page so that a new empty row appears. To delete one, just clear out both of its fields in the table.
- The CD directory search path text box lets you enter a list of directories that will be searched if a client tries to change to a relative subdirectory that is not in the current directory. For example, if /usr/local was included and a client tried to switch to the bin directory, he would be placed in /usr/local/bin (assuming no real bin subdirectory exists).
- Hit the Save button at the bottom of the page to activate the new aliases.
Aliases are not particularly useful in graphical FTP clients which present the user with a directory listing to click on. Because users do not and often cannot change to an explicit pseudo-directory like stuff: and aliases are not included in listings, they are hard to use. Command-like FTP clients like ncftp and the classic Unix ftp program are more suited to using them though.
Message and readme files
WU-FTPD can be configured to send the contents of various message files to clients when they login or enter certain directories. This can be useful to display information about your FTP server (such as who runs it and what files are hosted) or details of the contents of a particular directory to FTP users. Each file is only sent once to a client in a single session, to avoid annoying the user with repeated messages.
The server can also be set up to notify clients that certain files exist and inform them of their last modification dates. This is typically used for README files containing slightly less important information about a directory or the server, which users may want to read. Again, clients are only notified once per session for each such file.
To define message and banner files, follow these steps:
- Click on the Messages and Banners icon on the module's main page, which will take you to the form shown in Figure 41-3.
- The Message files section is a table for specifying files whose contents will be sent to clients. As usual with tables in Webmin, it lists existing files and their contexts, and has a one blank row at the bottom for adding a new one. The meanings of the fields are: Path The path to the file whose contents should be sent to the client. This can be either an absolute path like /etc/login.message or a relative filename like message.txt. In the latter case, it is looked for in each directory that the client enters. If you enter a full path and want anonymous clients to be able to see it, it must be under the anonymous FTP root directory. When to display If At login is selected, the file will be sent to clients after logging in. If Entering any dir is chosen, the file will be searched for and sent when changing to any directory. When Entering dir is chosen, the file will only be sent when the directory whose path you specify in the adjacent text box is entered. Again, this must be relative to the root directory for anonymous clients. Classes to display for If this field is left blank, the message is sent to all clients. However, if one or more classes of client is entered (separated by spaces) it will only be used for clients that fall into those classes. This can be useful for defining message files just for anonymous users, especially when using absolute paths.
- To define files that clients will be notified of the existence of, you will need to fill in the README files table. Again, this lists all existing files and has a blank row for adding a single new one. The meanings of the fields in this table's columns are: Path' The path to the file whose existence and modification time should be sent to the client. This can be either an absolute path like /etc/README or a filename relative to the directory being entered like README.txt. You can even use shell wildcard characters like * and ? in the filename to match multiple files, for example README*. When to display last modified date If At login is selected, the information will be sent to clients after logging in. If Entering any dir is chosen, the file will be searched for and its modification date sent when changing to any directory. When Entering dir is chosen, the modification date will only be sent when the directory whose path you specify in the adjacent text box is entered. Classes to display for If this field is left blank, the modification is sent to all clients. However, if one or more classes of client is entered (separated by spaces) it will only be used for clients that fall into those classes.
- To change the amount of information that WU-FTPD sends to clients when they connect, adjust the Greeting level field. If Hostname and version is selected, both the system's hostname and the FTP server version will be sent. If just Hostname is chosen only the hostname will be displayed, while if Neither is selected no information will be sent. The latter two options are the most secure, as an attacker may be able to use your FTP server's version to find a bug in it that could be exploited to take over your system.
- If you want to have the server sent a message to clients as soon as they connect, put it in a file and select the From file option for the Pre-login banner file field. Then enter the full path to the message file into the text box next to it.
- To change the hostname that WU-FTPD sends in the greeting and other messages, select the second option in the Hostname for messages field and enter some alternative name in the text box. This can be useful if your system's real hostname does not match the name the FTP clients use (server5.example.com instead of ftp.example.com for example).
- When you are done with this form, click the Save button to activate your changes. They will apply to all new FTP clients that connect from now on.
On many operating systems, the WU-FTPD configuration will include one or two message and README file definitions by default. Typically the .message file is searched for in every directory and sent to clients, as is the modification time of any file whose name matches the README* pattern.
Any message files that you define that can contain special codes starting with % that are replaced when the file is sent by dynamically generated text. For example, %U is replaced with the client's FTP login name, so a file containing the line _Welcome %U to the example.com FTP server_ would be sent to the client as something like Welcome jcameron to the example.com FTP server. According to the WU-FTPD manual page, the available codes are:
In a typical default configuration, WU-FTPD will log all uploads and downloads to the file /var/log/xferlog. However, you can choose the types of users that logging will be done for (Unix, anonymous or guest), have the log written to syslog instead, and select to record commands are security violations for some types of users. Logging to the system log gives you more flexibility, as you can choose which file messages are written to – although they will be mixed in with other daemon facility messages. See chapter 13 and the System Logs module for more information on how syslog works and which files it ultimately writes to.
Enabling logging of all commands allows you to track exactly what clients are doing, but can consume a large amount of disk space. The logging of security violations (attempts to violate WU-FTPD's file restrictions, covered in the “Denying access to files” section) can be useful for detecting hackers, and is unlikely to use up much space as such violations are not usually very frequent.
To edit FTP logging-related options in Webmin, the steps to follow are:
- On the module's main page, click on the Logging icon to bring up the small logging options form.
- To have all FTP commands executed by clients (including trivial ones such as CWD and LIST) recorded in the system log, select types of users for which they should be logged from the Log all commands for field.
- To change the types of users that transfer logging is done for, select them from the Log transfers for field. The *In directions* sub-field lets you choose whether uploads (Inbound), downloads (Outbound) or Both are recorded. On an anonymous FTP server, it may make sense to only record uploads due to the large number of downloads.
- To have transfers written to syslog, select System log in the Log transfers to field. Or to tell WU-FTPD to write to the /var/log/xferlog file instead, select XFER log file. If Both is chosen, transfers will be logged to both destinations. If you want to use a program like Webalizer (covered in chapter 39) to analyze your FTP server's logs, they must be written to xferlog as the lines that end up being written out by syslog have additional information added and thus cannot be parsed. Anything written to the system log will use the daemon facility, unless WU-FTPD has been compiled to use a different one, such as local7. This can in fact be quite useful, as it allows you to separate out the FTP messages and have them written to a different file, while still enjoying all the benefits of syslog.
- To enable the logging of attempted filename security violations, select the types of users that this should be enabled for from the Log security violations for field. These will always been written to syslog.
- Click the Save button at the bottom of the page to save and activate the new logging settings.
Limiting concurrent logins
If your system is configured to allow anonymous FTP logins and you expect to receive a lot of traffic, it makes sense to limit the number of connections that can be open to the FTP server at any one time. This puts a ceiling on the network and CPU load that FTP transfers can generate, which is important if the system is being used for some other purpose (such as running a web server).
WU-FTPD allows you to define limits on a per-class basis, so that anonymous clients can be restricted while real Unix users are not. It also lets you specify the times during which restrictions apply, so that a higher limit can be granted when the server is not as heavily used for other purposes (such as at night).
To set up concurrent login limits, follow these instructions:
- On the module's main page, click on the Limits and Access Control icon. The form shown in Figure 41-4 will appear in your browser.
- The Concurrent user limits table is where limits on the number of connections can be entered. Each row defines a limit that applies to a certain class at certain times. As usual with tables in this module, there will be one empty row at the bottom for adding a new limit (and if this is the first one, the table will only contain that one row). Existing limits can be edited by changing their fields in the table, or deleted by selecting the empty option from the class menu. The fields in each row should be filled in as follows: Apply to class' You must select the name of the class that this limit will apply to from the menu. Multiple limits can be defined for the same class at different times. Maximum users To set a limit for the chosen class, select the second radio button and enter the maximum number of concurrent connections into the adjacent text box. If the Unlimited button is selected, no limit will apply to the class at the specified times. For example, you could add a row that turns off restrictions at night above another row that sets them for the entire day. At times If Any time is selected, the limit will apply all the time. However, if you choose the second option and enter a UUCP-style time specification into the text box, only connections made during that period will be restricted. For example, Any0900-1700 means 9am to 5pm every day, Mo,Tu,We means Mondays, Tuesdays and Wednesdays, Wk means weekdays and and Wk1700-0900,Sa,Su means times outside office hours. WU-FTPD always checks the table in order for an entry that matches a connecting client's class and the current time, and stops when it finds one. This means that entries that specify times (such as Any0900-1700) should be placed above those that have Any time selected so that the specific entry is actually used when appropriate. Error message file The full path to a file containing a message that will be sent to clients whose connections exceed the limit. This should explain why they are being rejected, and suggest other times or FTP servers to try.
- Hit the Save button at the bottom of the page to activate the connection limits. To add more than one, you will need to re-visit the form so that a new blank row appears in the table.
Restricting clients by IP address
Even though it is possible to block clients from certain addresses by ensuring that they do not fall into any class, there is a feature in the module dedicated specifically to blocking clients based on their IP addresses or hostnames. This can be used to lock out specific hosts that are abusing your FTP server, or to restrict access to clients from only your own company or home network.
The steps to define banned client systems are:
- Click on the Limits and Access Control icon on the module's main page to open the form shown in Figure 41-4.
- Each row in the Deny access from table specifies an IP address, hostname or pattern to block logins from. As with other tables in this module, it will always an additional empty row for adding a new restricted address. In the Deny from address field you can also enter the full path to a file containing banned addresses, use negated patterns like !192.168.1.* or even the special address !nameserved which matches all clients that do not have a valid reverse DNS address. Only one can be entered though – to block additional addresses, you will need to add more rows. In the Error message file field you must enter the full path to a file containing a message that will be sent to blocked clients. This should explain to connecting users that they have been blocked, and perhaps give a reason why. If you want to add more than one row, you will need to save this form and re-open it so that a new empty row appears at the bottom of the table. Existing restrictions can be edited by just changing their fields, or deleted by clearing out the address.
- When you are done, hit the Save button at the bottom of the form to activate the new address restrictions.
Restricting access to FTP commands
WU-FTPD can be configured to restrict the FTP commands that certain types and classes of users can use. This is useful for stopping anonymous clients modifying files, as on most FTP servers they are only allowed to download, not upload, rename or delete. In fact, in its usual default configuration this is exactly how WU-FTPD is configured.
There are five commands that you can restrict access to, all related to server-side data modification. They are:
- Change the Unix permissions of a file on the server (chmod in the Unix FTP client).
- Delete a file or directory on the server (del or rmdir in the Unix FTP client).
- Change the name of a file or directory (rename in the FTP client).
- Upload a file with the same name as one that already exists.
- Change the default Unix permissions for newly created files (umask in the Unix FTP client).
It is not possible to stop clients using directory listing or download commands. Neither is it possible using this feature to prevent the upload of files that do not already exist – however, this can be achieved by setting directory permissions appropriately, or blocking all uploaded filenames as explained in the “Denying access to files” section.
To define which clients can use which commands, follow these steps:
- Click on the Permissions icon on the module's main page.
- On the form that appears, the Command restrictions table lists existing commands and the user types and client classes that are or are not allowed to use them. As usual, you can add a new command using the blank row at the bottom, edit existing entries or delete the restrictions on a command altogether by selecting the blank option from the Command menu. The FTP server processes this table in order when a client tries to do something, and uses the selection in the Allow? column for the first entry that matches to decide if it is allowed or not. This means that the order matters, and thus if two entries match the first one will decide what happens. The fields for each row and their meanings are: Command You must select types. The restriction will only apply to the types of user selected in this column. See the “Managing user classes” section earlier in the chapter for details on what each means. For classes Only the client classes selected in this column will be effected by the restriction.
- When you are done editing or adding to the table, hit the Save button to activate your changes.
If a client command does not match any entry in the table, it will be allowed by the FTP server (unless blocked by some other filename restriction set elsewhere).
Configuring the WU-FTPD Server module
To change the paths that the module uses for the WU-FTPD configuration files and programs, you will need to click on the standard Module Config link in the top-left corner of the main page. Unlike other modules there are no options related to the user interface, so you will probably not need to adjust anything on the configuration form if the module is working for you. By default, all the configuration fields are set to match the WU-FTPFD package included with your operating system or Linux distribution.
Even though there are fields for configuration files other than ftpaccess, at the time of writing the module does not actually edit those files yet.