Computer Protection Program Berkeley Lab
Computer Protection Program at Berkeley Lab Security
Ernest Orlando Lawrence Berkeley National Laboratory
Emergencies | Site Index | Contact Us
CPP Home
Contacts
Policy Guidelines
Scan Information
System Procedures
Tools & Services
ALERTS
Recent CPP Actions
News & Articles
CPP Intranet
 
 
  PROCEDURES FOR SECURING SYSTEMS  
Solaris 7 – 9 Security Guidelines [1]  

 

Introduction

 

Over the years the out-of-the-box security configuration for Solaris releases has improved considerably from a security perspective. It is nevertheless necessary to make numerous changes to Solaris systems to harden them sufficiently to enable them to resist the kinds of attacks (external and internal) that they are most likely to face. Following the steps in these guidelines will bring Solaris 7 – 9 systems up to a baseline level of security.

 

Baseline Security Measures

 

These guidelines are intended to produce a level of security that represents a reasonable balance between security and functionality/usability in Solaris systems. These guidelines describe steps to be taken including: providing adequate physical security, securing accounts and groups, securing your host's file system, securing services that run on your host, configuring logging, patching your system, and other performing additional important actions.

 

A.     Host-based and Physical Security

 

1.  If possible, put your host in a physically secure area, i.e., a server room with restricted access (such as via a card reader or combination lock).

 

2.  Secure access to boot level by assigning a strong PROM password. To do this use the eeprom command to set the security mode to “command” and then set the password.

 

3.  Change the boot sequence so that the hard drive is first. You can do this by defining the boot-device parameter in eeprom.

 

4.   Use a screen saver that requires a password. Use “lock screen” on the OpenWindows menu, or click on the lock symbol on the CDE menu bar. Additionally, set the screen saver to activate automatically after a fixed period of inactivity in Properties (OpenWindows) or Settings (CDE).

 

5.   List only the ttys that are allowed to login as root in /etc/securetty.

 

 

B. Securing Accounts and Groups

 

1.   Disable unnecessary accounts by locking them and/or assigning an invalid shell. The following accounts should normally be locked and/or disabled:

 

adm

bin

daemon

listen

lp

nobody

nobody4

noaccess

nuucp

smtp or smmsp (in Solaris 8 and 9)

sys

uucp

 

You can lock an account named “user6” by changing the entry for this account in /etc/shadow to:

 

user6:*LK*
 
OR
 
user6:*NP*

 

OR you can disable this account by assigning a shell of /bin/false in /etc/passwd:

 

foo:*:536:40:Ben Foo:/home/foo:/bin/false

 

(Note that many Solaris system administrators prefer noshell (e.g, /sbin/noshell) to /bin/false for reasons described at http://www.fish.com/titan/TITAN_Solaris9.html, which is also the site from which you can download the noshell program.)

 

2.   If your host runs the ftp service, disallow ftp access via disabled user accounts. Do this by creating /etc/ftpusers and then adding all of the following accounts to this file:

 

adm

bin

daemon

listen

lp

nobody

noaccess

nobody4

nuucp

root

smtp

sys

uucp

 

3.   Allow root access to as few other users (ideally only two or three people) as possible. Only users who are assigned system administration responsibilities should be allowed root access.

 

4.  Create a very difficult-to-guess password for all accounts, but especially the root account. See http://www.lbl.gov/ITSD/Security/systems/passwords.html#choose for guidelines concerning how to create a good password. To change a password for an account, enter:

 

% passwd <loginname>

 

Ensure that only one account, root, has a UID of 0. (Note that in some instances the smtp or smmsp account will need to have a UID of 0, too.)  Check this by entering:

 

# awk –F: ’$3 == 0’ /etc/passwd

 

This will print out only the password file lines that have UID 0.

 

The UID field is the third field in each line. Note that in the following example more than one account with a UID of 0 exists, something that should be corrected by changing the UID for the admin account to something other than 0.

 

root:*:0:0:root:/:/bin/sh

kjs:*:159:33:Wanda Smith:/home/smith:/bin/csh

admin:*:0:0:alternate root user:/:/bin/sh

 

6.  To limit who can use the su command, create a “wheel-like” group:

 

   # chgrp root /usr/bin/su

   # chmod o-x /usr/bin/su

 

Allow only users with root access to be in the root group.

 

7.   Ensure that there is an x in the second field of every line in /etc/passwd to ensure that the /etc/shadow file will be used for all access to passwords.  Note that if you run pwconv on Solaris, this will put the x in the appropriate place for each entry in /etc/passwd and will also create /etc/shadow. You will need to run pwconv after every new account is created if you are using shadow passwords.

 

8.   Ensure that there are no logins in which a password does not need to be entered by verifying that the following entry is in /etc/default/login:

 

PASSREQ=YES

 

      If this entry does not exist, add it.

 

9.   Check for accounts that do not require passwords by entering:

 

   logins –p

 

Ensure in particular that if the following default accounts exist, they are passworded (or have logins disabled):

 

demos

guest

 

10.  To ensure that passwords will be at least eight characters long (and thus more difficult to crack) and that they will be changed every 180 days, set PASSLENGTH=8 and MAXWEEKS=26 in /etc/default/passwd.

 

11.  Delete all entries in /var/spool/cron/crontabs for all deleted and disabled accounts. 
 
12. Assign appropriate permissions to restrict access to /var/spool/cron to only those who have an appropriate business-related need. 
 

 

C. Securing the File System [2]

 

1.   Ensure that root owns all files that it uses, in particular, all binaries that it uses.

  

2.   To the maximum possible extent, avoid having any file and/or directory be world-writeable. Use the chmod command to change permissions accordingly.

 

3.   Inspect all system files and directories do not allow any unnecessary read, write and/or execute access to group owner and world.

 

4.   Remove the SUID and SGID bits from all executables for which having these bits set is not clearly justifiable from a business/operational standpoint. To find all SUID files enter:

 

# find / -user root -perm -4000 -print

 

To find all SGID files enter:

 

# find / -user root -perm -2000 –print

 

To unset the SUID bit for an executable, foo, enter:

 

# chmod u-s foo  OR  chmod 0XXX

 

To unset the SGID bit for a file, foo, enter:

 

# chmod g-s foo 

 

      OR 

 

# chmod 0XXX foo

 

5.   To prevent users other than the owner of files in a temporary directory (/tmp and /var/tmp) from modifying or deleting them without authorization, ensure that the sticky bit is set in each. To set the sticky bit in the /tmp directory, for example, enter:

 

# chmod 1777 /tmp 

 

        OR

 

# chmod o+t /tmp

 

D. Securing Services

 

1.   Disable every service that is not necessary for business/operational purposes. When you evaluate which services are necessary, pay particular attention to the following services, in which vulnerabilities are generally exploited more than in other services:

 

uucp

echo

discard

daytime

chargen

sprayd

walld

exec

talk

finger

telnet

comsat

cmsd (calendar manager daemon)

kcms_server

cachefsd (cache file system daemon)

dtspcd (desktop subprocess control daemon)

sadmind

tooltalk

snmpXdmid

bootp

tftp

ftp (unless your host must be an ftp server)

http (unless your host must be a web server)

every r utility (rusers,  rquotad, rsh, rlogin, and so on)

 

You can disable some unnecessary services by disabling the startup file (if it exists) for each service that is unnecessary. Go to /etc/rc2.d and /etc/rc3.d. and change the capital “S” in the name of the script to a lowercase “s” to disable each service. (Note: in some system administrators’ thinking “s” is too close to “S;” they thus use “d” instead of “s” to disable scripts that start services.)

 

You should NOT disable any of the following startup files:

 

S01MOUNTFSYS

S05RMTMPFILES

S20sysetup

S30sysid.net

S69inet

S71rpc

S71sysid.sys

S72inetsvc

S74autofs

S74syslog

S74xntpd

S75cron

S75savecore

S80PRESERVE

S88utmpd

S99audit

 

Additionally, comment out the names of any unnecessary services in /etc/inetd.conf. To be sure that changes are made, enter:

 

# /etc/telinit -q

 

And then reboot [3] by entering:

 

# init 6

 

2.   Ensure that each startup script runs with the proper umask by running the following script as root:

 

umask 022

echo “umask 022” > /etc/init.d/umask.sh [4]

chmod 544 /etc/init.d/umask.sh

for d in /etc/rc?.d

do

ln /etc/init.d/umask.sh $d/S00umask.sh

done

 

3.   Use ssh for remote logins in lieu of more dangerous services such as telnet, rlogin, rsh, and rcp. For information about configuring and using ssh visit http://www.lbl.gov/cyber/systems/ssh.html#unix. 

 

If possible, allow inbound connections via sshd, not inetd. To render inetd inoperable, comment out every line in /etc/inetd.conf Also, turn off by renaming S72inetsvc, which contradicts your information above about not renaming it.

 

4.   Use a TCP wrapper to limit inbound connections based on type of service and IP address and to provide additional log data concerning attempted connections to your host. In /etc/default/inetd change the default entry for the ENABLE_TCPWRAPPERS to YES, i.e.:

 

ENABLE_TCPWRAPPERS=YES

 

Create the following entry in /etc/hosts.deny:

 

ALL: ALL

 

Create entries in /etc/hosts.allow for all hosts allowed to have inbound access, e.g.:

 

ALL: LOCAL @<netgroupname>

 

OR

 

ALL: .lbl.gov EXCEPT secure1.lbl.gov