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 -- it's
difficult to be certain that a server has not been compromised once
it's been on the internet without having been patched. Adding security
too late to a server that was never secure to begin with is an exercise
in futility.
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. Different kinds of servers have very different
requirements, and those idiosyncracies will affect the measures you
take to secure the server to begin with. Do a little research into
the kind of server you're trying to set up. For instance, if you're
running a mail server, what programs need to be installed? Are you
using Sendmail or one of the other mail programs, such as qmail?
What startup scripts need to be running, and where are they? What are
the crucial files that need to run as root? These are things that an
administrator should know ahead of time before setting up and tightening
down the server.
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. Alternately,
ftp://online.sunsolve.sun.co.uk/pub/patches/
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. Once you've
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.
Now kill -HUP /etc/inetd.conf, and grep -v "^#" /etc/inetd.conf again to
make sure you've removed everything you needed to remove. If it turns
out that there's nothing in inetd that you need -- and often this will be
the case, especially if you're hardening a desktop server -- it's just as
well to disable inetd altogether by editing the file /etc/init.d/inetsvc
to comment out the line that mentions /usr/sbin/inetd. If you do need to
use some of the services in inetd, simply take care to only allow what's
needed and disable everything else. If you're using inetd, consider
replacing it with xinetd. Xinetd is a secure replacement for inetd, and
can be found at
http://www.synack.net/xinetd
or http://sources.isc.org/network/daemon.
Remember, just because it's more secure doesn't mean you can be
sloppy in configuring it.
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. The important ones to be sure to disable (unless you know
they're needed for some reason) are /etc/rc2.d/S71rpc,
/etc/rc2.d/S76snmpdx, /etc/rc2.d/S77dmi, /etc/rc2.d/S99dtlogin,
and /etc/rc2.d/S74autofs. If this is not intended to be a mail server,
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 or equivalent
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 (note -- this file may exist
by default now, but it's a good step to take just to be sure). If you do
intend to let the server route, don't use in.routed and in.rdisc; use
static routes if routing is necessary. 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
tc/rc2.d/s73nfs.client) if you have not done so already. Make absolutely
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 the
following lines to /etc/system:
set noexec_user_stack=1
set noexec_user_stack_log=1
The next thing you'll want to do is set up TCP Wrappers or ipfilter. Both
are programs that help protect your server by specifying who can and cannot
access services remotely. TCP Wrappers can be downloaded from
ftp://coast.cs.purdue.edu/pub/tools/unix/tcp_wrappers/
or from Wietse Venema's site
and ipfilter can be found at http://coombs.anu.edu.au/~avalon/ip-filter.html.
The program you choose 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 or ipfilter, and configure the
services you'd left turned on in /etc/inetd.conf to be protected by
the program you've chosen. Guides to configuring TCP Wrappers or ipfilter
can be found on the net.
Another step that can be taken involves removing the suid and sgid bits
from programs that don't need them. These bits allow programs to run as
root, and if a program running as root is compromised, an attacker can
easily gain root access to the system. To find all suid and sgid files,
type:
find / -type f -perm -4000 -print
for suid files and
find / -type f -perm -2000 -print
for sgid files.
To remove the suid or sgid bit from these programs, use 'chmod u-s file'
or chmod g-s file' (where 'file' is the full name and path of the file).
Bear in mind that there are some programs which need their suid
bits in order to function properly. If you decided to allow Sendmail
to run on this server, for instance, you should not remove the suid bit
from the Sendmail file. Once you've removed the suid bit and sgid bit
from all files that don't need them, create a list of the files that
do need the bit set. Periodically check to see what files are
suid on your system -- if that list changes, it could be a sign of
compromise.
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, setting up chrooted
environments for available services, and so on.
Once you have the system basically set up, and before you hook it to a
live network, reboot and run
tripwire. Tripwire is a
host-based intrusion detection system -- run correctly, tripwire can
alert you to any changes that have been made to the system. Make a
database of the checksums tripwire generates 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 the
day.