Web server wiles, Part two
Secure your Solaris Web server from the perils of the void, part 2
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.
man shutdownfor more information). Generally we feel that your secure servers should have exactly two states: "off" and "running normally." Use
haltto take your server down and you won't care what's in /etc/rc.d.
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.
cronyou can also run the daemon without the
-bdoption. 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.
tcpd. The correct line is
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:
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
at the end of /etc/passwd and
at the end of /etc/shadow. Then use the
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.
/usr/local/bin/keysh is not a standard shell, you
have to create an /etc/shells file with these lines in it:
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
keyinit access command to initialize the S/Key
secret for user access. You have completed the S/Key setup for
You now want to allow the user access to use the
command to become superuser. First change the entry for group root in
Only users listed in this entry are allowed to become superuser using
keysu. Now you have to use the
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
so that users are forced to use
many scripts use
/bin/su to start processes that do not
require full superuser access. You should, however,
/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.
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
nosuid directive to take effect.
You must not apply the
nosuid directive to the special
filesystems. Note that TMPFS type filesystems (such as /tmp)
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:
/noshellbe 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.
routed(which can be spoofed). If you need to route through different gateways, consider adding
/usr/bin/routecommands to /etc/init.d/inetinit instead of running
Step 9: Confirming your configuration
Reboot your system one last time and plug it into the network. Confirm that the following are true:
/usr/local/bin/keysuto become superuser.
ps -efshould show very few processes; in particular,
sendmailand the various NFS processes should not be running.
touch /usr/FOOshould fail with an indication that the filesystem is read-only.
pscommand to /, making sure to preserve the setuid bit. access should not be able to get a process listing with
/ps -ef. Remove the
/psbinary 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
with the latest version. Replace the resolver library
with the latest version of
crontab (check your local Archie
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
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
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
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.
sendmailfrom cron to process queued mail occasionally.
tcp_wrappers, S/Key, wu-ftp,and
tripwireas appropriate to your environment.
telnetfrom /etc/inetd.conf, and edit /etc/hosts.allow to limit the machines that can use these daemons.
/noshellthe default shell for all accounts except root and access.
sendmail, syslog, bind,and
crontabwith more secure versions.
xntpfor accurate time stamping.
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
Next Month, on "As Pete's Wicked World Turns"
Next month we'll look at a new tool that can enable enterprise-wide security.
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 email@example.com.
If you have technical problems with this magazine, contact firstname.lastname@example.org