Click on our Sponsors to help Support SunWorld
Security: Pete's Wicked World by Peter Galvin

Web server wiles, Part one

Secure your Solaris Web server from the perils of the Void

SunWorld
April  1996
[Next story]
[Table of Contents]
[Search]
Subscribe to SunWorld, it's free!
Abstract
You have installed a firewall to protect your corporate networks. You have -- or want to have -- a Web server that is publicly accessible. That Web server must live outside your firewall or you must grant access to it through your firewall. Either way, it is exposed to the untrusted, villainous masses. You need to take extra precautions to protect the machine because it's available to the world and a likely target for an attack. This month we cover the first five steps to building a secure Web server.

Also in Pete's Wicked World this month: information on Java and JavaScript vulnerabilities, a problem with SunSoft's demo disks, and a pointer to an interesting discussion about Trojan-horse Internet programs. In the bookstore this month is Sun's security alert mailing list. (3,800 words)


Mail this
article to
a friend
By Peter Galvin & Hal Pomeranz

There are ten steps to installing a "secure" Web server. But before we get to them, first consider what we mean by "secure." Any machine that is publically accessible is necessarily insecure. By putting it directly on the Internet you've already opened the front door and allowed anyone to come in and have a look. It is possible to guard the door and be sure the visitors hang out in only one room though. By installing the operating system carefully, adding tools, and adding monitoring software, your Web server can be much safer than one that uses a default installation.

Let's step into your shoes. Your marketing department (or even worse, the president of your organization -- let's call him Mac) has asked you to make company information available via the Web or anonymous FTP. You are worried about some system cracker using your machine to supply pirated software, or worse, putting up pictures of the CEO's naked backside on your home page.

How secure does your system have to be? The answer is, "very secure." Any number of toolkits exist that allow total amateurs to become holy terrors. The good news is that if you can beat the popular intrusion toolkits, 90 percent of the bad guys will go bother somebody else who's less secure.

While the following techniques can make a Solaris-based system very secure, they have to be combined with a strong network architecture utilizing firewalls or filtering routers (there's no point in controlling access by IP address if crackers can send you packets with spoofed addresses). Such a strong architecture can only truly exist when combined with a comprehensive security policy covering your entire organization.

Furthermore, no system is ever perfectly secure. The extra services (Web servers and anonymous FTP) that you run on the machine will always impact the overall security of the system. Don't be tempted to install other software not listed in these instructions. This machine is supposed to be secure, not convenient to administer.

Step 1: Getting the hardware together

When you begin to build your secure server, it must not be connected to any network. Theoretically, some cracker could get in and drop back doors onto your system while you are in the process of securing it. There are documented cases of people trying to break into machines within five minutes of the machine being connected to the Internet.

You will need a CD-ROM drive to do the install and a tape or floppy drive for loading binaries and other files you created on other machines (no network, remember?). These instructions are appropriate for Solaris 2.4 on SPARC machines. If you use a different OS version, the security of the resulting system may vary widely. Solaris 2.5 seems to be more secure than 2.4, so these directions should work for it, as well.

Advertisements

Step 2: Installing the OS

As a general-purpose operating system, Solaris is quite flexible and contains many conveniences that make your work easier. Unfortunately, all of this extra functionality also makes it easier for potential crackers to gain access to your system. When attempting to create a secure system, the best plan is to start with the simplest OS you can and then add packages one-by-one on an "as-needed" basis. A limited OS configuration also boots and runs faster and is less prone to crashing than a feature-rich version.

Under the Solaris install program, the most limited version of the OS you can select is the Core SPARC installation cluster. In fact, even this cluster has too many features, and in later sections I'll show you how to turn off the dangerous ones. To begin with, however, this cluster is what you should first install on your secure server. After you have selected Core SPARC in the Sun installation screens, you will want to select Customize and add the Terminal Information cluster which gives you support for commonly used terminal emulators (such as xterm and others).

One of the advantages of the Core SPARC cluster is that it requires much less disk space than most types of Solaris installs. The following partition table is appropriate for machines loaded with the Core SPARC cluster: 

s0:	/	 	 32 megabytes
s1:	swap		256 megabytes
s2:	overlap
s3:
s4:	/usr		 50 megabytes
s5:	/var		150 megabytes
s6:	/local		??? megabytes (rest of the drive)
s7:

When was the last time you saw a 50 megabyte /usr partition? /var is large to allow for keeping extra logging and auditing information. Size swap as appropriate for your hardware, but extra swap helps prevent "denial of service" type attacks where the bad guys try and trigger too many processes on your system. Since most systems come with one and two-gigabyte drives these days, you should have at least half a gigabyte of space left for Web pages, anonymous FTP areas, etc.

Now, using some other machine, ftp to sunsolve.sun.com:/pub/patches and download the latest "recommended" (read: mandatory) patch cluster for Solaris 2.4 (2.4_Recommended.tar.Z). Put this tarfile on a tape, move it over to your secure server, and install the patches. Some patches will not be installed because the software they fix is not included in the Core SPARC cluster. Solaris 2.5 does not currently have any "recommended" patches, so if you're this version you can ignore this step.

Step 3: Strip down your OS

Under Solaris, you control what processes are started at boot time by adding and removing files in /etc/init.d and /etc/rc[S0-3].d (the files in /etc/rc[S0-3].d being links to files in /etc/init.d). Many of these startup scripts run processes that you absolutely do not want running on your secure server: NFS is a prime example.

Unless you are sure about the functionality of each startup script, take our advice and remove everything from /etc/init.d except the following files: 

MOUNTFSYS     cron        inetsvc       standardmounts  utmpd
acct          devlinks    perf          sysetup
audit         drvconfig   rootusr       syslog
buildmnttab   inetinit    rtvc-config   ufs_quota

Next remove every file from /etc/rc0.d, /etc/rc1.d, and /etc/rc3.d. Also remove any files in /etc/rcS.d and /etc/rc2.d that no longer have corresponding files in /etc/init.d.

Now edit /etc/init.d/inetinit and add the following lines near the top of the file: 

ndd -set /dev/ip ip_forward_directed_broadcasts 0
ndd -set /dev/ip ip_forward_src_routed 0
ndd -set /dev/ip ip_forwarding 0

These lines turn off a feature called IP forwarding. Nearly any machine that uses IP-based networking is capable of being a router, which means the bad guys could route packets through your machine to machines on your internal network or other secure machines that might trust the machine you are building. Turning off IP forwarding disables this feature.

Finally, add a new script called /etc/init.d/tmpfix: 

#!/bin/sh
#ident  "@(#)tmpfix 1.0    95/08/14"
 
if [ -d /tmp ]
then
	/usr/bin/chmod 1777 /tmp
	/usr/bin/chgrp sys /tmp
	/usr/bin/chown sys /tmp
fi

and then ln -s /etc/init.d/tmpfix /etc/rc2.d/S79tmpfix so the script is invoked at boot time. This script prevents an attack that would allow a system cracker to get superuser access on your machine. (See "Re-tooling" SunWorld Online October 1995.)

When you are done, reboot your machine. When the machine comes back up, the output of ps -ef should look like this: 

     UID   PID  PPID  C    STIME TTY      TIME COMD
    root     0     0 55   Mar 04 ?        0:01 sched
    root     1     0 80   Mar 04 ?       22:44 /etc/init -
    root     2     0 80   Mar 04 ?        0:01 pageout
    root     3     0 80   Mar 04 ?       33:18 fsflush
    root  9104     1 17   Mar 13 console  0:00 /usr/lib/saf/ttymon -g -h -p myhost console login:  -T sun -d /dev/console -l co
    root    92     1 80   Mar 04 ?        5:15 /usr/sbin/inetd -s
    root   104     1 80   Mar 04 ?       21:53 /usr/sbin/syslogd
    root   114     1 80   Mar 04 ?        0:11 /usr/sbin/cron
    root   134     1 80   Mar 04 ?        0:01 /usr/lib/utmpd
    root   198     1 25   Mar 04 ?        0:00 /usr/lib/saf/sac -t 300
    root   201   198 33   Mar 04 ?        0:00 /usr/lib/saf/ttymon
    root  6915  6844  8 13:03:32 console  0:00 ps -ef
    root  6844  6842 39 13:02:04 console  0:00 -sh

If you followed the above steps, you should see no other processes running on the system.

You will note that the /usr/lib/sendmail daemon is not running on the system: this is a feature. Processes that need to send mail off the system can and will invoke sendmail directly (possibly via some other mail user agent such as mailx), but you do not have to run a sendmail daemon that listens on port 25 and processes the mail queue immediately. You should add the following to root's crontab file: 

0 * * * * /usr/lib/sendmail -q

This entry will invoke sendmail every hour to process any queued mail.

Step 4: Install third-party software

You will need three pieces of software to help secure your system and allow you to do safe administration of the machine over the network. Because there should be no compiler on your secure server, you will have to build these packages on some other machine and bring them onto the new machine you are building via a tape or floppy disk.

The first package is the TCP Wrappers package written by Wietse Venema. Wietse's source code produces a small binary called tcpd that can be used to control access to services (such as telnet and ftp) that are started out of /etc/inetd.conf. Access control can be performed on IP address, domain name, and a raft of other parameters, and tcpd can raise alarms via syslog or e-mail if unauthorized connection attempts are made.

Next you will need the S/Key package (part of the logdaemon toolset). S/Key is a one-time-only password mechanism. Instead of typing in your password over the network, the S/Key software will send you a challenge string, and you will compute a response on your local machine using the challenge and a secret password that you have memorized. If you send the proper response back, the S/Key software gives you access to the machine but the response you gave will never again be valid for getting access to the machine. This means that if somebody is using a packet sniffer, they cannot capture the response and use it to break into your machine. The S/Key software also comes with a version of the su command that uses S/Key challenge/response to grant superuser access safely over the network.

If you plan to allow ftp access to your secure server (whether anonymous or for administrative access), you need to get a copy of the WU-Archive ftp daemon. You must get version 2.4 or later since previous versions have major security holes. If you are going to grant administrative ftp access (as opposed to only anonymous ftp), you must hack S/Key support into the ftp daemon binary. In the Crimelabs S/Key distribution you will find an skey/misc/ftpd.c file that demonstrates how to make a previous version of the WU-Archive ftp daemon support S/Key. You will have to make the analogous changes to the v2.4 wu-ftpd source. You may also want to read the wu-ftp FAQ

We will go over specific configuration of each package in later sections, so for now just compile and install the binaries (tcpd, wu-ftpd, and keyinit, keysu, and keysh from the S/Key software) in /usr/local/bin. When compiling wu-ftpd you will have to specify configuration and logging directories: we recommend you put the configuration directory somewhere under /etc and the logfiles under /var (so they have plenty of room to grow).

Step 5: Network access to your system

When your secure machine eventually gets into position on the network, you will probably want to be able to use telnet and ftp to access the machine. Note that you do not have to enable these services on your machine, making your machine that much more secure, but that means you will always have to log in on the console and move files on and off the machine using tape or floppy disk.

The telnet and ftp daemons are started by the inetd process. inetd's configuration file, /etc/inet/inetd.conf, contains many other services besides telnet and ftp, so it is best to simply remove this file and create a new one containing only the following lines: 

ftp stream tcp nowait root /usr/local/bin/tcpd /usr/local/bin/wu-ftpd
telnet stream tcp nowait root /usr/local/bin/tcpd /usr/sbin/in.telnetd

Note that we are using tcpd to control access to both of these services and are using the wu-ftpd binary instead of the ftp server that comes with Solaris. If you do not want to allow anybody to telnet or ftp to you system, then simply remove the appropriate line from inetd.conf, or remove the file altogether and inetd will not even be started at boot time.

Access control for tcpd is configured using the /etc/hosts.allow and /etc/hosts.deny files. tcpd looks at hosts.allow first, so you can permit a few machines to have telnet or ftp access and then deny access to everybody else in hosts.deny (this is often called a "default deny" policy). Here is a sample hosts.allow file: 

ALL: 172.16.3.0/255.255.255.0

This would allow any user on any host on the 172.16.3.0 network to have access to all of the services (telnet and ftp) on your machine. That user will still have to supply the appropriate password or S/Key response (see below). Always use IP addresses in the hosts.allow file, because hostname information can be spoofed (if you are using the Internet Domain Name Service, or some other name service such as NIS).

Now we want to disallow access for everybody else. Put the following line into /etc/hosts.deny: 

ALL: ALL: /usr/bin/mailx -s "%d: connection attempt from %c" root@mydomain.com

Not only does this deny access to all services from all hosts, it causes tcpd to send an alarm via e-mail that somebody is trying to get access to the machine. Substitute the e-mail address of somebody who reads e-mail regularly for root@mydomain.com in the above line.

Now you want tcpd to log all accesses via syslog. Put the following line in /etc/syslog.conf: 

auth.auth.notice;auth.info           /var/log/authlog

The white-space on the line above must be tabs, or syslog will be unable to properly parse the file and no logging will happen. Note that the logging facility is a configurable parameter when building tcpd, but we recommend using AUTH, as opposed to any LOCAL* facilities.

Finally, you need to configure wu-ftpd. This is tricky even for experts. When you compiled wu-ftpd, you specified a directory where the daemon will look for its configuration files. This configuration directory will contain a pid directory and three files. The ftpconversions file should be empty but it must exist. The ftpusers file should contain a list of all users in the machine's password file who should not be allowed to ftp into the system. This file should contain every user in the password file: we will add a user later who is allowed to ftp into the system. Most especially, root should always be in the ftpusers file.

The last file in the configuration directory is the ftpaccess file. Rather than go into full detail, here is a file that you can use if you do not want to allow anonymous ftp into your system, but do want some users to be able to upload files to the machine: 

class users real 172.16.3.*
 
log commands real
log transfers real inbound,outbound

This allows users to ftp from any host on network 172.16.3.0 and from nowhere else (which is redundant if you are already using tcpd, but security in depth is a Good Thing). All commands and file transfers will be logged to the log file you specified when you compiled the daemon (which is why we recommended you put it in /var where it has plenty of space to grow).

Configuring anonymous ftp is beyond the scope of this article, but be warned to be very careful, because it is easy to make a mistake and give away access to your system. Review the documentation that comes with wu-ftpd for information and pointers to other documents on anonymous ftp.

Bug of the Month Club

First, a bug that ties in nicely with this month's topic. A CERT advisory has been issued about a vulnerability in the NCSA httpd 1.5a-export and APACHE httpd 1.0.3 (and Apache Web server), specifically its use of CGI scripts. The sample CGI code contains a call to escape_shell_cmd(). Any program that relies on escape_shell_cmd() to prevent exploitation of shell-based library calls may be vulnerable to attack. The best solution to this problem is to remove all calls to functions like system() and popen() that cause the base problem. A revised version of the util.c module that calls escape_shell_cmd() is also available for re-compilation of all CGI programs on your site.

More and more problems with Java and JavaScript are coming to light, both because the languages are evolving and because they are coming under more scrutiny. A very nice summary of the current security problems is included in the March 18th (96-01) CIAC notes. If you are considering using Java, be sure to read this to understand the current exposures and expected fixes. Also in the note is a cautionary tale about the thoroughness of Web-crawlers. Web-site administrators are sometimes too free with their pointers, including links to password files, host files, and other information best kept private. The crawlers are finding this information, so searches for keywords like passwd are turning up embarrassing links. Be sure yours isn't one of them!

CERT has also released a Java advisory about the bug that lets applets connect to sites other than their source.

Sun has released information on an interesting bug, via a CERT advisory. This one results from interrupting the installation script that comes with SunSoft demo CDs. To see if you are vulnerable, look for a line such as x-spam-sh in your $HOME/.mailcap file. If it's there, remove it before someone runs commands on your system without your knowledge.

In March, there was a very interesting discussion on the Sneakers mailing-list. It was started by Bill Roswell of Occidental Petroleum Corp. He pointed out that PointCast (a fantastic information-server/screen-saver by the way) is one of a new breed of Web-based applications that could potentially open up a large security hole. Note that the same is true of other similar applications: we're not singling out PointCast. These programs actively connect to the Internet to transfer data, as well as new versions of the program itself. Normally, this is useful behavior. PointCast, for instance, updates its news, weather, and sports information dynamically and displays them when requested or as a screen-saver. What if a malicious program in this vein were set loose on the Internet? It could be seemingly useful, getting behind many firewalls as users load it onto their machines. After a while it could operating without notice within your environment, wreaking havoc or stealing information. Consider the effect of someone hacking the PointCast site and installing a Trojan version of the program. A chilling thought. The PointCast folks explain that they take precautions to avoid such problems (checksumming new version of the program), but others might not be so thorough, or might purposefully violate your trust.

The Bookstore

Sun has a security mailing list that you should be receiving. You don't even need to be a Sun support contract holder to be included. Just send mail to security-alert@sun.com with the body contents "SUBSCRIBE cws e-mail-address" (replacing e-mail-address with your address, of course).

O'Reilly has published another interested security-related book: Bandits on the Information Superhighway by Daniel Barrett. It has a lot of information on life on the Internet. It's aimed at the novice or even journeyman Web surfer, but there are bits and pieces that can be of use even to seasoned vets. It's full of anecdotes and cool sidebars. If everyone that used the Web read this book, the Web would be a much more useful place. Spammers would be put in their place, pyramid schemes would no longer pile up, and junk e-mail would be no more. It includes sections on "Buying and Selling on the Net," meeting people (and avoiding harassment), straight talk for parents worried about their kids and exposure to pornography, and "what to do if you are ripped off." A removable poster in the back lists the 15 ways to spot a bandit on the Information Superhighway. All and all, it is worthy of bookshelf space, even if it's just there as a loaner for when one of your charges comes to seek advice or complain about Internet happenings.

Next Month, on "As Pete's Wicked World Turns"

Next month we'll describe the final five steps you need to perform to build your secure Web server.


Click on our Sponsors to help Support SunWorld

Resources

About the author
Peter Galvin is Chief Technologist for Corporate Technologies, Inc., a Systems Integrator and VAR. He is also Adjunct System Planner for the Computer Science Department at Brown University, a member of the Board of Directors of the Sun User Group, and has been Program Chair for the last four SUG/SunWorld conferences. As a consultant and trainer, he has given talks and tutorials world-wide on the topics of system administration and security. He has written articles for Byte and Advanced Systems (SunWorld) magazines, and the Superuser newsletter. Peter is coauthor of the best-selling Operating Systems Concepts textbook. Reach Peter at peter.galvin@sunworld.com.

What did you think of this article?
-Very worth reading
-Worth reading
-Not worth reading
 -Too long
-Just right
-Too short
 -Too technical
-Just right
-Not technical enough
 
 
 
    

SunWorld
[Table of Contents]
Subscribe to SunWorld, it's free! 		[Search]
Feedback 		[Next story]
Sun's Site

[(c) Copyright Web Publishing Inc., and IDG Communication company]

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-04-1996/swol-04-security.html
Last modified: