Questions and Answers

Bjorn Satdeva

I have received several questions about how to get access to the System Administration Archive at sysadmin.com. As with any other ftp archive, you will first need Internet access. Without it, there is not much that can be done (I have gotten several requests for access by email and will probably make that available later in 1996, but for now there is plenty of work just building the archive).

To download a file, ftp to ftp.sysadmin.com and login as "ftp." You will be prompted for a password; just use your email address. You will then be given access to the archive.

By the way, if you are making a lot of anonymous ftp requests, you might like the ncftp program. This program will automatically login for you, so it will appear that you get in without having to go through the authentication process. If you are interested in checking out this program, you can get it from:

ftp://ftp.sysadmin.com/pub/admin/networking/clients/ncftp

Hot off various security mailing lists is information about a big security problem in Microsoft Windows 95. Although this is not strictly a UNIX issue, it is something that many UNIX system administrators may need to deal with. This security issue concerns the .pwl files that are protected by RC4 with 32-bit keys. Not only are the keys short, and therefore breakable by brute force, but the implementation is also lacking in quality. These files, therefore, can be decrypted in a trivial amount of time, using a program that is being circulated on the Internet.

The following example illustrates a problem I encountered substituting variables into quotations:

#! /bin/sh
for file in 'ls *'
do
wwwstat -d 'Nov' -n '/~$file' > $file.html
done

Outside the quotations, the substitution works correctly. Inside the quotations, however, the shell script views $file as "$file" instead of the variable it represents. Any suggestions as to how to make this substitution?

By definition, shell variables will not be expanded inside single quotes. If you use double quotes instead, the script should work just fine:

#! /bin/sh
for file in 'ls *'
do
wwwstat -d 'Nov' -n "/~$file" > $file.html
done

We need to allow some of our users to execute some specific programs as root. Is there a way I can do this without having to give them the root password?

Tom Christensen wrote a nice utility, called op, however, at the time, his company would not allow him to distribute the program. Fortunately for the rest of us, Dave Koblas did a reimplementation of the program. For some reason, the program has never gotten the widespread use that it deserves, possibly because of limited awareness of it. You can get the program from the System Administration Archive on ftp.sys.admin.com. The URL is:

ftp://ftp.sysadmin.com/pub/admin/tools/hosts/op/op-1.1.tar.gz

With op you can delegate root authority to some of your users, while ensuring that they can only execute the commands with the arguments that are required. op uses regular expressions to determine which commands should be allowed. You could, for example, delegate authority to users to perform shutdowns, while enforcing a 10-minute warning.

We want to set up an anonymous ftp server at our site. How would you recommend we do this?

Setting up an anonymous ftp server is fairly straightforward, however you need to be careful not to breach the security of the machine when you start it up. All of the software you will need is available from the Internet, and one of the pieces you will need is the ftp server itself. In my opinion, the best server around these days is one from Washington University, known as wu-ftpd. You will need version 2.4, and you can get it from:

ftp://ftp.sysadmin.com/pub/admin/networking/servers/wu-ftpd

To protect the server as much as possible, you will need the chrootuid program:

ftp://ftp/sysadmin.com/pub/admin/security/hosts/chrootuid

If your OS uses dynamically loaded libraries, it would be a good idea to statically link the above programs. You should also get the sources for the ls program and statically link that, too.

Now, you are about ready to set up your ftp server. Create a home directory where the ftp server should live (e.g., /var/ftp). If you are planning to allow people to upload files to your system, you should make this directory a separate filesystem (otherwise Internet users could fill up your filesystem and disrupt more important services). This directory will be the chroot point for chrootuid later.

Next, you need to create subdirectories for the ftp server. As the server will be running chrooted, you might need more files than mentioned here depending on your specific operating system. The subdirectories you will need are:

bin    for executables
etc    for configuration files
data   for your ftp archive

The bin directory needs to contain the executable of the ftp server itself (ftpd). It should be owned by root, and be executable by user and group, but neither readable nor writable. A long list of that directory should look somewhat like this:

---x--x---  1 root  wheel  200704 Oct 17  1995 ftpd

(Note: the ls program does not go in this bin directory).

The etc directory must contain a version of the password file (but absolutely not the real one). You will need entries for ftp, root, and nobody, each of which should have an asterisk (*) in the password field. You can add users who have privileges beyond the anonymous ftp account, but remember that you run the same risks here for password sniffing as with any other reusable password authentication. The password file then will look somewhat like this:

root:*:0:0:System Administrator:/:
ftp:*:4:7:Anonymous FTP:/data:
nobody:*:65534:32766:Unknown User:/nowhere:/dev/null

It is important which directory you specify as home directory for the user ftp, because the server will do a chroot to that directory before allowing access. It might seem to be overkill that I do a chroot with chrootuid before starting the server, when the server also does a chroot. Remember, however, that the server does a lot of work (like reading configuration files) before it does its chroot, and it is possible to break out of the server and get root access on the machine before that chroot takes place. Using the chrootuid is just another example of the "belt and suspender" approach I like to use when building firewalls.

You will also need to create a group file of similar content and a resolver configuration file for the nameserver, because ftpd cannot get to the real one.

The ftpd configuration files also go into the etc directory. I will discuss these files below. You may need a number of other files to satisfy the requirement from ftpd. To find out what files a program expects to be able to access, you can look directly into the executable image:

strings ftpd | grep '^/' | sort -u

This will give you the complete list of required files.

Now, you need to add the configuration files for the ftp server. The most important is ftpaccess, which is used to configure much of the server's behavior. A sample file is in Figure 1.

Next, you must put files into the data directory. It is common practice to have a pub directory in which all files that can be downloaded must reside. All these files must be owned by root and wheel (or the equivalent thereof), but should not be writable by user ftp or nobody. I like to execute the following from cron on a regular basis to ensure that this is really enforced:

find /var/ftp -perm -002 -print | xargs ls -ld | grep -v '^lrwxrwxrwx'

The grep in the end is to ignore symbolic links.

The last thing you need to do is add the executables and configuration files used by the server after it has done a chroot. The bin directory (/var/ftp/data/bin in this case) must contain the ls program and any other executable you would need, such as gzip or tar. The etc directory (/var/ftp/data/etc in this case) should contain the welcome message and any other necessary generic messages.

To start the server, you edit the inetd.conf file by adding an ftp entry like this:

ftp  stream  tcp   nowait  root  /usr/local/lib/ftpd ftpd

If you like to run the daemon under Wietse Venema's TCP/IP daemon wrapper, use the following entry:

ftp  stream  tcp   nowait  root  /some/where/tcpd/usr/local/lib/ftpd

On some systems, you may need to omit the root field, because all daemons are executed as root by default.

The file /usr/local/lib/ftpd should be a shell script that is maintained by the superuser, because inetd runs the script with root privilege. This script runs the real ftp daemon as an unprivileged process in a restricted environment.

#!/bin/sh
exec /usr/local/bin/chrootuid /var/ftp nobody /bin/ftpd

I am a new system administrator, and am trying to learn what I need as fast as possible. What books would you recommend to help me?

Your starting point should be Unix System Administration Handbook, 2nd Ed. by Evi Nemeth, Garth Snyder, Scott Seebass, and Trent R. Hein (Prentice Hall). This book covers most areas of system administration and will give you much of the general background. For more in-depth information, you could choose a more specific book from O'Reilly & Associates. DNS and Bind by Paul Albitz and Crickett Liu; Sendmail by Bryan Costales, with Eric Allman and Neil Rickert; TCP/IP Network Administration by Craig Hunt; and Managing NFS and NIS by Hal Stern would give you a good beginning technical understanding of the job.

I have been looking at your ftp site, and there is a lot of material there. Is there any way you can give us pointers to which software is of the greatest value?

Yes, there is a lot of material; it is approaching 1 Mb of sources and information and is still growing. To give the pointers you ask for would require a book, however, I do teach a one day course during which I go over some of the most useful programs. The next time I will be teaching that course is at the SANS Conference in the spring. In this column, I can choose one program each month and go into some details. I will start this right away, and call it the tool of the month; this month I have chosen nslint.

nslint performs consistency checks on domain nameserver configuration. It reads the server configuration files, and reports on any nameserver record that is malformed, such as PTR records in which names are missing a trailing dot, and A records with matching PTR records (and vice versa). I routinely run this program after updating a domain nameserver, as it often will highlight problems, allowing them to be fixed immediately.

If you are maintaining one or more domain nameservers, you probably find this tool very useful. It can be obtained from the System Administration Archive, at the following URL:

ftp://ftp.sysadmin.com/pub/admin/tools/networking/nslint/nslint.tar.gz

The program was written and is currently maintained by Craig Leres (leres@ee.lbl.gov). The current release is 1.5a3.

About the Author

Bjorn Satdeva is the president of /sys/admin, inc., a consulting firm which specializes in large installation system administration. Bjorn is also co-founder and former president of Bay-LISA, a San Francisco Bay Area userOs group for system administrators of large sites. Bjorn can be contacted at /sys/admin, inc., 2787 Moorpark Ave., San Jose, CA 95128; electronically at bjorn@sysadmin.com; or by phone at (408) 241-3111.