AllowOverride none </Directory>

...............................................................................................

All Web sites and all directories on this server have default Options of AuthConfig and Limit, and do not permit any of the AllowOverride settings. To override these for a virtual host, use the Options and AllowOverride statements within the virtual host description. (You can use any option that is valid in the main server configuration on a virtual host.)

By overriding these options, you can set server access on a client−by−client basis; for example, you could allow server−side includes on one virtual host, but not on others. The following virtual host has its own Options settings that override the server's default settings:

...............................................................................................

<VirtualHost 209.69.178.18> ServerName data.AbsoluteBSD.com DocumentRoot /home/mwlucas/data Options Limit IncludesNOEXEC </VirtualHost>

...............................................................................................

Now that you can configure virtual hosts for clients, they'll want to upload files (typically via FTP).

.NET on FreeBSD

.NET is a technology that is expected to be popular for writing Web−based programs. (Technically, Microsoft's official .NET platform is .NET Server.)

.NET is an implementation of the ECMA Common Language Infrastructure (CLI), a standard created and promoted by Microsoft. Microsoft has released a separate implementation of the CLI that runs on both FreeBSD and Windows 2000, called the Shared Source Common Language Infrastructure (SSCLI), and code−named Rotor. Presumably, the Microsoft .NET Server version integrates more tightly with the Microsoft world than this shared−source version does.

As this book is being published, Rotor is available in a beta release. I expect it to be updated regularly. This section discusses the basics of installing the SSCLI on FreeBSD.

Installing the SSCLI

The SSCLI is available in /usr/ports/lang/cli. At this time, the port only builds properly if you are using /bin/sh as your shell. If you're using another shell, change to /bin/sh to install this port. Then run these commands:

...............................................................................................

#cd /usr/ports/lang/cli

#exec /bin/sh

#export SHELL=/bin/sh

#make install

...............................................................................................

359

This will download and compile the software, but it won't install because Microsoft allows use of this software only under its license terms. When the software finishes compiling, it will warn you that you must read the license agreement, which you'll find in /usr/ports/lang/cli/work/sscli/license.txt. Read it, and be sure you understand it. Microsoft habitually licenses its software under terms that may be uncomfortable for people accustomed to FreeBSD, and changes those terms as it sees fit.

Once you have read the license, run this command:

...............................................................................................

# make −DI_AGREE_TO_LICENSE_TERMS install

...............................................................................................

Note I recommend not running make clean as part of the install. The Rotor toolkit includes a lot of source code, documentation, and examples, which you might well need in order to use this experimental software. A make clean would remove most of it.

The preceding command will install the SSCLI under /usr/local, in a subdirectory that will depend on the version of Rotor you are installing. (The first beta version installed in /usr/local/cli−20020326.) Add this directory to your $PATH, and you're ready to run Rotor programs.

FTP

FTP, the file transfer protocol, is the classic protocol for moving files from one computer to another over the Internet, and most of your users will want to use it to transfer files to or from servers. Like many other older protocols, FTP has not aged well. You'll find a wide variety of issues with it, and over the years, fixes for these problems have been bolted onto the protocol. While FreeBSD makes handling FTP as easy as possible, you'll still need to do some work with it to keep it chugging along.

FTP Security

Because FTP transmits passwords and usernames in clear text, anyone with a packet sniffer on the local network will be able to capture FTP usernames and passwords. Nobody except the network administrator should have a packet sniffer on your network, so you're probably all right for regular users. Your users will probably insist on having FTP access, however.

Do not transmit sysadmin passwords over the network in clear text, however. Instead, use scp(1) to upload and download files to and from your account. (We'll look at scp at the end of this chapter.) Scp isn't too popular (yet), and the encryption it uses can overload a server if you have a great number of connections open.

The FTP Client

FTP is a fairly complex protocol, and, unlike POP3 or SMTP, can't be easily tested. You must use an FTP client to use FTP, and FreeBSD includes one. To connect to a host, just type ftp and the hostname.

360

...............................................................................................

# ftp magpire.blackhelicopters.org

Connected to magpire.blackhelicopters.org.

220 magpire.blackhelicopters.org FTP server (Version 6.00LS) ready. Name (magpire:mwlucas):

...............................................................................................

The client sends your local username as a default, but you can enter a different username if you need to. It will then ask you for your password:

...............................................................................................

331 Password required for mwlucas. Password:

230 User mwlucas logged in, access restrictions apply. Remote system type is UNIX.

Using binary mode to transfer files. ftp>

...............................................................................................

If everything goes as planned, you should now be logged into the remote server in a shell almost like a command shell. You cannot execute commands, but you can move around and view files using standard UNIX commands, such as ls and cd.

Downloading with FTP

Use the get command to copy a file from the remote server to your local server, like so:

...............................................................................................

ftp> get .cshrc
local: .cshrc remote: .cshrc
150	Opening BINARY mode data connection for '.cshrc' (767 bytes).
100% |**************************************************| 767		00:00 ETA
226	Transfer complete.
767	bytes received in 0.00 seconds (173.42 KB/s)
ftp>

...............................................................................................

As you watch, your FTP client will open a connection to move the file over. You'll see a line of asterisks move across your screen as the file is moved, and an ETA line that will update with the length of time remaining in the download. When the file transfer is finished, you'll get a notification, the size of the file moved, and an FTP prompt.

Uploading with FTP

Use the put command to copy a file from your local system to the remote system. Its output looks much like the example above, so I won't repeat that here.

Moving Multiple Files

Use the mget and mput commands to move multiple files at once. For example, here's how you'd move all of the files with .txt extensions in your current directory:

...............................................................................................

361

ftp> mget *.txt

...............................................................................................

Disabling the Prompts

By default, ftp will prompt you to confirm that you really want to move each file. But if you're pulling down a directory with dozens or hundreds of files, you almost certainly don't want to be asked to confirm each one. You can turn the verification on and off with the prompt command.

...............................................................................................

ftp> prompt

Interactive mode off.

ftp> mget *

...............................................................................................

In this example, we are downloading all the files in the current directory without asking for verification for each one.

Binary and ASCII Transfers

The difference between binary and ASCII transfers is one big source of confusion, resulting from the different handling of the return and newline characters. DOS systems and UNIX systems have long disagreed on how to mark the end of a line, as you may have seen when moving files between the two. If you do an Internet search, You'll find many documents describing the issue in all its painful detail, and many articles from one side denouncing the other for being Just Plain Wrong. All you need to know is how to live with the problems they cause.

UNIX systems default to using binary transfers, while Windows−based systems default to using ASCII. You can tell an FTP server to use binary transfers with the bin command, and ASCII with the a command.

Basically, you can successfully transfer both binary and ASCII files in binary mode. You can transfer ASCII files with ASCII mode, but binary files transferred in ASCII mode will be corrupted. Binary mode works for everything, so use it.

Viewing Files

Finally, we have the question of looking at files. The less command displays the contents of a file, one page at a time, which allows you to scan things, such as index and readme files to learn exactly what you need to download.

The FTP Server

Now that you know how to do basic file transfer with FTP, let's look at how to provide basic FTP services.

By default, FreeBSD runs the FTP daemon from inetd. Most systems don't get many FTP requests, and inetd can easily handle the few requests that do arrive. If you won't be supporting more than a few simultaneous FTP sessions, the default settings will work well.

362

However, if you're running a high−capacity FTP server and will be servicing dozens, hundreds, or even thousands of simultaneous connections, running FTP from inetd will just add additional system overhead. You'll run into inetd's bottlenecks and rate−limiting, and find that your users are unhappy.

To solve these problems, you need to pull ftpd out of inetd. Set up ftpd to run in standalone mode, where it is permanently listening to the network and handling requests itself.

Setting Up Standalone Ftpd

To run ftpd in standalone mode, first disable inetd's ftpd by commenting out the appropriate line in /etc/inetd.conf. We do this because only one program can run on a TCP port at one time. Since inetd starts before any local programs, it would tie up the FTP TCP ports; your standalone ftpd would not be able to run.

Next, you need to tell ftpd it is running in standalone mode, by using the −D flag. You can do so by starting ftpd automatically at boot with a script in /usr/local/etc/rc.d, just like other standalone or add−on programs. A sample script would look like this:

...............................................................................................

#!/bin/sh

/usr/libexec/ftpd −D

...............................................................................................

Users can then make FTP connections to transfer files. That's really it! Everything else is tweaking your FTP server.

Logging Ftpd Usage

The ftp daemon has a variety of logging functions. If you specify −l once (the default in /etc/inetd.conf), ftpd will log all successful and unsuccessful login attempts. If you specify it twice, ftpd will log all FTP activities: downloads, uploads, directory creation and removal, and any other file alterations.

Add these options to the end of the ftpd command line in your startup script. If you wanted ftpd to run in standalone mode, and to log all FTP activity, your script would include the following line:

...............................................................................................

/usr/libexec/ftpd −D −ll

...............................................................................................

Disabling Server Changes

You might want to prevent users from uploading files or changing the server's filesystem in any way. This is good for a server that only provides downloads, such as a corporate document server or a mirror site. To do so, use the −r flag.

363

Caging Users

One common concern with FTP is that it can allow users to download arbitrary files on the system, and that FTP passwords can be sniffed. You don't want your system compromised because some doofus user handed out his password!

To prevent users from digging around on your system, you can cage (or chroot) them into their home directories. When caged, a user can FTP into the system and upload, download, or change files in his home directory (or its subdirectories) only. If the user tries to visit a directory outside of the home directory, however, the system will not allow it. This is much like a small jail, which we discussed in Chapter 8.

Chroot is useful for Web servers that have multiple clients on one machine. After all, the users only need to see their own directory, not anyone else's.

Chrooting Users

To cage a user, add the username(s) to the file /etc/ftpchroot. Each time a user logs in with ftp, the user's account is checked against the contents of /etc/ftpchroot. If the username appears there, the user is locked into her home directory. Caged users have complete control in their home directory, and can create however many subdirectories and store as many files as their disk space allows; they simply cannot leave their home directory and go exploring the system.

Chrooting Groups of Users

Users who are members of a group listed in /etc/ftpchroot are caged as well. (Group names have an at sign (@) in front of them.) You can list a group in /etc/login.access and disallow SSH logins, and all users in that group will be pretty tightly chained.

For example, suppose we have a system with two junior system administrators, Phil and Chris. These administrators should be loading files only into their home directories. Similarly, we have a group of clients who maintain their own Web sites. These clients are all in the webclients group, listed in /etc/group. To chroot all of these users, set up /etc/ftpchroot like this:

...............................................................................................

phil

chris

@webclients

...............................................................................................

Disallowing FTP Access

The name of the /etc/ftpusers file is rather deceptive; rather than containing a list of allowed users, it contains a list of users who are not allowed to log in with FTP. FreeBSD's default /etc/ftpusers lists a variety of system accounts, such as root and nobody.

You can list groups in this file by prefacing them with the @ symbol. For example, you could disallow members of the wheel group from using FTP. (People who can use the root password should not be transmitting their passwords in clear text!)

364

Connection Messages

When a client first makes an FTP connection, the contents of /etc/ftpwelcome are displayed. You can put legal warnings, capacity statements, obscenities, and threats, or whatever else you like in here, and users will see it before they even get a login prompt. This is an excellent place to put an "unauthorized use disallowed" message, which is actually admissible in court if someone hijacks your services for illegal purposes.

Welcome Messages

Once a user has logged in, the /etc/ftpmotd file is displayed. Terms of usage are commonly displayed here.

Setting Up Anonymous FTP Servers

Anonymous FTP sites are a popular way to provide files and documents to the Internet at large. Anonymous FTP sites are frequently hacked, however. While FreeBSD's ftpd is quite robust and secure, you should still take some basic precautions and set your server up properly to avoid problems. Here are some recommendations:

1.If at all possible, set ftpd to run read−only by starting it with the −r flag.

2.Use ftpd's −S flag to log all anonymous FTP activity to the file /var/log/ftpd. The file must exist before ftpd will start the log, so you need to run touch /var/log/ftpd to create it.

3.Create a user called ftp. This user's home directory will be the root of the anonymous FTP directory, and all files must be placed in this directory.

4.Create the directory /home/ftp/pub for the traditional pub folder in an FTP server. If you want users to be able to upload files, make this directory mode 777 (chmod 777 pub). If it's read−only, make this directory mode 444. This will give you basic anonymous FTP.

A Warning on Anonymous FTP

Allowing just anyone to upload files to your server may seem like a friendly activity. You might have bandwidth to spare, and you might desire to provide a public service. In an ideal world, this would be lovely.

If you allow anyone to store data on your system, however, people can use your FTP server to store illegal software, child porn, or terrorist data. To make it harder for you to find, they can create hidden directories or disguise the data. Even if you go looking through all the crud people will upload, if you see a file labeled FreeBSD FTPd configuration.txt, you're probably going to ignore it; you can't be expected to check every single file. It's not your fault that that file is actually an MPEG of the Gerbil Liberation Front training for their secret mission to cram the president into a wheel and make him run for his life.

NoteFreeBSD includes a variety of FTP servers in /usr/ports/ftp, many of which have nifty features, good−looking Web sites, and devoted user communities. Check the freebsd−security mailing list archives for a discussion of a server before you install it, however, because many popular

365

FTP servers have a history of bad security holes. For example, one popular FTP server has the unofficial tagline of "providing remote root since 1994." Look around, and be choosy.

366