|
Securing Sun's Solaris Operating System
Now that you've installed patches, your machine should be pretty darn secure,
right? Maybe in an ideal world, but there are still plenty of setuid programs
left, and directory ownership problems to contend with. Plenty of work still
needs to be done.
 | Baselines |
Just to set a baseline, here's what the SS20 we're working on currently looks
like.
# ps -ef
root 0 0 0 17:06:38 ? 0:01 sched
root 1 0 0 17:06:41 ? 0:00 /etc/init -
root 2 0 0 17:06:41 ? 0:00 pageout
root 3 0 0 17:06:41 ? 0:17 fsflush
root 200 1 0 17:07:37 ? 0:00 /usr/lib/saf/sac -t 300
root 203 200 0 17:07:37 ? 0:00 /usr/lib/saf/ttymon
root 45 1 0 17:06:53 ? 0:00 /usr/lib/devfsadm/devfseventd
root 49 1 0 17:07:04 ? 0:00 /usr/lib/devfsadm/devfsadmd
root 201 1 0 17:07:37 console 0:00 -sh
root 184 1 0 17:07:36 ? 0:00 /usr/sbin/nscd
root 168 1 0 17:07:35 ? 0:00 /usr/sbin/syslogd
root 190 1 0 17:07:36 ? 0:00 /usr/lib/utmpd
root 171 1 0 17:07:35 ? 0:00 /usr/sbin/cron
root 841 839 0 19:07:03 console 0:00 ps -ef
# netstat -an
UDP: IPv4
Local Address Remote Address State
-------------------- -------------------- -------
*.514 Idle
*.* Unbound
TCP: IPv4
Local Address Remote Address Swind Send-Q Rwind Recv-Q State
-------------------- -------------------- ----- ------ ----- ------ -------
*.* *.* 0 0 24576 0 IDLE
*.* *.* 0 0 24576 0 IDLE
| Install and run Titan |
Great. Now that we've set up a baseline, let's start to lock down the machine. Once upon a time, most of the
work in locking down Solaris machines had to be done by hand, with a little help from precious few tools -- like Casper Dik's fixmodes.
Now, that task is a lot easier, thanks to a program called Titan. Brad Powell, Matt Archibald, and
Dan Farmer took the tasks that people have been manually performing for years, and scripted them -- great news for
those without the time or patience to do everything by hand, especially when it needs to be done for dozens
of machines.
Once you've downloaded and untarred Titan, go into the base directory and run the Titan-Config program. This will
make backups of critical files, ensuring that you can undo the changes it makes if neccessary. It will then leave several
sample configuration files in the directory. I usually use the sample.Server configuration file as a template, and enable the
options to lock down directory permissions and file permission. Note that some of those permissions may be more
extreme than needed, and some fine tuning may be in order. For example, a large quantity of setuid binaries will have executable permissions removed for everyone
not in the staff group. This may work fine with a limited number of people who need to administer all portions
of the machine, but an alternate method is to make use of Solaris' file ACL's, to give fine grain control over
who can execute what binaries. The other thing you want to consider is activation of BSM. By default, Titan
will enable it. BSM can generate mountains of logs, and while logging as much information as possible is a good
policy, excessive logging might create disk space issues. Consider carefully if you're equipped to deal with
what could be a considerable amount of additional log quantity, and remove the bsm.sh module if you decide
you don't need it.
Titan is fairly straightforward to run. Running Titan with the -c option, followed by the configuration file,
allows you to specify that it will run your configuration file. It may take a while to do its thing, so be
patient. One important caveat to note is that titan will make use of some programs in the /usr/ucb directory. BSD
chown is used quite frequently, so you may find it necessary to install the SUNWscpu package. Alternately, you
can mimic the BSD chown behavior with a simple script:
#!/bin/sh
chown `echo $1 | sed 's/\./:/g'` $2
This will mimic the minimal functionality needed by the BSD features Titan actually uses, without the need for
installing the whole BSD compatibility subsystem. Why Titan's authors insist on using the BSD style chown -- when the only
difference is that they use the . versus : semantic for setting user and group -- isn't immediately apparant.
| Reboot! |
After running Titan, you'll probably want to reboot your system, as it does alter some of the TCP/IP stack settings,
and possibly enable BSM.
| Removal and ACL'ing of setuid root binaries |
Titan leaves a large number of setuid binaries in place. The machine we're
installing on will only be accessed via a serial console, and the only
interactive account on it is root. Therefore, many setuid and setgid programs
had their setuid and setgid bits removed. If you require remote access, and
hopefully you'll be using sshd, you will need to keep pt_chmod setuid root.
Here are the binaries which are left setuid PRIOR to altering the permissions.
- -r-sr-xr-x 1 root bin 14692 Sep 16 14:05 /usr/lib/fs/ufs/quota
- -rws--x--x 1 root staff 4436 Sep 16 14:03 /usr/lib/pt_chmod
- -r-sr-xr-x 1 root bin 7528 Sep 16 14:07 /usr/lib/utmp_update
- -r-sr-xr-x 1 root sys 28472 Sep 16 14:03 /usr/bin/sparcv7/ps
- -r-sr-xr-x 2 root bin 11976 Sep 16 14:07 /usr/bin/sparcv7/uptime
- -r-sr-xr-x 2 root bin 11976 Sep 16 14:07 /usr/bin/sparcv7/w
- -rwsr-x--- 1 root staff 17932 Sep 16 13:58 /usr/bin/crontab
- -rwsr-x--- 1 root staff 14600 Sep 16 14:08 /usr/bin/eject
- -r-sr-xr-x 1 root bin 30596 Sep 16 14:00 /usr/bin/login
- -rwsr-xr-x 2 root staff 104580 Sep 16 14:02 /usr/bin/passwd
- -r-sr-xr-x 1 root bin 6968 Sep 16 14:02 /usr/bin/pfexec
- -rwsr-x--- 1 root staff 16992 Sep 16 14:05 /usr/bin/rlogin
- -rwsr-x--- 1 root staff 9536 Sep 16 14:05 /usr/bin/rsh
- -rwsr-x--- 1 root staff 18172 Sep 16 14:05 /usr/bin/su
- -rwsr-xr-x 2 root staff 104580 Sep 16 14:02 /usr/bin/yppasswd
- -r-sr-xr-x 1 root bin 13556 Sep 16 14:07 /usr/sbin/sparcv7/whodo
- -rwsr-x--- 3 root staff 18628 Sep 16 14:09 /usr/sbin/allocate
- -rwsr-x--- 1 root staff 48180 Sep 16 13:57 /usr/sbin/ping
- -rwsr-x--- 1 root staff 23564 Sep 16 14:04 /usr/sbin/sacadm
- -r-sr-xr-x 1 root bin 36888 Sep 16 13:57 /usr/sbin/traceroute
- -rwsr-x--- 3 root staff 18628 Sep 16 14:09 /usr/sbin/deallocate
- -rwsr-x--- 3 root staff 18628 Sep 16 14:09 /usr/sbin/list_devices
- -rws--x--x 1 qmailq qmail 19752 Jan 12 01:10 /var/qmail/bin/qmail-queue
- -rws--x--x 1 root other 2052296 Jan 7 01:23 /opt/local/bin/ssh1
As you can see, that's quite a few binaries. I removed the setuid bits on all of them except su,
utmp_update, ps, w and pt_chmod. I placed an ACL on su, ps and w, allowing
the 'admin' user to run them.
# getfacl su
# file: su
# owner: root
# group: sys
user::r-x
group::--x #effective:--x
mask:--x
other:--x
# setfacl -m user:admin:--x,other:---
# getfacl su
# file: su
# owner: root
# group: sys
user::r-x
user:admin:--x #effective:--x
group::--x #effective:--x
mask:--x
other:---
I did identical operations on ps and w. (In another article, I'll discuss more effective use of ACL's.) Our final tally is as follows:
- -rws--x--x 1 root staff 4436 Sep 16 14:03 /usr/lib/pt_chmod
- -r-sr-xr-x 1 root bin 7528 Sep 16 14:07 /usr/lib/utmp_update
- -r-sr-x---+ 1 root sys 28472 Sep 16 14:03 /usr/bin/sparcv7/ps
- -r-sr-x---+ 2 root bin 11976 Sep 16 14:07 /usr/bin/sparcv7/uptime
- -r-sr-x---+ 2 root bin 11976 Sep 16 14:07 /usr/bin/sparcv7/w
- -rws--x---+ 1 root staff 18172 Sep 16 14:05 /usr/bin/su
| Install compiler |
In the previous article detailing installation, we decided to install a compiler on this system
for convenience purposes. We'll use gcc. Installing it via a package, such as can be found on www.sunfreeware.com,
will allow us to remove it after we've built all the software we need, if we choose to do so. www.sunfreeware.com has packages built for versions of Solaris
from 2.5 through 8. While we'll only be getting gcc AND gzip from there, a variety of
other packages can be downloaded. Depending on how much time you want to
spend compiling your own packages, this site may be able to help you get things
done. The usual caveat of not running packages you didn't compile applies; if
at all possible, compile your own software.
Assuming you use www.sunfreeware.com to obtain a compiler, install first the
gzip package, and then the gcc package, using the standard pkgadd utility.
| Install Apache |
We next went ahead and downloaded Apache from www.apache.org, and modperl and
Embperl from perl.apache.org. Installing these, at this stage, is pretty
straightforward. We simply follow the directions as presented in the mod_perl
directory. As Solaris 8 ships with perl, we didn't need to install another
copy. However, those of you using this as a guide to installing and securing
versions of Solaris prior to 8 will need to install perl. I chose to install
this in /export/home/apache, as I will eventually be installing it chrooted.
This will be the topic of an upcoming article, so keep an eye out for it.
| Install daemontools, ucspi-tcp, qmail and dnscache |
I next went ahead and built and installed daemontools, ucspi-tcp, qmail and
various pieces of dnscache. These are all available off of cr.yp.to.
daemontools, ucspi-tcp and qmail were all installed in a fairly normal manner.
The following startup scripts were used:
#!/bin/sh
#Svscan script for running qmail-send via supervise
PATH=$PATH:/usr/local/bin
exec /var/qmail/rc
-----------------------
#!/sbin/sh
# svscan startup script, placed in /etc/init.d, linked in /etc/rc2.d
case "$1" in
'start')
[ ! -x /usr/local/bin/svscan ] && exit 0
(cd /usr/local/service; PATH=$PATH:/usr/local/bin /usr/local/bin/svscan&)
;;
'stop')
cd /usr/local/service
for i in `ls /usr/local/service`
do
svc -d $i
done
PATH=$PATH:/usr/local/bin
/usr/bin/pkill -x -u 0 -P 1 svscan
/usr/bin/pkill -x -u 0 -P 1 supervise
;;
*)
echo "Usage: $0 { start | stop }"
exit 1
;;
esac
exit 0
Follow the directions contained in the distributions; they're very straightforward.
Finally, we installed dnscache, also available off cr.yp.to. Dnscache
is also straightforward; builds cleanly, installs cleanly, and
comes with programs to configure some of its more complex features. The directions are also excellent.
Since a single machine is acting as the local dns cache, and serves internal
names for the network, we did one thing differently. Normally, a separate
machine would be used as a DNS cache and as a name server. Rather than run
hosts files, I chose to install a cache AND a nameserver for my network,
'internal', on a single machine. I simply created a clone of the loopback
device, lo0:1, with the ip 127.0.0.2. I installed tinydns, per the
instructions, and bound it to 127.0.0.2. I then told the external cache I installed
to consult 127.0.0.2 for all lookups to the .internal network. Voila. Ideally, these two applications should be on separate machines, especially if the
dns server will be serving requests from the outside.
| RPC Tips |
If you are going to be running NFS, NIS, ToolTalk, or any of the
other million or so RPC services Sun includes, you need to run
rpcbind. That's OK, just be aware that RPC has traditionally been
a weak point in most security models. NFS and NIS are started from
startup scripts in /etc/rc2.d and rc3.d, namely S71rpc, S73nfs.client and
S15nfs.server. Don't need them? Simply rm the startup scripts, or
rename them to something not beginning with an S. Make sure to edit
your /etc/inetd.conf, and remote non-essential RPC services.
Please note that removing ttdbserverd may cause OpenWindows to freeze, or
certain DeskSet tools to break. To prevent the freezing, edit the
/usr/openwin/lib/openwin-sys file, and remove the line that starts the
ttsession program.
| NFS Tips |
Over the years NFS users have graced the three letters
of the acronym with many alternative meanings -- the most famous of which bawdily references the system's level of security.
NFS isn't quite as evil as some would make it out
to be. Yes, it's pretty insecure, but it seems to be a requirement
in many environments. So here are a few steps to take to make things
better.
First, don't share your root filesystem. There is no need
to expose the entire machine. Instead, decide exactly what pieces of
data need to be shared, and work from there. Don't export things to
the world. It takes some extra work to specify what machines can mount
a share, but it's not difficult to do, and it does a lot of good in securing
some of NFS's problems. Try to export things nosuid, and only read/write if
absolutely necessary: It can be a
nuisance at times, but it prevents people from obtaining root on their
local machine and easily getting root on other machines. (Please note the
use of the word easily... NFS will definitely make it easier to do so).
Finally, use the fsirand program on filesystems that will be mounted via NFS.
This will help prevent trivial guessing of NFS file handles. If have the option,
running NFS over Secure RPC will help from the authentication standpoint, but
NFS traffic will still be visible on the wire.
| Remote Administration Tips |
Solaris 2.6 and better ship with both SNMP and DMI enabled.
Sadmind is also installed.
SNMP has some very well known holes, some protocol specific and some that are peculiar to Sun. If you're going to run SNMP, make sure to
get the latest patches. These will fix some of the problems, in a manner that
is somewhat flawed -- whatever you do, do not attempt to make their snmpd
support read/write. The daemons in question run out of /etc/rc3.d/S76snmpdx.
Change it to begin with something other than an S, and that's one more problem
eliminated. dmi is started out of S77dmi, also in /etc/rc3.d. Move this one
too if you aren't using it. sadmind runs out of inetd, so to turn it off,
simply comment out that entry and restart or HUP inetd.
| Weird Services |
A few new services have been added that you might not know about.
One such service is nscd -- the name service cache daemon. This service is meant to cache common name
service requests. This will cache domain name queries, the password file, group
file, and a few other files. The idea is to provide an on-machine cache for
common queries. Nscd goes along way in speeding up common dns queries, and
helps speed up things like NIS and NIS+. Disabling nscd can also break
certain programs (Netscape for instance). The security impact of nscd is an
unknown quantity, although early versions had definite problems: overpopulation
of the cache would result in nscd segfaulting. On a site doing large
quantities of name lookups, this can quickly become a problem. Also, the
methods nscd uses for caching aren't readily apparent. If nscd doesn't cache
the type of lookup being done, it may be possible to perform cache poisoning
attacks against machines running nscd, in a manner similar to that employed
against older versions of bind. Beware.
| Optional additions |
Allowing remote access? If you can, only allow an encrypted method
of access to be used. The most popular of these is SSH. The code has been
thoroughly scrutinized, and while occasional problems do float to the surface,
it's much better than running an unencrypted, weakly authenticated protocol
like telnet.
If you have to run RPC services, change to Wietse Venema's secure rpcbind. It
has enhanced logging and ACL capabilities. It's even based off of Sun
rpcbind source code, so you don't have to worry about incompatibilities.TCP wrappers also go a long way in tightening the services you need to run
.
Even if you aren't running "simple" services, the rule capabilities of the
libwrap library work well, and there are already hooks for the library in
popular secure service replacements like sshd.
Hopefully you're now running a machine that you can feel confident is secure.
While not every machine will conform to the guidelines we used above, certain
things remain constant: Always install as few packages as you can, run as
few services as you can, and eliminate as many setuid programs as possible.
This will go a long way in protecting your machine, now and in the future.
|
