Unix Security with Solaris 2.6/7
As in any security venture, the place to begin securing a UNIX system
(Solaris, in this case) is prior to and during
installation. Waiting until after a machine has been in the field
to address its security presents a huge number of problems.
Before installing the system, spend a moment to think about exactly
what this machine's role will serve. Is it a mail
server? If so, there are certain services it needs to run...and
certain services it does not. Is it a workstation? Does it
need to be accessible remotely? These are the kinds of things
that should be considered before the machine is even
installed. Next, you should select the most recent version
of the operating system. The current stable version of
Solaris is Solaris 7; Solaris 2.6 is on many machines, though,
and as I have more experience with it, I'm going to
have to stick with that for this write-up. So make sure you have
your operating system software ready. From a
computer that is already secure and connected to the network,
go to http://sunsolve.sun.com/ and click on the
'Patches' link on the left. Navigate through and download
all the patches you'll need for the new system.
also has patches -- look for the Patch Reports at the bottom of the page.
Once you have the OS ready and the patches downloaded, you're
ready to start installing. Begin by selecting End
User with On-line manual pages. This will give you the basic
components you need without adding unnecessary,
potentially vulnerable software. If there are packages that need
to be added later, that isn't a problem. Make a note of the
packages that will need to be added after installation is complete,
look into the security issues of each package, and install the
package once all other security patches have been put into place.
finished the installation and the system has rebooted, put the
server on an isolated network with the other secure
machine that you used for downloading the patches earlier.
Download the patches from the secure host to the new
machine and install them.
When you've got the operating system and all patches installed,
it's time to start fine-tuning the system. Remember -- when making
changes to system-dependent files such as the ones discussed here,
it's best to get into the habit of always making a backup copy of
the file you're editing prior to modification. This way, if there's
a problem, restoration is simple. To make a backup, use the format
'cp filename date-filename', where
'filename' is the name of the file you're editing and 'date' is the
current date. The place
to start, as with any UNIX-based system, is /etc/inetd.conf. By
prepending the line with a # symbol, comment
out anything you don't absolutely need -- if
the server you've built isn't designed for mail, it probably
doesn't need pop turned on. It's a good bet that rexd
won't be utilized, and the rlogin/rsh services
should never be enabled. Be aware of what you
have turned on and what it does. As with anything, if you
aren't certain if it needs to be there, comment it out.
You can always go back
and turn something on later. To see what's actually running,
type 'grep -v "^#" /etc/inetd.conf' -- that will show you
all lines that are not commented out. Ideally, comment out ftp, tftp,
systat, rexd, ypupdated, netstat, rstatd, rusersd, sprayd, walld, exec, talk,
comsat, rquotad, name, uucp, sadmind, login, finger, chargen, echo, time,
daytime, discard, telnet, imap, pop3, dtspc, fs, kcms, and all rpc services.
The best thing to
do, generally, is to comment out every line in /etc/inetd.conf initially,
and then turn things back on later if they're needed. As a note -- if
you comment out the line for telnet and you still want to access the
machine remotely, make sure you install
Secure Shell or OpenSSH, or you won't be
able to get in. xinetd is a secure replacement for inetd, and can be found at
Remember, just because it's more secure doesn't mean you can be
sloppy in configuring it.
Now kill -HUP /etc/inetd.conf, and grep -v "^#" /etc/inetd.conf again to
make sure you've got everything.
Next, go to /etc/rc2.d and /etc/rc3.d and go through a similar
process with startup scripts. All you need to do to stop
a script from running is to type './script stop' (where 'script' is the name
of the script you're trying to stop). Then replace the 'S' at the start
of its name with a lower-case 's' by typing 'mv Sscript sscript'.
Again, make a backup of any file you
are going to edit before altering it, be aware of what all
these scripts actually do, and run only those you feel need to be running.
Make sure to disable /etc/rc2.d/S71rpc,
/etc/rc2.d/S76snmpdx, /etc/rc2.d/S77dmi, /etc/rc2.d/S99dtlogin,
and /etc/rc2.d/S74autofs. You can actually still send mail without
sendmail running as a daemon (i.e., listening on a port). First do
'/etc/rc2.d/S88sendmail stop', then edit /etc/rc2.d/S88sendmail. Find
the line that reads '/usr/lib/sendmail -bd -q15m'. Change that to
'/usr/lib/sendmail -q15m'. Note -- the number (15m) may be different, but
it doesn't matter; what you're doing is removing the '-bd' from the line.
Next, tighten down various other potential problems. Be sure
root has a umask setting of 077 or 027, so any file created by root is,
by default, not readable or writable by others. Be sure root
has a safe search path, as in /usr/bin:/sbin:/usr/sbin. Go
into etc/default/login and make certain root can't log in
remotely, and make certain root is in /etc/ftpusers. Edit
/etc/shadow and * out the accounts for 'uucp', 'nuucp',
'listen', 'ftp' and 'sys' -- and any other unnecessary accounts
that might be in there. Remove group write permission
(chmod -R g-w /etc) of the /etc directory; unless you're using
the wheel group and extending permissions that way,
the files in /etc don't need to be group writable. If the host
is going to have more than one interface, don't let it
route -- touch /etc/notrouter, which will create a file telling the
system it isn't allowed to route.
Don't use in.routed and in.rdisc; use static routes if routing
Disable the automounter (remove
all /etc/auto_* files, and disable /etc/rc2.d/S74autofs if you haven't
already stopped that script previously).
If not absolutely necessary, there's no need to use NFS; rename
etc/rc3.d/S15nfs.server and etc/rc2.d/S73nfs.client
(to etc/rc3.d/s15nfs.server and etc/rc2.d/s73nfs.client).
If you haven't already, make sure to
rename /etc/rc2.d/S71rpc -- don't use the rpc
services or NIS if you can avoid it. Weitse Venema has written
a secure replacement for rpcbind (ftp://ftp.porcupine.org/pub/security/index.html).
If you -must- use NFS, make sure
you've replaced rpcbind and bear in mind that all NFS traffic
flows in clear text, thus is not secure. Also, use fsirand to randomize
inode numbers on NFS servers. Lastly, try to prevent buffer
overflows in the stack (this may break certain things,
so be careful) by adding set noexec_user_stack=1 and set
noexec_user_stack_log =1 to /etc/system.
The next thing you'll want to do is set up TCP Wrappers. TCP
Wrappers can be downloaded from
or from Wietse Venema's site -- this should be downloaded
to the host that downloaded your patch files earlier, and then
the new Solaris box should download from the secure
box. Install TCP Wrappers, and configure the services you'd
left turned on in /etc/inetd.conf to be protected by
There are other options to make a Solaris box even more secure,
such as creating the wheel group (so only those
users in the wheel group can execute commands such as su),
locking down files such as /etc/hosts.equiv such that no
one can alter the files, going into /etc/default/inetinit and
altering the parameters for TCP initial sequence number
generation by setting TCP_STRONG_ISS=2, using xntp instead of ntp,
disabling IP forwarding and source routing`
in etc/init.d/inetinit, logging to a remote log host,
making /noshell the default shell for all accounts except root
and access, removing extraneous files from
/etc/init.d, locating all suid and sgid files (by doing 'find / -type f
-perm -4000 -print' for suid files and 'find / -type f -perm -200 -print'
for sgid files) and removing the suid and/or sgid bit from those that aren't
needed (using 'chmod u-s file' or chmod g-s file'), and so on.
Once you have the system basically set up, and before you hook
it to a live network, reboot and run tripwire.
Make a database of checksums on a secure remote server or on
tape or floppy. Optimally, get the commercial
version of tripwire, as it can sign the database, to guard
against tampering. Run tripwire regularly at random,
frequent intervals -- one idea is to run tripwire before the
nightly backup, -and- at some random time during
Lance Spitzner's whitepaper
Solaris Security FAQ
Sun's Solaris Patch Site
Alternate Solaris Patch Site