Web server wiles, Part one
Secure your Solaris Web server from the perils of the Void
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.
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.
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
/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
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.
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
(possibly via some other mail user agent such as
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
0 * * * * /usr/lib/sendmail -q
This entry will invoke
sendmail every hour to process any
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
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
that are started out of /etc/inetd.conf. Access control can
be performed on IP address, domain name, and a raft of other
tcpd can raise alarms via
syslog or e-mail if unauthorized connection attempts are
Next you will need the S/Key package (part of the
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
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
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
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
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
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
ftp daemons are started by
file, /etc/inet/inetd.conf, contains many other services
ftp, so it is best to
simply remove this file and create a new one containing only the
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
ftp server that comes with Solaris. If you do not
want to allow anybody 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
access and then deny access to everybody else in hosts.deny
(this is often called a "default deny" policy). Here is a sample
This would allow any user on any host on the 172.16.3.0 network to
have access to all of the services (
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" email@example.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 firstname.lastname@example.org in the above line.
Now you want
tcpd to log all accesses via
syslog. Put the following line in
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
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
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
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
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
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
popen() that cause the base problem. A
revised version of the
escape_shell_cmd() is also available for
re-compilation of all CGI programs on your site.
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
This one results from interrupting the installation script that comes
with SunSoft demo CDs. To see if you are vulnerable, look for a line
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.
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 email@example.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.
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 firstname.lastname@example.org.
If you have technical problems with this magazine, contact email@example.com