Although WU-FTPD was dropped from the distribution, you can still use WU-FTPD by downloading and installing the following packages from rpmfind.net:
When WU-FTPD is first installed, it is disabled. However, much of the FTP configuration is already in place.
Refer to "Starting and shutting down the WU-FTPD service" to see how to start the FTP server.
The following sections describe the setup of the wu-ftpd package when it is first installed:
FTP Daemon — The FTP daemon is set up in the /etc/xinetd.d/wu-ftpd file as /usr/sbin/in.ftpd. When someone requests FTP service from your computer (probably on port 21), the xinetd daemon (which listens to lots of ports) starts the FTP daemon to handle that FTP login request. The daemon runs with the -l option (so that FTP requests are logged by syslog to /var/log/messages) and the -a option (so that the /etc/ftpaccess file is used to define access permissions).
Access Permissions (/etc/ftpaccess) — The ftpaccess file delivered with the wu-ftpd package is quite restrictive, although you can change it to be as open or as restrictive as you like. Here is how the file is originally set:
deny and allow — The following lines are included to set which user accounts are allowed and which are denied access to the FTP service. The deny-uid and deny-gid entries prevent access to the FTP service by any users with IDs of 99 or less or 65534 or greater for either user or group accounts. The allow-uid and allow-gid lines make an exception to the deny rules by allowing the ftp user and group to use the FTP service.
deny-uid %-99 %65534- deny-gid %-99 %65534- allow-uid ftp allow-gid ftp
guestuser * — This line causes all users to have their home directory as their root directory by default. So, if your home directory were /home/jake and you opened an FTP connection to the computer, you would only be able to see files that were in /home/jake or its subdirectories. (To change this behavior, either add a comment character, #, before the line or add a realuser user line, replacing user with the name of the user whom you want to allow to change directories outside of his/her home directory.)
email root@localhost — E-mail related to the administration of the FTP server is directed to the root user on the local computer, by default.
loginfails 5 — The FTP connection terminates after five consecutive failed login attempts. (This slows down people who are trying to guess your server's passwords.)
readme README* — When the user logs in (login) or changes to any other accessible directory (cwd=*), the user is notified of the existence of README files, if they exist. By default, no README files exist. For any file that begins with the word README, a message is displayed by the server that says "Please read the file README.whatever."
message — This indicates that the message contained in the /welcome.msg file should be displayed when a user logs in to FTP. A similar line indicates that the .message file is displayed when the user enters a directory that contains such a file. By default, none of these files exists. If you want them on your FTP server, you have to create them yourself.
The /welcome.msg file is relative to the root directory that the FTP user logs into. A guest user, such as anonymous, would by default have /var/ftp as his or her root directory. The welcome.msg file would therefore have to be in /var/ftp.
compress yes all — This enables compression of files for the FTP site for all users. The compress command is the standard compression command used in UNIX systems (though gzip is used more often with free operating systems, such as Linux). The compress command lines used to carry out the compressions are defined in /etc/ftpconversions. (Files stored by compress have a .Z suffix.)
tar yes all — This enables tar compression for all users at the FTP site. The tar command is the standard UNIX command used to create archives of multiple files. The tar commands used to carry out the compressions are defined in /etc/ftpconversions. (Files stored by tar have a .tar, .tar.gz, or .tar.Z suffix.)
chmod no guest, anonymous — This prevents guest and anonymous user names from changing the permissions on any files or directories.
delete no anonymous — This prevents anonymous user name from deleting files or directories.
overwrite no anonymous — This prevents anonymous user name from overwriting existing files or directories.
rename no anonymous — This prevents anonymous user name from renaming any files or directories.
log transfers anonymous, guest, real inbound, outbound — This logs file transfers for the anonymous user, guest user, and any real users (that is, those who have their own user accounts on the Linux system). Both uploads (inbound) and downloads (outbound) transfers are logged.
shutdown /etc/shutmsg — This checks the /etc/shutmsg file to see if the server is about to be shut down. If it is, your FTP server sends a message to current FTP users, warning them that the server is about to go down. It also denies new FTP connections and disconnects current users at a specified time prior to shutdown. (By default, the /etc/shutmsg file does not exist.) See the section on setting up FTP shutdowns later in this chapter for information on how to set up a shutdown file for scheduled FTP shutdowns.
passwd-check rfc822 warn — This checks that passwords for anonymous logins are rfc822-compliant addresses. In other words, the FTP server asks for any valid e-mail address as the password for the anonymous login. If the address is not compliant (that is, is not in the form email@example.com), the server will "warn" the user but still allow the user to log in.
FTP Root Directory — For a user who logs in as an anonymous user, the /var/ftp directory is assigned as the user's root directory. In other words, the anonymous user could not change directories above the /var/ftp directory (or even know what files exist outside the /var/ftp directory structure).
Within the /var/ftp directory are those directories and files necessary to make FTP work properly, without your having to access other files in the file system. The /bin directory contains executable commands that FTP may need (such as compress, ls, and gzip). The /etc directory contains passwd and group entries. The /lib directory holds shared object libraries needed by FTP. Finally, the /pub directory is available for placing the files that you want to be generally available to anonymous users.
The different types of users who can use the FTP services from your server include the anonymous user name, any of the real users who have been added to your computer (in /etc/passwd), and any special guest accounts that you set up. The following sections describe each of these types of users and how to set them up.
Because most visitors to an FTP site from the Internet will not have an individual login account to the computer, the anonymous user name is used on public FTP sites. With the anonymous user name, anyone who can reach the FTP site from the network can log in to the server and have minimal permission for its use. Typically, "minimal" means that an anonymous user can only copy files from (and not write files to) the FTP server and that only selected directories are even visible.
Here is an example of a login session from an anonymous user:
$ ftp maple Connected to maple 220 maple FTP server (Version wu-2.6.2-8) ready. Name (maple:mike): anonymous 331 Guest login ok, send your complete e-mail address as password. Password: ********* 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> ftp> bye 221-You have transferred 0 bytes in 0 files. 221-Total traffic for this session was 313 bytes in 0 transfers. 221-Thank you for using the FTP service on maple. 221 Goodbye.
While I was logged on to the FTP server, I had access to all files and directories that the server allowed to the anonymous user. That would probably include only a limited area of the server's system (the /var/ftp directory, by default, on Red Hat Linux systems). There were probably restrictions on what I could change, delete, or create on the server as an anonymous user as well.
One of the great advantages of anonymous FTP is that it can easily be automated. Instead of using the ftp command, users can simply type the FTP address of the server into a Web browser. Users don't even need to know that they are being logged in as an anonymous user when they visit the FTP site. The list of files and directories requested simply appears.
Assuming you have installed the anonftp software package and started the FTP service, anonymous users are given access to your FTP server by default. This assumes that your firewall is not blocking access to the service and that disable = yes was changed to disable = no in the file /etc/xinetd.d/wu-ftpd. To prevent anonymous users from accessing your FTP server, add the following line to your /etc/ftpaccess file:
The users who have valid login accounts to your computer can also access the computer via FTP. These users can have any user name that the administrator defines. To use FTP, they can simply type their user names and passwords at the FTP prompts. At that point, they will be logged in to the FTP server.
See Chapter 11 for information on setting up regular real user accounts.
Instead of having /var/ftp as their root directory, however, real users have their regular home directory (such as /home/user, where user is the user name) as their root directory and current directory when they log in. Like the anonymous user, the real user has special restrictions with regard to the file system. By default, real users cannot access any files outside of their home directory and related subdirectories.
If you used WU-FTPD in a Red Hat Linux system prior to version 7.3, you may remember that real users' access was not restricted to their home directory. If your users complain, you can consider reconfiguring the ftpaccess file.
No special configuration needs to be done in the /etc/ftpaccess file to allow a user with a real account to connect to the server through FTP. However, if you want to provide one or more real users with the same access to the file system that they would have if they logged in directly, you could redefine that user or group as real by setting a realuser or realgroup value for the user or group, respectively. (For example, add a line that reads realuser joe to give the user named joe access to files outside of his home directory.)
To prevent any real user from using the FTP service, you can simply add the person's user name to the /etc/ftpusers list. By default, these users are excluded because they are on this list: root, bin, daemon, adm, lp, sync, shutdown, halt, mail, news, uucp, operator, games, and nobody. Most of those users are administrative accounts that could be exploited. In the /etc/ftpaccess file, all administrative accounts except the ftp user and group are denied access to the FTP service by default.
A guest user is sort of halfway between a real user and an anonymous user. You can assign any name as a guest user. However, the guest user is limited to a restricted area of the file system, typically the user's home directory.
Using guest user accounts is a great way to give specific users permission to add files to and remove them from a specific part of your file system but not allow them to do much else. This is useful, for example, if you want to give users a place to set up their own Web pages.
In general terms, an FTP guest user will have an account set up in the Linux /etc/passwd file, then that user will be defined as either a guestuser or guestgroup in the /etc/ ftpaccess file. The following is an example of how to set up an FTP guest user account (you must be the root user to do this procedure):
Add the user account as you would normally. For example, to add a user named mike with a home directory of /home/mike, type the following (as root user):
# useradd -m mike
Add a password for mike using the passwd command (entering it twice, as prompted):
# passwd mike Changing password for user mike. New password: ******** Retype new password: ********
Edit the user's account information in /etc/passwd so that the user's root directory is changed to the restricted directory (for example, the user's /home directory). Here is an example of how that new entry would look for the user named mike:
The dot (.) after /home/mike makes the /home/mike directory on the FTP server the root directory for mike. When mike logs in, his current directory is /home/mike/pub. The /etc/ftponly value prevents a shell from starting up (such as /bin/bash) if mike were to log in from a regular Linux prompt.
Copy the sample ftponly file to /etc and make it executable as follows:
# cp /usr/share/doc/wu-ftpd*/examples/ftponly /etc/ # chmod 755 /etc/ftponly
Add the line /etc/ftponly to the /etc/shells file.
Create directories needed for the guest user's home directory to have everything FTP needs to work properly. To do this, I just copied everything from the /var/ftp directory structure (as root user) to my guest user's home directory (/home/mike). After that, I changed group assignment of /home/mike/pub to mike:
# cp -r /var/ftp/* /home/mike # chgrp mike /home/mike/pub
Add the necessary definitions to /etc/ftpaccess. If you changed the default (guestuser *), which makes all real users into guest users, you need to define the user as a guest login. For example, to define mike as a guest login, add the following to /etc/ftpaccess:
With just guestuser mike defined, the user mike has /home/mike as his root directory and he can get files (but not put them on the server). Also, he can browse the directory structure below /home/mike only. To add to or change permissions, see the section on controlling FTP access later in this chapter.
At this point, the guest user can use the ftp command to connect to the server and have access to only those files and directories that are under the user's restricted directory.
As an FTP site administrator, you are responsible for setting up the directory structure used on your site. You also have an opportunity to make the navigation of your site easier for users by providing a variety of message files and README files on your site and to change the greetings on your FTP server. The following sections describe these features.
Because you are providing a limited view of the file system to those who use your FTP service, you must provide everything they need within the root file system that they can access (typically, /var/ftp). How to set up the minimal directory structure for FTP is described in the section on setting up guest users.
A viable directory structure is provided in the /var/ftp directory when you install the FTP service in Red Hat Linux (specifically, the anonftp package). After that, most of what you want to share with the public can be arranged in the /pub directory structure that you create. For directories containing information that is restricted to certain classes of user, you may want to create a different root directory (such as /local).
Specific directories can be included or excluded within the directory structure using a variety of parameters in the /etc/ftpaccess file. You can choose which directories allow upload and download. You can also set whether users can rename, delete, overwrite, or change permissions of files. See the sections on controlling FTP access for further information on setting up user directories and files.
The FTP service on your Red Hat Linux computer is set up to automatically display messages and to alert the user to the existence of README files at different times in a user's navigation of your site. When FTP is installed, however, none of these files exist. So to help the navigation of your site, you need to create these files.
A README file is a standard method of providing information about the contents of a software package or, in this case, the contents of an FTP directory. Your FTP server is set up, by default, to alert users to the existence of README files when they either log in or change into a directory that contains a README file. Here are the entries in the /etc/ftpaccess file that make this happen:
readme README* login readme README* cwd=*
The asterisk at the end of README indicates that any files that begin with the word README are matched (such as README.info, README-help, or README.txt). The README file is usually in plain text, so anyone can read it. Add a README file to the /var/ftp directory (to describe the contents of the FTP server) or to any directory where you want to describe the contents to the user who enters that directory.
Users who enter a directory containing a README file will see a message that tells them that the README file is there. They have to open the file themselves to see the contents. Here is an example of what they will see after logging in:
230-Please read the file README 230- it was last modified on Thu May 23 16:46:20 2002 – 0 days ago
If you want to make sure that the users see a message when they log in or enter a particular directory, you can create welcome.msg and .message files. You can create the files using any text editor. Two entries in the /etc/ftpaccess file define how message files are set to be read:
message /welcome.msg login message .message .cwd=*
You can create a welcome.msg in the FTP user's root directory (probably /var/ftp for anonymous users). It should be a plain-text message. It will appear when the user first logs in to your FTP server. In each directory, you can create a .message file. When users enter that directory, the contents of the .message file are displayed. As with the welcome.msg file, the .message file should be in plain text.
When users log in to your FTP server, they see several standard greetings. You can change the greetings they see and what those greetings include by adding to your /etc/ftpaccess file.
By default, a user who logs in to your FTP server won't see much information. The default greeting when a user logs in to your FTP server looks something like this:
$ ftp maple Connected to maple (10.0.0.11). 220 maple FTP server (Version wu-2.6.2-8) ready. Name (maple:mike):
That was the full greeting. To shorten the greetings that a user sees, you can set the greeting option to brief or terse in the /etc/ftpaccess file as follows:
The terse option causes a somewhat shorter output to be displayed before the login prompt. Here is an example:
$ ftp maple Connected to maple (10.0.0.11). 220 FTP server ready. Name (maple:mike):
Normally, your system's host name is displayed when someone connects to your FTP service. If you want to assign a special host name that applies only to connections to your FTP server, change that name in the /etc/ftpaccess file. Here is an example of the line you would enter:
The next time an FTP user connects, that user will see the host name as ftppine.
If you want to have a message appear after a user connects to your FTP service, but before the login prompt, you can do that with the banner option in the /etc/ftpaccess file. First, you need to create a text file that contains the message you want to print. Next, add a banner line pointing to that file (relative to your system root, not the FTP relative root). For example:
With this example, the next time a user connects to the FTP service, the contents of the /etc/ftpbanner.msg file are displayed after the connection message and before the login prompt appears.
Just because you open your computer to public access doesn't mean that you have to let everyone abuse your computing resources. In the /etc/ftpaccess file, you can define exactly which directories are readable and writable. You can limit the number of users who can access your FTP server at a time. You can also set permissions or limits to your resources for individuals or groups. The following sections describe some of your options.
By setting up user classes, you create a method of assigning access to different resources to different groups of users. Any user who does not fall into a class will not have access to your FTP server. That's why the default class includes all users with the following line:
class all real,guest,anonymous *
First decide which groups of users you want to treat separately. An effective technique is to define your local users as one class and all other users as another class. The class keyword lets you assign classes based on network address and types of user within that address (that is, real, guest, or anonymous). For example, you may want to assign one set of permissions for all users within your Internet domain and another set for everyone else. Here's how to do that:
class home real,guest,anonymous 10.0.0.0/8 class world real,guest,anonymous *
In this example, all users who come from a host computer with an address on network number 10.0.0.0 (presumably your local network) are assigned to the "home" class. Users from other networks are assigned to the "world" class. You can use a network number or a domain name.
The /8 following the network address is a shorthand for the netmask. It indicates that the eight leftmost bits represent the network. In this example, therefore, the number 10 represents the network number and the next three octets represent individual host addresses.
As discussed earlier, user types defined within each class are represented by one of the following keywords:
real — For users who have a login account on the local computer.
guest — For users with real login accounts who are designated as guestusers or guestgroups in the /etc/ftpaccess file.
anonymous — For anyone who logs in under the anonymous user name.
With class names assigned, you can assign limitations or permissions to any of those classes.
By default, anonymous users are not permitted to upload files to your FTP server. For uploading to occur, you must specifically allow uploading in the /etc/ftpaccess file, using the upload parameter. Also, specific parameters deal with whether guest and anonymous users can delete, overwrite, rename, or change permissions of files and directories. (Remember that allowing public uploading of files to your FTP server can pose a significant security risk.)
You need to add information to your /etc/ftpaccess to enable FTP users to upload files to your Red Hat Linux system. Here are two examples of using the upload parameter to permit ftp users to upload files:
upload /var/ftp /incoming yes mike sales 0600 upload /var/ftp /testdir yes ftp ftp 0666
These examples enable you to upload files to the /incoming and /testdir directories in the anonymous user's root directory (/var/ftp). The permission the user has to write to the /incoming directory (and its subdirectories) is as the user mike and the group sales. Files are written with 0600 permission (so only mike could read and write the files). In the second example, ftp user and group permission are used to create the file and its read/write permissions are open (0666).
If you don't remember what permission settings such as 0666 and 0600 mean, refer to the description of access permissions in Chapter 4. These are common options used with the chmod command to change access permissions.
Allowing upload permission also allows those same users the right to create directories (within the upload areas). To disallow the creation of directories, add the nodirs keyword at the end of an upload line (after the permission numbers). To have the ability to create directories turned on for an instance where it may be off, add the dirs keyword to the end of the line.
Another useful option with the upload parameter is the class option. The class option lets you set upload permission for a select class of users. Here is an example of using the class option:
upload class=home /var/ftp /incoming/local yes ftp guest 0666
In this example, along with the previous example, any anonymous user could write to the /incoming directory, but only those who belonged to the class called home can write to the /incoming/local directory (within the /var/ftp directory). The permissions in this case are open (0666), and files and directories are created with FTP and guest for the user and group who own the file, respectively.
Using upload is not enough to ensure that an anonymous user can upload files to your FTP directories. Red Hat Linux file and directory ownership also applies. For example, if the incoming directory were owned by root, 700 permission would not allow the anonymous user to upload, but 777 permission would.
Using the noretrieve parameter, you can prevent files with specific names or from specific directories from being retrieved. Here are some examples:
noretrieve relative class=world /pub/homestuff noretrieve absolute /etc/hosts /etc/inittab noretrieve core personal money
In these examples, relative and absolute keywords indicate whether the files and directories indicated are relative to the FTP user's directory (for example, /var/ftp) or an absolute path from the system's root directory. The first line indicates that any users in the class world cannot retrieve files from the /pub/homestuff directory relative to the /var/ftp directory (that is, /var/ftp/pub/homestuff). The second line says that the system's /etc/hosts and /etc/inittab files cannot be retrieved. When no path name is indicated, as in the third line, no files that match the names shown can be downloaded, regardless of where they reside in the file system.
If you have prevented a group of files from being retrieved using the noretrieve parameter, you can selectively allow certain files and directories to be retrieved using the all-retrieve parameter. Here's an example:
all-retrieve relative class=world /pub/homestuff/publicfile.txt
Although you restricted download from the /pub/homestuff directory in a previous example, you now allow the download of /pub/homestuff/publicfile.txt to the world class of users.
Even after you have allowed a user or class of users permission to upload files to your FTP server, you still have a lot of control over different aspects of writing and changing files. Each of these permission capabilities can be turned on or off for anonymous, guest, or real users. Or you can turn them on or off for a specific class of users. Below are a few examples. By default, all these services are turned on when a user has upload capabilities (that is, the capability to write to an FTP server).
Remember that Red Hat Linux ownership permission still applies to files and directories, regardless of how these permission capabilities are set. For example, even if you are allowed to use chmod, you still couldn't use it to change permission on someone else's file that was set to 0600.
You can set whether or not a user can change the permissions associated with a file or directory using the chmod parameter. You set chmod to either yes (to allow it) or no (to disallow it). Then you can add a comma-separated list of keywords to choose who is assigned that permission. Here is an example:
chmod yes guest,class=home chmod no anonymous
In this example, all guest users are allowed to use the chmod command in directories to which they are allowed to upload files. An anonymous user, however, is not allowed to use the chmod command to change file and directory permissions.
To give users with file ownership permission to delete files, use the delete parameter as shown:
delete yes class=home delete no anonymous,guest
This example enables deletions for any user in the home class. However, deletions are not allowed for anonymous or guest users who do not belong to that class.
To allow users to overwrite files that currently exist on the FTP server, use the overwrite parameter. Here is an example:
overwrite no anonymous,guest,class=home
In this example, no anonymous users, guest users, or users from the class home are allowed to overwrite files using the FTP service (regardless of the ownership of the files).
To allow a user to rename a file with the FTP service, use the rename parameter. Here is an example:
rename no anonymous,guest
This prevents anonymous or guest users from renaming files using the FTP service, regardless of file ownership.
To enable a user to change the default permission bits assigned to the files and directories the user uploads, use the umask parameter. Here is an example:
umask yes anonymous,guest
This example enables anonymous and guest users to use umask.
You can limit how many users at a time can be logged in to your FTP server based on the class of the user. This is an excellent way of making sure that your local users can access your server, even when there is extraordinary demand from the outside world. (By not defining any limit values, you ensure that connections will not be refused based on there being too many connections.) Here are some examples of limit entries:
limit home 40 Any /etc/ftp.overlimit limit world 120 Any /etc/ftp.overlimit
The first example limits the number of users in the home class (which you assigned your local users to) who can be connected at any one time to 40. The world class of users is limited to 120 simultaneous connections to your server. If the maximum number of connections for a group is reached, a connection from the user is refused and a message that you created in /etc/ftp.overlimit is presented to the user.
The keyword Any indicates that this limitation is in effect on any day. You could, instead, assign the particular limit definition to apply to a particular day or time of day. For example, to set a limit that applies only on weekends, you could do the following:
limit world 140 SaSu /etc/ftp.overlimit
You can also create a limit entry based on time rather than days. To indicate a time period from 10 p.m. to 5 a.m. where access could be extended, you would enter the numbers 2200–0500, instead of SaSu, in the example. If conflicts between limit entries occur, the first matching limit takes precedence.
Downloading is what most people go to FTP sites to do. Typically, the disk area assigned to anonymous users contains documents or software that people can freely download over the network. Some options, however, enable you to limit how much of the computer's resources a user can consume while downloading files. The following sections describe some of them.
Using the file-limit parameter, you can limit the number of data files that a user can transfer in a given session based on user class. Here are some examples:
file-limit total 100 home file-limit in 5 world file-limit out 30 world
The first example allows all users in the home class (which we defined as belonging to your domain) to download and/or upload up to 100 files during an FTP session. To place limits on what the outside world can upload to your computer, the world class is limited to 5 incoming file transfers (uploads) and 30 outgoing transfers (downloads) per session. If no class is indicated, an entry applies to users who don't fall into a class that already has file-limit defined.
Instead of limiting the number of files a user can transfer, you can limit the amount of data that can be transferred by a user. Here are some examples:
byte-limit total 102400000 home byte-limit out 51200000 world byte-limit in 25600000 world
The byte-limit parameter limits the amount of data transferred during a session to a certain number of bytes. The first line shows that the total amount of data that a user in the home class can transfer during a session (both in and out) is 102400000 bytes (about 100MB). Someone assigned to the world class can take (out) only 51200000 bytes of data during an FTP session (about 50MB). A user in the world class can also upload only 25600000 bytes of data during a session (about 25MB).
If a user reaches the end of the byte-limit value during a transfer, the transfer is allowed to complete before the connection is dropped.
You can limit the amount of time that an anonymous or guest user can be connected during an FTP session with the limit-time parameter. There is no way to limit connection time for any real users. By default, anonymous and guest users aren't limited either. For example:
limit-time anonymous 120 limit-time guest 240
In this example, the anonymous user is limited to sessions that are 120 minutes long. A guest user, however, is limited to 240-minute sessions.
You can deny certain host computers from having access to your FTP server. Likewise, you can deny access for anonymous, guest, and real accounts in different ways.
You can deny FTP access to requests coming from specific hosts using the deny parameter. Here's an example:
deny maple,snowbird,oak /etc/ftpdeny.msg
In this example, any user who tries to log in to your FTP service from computers named maple, snowbird, or oak will be denied access to your system. After the user tries to log in, a message from a specified text file (in this example, /etc/ftpdeny.msg) is displayed to the user, and no connection is made. To use this feature, you need to create the text file yourself.
You can use the guestserver parameter to limit which hosts are enabled to access your server using anonymous or guest logins. Here is an example:
In this example, guest and anonymous logins are limited to connections from the hosts named maple, pine, or snowbird. Logins of those types from other computers are rejected. If you were to use the guestserver parameter alone with no host names, all requests for guest and anonymous logins would be denied.
You can deny access to your FTP service to a login from a real user (one who has a user account to your system in /etc/passwd) by adding the name to the /etc/ftpusers file. The main reason for doing this is to prevent people from trying to break into your system through administrative accounts. It may seem counterintuitive to deny access to administrative users, but it prevents potential security breaches. User names that are in this file by default are:
root bin daemon adm lp sync shutdown halt mail news uucp operator games nobody
If these administrative real user accounts were accessible from your FTP server, crackers may be able to break into your system through FTP. This could gain them access to your entire Red Hat Linux system — not just to the /var/ftp directory structure.
You can deny access to your FTP service for users who try to log in as users with particular user or group names or numbers. The deny-uid and deny-gid features can be used instead of the /etc/ftpusers file previously described. The allow-uid and allow-gid features can be used to allow permission to use a service that has been denied in the /etc/ftpusers file.
You can identify users and groups by either numbers or names. If you use numbers, those numbers must be preceded by a percent sign (%). Here are some examples:
deny-gid %-110 deny-uid %-110 allow-uid uucp news
In these examples, all administrative logins and other users up to user id 110 and group id 110 are denied access to your FTP service. The allow-uid line, however, overrides the denial of service for the uucp and news logins.
Once you have configured your FTP server, you are ready to start it up. WU-FTPD is enabled or disabled based on information in the /etc/xinetd.d/wu-ftpd directory. To shut down the WU-FTPD service temporarily, you can use the ftpshut command.
To enable WU-FTPD, which is disabled by default, you have to change the disable = yes entry in the /etc/xinetd.d/wu-ftpd file. Open the file as root user, using any text editor, and change the line to read as follows:
disable = no
Next, you need to restart the xinetd daemon so that the new changes are picked up. You can do that by typing the following as root user:
# /etc/init.d/xinetd restart Stopping xinetd: [ OK ] Starting xinetd: [ OK ]
Now try using the ftp command or other FTP client to connect to your WU-FTPD server.
The ftpshut command shuts down the FTP service. Any users who are currently connected to the FTP service are disconnected. When they type FTP commands, they will see a message such as "FTP server shut down —- please try again later" or simply "Not connected."
With the ftpshut command, you can either shut down the server immediately or set it to shut down in the future. To shut down the service immediately, type the following:
# ftpshut now
You can set the server to shut down at a specific time by either adding the number of minutes from now that you want the server to shut down or by entering a particular time in the future. Here are some examples:
# ftpshut 20:18 # ftpshut -l 20 -d 3
In the first example, the server is set to shut down at 20:18 (or 8:18 p.m. on a 12-hour clock). In the second example, the -l option specifies the number of minutes left before the server will be shut down (in this example, 20 minutes). The -d option specifies the number of minutes before the FTP service shuts down that users are disconnected from the server. (If no -d option is specified, users are disconnected five minutes before the server shuts down.)
To be less antisocial about shutting down your FTP service, it's nice to send a warning message to let users know that FTP is going down. Here's an example of how to send a shutdown-warning message when you shut down your FTP server:
ftpshut 20:15 "FTP will go down soon. Finish and disconnect."
After ftpshut is run, it creates a file called shutmsg in both the /etc and /var/ftp/etc directories. When your FTP server shuts down, it stays down until these files are removed. So, to restart your FTP server, all you have to do is the following (as root user):
# rm /etc/shutmsg /var/ftp/etc/shutmsg
The above command removes the files. At this point, users will immediately be able to reconnect to your FTP server. Another command you could use to restart your FTP server is the ftprestart command.
Whenever you set up a service from your computer for general consumption, it's a good idea to keep an eye on it. You can use many of the same techniques that you use to monitor your computer's file system in general to monitor your FTP server (for example, various tools for watching disk space consumption). To track the activities of users on your FTP system, however, FTP provides logging features.
When the ftpd daemon is enabled (from an entry in the /etc/xinetd.d/wu-ftpd file), the -l option is added to the command line. This option causes each FTP session to be logged to the syslog facility. As a result, messages that provide some of the following information about FTP activities will be sent to your /var/log/messages file:
User name, host name, and IP address of the user trying to connect to your FTP service.
The user name logged in under (anonymous, and so on).
How and when the FTP service was disconnected for the user.
You can use this information to monitor the activities on your server. For example, if someone is trying to break into your system, you can see multiple failed login attempts. You can also see if you are getting more anonymous FTP requests than you can handle.
If there are file transfers during the session, they are logged to the /var/log/xferlog. In that file you can see both incoming and outgoing file transfers. Here are two examples of log entries in the /var/log/xferlog file:
Sat Aug 23 21:26:20 2003 1 oak 1625 /in/log b _ i r mike ftp 1 root c Sat Aug 23 21:27:23 2003 1 pine 124 /pub/a.txt a o r mike ftp 1 root c
In the first example, the transfer occurred at 21:26:20 on Saturday, August 23, 2003. The transfer time was only one (1) second. The remote host name is oak, and the size of the file is 1625 bytes. The transferred file was named log and was put in the /in directory on the FTP server. The type of transfer was binary (b). The underscore ( _ ) indicates that no special action (such as file compression or decompression) was taken. The i shows that it was an incoming transfer. The user was a real user (r) named mike. The service invoked was ftp. Authentication was done using RFC931 authentication (1). The user id returned by the authentication method was root. The c indicates that the transfer was completed.
In the second example, several items are of interest. The remote computer name was pine. The file was transferred using an ASCII transfer method (a). The file /pub/a.txt was transferred from the file server (o).