HostedDB - Dedicated UNIX Servers

Protecting Sun systems v 1.0
by Jeffrey Boulier

Please note: this is a work in progress! Go here

for the latest version.

Note to GWU users: most of this is taken from sun-setup.txt

_-_ _,,                               -_-/              
   -/  )    _          '             (_ /               
  ~||_<    < \,  _-_, \\  _-_       (_ --_  \\ \\ \\/\\ 
   || \\   /-|| ||_.  || ||           --_ ) || || || || 
   ,/--|| (( ||  ~ || || ||          _/  )) || || || || 
  _--_-'   \/\\ ,-_-  \\ \\,/       (_-_-   \\/\\ \\ \\ 
  -_-/                              ,         
 (_ /                           '  ||         
(_ --_   _-_   _-_ \\ \\ ,._-_ \\ =||= '\\/\\ 
  --_ ) || \\ ||   || ||  ||   ||  ||   || ;' 
 _/  )) ||/   ||   || ||  ||   ||  ||   ||/   
(_-_-   \\,/  \\,/ \\/\\  \\,  \\  \\,  |/    

Once you've gone through the initial install of a Sun system, you don't
want to just leave it around for hackers to destroy. Here are some basic
steps to help protect your system from the evil that lurks within your
firewall (assuming you're one of the lucky who have one!).

I) Reconfigure your kernel parameters by editing /etc/system.

/etc/system is a file containing various kernel settings. Become root and
open it up with an editor (vi if you are at a terminal or have some Unix
experience, /usr/openwin/bin/textedit if you are in a graphical session
and are not familiar with Unix).

Go down towards the bottom of the file, and add the following

******* security settings entered mon/day/year by YOURNAME
set noexec_user_stack=1
set noexec_user_stack_log=1
******* performance setting entered mon/day/year by YOURNAME
set priority_paging=1

SECURITY: These variables help protect the system against attack by
hackers by making it much harder for them to break in by using Stack
Overflows. In a nutshell, the creep will take a program which runs as root
and overflow the program's stack. Unable to handle the flow, the program
executes what it was given as root -- perhaps something that e-mails death
threats to the president every time you log in.

Without the "execution" bit turned on in the stack or its log, most of
these buffer overflows will fail to work. It's possible to get around this
kernel protection, but puts a pretty substantial barrier in the hacker's
way. A protected kernel will also send an entry into the syslog if it
catches the attempt.

The above security settings are valid for Solaris 2.6 and higher.

PERFORMANCE: No memory is unused memory on a Sun. All not currently being
used by programs or the operating system is used to cache files,
preventing the system from needing to go to the much slower disk to reread
a file or program. Turning priority_paging on alters the algorithm that
the Sun uses when deciding which files in the cache to keep and which to
toss, giving you even more effective use of your memory.

priority_paging is available starting with late kernel revisions of
Solaris 2.5.1 and on.

II) Turn off unneeded services in inetd.conf

        There are many services automatically enabled that really don't
need to be. There have been and probably always will be holes in these
services that will potentially allow some user of in Greenland to take
over your machine without him even having an account. Disable these
unneeded programs to protect your machine. You may disable them like this:

        0) Become root
        1) Edit /etc/inetd.conf with Your Favorite Editor

        Services that are inactive are commented out by putting a '#' sign
in front of them. For example, part of your default inetd.conf file looks
like this:

# Tnamed serves the obsolete IEN-116 name server protocol.
name   dgram   udp     wait    root    /usr/sbin/in.tnamed     in.tnamed

        You don't want this, because 99.999% of you aren't using "the
obsolete IEN-116 name server protocol". Comment it out so the line looks
like this:

# Tnamed serves the obsolete IEN-116 name server protocol.
#name   dgram   udp     wait    root    /usr/sbin/in.tnamed     in.tnamed
Note the new "#" sign!

        I suggest at least commenting out most services, perhaps leaving
something like:

ftp     stream  tcp     nowait  root    /usr/sbin/in.ftpd       in.ftpd
telnet  stream  tcp     nowait  root    /usr/sbin/in.telnetd    in.telnetd
rstatd/2-4      tli   rpc/datagram_v wait root /usr/lib/netsvc/rstat/rpc.rstatd rpc.rstatd
100083/1        tli     rpc/tcp wait root /usr/dt/bin/rpc.ttdbserverd rpc.ttdbserverd
100221/1        tli     rpc/tcp wait root /usr/openwin/bin/kcms_server kcms_server
fs              stream  tcp     wait nobody /usr/openwin/lib/    fs
100234/1        tli     rpc/ticotsord   wait    root    /usr/lib/gss/gssd gssd 
dtspc stream tcp nowait root /usr/dt/bin/dtspcd /usr/dt/bin/dtspcd

	As far as I'm aware, this *minimal* level of protection would
break no Sun application in use at GW. Your site may be different.

	Once you've made the changes, send a "HUP" signal to inetd's 
process id.

		kill -HUP inetd-pid-goes-here

        On servers which will not be running CDE, and/or should be
particularly secure, you will want to comment out all services except for
FTP and telnet. In fact, on servers that need to be *really* secure, you
might want to comment out telnet and ftp and only allow logins from the
console or via SSH (installing SSH to be discussed later in this article).

        You can use "grep" To find out what services currently available
on your machine through inetd.

                grep -v "^#" /etc/inetd.conf

This returns all lines in /etc/inetd.conf which *don't* (the -v) have a
comment character (the #) at the start (the ^) of the line.

III) On Solaris 7 and higher, make your filesystems "logging" for better
crash protection and faster speed.

Edit /etc/vfstab

Go to the "options" field next to all your filesystems with FS type ufs.
Replace the "-" with "logging" (no quotes!) The improvement will take
place the next time you mount your filesystem.

IV) Stop daemons you are not using from starting!

Chances are you are not using nfs, cachefs, running an Enterprise 10000 on
your desktop, nor have you the desire to continually receive SNMP errors.

The following is a set of commands which move some of these non-essential
startup scripts out of the way. Note that what we're doing is really just
making the first letter of each program name lowercase. Suns ONLY start
programs beginning with capital S in the /etc/rc*.d directories upon
startup; by switching the name to lowercase, you make it easy to go back
and re-add the service, if, for example, it turns out that you do want to
use NFS.

#snmp not needed
mv /etc/rc3.d/S76snmpdx /etc/rc3.d/s76snmpdx
mv /etc/rc3.d/S77dmi /etc/rc3.d/s77dmi
# I am not an nfs server
mv /etc/rc3.d/S15nfs.server /etc/rc3.d/s15nfs.server
#I'm not mounting files from an  NFS server
mv /etc/rc2.d/S73nfs.client /etc/rc2.d/s73nfs.client
# Nor am I running cachefs
mv /etc/rc2.d/S73cachefs.daemon /etc/rc2.d/s73cachefs.daemon
mv /etc/rc2.d/S93cacheos.finish /etc/rc2.d/s93cacheos.finish
#I'm not using ntp for time synchronization
mv /etc/rc2.d/S74xntpd /etc/rc2.d/s74xntpd
#I'm not an Ultra 10000
mv /etc/rc2.d/S99tsquantum /etc/rc2.d/s99tsquantum 
#I'm not using the automounter (generally NIS, NIS+ use this)
mv /etc/rc2.d/S72autoinstall /etc/rc2.d/s72autoinstall

Other things to consider getting rid of include:

# If sendmail doesn't need to be run as a daemon
# on this box....
mv /etc/rc2.d/S88sendmail /etc/rc2.d/s88sendmail
# This system doesn't print, or send print jobs to systems which do:
mv /etc/rc2.d/S80spc /etc/rc2.d/s80spc
mv /etc/rc2.d/S80lp /etc/rc2.d/s80lp
# I don't want the CDE login screen to automatically start on this system
mv /etc/rc2.d/S99dtlogin /etc/rc2.d/s99dtlogin
# The sysadmin can mount the CD manually, without volume manager's assistance
mv /etc/rc2.d/S92volmgt /etc/rc2.d/s92volmgt

IV) It is now time to patch your system. Patching should be done on a
regular basis. If you are running a system which has already been hammered
down (no CDE, most ports closed off) then as a rule of thumb, I'd suggest
"patch *at least* every three months or when you have problems".  System
administrators for inherently insecure time-sharing systems *OR WHO ARE
PARTICULARLY SECURITY-CONSCIOUS* should keep a careful eye on the latest
sets of patch reports and apply fixes ASAP when patches for potential root
comprimises are available.

A check-patches ksh/perl script is available which checks the difference
between the currently installed patches and those listed in the patch
report, breaking things down into security/recommended/both/neither
sections. Let me know if you there's a demand, and I'll put it on a

More usefully, I wrote a shell-script called "getpatches" which grabs the
latest security & recommended patches from sun, unpackages them, cleans
out the ones that have already been installed, and sets up the remaining
patch cluster for your use. The latest version is available from

Download getpatches, change it to be executable by typing

	chmod +x getpatches

and run it


once you've run getpatches, shutdown your system to the OK prompt with

		/usr/sbin/shutdown -y -g0 -i0

and then reboot into single user mode:

		boot -s

and install the patches you got with getpatches. (getpatches should
tell you how to install them, if you've never patched your system

Once they are installed, shut your machine down again: 

                /usr/sbin/shutdown -y -g0 -i0 

and "boot" it back normally:


Note that particularly crafty system administrators can install certain
patches without taking the whole system down. When Sun
front-line support tells you never to patch a running system, they're
reading from a script. You can use lsof to tell you if a file/library is
in use; if it is not, or the app using it can be shut down without turning
the system off, chances are that the relevant patch can be applied
(though I disclaim any responsibility if it crashes your system!)

Further note that patching can put back startup scripts you removed in
/etc/rc*.d and/or restore 'suid' capability to files from which it has
been taken, so check your system after you've patched!


You may fetch all sorts of pre-compiled utilities
from a wonderful place called, and/or its 
corresponding FTP site,

I suggest gcc, gzip/gunzip, and top as "must have" packages, though
they're not extraordinarily security related. 


You can download the source code for tcp-wrappers from

Tcpwrappers is used to allow you to build access control lists based on
IP-addresses. For example, you can set things up to allow FTP from
everywhere except the domain, and allow telnets only from your
126.12 subnet.

 To install, edit the Makefile, uncomment the entry listed under
Solaris 2.x so it looks like


if you don't have a "real" C compiler, change the entry under "sunos5" so
it looks like

	@make CC=gcc REAL_DAEMON_DI...

save and exit.
Then type 


To install, type 

cp tcpd /usr/sbin/tcpd
cp tcpdchk /usr/sbin/tcpdchk
cp libwrap.a /usr/lib
cp tcpd.h /usr/include
cp tcpdmatch /usr/sbin/tcpdmatch

mkdir -p /usr/share/man/man3
mkdir -p /usr/share/man/man8

cp *.5 /usr/share/man/man5
cp *.8 /usr/share/man/man8
catman -w

chmod 755 /usr/sbin/tcpd /usr/sbin/tcpdchk /usr/lib/libwrap.a 
chmod 755 /usr/sbin/tcpdmatch
chmod 755 /usr/include/tcpd.h

Edit /usr/share/man/ and put ",8" at the end.

then create your hosts.allow (use tcpdchk to see if it works correctly!)

Here is a sample /etc/hosts.allow, it allows connections to all protected
services from within the 128.164 subnet and the local machine only:

ALL: 128.164. ALLOW
^     |     ---------------------------+
|     +-------+                        |
service       |                      Action
         IP addresses, domain
         names, etc.

and modify inetd.conf. Edit it so the entries for wrapped services look like:

ftp     stream  tcp     nowait  root    /usr/sbin/tcpd  in.ftpd
telnet  stream  tcp     nowait  root    /usr/sbin/tcpd  in.telnetd

and then kill -HUP the inetd process.

You can download ssh from

To compile, first

./configure --with-libwrap   ### You did compile tcpwrappers, first,right?
                             # also make sure /usr/openwin/bin is inyour
                             # path

make install      ###There will be lots of errerz from "mv"
                  ### it is trying to preserve an older install of ssh
                  ### which, in point of fact, you don't have yet. Ignore
                  ### them.

And then you need to put a startup script in /etc/rc3.d so it starts
itself up properly.

Create and edit a file called /etc/rc3.d/S85sshd
# Startup for Secure Shell

case "$1" in
        PID=`/usr/bin/ps -ef |grep /usr/local/sbin/sshd|grep -v grep|awk '{print $2}'`
        if [ -z "$PID" ] ; then
                echo "Starting Secure Shell Daemon"
        PID=`/usr/bin/ps -ef | grep /usr/local/sbin/sshd | awk '{print $2}'`
        if [ ! -z "$PID" ] ;  then
                /usr/bin/kill ${PID} 1> /dev/null 2>&1
        echo "Usage: /etc/init.d/sshd { start | stop }"
exit 0


And then chmod 755 /etc/rc3.d/S85sshd



More places to go for security help:

The Sun fingerprint database, located at :

can tell you if one of your OS files is non-standard, possibly because
it's a trojan horse left behind by the invader.

Sunworld magazine's security FAQ:

"Fixsolaris" - Particularly, pay attention to  the 'lockdown' section.

VII) Mailing lists & Other Resources: has the quintessential low-volume security mailing list, and
is the place you want to go to report hacking incidents. Many articles
are well worth perusal. This is the grandaddy of all security sites. has a great mailing list, though it's not as exhaustively
reviewed as I'd like.  For a free subscription, e-mail with
the subject: Subscribe NewsBites

VIII) Other swell places to go: <- Links and hosts  many wonderful Sun resources <- My personal site. Have fun with your Sun! <- great for your internal or external internet-based
		training programs, if we do say so ourselves.

Coming soon! The lesson plan/notes from my security seminar!