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

May  1996

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.

• Files in /etc/rc[01].d. The files in /etc/rc[01].d do not actually start any dangerous programs, and are merely used for moving between various run levels (see man shutdown for more information). Generally we feel that your secure servers should have exactly two states: "off" and "running normally." Use halt to take your server down and you won't care what's in /etc/rc[01].d.

• Turning off IP forwarding. The following lines:

  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
  

  should be added to the end of /etc/init.d/inetinit. When placed at the front of the file, the device configurations later in the file cause these values to be reset. Under Solaris 2.5, creating a file called /etc/notrouter will turn off IP forwarding.

• /etc/init.d/tmpfix. This script is not necessary on Solaris 2.5 machines.

• Other files in /etc/init.d. Casper reiterates that the choice of which scripts to take out of /etc/init.d is highly dependent upon which version of Solaris you are using. The list of files we presented in our article was based on a Solaris 2.4 machine, so make sure you know what you're doing if you try out the directions on a Solaris 2.5 machine.

• Sendmail. Instead of invoking sendmail from cron you can also run the daemon without the -bd option. This will cause the daemon to be a queue-watcher only. We prefer not to have the daemon running (one less process to worry about on the system), but your mileage may vary.

• /etc/syslog.conf. There was a typo and an error in our instructions for configuring /etc/syslog.conf for tcpd. The correct line is

  auth.info		/var/log/authlog
  

  which will log all auth events with severity info and higher to /var/log/authlog. Don't forget that the whitespace in this entry must be tabs.

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

• Filesystem permissions. Though there is some disagreement within Sun, our source recommends downloading and using fix-modes. The programs in this package clean up insecure group permissions on some system files and directories. This script has recently been updated to support Solaris 2.5 systems. Unfortunately, it would take a lot of work within Sun to fix these problems in the Solaris releases, but generally speaking, they need to be fixed. Thus the controversy.

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:

• Bogus shells in /etc/passwd. Make /noshell be the login shell for all users except root and access. Since this shell neither exists nor is in /etc/shells, crackers will never be able to get access through these accounts.

• Remove /etc/auto_*. Removing /etc/init.d/autofs should have prevented the automounter from starting up, but there's no reason to keep these files around either.

• Remove /etc/dfs/dfstab. Again, purging /etc/init.d should prevent the machine from ever becoming an NFS server, but best to get rid of this file anyway.

• Remove crontab files. You should remove all files from /var/spool/cron/crontabs except the root file.

• Use static routing. Create an /etc/defaultrouter file instead of relying on information from routed (which can be spoofed). If you need to route through different gateways, consider adding /usr/bin/route commands to /etc/init.d/inetinit instead of running routed.

Step 9: Confirming your configuration

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

• You should be able to telnet and ftp to your secure server from the machines you configured tcpd to allow.

• Trying to access the machine from any other machine should result in a denial of access and an e-mail to the appropriate party.

• You should be able to login via telnet and ftp as user access, but not as root or any other user.

• User access should be able to /usr/local/bin/keysu to become superuser.

• ps -ef should show very few processes; in particular, sendmail and the various NFS processes should not be running.

• touch /usr/FOO should fail with an indication that the filesystem is read-only.

• As the superuser, copy the ps command to /, making sure to preserve the setuid bit. access should not be able to get a process listing with /ps -ef. Remove the /ps binary when you are done.

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.

• Keep the system disconnected from the network until all is ready.
• Install just the core operating system, adding only necessary packages.
• Install recommended and security patches.
• Strip down the OS by removing startup files (carefully!).
• Disable IP forwarding in /etc/init.d/inetinit.
• Add a script to system startup to fix /tmp permissions (except on Solaris 2.5).
• Verify that few processes are running via ps.
• Invoke sendmail from cron to process queued mail occasionally.
• Install and configure tcp_wrappers, S/Key, wu-ftp, and tripwire as appropriate to your environment.
• Remove all but wu-ftp and telnet from /etc/inetd.conf, and edit /etc/hosts.allow to limit the machines that can use these daemons.
• Enable logging of all telnet access to the system via syslog .
• Mount filesystems read-only and no-suid as appropriate.
• Make /noshell the default shell for all accounts except root and access.
• Remove /etc/auto_*, /etc/dfs/dfstab, /var/spool/cron/crontabs/* (except root).
• Use static routing.
• Test your system thoroughly, including allowed access and denied access, and event logging.
• Consider replacing sendmail, syslog, bind, and crontab with more secure versions.
• Install xntp for accurate time stamping.
• Consider enabling system accounting.
• Keep monitoring and testing the Web server.

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.

Resources

fix-modes ftp://ftp.fwi.uva.nl/pub/solaris/fix-modes.tar.gz
• sendmail
  ftp://ftp.cs.berkeley.edu/ucb/sendmail/
• bind
  ftp://ftp.vix.com/pub/bind/BIND
• XNTP
  ftp://ftp.udel.edu/pub/ntp/
• tripwire
  ftp://coast.cs.purdue.edu//pub/COAST/Tripwire/
• CERT advisory
  ftp://info.cert.org/pub/cert_advisories/CA-96.07.java_bytecode_verifier
• CERT advisory
  ftp://info.cert.org/pub/cert_advisories/CA-95:18.widespread.attacks

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.

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: