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

Web server wiles, Part two

Secure your Solaris Web server from the perils of the void, part 2

SunWorld
May  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 attack. This month we cover the last five steps to building a secure Web server. We also include some views from Sun about our first five recommendations.

Also in Pete's Wicked World this month: information on Java and JavaScript vulnerabilities. (2,700 words)



Mail this
article to
a friend
Last month we looked at the first five steps to securing your Web server from prying fingers. This month we cover the last five steps. But before we do, let's look at some feedback we received from Casper Dik at Sun. He makes some good points that need attention. We include the gist of his feedback below.


Advertisements

Also, from an anonymous but well-placed source on one of Sun's planets:

Thanks to everybody who contributed their comments to our article. When dealing with security issues, scrutiny by outsiders is always worthwhile!

Now, the last five steps:

Step 6: Configuring S/Key

In last month's article we discussed using S/Key as a mechanism for getting access to a system without transmitting a reusable password across the network. To begin using S/Key, create an account that uses /usr/local/bin/keysh as its login shell. You will login as this user with some reusable password of your choosing and then keysh will force you to respond to an S/Key challenge before giving you a shell prompt.

You should put

access:x:100:100:Access Account:/tmp:/usr/local/bin/keysh

at the end of /etc/passwd and

access:NP:6445::::::

at the end of /etc/shadow. Then use the passwd access command to set the password for user access. The password you choose here doesn't have to be a very good password, since you will be relying on keysh to provide the security for this account.

Since /usr/local/bin/keysh is not a standard shell, you have to create an /etc/shells file with these lines in it:

/sbin/sh
/usr/local/bin/keysh

Only users whose login shell is one of these two shells are allowed to access the machine.

Now create an empty /etc/skeykeys file and make it mode 600 and owned by root:

touch /etc/skeykeys
chmod 600 /etc/skeykeys
chown root /etc/skeykeys
chgrp root /etc/skeykeys

Use the keyinit access command to initialize the S/Key secret for user access. You have completed the S/Key setup for user access.

You now want to allow the user access to use the keysu command to become superuser. First change the entry for group root in /etc/group:

root::0:root,access

Only users listed in this entry are allowed to become superuser using keysu. Now you have to use the keyinit root command to initialize the S/Key secret for the superuser. I recommend using a different secret word than you used for user access.

At this point you may be tempted to simply remove /bin/su so that users are forced to use keysu. Unfortunately, many scripts use /bin/su to start processes that do not require full superuser access. You should, however, chmod 500 /bin/su so that only the superuser can run this program.

Note the implicit assumption that access is a group account shared by several administrators. You may feel more comfortable giving each administrator a separate account with a different S/Key secret so that you have a better audit trail. The downside to this approach is it creates more accounts that can have bad passwords on them and allow crackers to gain access. Decide what makes sense for your organization.

Step 7: Controlling your filesystems

One way to thwart potential system crackers is to prevent them from running setuid programs on your machine. The steps you have already taken make it unlikely that anybody is going to get an unauthorized setuid program onto your machine, but a little paranoia never hurt anybody in the security business.

Use the nosuid option in /etc/vfstab to prevent setuid programs from being executed on any of your UFS filesystems:

/proc           	-       /proc      proc    -   no   -
fd              	-       /dev/fd    fd      -   no   -
swap            	-       /tmp       tmpfs   -   yes  -
/dev/dsk/c0t3d0s1       -       -          swap    -   no   -
 
/dev/dsk/c0t3d0s0 /dev/rdsk/c0t3d0s0  /       ufs  1   no   remount,nosuid
/dev/dsk/c0t3d0s4 /dev/rdsk/c0t3d0s4  /usr    ufs  1   no   ro
/dev/dsk/c0t3d0s5 /dev/rdsk/c0t3d0s5  /var    ufs  1   no   nosuid
/dev/dsk/c0t3d0s6 /dev/rdsk/c0t3d0s6  /local  ufs  2   yes  nosuid

Note that /usr contains some setuid executables (not the least of which are the S/Key binaries in /usr/local/bin), so we mount it read-only instead of nosuid. The root filesystem is mounted by the boot PROM, so it has to be remounted for the nosuid directive to take effect.

You must not apply the nosuid directive to the special filesystems. Note that TMPFS type filesystems (such as /tmp) are automatically nosuid in recent releases of Solaris.

Step 8: Finishing touches

Here are a few more simple steps you can take to make your system more secure:

Step 9: Confirming your configuration

Reboot your system one last time and plug it into the network. Confirm that the following are true:

Congratulations! You have just created a very secure machine.

Step 10: Don't stop there

There are a number of freely available replacements for common system programs that are significantly more secure than the versions provided with Solaris. Consider replacing sendmail with the latest version. Replace the resolver library with the latest version of bind. Replace syslog and crontab (check your local Archie server).

Your logging information is only as good as the timestamps in your files. Consider running XNTP to keep your system clock in synch with accurate clock sources from the Internet and with other machines on your networks. If somebody breaks in to your network, you may have to correlate logs between dozens of systems, so their clocks had better be in synch.

Before your system goes live on the network, get a copy of tripwire and make a database of MD5 checksums for all files on your secure server. Put this database on removable media (tape or floppy disk) so that somebody who breaks into your system can't modify the data. Run tripwire at random (but frequent) intervals to make sure nobody is tampering with your files.

Consider running process accounting so that you have a record of every command executed on your system. You will pay a performance penalty (10 to 20%) if you turn on process accounting. See man acct for more information.

Change your S/Key secrets regularly (every 30 days if you can stand it) and choose good secret words (use non-alphanumeric characters and long secret words). Change the secret words on the system console or use keyinit -s to change the secret over the network. Do not use the same secret word for both the access and root accounts.

Web server security checklist

Use this checklist to be sure your server is installed as securely as possible. Feel free to add to the checklist for site-specific steps, or to share your additions with us if they are general-purpose.

Even if you only implement some of these security steps, your Web server will be much more secure than a standard server installed with a standard Unix configuration. But to be safe, go whole-hog and lock that server down with all of these tools and techniques.

Bug of the Month Club

Unfortunately, Java has yet another associated security problem. This one would let maliciously written applets perform any operation on the system that the user viewing the applet could perform. There are currently no available patches to fix this, so it is advised that Java be turned off in Netscape Navigator. The problem is not fixed in version 2.01. For more information, check out the CERT advisory.

Generally speaking, CERT is a very useful resource for security, especially as it plays on the Internet. It's easy to find, well known, and well documented. So why is it that many sites are ignoring their advice and, consequently, being broken into?! CERT has posted a reminder that several known penetration methods are still in use and still finding victims. The problems exploited include old and un-patched OSes, poor or no passwords on accounts, systems that have been broken and had packet sniffers installed to find more victims, IP spoofing attacks, misconfigured anonymous FTP accounts allowing software piracy and system break-ins, and attacks on sendmail. Please, even if you won't take any other security steps, you need to be sure these are addressed. For more information, check out the CERT advisory.

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

Next month we'll look at a new tool that can enable enterprise-wide security.


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 co-author 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-05-1996/swol-05-security.html
Last modified: