Hardening Solaris with Yassp

Secure installation of Bastion hosts

By SeŠn Boran
www.boran.com/security/sp/Solaris_hardening3.html

This article presents a concise step-by-step approach to securely installing Solaris for use in a firewall DMZ or other sensitive environment, using the Yassp tool (and with Solaris 8 the Sunscreen EFS lite firewall).

This article was written (and tested) for Solaris 2.6/7/8, but the techniques described here should work fine on earlier versions too. This article has been updated since the original release, see the section Changes to this article.

DRAFT: Yassp beta#15

Your feedback is welcome.


The hardening process is divided into the following steps:

  1. Preparation
  2. Initial OS installation
  3. Install YASSP
  4. Mounting file systems restrictively in /etc/vfstab
  5. Solaris 8: Install Sunscreen EFS
  6. More hardening: routing, email, resolver, tools
  7. Patches
  8. RPC
  9. Logging, Cron, Permissions
  10. Limiting SUID Files
  11. Install an Integrity Checker: e.g. Tripwire
  12. Install, test, harden applications
  13. Going Live

Regular maintenance
Yassp Overview
Additional Notes
References
Changes to this article


1. Preparation


2. Initial OS installation

Connect the serial console, switch on, halt to the OK prompt by sending a Stop-A (~#, ~%b, or F5 depending on whether you use tip, cu or a vt100 terminal), then start the installation procedure:  boot cdrom - install .
Note: On Solaris 8, make sure your use "Software CD#1" and not the "Installation CD".

Install the end user bundle (or even better only the core packages which take only 110MB), set hostname, terminal, IP parameters, timezone, etc. Don't enable any naming services like NIS or NFS. Don't enable power management, or mount any remote file systems (NFS).
Note: On Solaris 8, the user bundle can be customised via "F4", packages can be added or removed.

Choose manual disk partitioning:

Reboot.

Set a strong password (7 or 8 chars with numbers, letters and punctuation) for root.

The installation is documented in /var/sadm/install_data/install_log

Next, we install man pages not included in the User Bundle and the recommended patches.

C-shell fans:

If you use the C-Shell, the following will make command-line editing easier and enable history functions:

csh;
setenv TERM vt100;
setenv VISUAL vi;
setenv EDITOR vi;
set filec;
set history=40;
alias h history;
alias ls 'ls -aF \!*';

No man pages are installed with the user bundle, so install them while the Solaris CD is still mounted. Note: if you only installed the core bundle, SUNWlibc is needed for viewing the man pages (which needs sgml2roff), so add this package as well if needed (it is on CD#1 on Solaris8).

cd /cdrom/cdrom0/s0/Solaris_2.6/Product;
pkgadd -d . SUNWman SUNWdtma SUNWjvman SUNWpmowm SUNWolman SUNWxwman

cd /cdrom/cdrom0/s0/Solaris_2.7/Product;
pkgadd -d . SUNWman SUNWdtmaz SUNWdtma SUNWjvman SUNWpmowm SUNWxwman

On Solaris 8, insert CD#2. To save space, the man pages could be limited to the standard ones and java:

cd /cdrom/cdrom0/Solaris_*/Product;
pkgadd -d . SUNWman SUNWjvman SUNWj2man

While we're here, we'll install compression tools (needed to unpack

Core install notes:

"core" bundle users may wish to add other useful packages now, for example:

Terminfo: SUNWter
Accounting: SUNWaccr SUNWaccu
NTP: SUNWntpr SUNWntpu
UCB tools: SUNWscpu
Man pages tools: SUNWlibC SUNWdoc

Yassp), zlib (for OpenSSH) and bash/tcsh (because they are nice shells :).
pkgadd -d . SUNWgzip SUNWbash SUNWbzip SUNWtcsh SUNWzlib

Update indices, so that "man -k keyword" will allow searching of relevant man pages:

/usr/lib/makewhatis /usr/man;
/usr/lib/makewhatis /usr/openwin/man;

Download (e.g. to /opt/install) and install the latest recommended and security patch bundle from Sun:

Solaris URL
2.6 SPARC ftp://sunsolve.sun.com/pub/patches/2.6_Recommended.tar.Z
7 SPARC ftp://sunsolve.sun.com/pub/patches/7_Recommended.zip
7 Intel ftp://sunsolve.sun.com/pub/patches/7_x86_Recommended.zip
8 SPARC ftp://sunsolve.sun.com/pub/patches/8_Recommended.zip
8 Intel ftp://sunsolve.sun.com/pub/patches/8_x86_Recommended.zip

These files can be many tens of megabytes, since they cover all Solaris packages, not just those relevant to your installation. 
When the bundled is unzipped, it creates a subdirectory.

a) On a new system where de-installation is unlikely to be necessary, install without being able to remove patches. This will save lots of disk space:
cd 8_*Recommended;
./install_cluster -nosave

b) Installation on an existing system, or where de-installation of the patches must be possible if the patch cluster messes things up (this will take more disk space as copies are saved in /var/sadm/patch). Patches can only be individually de-installed, there is not "deinstall_cluster" functionality.
./install_cluster

Reboot and logon again as root.

Note: patches will be checked and updated again, in more detail, in the Patch section below.


3. Install YASSP

Yassp (Yet Another Solaris Security Package) is a tool for hardening Solaris, that also includes several other security tools precompiled. We use Yassp because it is comprehensive, is a consensus of security experts, can be backed out and has been tested by many people. It's not perfect though, if this is your first encounter with Yassp, read the Yassp section first before proceeding.

Here we present detailed installation and configuration instructions for Yassp. Note that after installing Yassp, a backup of all files changed will be available in /yassp.bk/Before_DATE.

 

SSH note:

SSH is a good thing, it should be considered essential for any UNIX box. There are several SSH variants (see the SSH section). Yassp bundles OpenSSH, but there are a few issues:

  • SecurID authentication is not yet supported (use SSH1 for that).
  • The Solaris package SUNWzlib must be installed first.
  • Binaries are only available Solaris 8 (they are not backwards compatible)

First: Record a log of all command actions/taken in the this section, by running:

script -a /yasspinstall.log
which will keep a log of all commands and results in yasspinstall.log. This may be useful for browsing through later and is useful audit documentation.

Download yassp.tar.gz [1] (having verified it's PGP signature) to the target, e.g. to /opt/install.

Shutdown the network interface during this next phase, just in case (the interface name depends on the architecture e.g. le0 on old SPARCs):

ifconfig hme0 down

Extract Yassp:

gunzip <yassp.tar.gz | tar xf - 
which will create a yassp subdirectory
cd yassp; ls -l
drwxr-xr-x 2 7644 7001 512 Nov 20 06:54 RCS
-r-------- 1 7644 100 14482 Nov 20 06:54 README
-r--r--r-- 1 7644 100 8418 Nov 20 06:52 WhatIsNew
-rw-r--r-- 1 7644 7001 66 May 21 2000 admin
-rw-r--r-- 1 7644 100 61952 Nov 20 01:20 aubtocsin
lrwxrwxrwx 1 7644 100 9 Nov 22 10:13 aubtocsin_i386 -> aubtocsin
lrwxrwxrwx 1 7644 100 9 Nov 22 10:13 aubtocsin_sparc -> aubtocsin
-rw-r--r-- 1 7644 100 136192 Nov 20 06:54 gnugzip_i386
-rw-r--r-- 1 7644 100 147456 Nov 20 06:54 gnugzip_sparc
-rw-r--r-- 1 7644 100 903168 Nov 20 06:54 gnurcs_i386
-rw-r--r-- 1 7644 100 1021952 Nov 20 06:54 gnurcs_sparc
drwxr--r-- 3 7644 100 512 Nov 20 06:53 html_doc
-r-xr-xr-x 1 7644 100 5323 Nov 20 05:25 install.sh
-rw-r--r-- 1 7644 100 3180544 Nov 20 06:54 openssh_i386
-rw-r--r-- 1 7644 100 4121600 Nov 20 06:54 openssh_sparc
-rw-r--r-- 1 7644 100 26624 Nov 20 06:54 parcdaily
lrwxrwxrwx 1 7644 100 9 Nov 22 10:12 parcdaily_i386 -> parcdaily
lrwxrwxrwx 1 7644 100 9 Nov 22 10:12 parcdaily_sparc -> parcdaily
-rw-r--r-- 1 7644 100 231936 Nov 20 06:54 prftripw_i386
-rw-r--r-- 1 7644 100 293888 Nov 20 06:54 prftripw_sparc
-rw-r--r-- 1 7644 100 1290240 Nov 20 06:54 secclean
lrwxrwxrwx 1 7644 100 8 Nov 22 10:12 secclean_i386 -> secclean
lrwxrwxrwx 1 7644 100 8 Nov 22 10:12 secclean_sparc -> secclean
-rw-r--r-- 1 7644 100 271360 Nov 20 06:54 wvtcpd_i386
-rw-r--r-- 1 7644 100 609792 Nov 20 06:54 wvtcpd_sparc

Run the Yassp installation:

./install.sh

The installation can be automated, but by default, the user is prompted to allow installation and specify the list of binary programs to install.  The default is to install the following packages: SECclean GNUrcs GNUgzip PARCdaily WVtcpd (includes rpcbind), PRFtripw and also OPENssh.
We assume here that all packages are installed.

This installs the above packages and runs the hardening script SECclean, which tightens file permissions/system configuration, tunes tcp/ip, disables most services etc. It can take one hour to run on a slow machine.

An example of yassp output is yassp_install.txt.

Workaround for limitations in Yassp beta #15:

  1. SSH:
    • Yassp will not install SSH on Solaris 7 or earlier versions. Binaries are only available for Solaris 8. (see the SSH sidebar).
    • The server side of scp will not work as expected without the following:
      chmod 755 /usr/local /opt/local
      ln -s /usr/local/bin/scp /usr/bin/scp
  2. Solaris 8 10/00 includes a new daemon 'picld', not covered by Yassp. The man page says: "Platform Information and Control Library (PICL) provides a mechanism to publish platform-specific information for clients to access in a platform-independent way. picld maintains and controls access to the PICL information from clients and plug-in modules. "
    Consider disabling it:
    mv /etc/rcS.d/S95picld /etc/rcS.d/.S95picld
    mv /etc/init.d/picld /etc/init.d/.picld
  3. Tocsin (from Doug Hughes) is a 'featherweight' Intrusion Detection System. A binary package is included in the Yassp tarball, but not automatically installed.  Read the Tocsin notes below and install it if needed:
    pkgadd -d aubtocsin
Configuring Yassp

Having installing Yassp, the first thing to do is browse the man pages yassp.conf(4) and yassp(1) and have a look at the configuration /etc/yassp.conf. Typically nothing needs to be enabled for bastion hosts, except ssh access. /etc/yassp.conf is well commented and should be easy to understand.

  1. Accounts:
  2. Cron:
  3. SSH: Yassp has installed an SSH client and server, with a pretty tight configuration.
  4. Syslog: On Solaris 8, Yassp will start syslog with the "-t" option, so it will not accept syslog connections from other hosts. So, if you want to run a central syslog server, set SYSLOGFLAGS="" .
  5. If INETD services are needed, set RUNINETD to YES and uncomment the appropriate line in /etc/inetd.conf. By default, all inetd.conf services have been disabled by Yassp -- reopen specific services, only if absolutely needed. Use tcp wrappers if possible (examples for finger and tftp are listed in inetd.conf), and edit the tcp wrapper access control files /etc/hosts.allow and /etc/hosts.deny.
  6. nscd daemon:
  7. Edit login banners to warn users about unauthorised access, you may need this if you want to prosecute intruders. For Telnet and SSH, use /etc/issue (for pre-login) and /etc/motd (for post-login). Default banners are installed by yassp.
  8. Yassp tunes Solaris by adjusting /etc/system, these may need further modification.
Reboot, check processes

Switch off the scripting, remove the install directory if desired.

# exit
Script done, file is /yasspinstall.log

# cd; rm -rf /opt/install/yassp

Warning: if you are installing via the Network, rather than the console (which is not recommended), then don't reboot the system until Yassp hasn't been configured (see above), for example to allow network login via SSH.

Now reboot for the changes to have effect:

# reboot

Check for error messages on the console, fix if necessary.  Login as root and check the process list, it should be something like the following example for Solaris 8:

UID PID PPID C STIME TTY TIME CMD
root 0 0 0 11:01:48 ? 0:01 sched
root 1 0 0 11:01:51 ? 0:00 /etc/init -
root 2 0 0 11:01:51 ? 0:00 pageout
root 3 0 0 11:01:51 ? 0:00 fsflush
root 375 1 1 11:03:32 console 0:00 -sh
root 151 1 0 11:02:13 ? 0:00 /usr/sbin/cron
root 153 1 0 11:02:14 ? 0:00 /usr/sbin/syslogd -t
root 440 375 1 11:03:46 console 0:00 ps -ef
root 390 1 36 11:03:34 ? 0:09 /opt/local/sbin/sshd

check the network connections, only ssh and possibly syslog (Solaris 7 and younger) should be listening:

netstat -a

UDP: IPv4
Local Address Remote Address State
-------------------- -------------------- -------
*.* Unbound

TCP: IPv4
Local Address Remote Address Swind Send-Q Rwind Recv-Q State
-------------------- -------------------- ----- ------ ----- ------ -------
*.* *.* 0 0 24576 0 IDLE
*.ssh *.* 0 0 32768 0 LISTEN
*.* *.* 0 0 32768 0 IDLE

In the next sections we run through additional configuration, not directly covered by Yassp.


4. Mounting file systems restrictively in /etc/vfstab

Several options can be set to improve the security and robustness of filesystems when they are mounted. Run the mount command to check that filesystems options are effective.

Mount option OS Description When to use it
nosuid 2.x Disables SUID programs, but also disables devices! /var or /home or data disks where no SUID programs, or devices (and hence chroot environments are used).
/tmp won't work either, unless it is on disk.
logging 2.7 or later keeps a transaction log within the mounted partition. The advantage is an almost instantaneous filesystem check - which may take a considerable while with larger hard-disks, e.g. 50 GB. The disadvantage is the additional time spent writing the transaction log. /usr /opt /home

Recommended for all file systems except: root (if Veritas VxVM is used), or where file write performance is critical.
noatime 2.7 or later allows mounting file systems without updating inodes at each access to any file. This will significantly speed up services like web caches or news servers, which do a lot of file IO with small files. /var or any partition where lots of file access are expected (web cache or news partitions).
size=100m 2.5.1 or later Allow /tmp to only use 100MB of swap space. The value could be set to say 30% of swap space. /tmp
ro 2.x Read-only

Mounting filesystems read-only provides only a limited protection against Trojans/attackers (if they get root, they can remount read-write).

It may save time fsck'ing when booting, can improve performance (access times don't need to be updated) and can prevent the sysadmin from making mistakes or help detecting mistakes (accidentally deleting files etc.).

Mounting read-only is a major argument for maintaining separate file systems for /usr or /opt.

Note that to mount /usr read-only, /usr/local often needs to be on a different partition.

Be very careful when editing vfstab, e.g. an error on the / or /usr lines can render the system unbootable! If this happens, boot from cdrom in single user mode, mount the problem disk, correct vfstab and reboot. Some examples of vfstab entries are:

A simple server with only a root and /var partition, running Solaris 2.8:

fd                -                  /dev/fd fd - no -
/proc             -                  /proc proc - no -
/dev/dsk/c0t3d0s1 -                  -    swap  - no  logging
/dev/dsk/c0t3d0s0 /dev/rdsk/c0t3d0s0 /    ufs   1 no  logging
/dev/dsk/c0t3d0s7 /dev/rdsk/c0t3d0s7 /var ufs   1 no  logging,nosuid,noatime
swap              -                  /tmp tmpfs - yes size=100m

and on a larger server:

fd                -                  /dev/fd fd - no -
/proc             -                  /proc proc - no -
swap              -                  /tmp tmpfs - yes size=200m 
/dev/dsk/c0t8d0s0 /dev/rdsk/c0t8d0s0 /    ufs   1 no  logging
/dev/dsk/c0t8d0s1 -                  -    swap  - no  -
/dev/dsk/c0t8d0s4 /dev/rdsk/c0t8d0s4 /usr ufs   1 no  logging
/dev/dsk/c0t8d0s6 /dev/rdsk/c0t8d0s6 /var ufs   1 no  nosuid,noatime,logging
/dev/dsk/c0t8d0s5 /dev/rdsk/c0t8d0s5 /opt ufs   2 yes logging
Reboot to allow the vfstab values to have effect.

5. Solaris 8: Install Sunscreen EFS

For maximum protection, a local firewall can be installed:

  1. On Solaris 8, the iPlanet CD#2 contains among other things, a restricted edition of the Sunscreen EFS lite firewall. It can also be download for free from Sun.
  2. IPfilter [20] can be used as an alternative for older Solaris versions.

Sunscreen lite can be used to protect network communications to the local machine (among other things).  Below we present a quick overview of setting up some simple rules on the command line, see [9] for a detailed discussion of Sunscreen configuration.

# cd /opt/SUNWicg/SunScreen/bin;
# ./ssadm active
Active configuration: www default Initial.2
# ./ssadm edit Initial
edit> list rule
1 "common" "*" "*" ALLOW
edit> list address
"*" RANGE 0.0.0.0 255.255.255.255
"le0.net" RANGE 176.17.17.0 176.17.17.255
"localhost" HOST
"smtp-server" HOST 1.1.1.1
"www_le0" GROUP { } { }
edit> list service common
"common" GROUP "tcp all" "udp all" "syslog" "dns" "rpc all" "nfs prog" "icmp all" "rip" "ftp" "rsh" "real audio" "pmap udp all" "pmap tcp all" "rpc tcp all" "nis" "archie" "traceroute" "ping"

So we see that the default policy allows quite a few services through.

Let's presume that we are setting up a HTTPD server (on port 80) and intend to manage it via SSH. We also want to allow ping and traceroute for initial trouble shooting. We could then create and active the new firewall policy restricting access to these services as follows

# ./ssadm edit Initial
edit> add service ssh      SINGLE FORWARD "tcp" PORT 22
edit> add service myhttp GROUP ping traceroute ssh www
edit> replace rule 1 ALLOW myhttp "*" "*"
edit> list rule
1 "myhttp" "*" "*" ALLOW
edit> save
edit> verify
Configuration verified successfully (not activated).
edit> quit
www# ./ssadm activate Initial
Configuration activated successfully on www.

Voila!

# cd /opt/SUNWicg/SunScreen/bin;
# ./ssadm edit Initial
edit> add address mgt_net RANGE 176.17.17.0 176.17.17.255
edit> add service mgt GROUP ping traceroute ssh
edit> add service https SINGLE FORWARD "tcp" PORT 443
edit> add service outgoing GROUP ping traceroute dns
edit>
edit> replace rule 1 ALLOW www "*" localhost
edit> replace rule 2 ALLOW https "*" localhost
edit> replace rule 3 ALLOW mgt mgt_net localhost
edit> replace rule 4 ALLOW outgoing localhost "*"
edit> replace rule 5 ALLOW smtp localhost mgt_net
edit>
edit> save
edit> verify
Configuration verified successfully (not activated).
# ./ssadm activate Initial
Configuration activated successfully on www.

Now test the network connections, to ensure the rules have the desired effect. To rollback to the initial configuration, delete all rules and add:

replace rule 1 ALLOW "common" "*" "*"

Finally, we can stop the remote Firewall management GUI. Why would we do this? If we are comfortable with the command line "ssadm" then one daemon more and one more configuration interface, that needs to be correctly configured and watched.

Disabling the following line in /etc/rc2.d/S63sunscreen
$SS_LIBDIR/run_httpd start efshttpd

In /opt/SUNWicg/SunScreen/lib/ss_boot, disable:
$SS_LIBDIR/ssadmserver start >/dev/console 2>&1

See also [9] for a detailed discussion of Sunscreen configuration.


 

6. More hardening: routing, email, resolver, tools

The system has now gone through a first hardening phase and should be still working! Boot and login on the console as root. Check for error messages on the console, fix if necessary.


Reboot, check for errors.

Install tools and scripts: All tools should already have been compiled and tested extensively on another machine.

 


7. Patches

Wait, don't skip to the next section just yet! Yes, patches make us all yawn... are they a waste of time? This sections presents some strategies for handling patches and tools to make life easier.

During installation, the Solaris recommend patch bundle was installed. However, not all security fixes are included in this bundle, and as time goes by you'll have to check regularly for new patches. Systems which have security patches installed are more secure than those which don't. For overview of the concepts of Solaris Patching, see "A SunSolve Patch Primer"  [15].

Patch strategies

Weakness are continually discovered in Solaris and 3rd party applications. Not only do the weakness pose threats but the volume of weaknesses and patches can be a threat: if not managed carefully, they will consume too much time or they will be simple ignored.

The first problem is to be aware that weaknesses and/or patches actually exist. Possible strategies are:

  1. Get on all the mailing lists of organisations such as CERT/First, vendors like Sun, and especially Bugtraq. This can consume quite a lot of time.
  2. Get on the mailing list of an organisation which produces regular summaries of weakness/patches and security news, for example , SecurityFocus (Sun section/ email list) or SANS. If a regular source of reliable information on Solaris and the applications that you use can be found, it may save much time.
  3. Run a tool on important servers that checks the current patch level and compares it with the newest list of patches available from Sun: This is the ideal situation (it is discussed below in more detail).
  4. Check Sun's recommended patch bundles for changes every month or two: This requires little effort, but security is not as tight and the recommended bundles do not cover all Security problems. The recommended bundles may cause problems with some applications though, if kernel patches are applied.
  5. 3rd party application patches need to be checked and applied too. Don't forget them!

How do you decide whether a weakness is worth patching?

Warning: Patches reverse some of Yassp's changes. So reboot after applying patches and check carefully that no enexpected daemons are running.

Patch Tools [15]:

8. RPC

RPC services should be avoided on sensitive servers, such as those on the Internet or in a DMZ. RPC uses dynamic ports and provides no standard access control methods. However, some programs insist on having RPC e.g. CDE, OpenWindows, Disksuite and Legato Networker. If possible avoid RPC, otherwise....

Improving Disksuite Security:

Disksuite is a tool bundled with Solaris that allows disks to be mirrored or gathered into RAID sets. This is useful feature to have in the system. The problem is that Disksuite uses RPC (specifically: two programs rpc.metamhd and rpc.metad which run from inetd).

How can Disksuite security be improved?

  1. Don't run Disksuite. This is my often choice.
    • Hardware RAID systems have the advantage that no special software like Disksuite is needed. This is better for secure systems (simplicity) and in disaster scenarios you may find Disksuite isn't all that easy to handle.
    • For system disks (where data does not change often), I've written a script for backing up boot disks with cpio. See also the section Boot disk backup.
  2. Run Disksuite but stop the associated RPC services (in /etc/inetd.conf) and stop rpcbind:
    • The "metad" service can be disabled but this means the "metatool" will not work. Command line tools will work fine -- and you should know them in any case for disaster scenarios with system disks.
    • The "metamhd" service can be disabled but this means you cannot share metadevices between systems.

OK, let's get back to general measures for RPC security:


9. Logging, Cron, Permissions

Configure logging and pruning:

BACKUPF="/etc/passwd /etc/shadow /etc/group /etc/yassp.conf /var/sadm/install/contents"
LOGS="/var/log/authlog /var/log/sshlog /var/adm/messages /var/adm/named /var/log/kernlog /var/log/userlog /var/log/maillog /var/log/daemonlog /var/log/lprlog /var/log/newslog /var/log/cronlog /var/log/local0log /var/log/local2log /var/log/loc al5log /var/log/alertlog"

Syslog configuration:

Syslog client: Designate one machine as the loghost (in /etc/hosts).

Syslog server or "loghost":

## Prune syslog logs weekly, keeping the last 6 months or so:
55 23 * * 6 /secure/rotate_log -n 40 alertlog
55 23 * * 6 /secure/rotate_log -n 40 authlog
55 23 * * 6 /secure/rotate_log -n 20 cronlog
55 23 * * 6 /secure/rotate_log -n 40 daemonlog
55 23 * * 6 /secure/rotate_log -n 40 kernlog
55 23 * * 6 /secure/rotate_log -n 40 local0log
55 23 * * 6 /secure/rotate_log -n 40 local2log
55 23 * * 6 /secure/rotate_log -n 40 local5log
55 23 * * 6 /secure/rotate_log -n 20 newslog
55 23 * * 6 /secure/rotate_log -n 40 userlog
55 23 * * 6 /secure/rotate_log -n 10 lprlog
55 23 * * 6 /secure/rotate_log -n 20 maillog

Add a root cron entry for Yearly cleaning of login entries and pruning of other local logs (note that /secure/weekly includes this)

## Empty login/logout records at year end
0 0 31 12 * /secure/wtrim.pl wtmp 20
0 0 31 12 * /secure/wtrim.pl wtmpx 20
#
# Solaris 2.x logs:
0 4 * * 6 /secure/rotate_log -L /var/adm -n 30 loginlog
0 4 * * 6 /secure/rotate_log -L /var/adm -n 30 sulog
0 4 * * 6 /secure/rotate_log -L /var/adm -n 2 vold.log
0 4 * * 6 /secure/rotate_cron

Other root cron entries:

Set date once a day with a reliable source using rdate (you may prefer NTP, it's more accurate, but complex, uses bandwidth and is an additional security worry):
## Synchronise the time:
0 * * * * /usr/bin/rdate YOURTIMEHOST  >/dev/null 2>&1

Consider installing a script to check that important daemons are running. Install monitor_processes.pl [3] and add a root cron entry:
## Check that important processes are running during office hours:
## [If you run 7x24, modify accordingly]
0,30 8-19 * * 1-5 /secure/monitor_processes.pl sshd httpd

Documentation:

Document configuration changes in a text file such as /etc/mods, update after each change, with date, author, files affected, description.
cat > /etc/mods <<EOF
15.10.00  sb  New install of Solaris8 and tools according to hardening guidelines
EOF

 


10. Limiting SUID Files

Files which have the SUID bit set (an "s" where the execute bit for the owner/group is shown in 'ls' listings) allow the user executing the program to assume the identity/group of the owner of the program. This is typically used to allow normal users to access certain function typically only allowed to root, for example binding to low ports, mounting  a floppy disk, etc. The problem is that historically, many security weakness have been found in such programs allowing attackers with local accounts to become root by exploiting buffer over flows, race conditions etc.

• Solaris has many "SUID root" binaries and each one presents a risk, so when hardening systems it is advisable to disable as many SUID program as possible.
• The purpose of this section is to provide a brief overview of the subject, a list of documents and scripts for disabling SUID files is provided.
• See [8] for SUID references and further reading.

What SUID files are on the system?

The find command can be used to list all SUID files:
find / -perm -u+s -ls

or all SGID files:
find / -perm -g+s -ls

How should we handle SUID files? Possible courses of action, in order of preference, are:

What SUID files need to be limited?

Some auditing ideas:

Further reading:

More file permissions tightening:

chmod o-rx /etc/security          #Not needed for Solaris8 or later
chmod 400 /.shosts /etc/sshd_config /etc/ssh_known_hosts

To Do:

It would be useful to have packages that reset the SUID files for examples situations such as Bastion Hosts (high), multi-user servers (medium), workstations (low). The packages would also correct the pkg database so that 'pkgchk -n' would not report permissions errors after the SUID files had been adapted.


11. Install an Integrity Checker: e.g. Tripwire

You should regularly check the integrity of files on the system, to be assured that they have not been maliciously modified. Solaris provides "pkgchk -n" which checks the package databases against the size, permissions and checksums of actually installed files. This is useful and recommended, however checksums can be fooled and the package database can itself be manipulated, so it is no protection against the clever attacker (or the script Kiddie with a clever rootkit). What is required, is a file integrity checker that uses secure (one-way) hashing algorithms.

Which is why the Yassp Tarball installs tripwire in /secure/tripwire. Tripwire uses several secure hashing algorithms (and in it's commercial form, provides cryptographic signing of it's database).

At this stage of the installation, it is recommended to take a snapshot of the files on the newly configured system, i.e. initialise tripwire's database and then run regular checks to monitor for changes. If possible, keep the master database on another machine, offline or on write-once media.

What options do we have for integrity checking?

An example using the free Tripwire Version 1.2 (bundled with Yassp):


12. Install, test, harden applications

Depending on the function of the server, applications such as ftpd, BIND, proxies, etc. are installed at this point.

Hardening of specific applications like ftp, DNS, Email and also general application tips are discussed in a separate document [16].

 

13. Going live


Preparing to go live
  1. You probably won't need CR-ROMs or floppies anymore, so disable the volume manager in /etc/yassp.conf (if it was still enabled, which it not by default).
    If you do need to mount a CD in the future, start vold manually and check for new devices:
        drvconfig; disks; vold &; volcheck; df -k
  2. If partitions such as /opt or /usr had to be mounted read-write during the application install/testing, consider mounting them read-only now.
  3. Reinitialise tripwire (or equivalent integrity checker).
  4. Backup the system to two tapes, one offsite.
  5. Run a network scan on the system, to ensure that only expected services are visible. A commercial tool such as ISS or a free one like Nessus, nmap, Satan/Saint/Sara should do the job. Print out the results and archive.
  6. If possible, have additional people do the final testing, just in case something was forgotten.
  7. Test in detail - What works? What is forbidden? Check console/log entries. Does the system behave as expected? Watch the logs very frequently during the first few days of production.
Going Live

Connect to the live network. Test in detail. Check log entries. Does the system behave as expected?

Have applications been tested in detail, by different people with different points of view, from different access points on the network?


Regular maintenance

The following activities should take place hourly, daily, weekly or monthly, depending on how critical the system is:


Yassp Overview

Jean Chouanard of Xerox and a host of Solaris experts have developed the Yassp (Yet Another Solaris Security Package) [1] scripts for hardening Solaris and which includes many useful precompiled security tools .

The first version appeared in summer 1999 and adhered pretty closely to the SANS Solaris Hardening Guide v1. We now have an improved Yassp beta#15 (Nov.2000) that now goes much further and is a final release candidate. It's been tested by admins, has received much input from experts and tries to pull together all known issues of Solaris hardening into one bundle.
Yassp includes scripts and binaries for key tools and allows individual tuning, so that it can be used for bastion hosts, servers and workstations.
An example of a complete yassp installation output is useful in understanding what it does, yassp_install.txt. An example of a deinstallation is yassp_deinstall.txt.

The core hardening features are in the SECclean package in Yassp:

Yassp tarball:

There is also a tarball available in addition to SECclean. This tarball also includes binary packages for SPARC / X86 for key security tools.

The tools are installed in /opt/local, except tripwire which goes in /secure/tripwire.

Yassp installation logs:

YASSP Advantages
Yassp disadvantages

Additional Notes

This article has been very specific, in the interest of making it practical. However, each security administrator has his own methods and each site has different requirements. There are many more issues than just those above, we address some more advanced topics in this section:


References

[1] Jean Chouanard's YASSP (yet another solaris security package) for Solaris 2.6/7/8
www.yassp.org
The list of SECclean hardening actions is documented at www.yassp.org/internal.html
Express installation guide: www.yassp.org/express.html
The developers email list is archived at www.theorygroup.com/Archive/YASSP
Local copies (if you can't get to the main site): yassp.tar.gz(beta#15) secclean.Z. (beta#15)
[2] Sunworld security columns
www.sunworld.com/sunworldonline/common/swol-backissues-columns.html
Solaris Security FAQ www.sunworld.com/common/security-faq.html
Padded Cells: www.sunworld.com/swol-01-1999/swol-01-security.html
Tripwire: sunworld.com/sunworldonline/swol-02-2000/swol-02-security.html?0306a
[3] Scripts included with this article:
See: www.boran.com/security/sp/solaris
[4] Doug Hughes:
- tocsin
can be downloaded in source form (tocsin.tar.gz), or a Solaris package (AUBtocsin), from: ftp://ftp.eng.auburn.edu/pub/doug
- tips and links on Disksuite, VxVM and the SPARC Storagearray:
www.eng.auburn.edu/pub/mail-lists/ssastuff
[5] Tripwire:
Free version V1.2 ftp.cerias.purdue.edu/pub/tools/unix/ids/tripwire (last updated in 1994).
Commercial Version www.tripwiresecurity.com (starts at $495.-/server) also runs on NT.
OpenSource Version www.tripwire.org Planned for late 2000, on Linux only?
Sunworld article.
[6]  Sample tools for analysing logs:
Logcheck www.psionic.com/abacus/logcheck (see also my improved version of logcheck.sh, a zip with my improvements and solaris binaries and a local copy of the original logcheck-1_1.tar.gz)
Swatch  ftp.stanford.edu/general/security-tools/swatch
[7] All About SSH PartI and Part II
[7a] ftp.cs.hut.fi/pub/ssh
[8] Disabling SUID files:

Solaris 7 Setuid/Setgid Files Information Systems and Technology University of Waterloo
[Reg Quinton's documentation on Solaris 7 SUID files and associated scripts].
ist.uwaterloo.ca/security/howto/1999-04-21.html
Solaris 2.6:
ist.uwaterloo.ca/security/howto/2000-08-22.html
Solaris 8:
ist.uwaterloo.ca/security/howto/2000-08-17.html

Titan's ziplock module
www.titan.org

Example listing of SUID/SGID files on a Solaris 7 system:
www.boran.com/security/sp/solaris/suid_sol7.txt
Example listing of SUID/SGID files on a Solaris 8 system:
www.boran.com/security/sp/solaris/suid_sol8.txt

[9] Review: Sunscreen EFS3 Firewall -  Checking out Sun's Stealth Firewall
SunscreenEFS.html
[10] Casper Dik's fix-modes script contains a huge number of file permission improvements for most Solaris versions. ftp.wins.uva.nl:/pub/solaris/fix-modes.tar.gz
Jens VŲckler's nettune script www.rvs.uni-hannover.de/people/voeckler/tune/EN/tune.html
See also the local copy nettune.
[11] The Titan Project  www.titan.org
[12] AIDE, a GPL file integrity checker. www.cs.tut.fi/~rammer/aide.html
Basic File Integrity Checking (using AIDE)
[13] My articles on BIND: bind_hardening.html
[14] Wietse Venema's tools and papers (tcp wrapper, rpcbind/portmapper, postfix, Satan, ....) ftp.porcupine.org/pub/security/index.html
[15] Patches:
[16] Hardening Applications, application_hardening.html
[17] syslog replacements:
syslog-ng www.balabit.hu/products/syslog-ng (tcp connections, content filtering, encryption, authentication)
secure syslog  www.core-sdi.com/english/slogging/ssyslog.html (encryption and authentication of a trusted auditors machine)
Nsyslogd coombs.anu.edu.au/~avalon/nsyslog.html (tcp connections and SSL)

'Security Issues in Network Event Logging' working group, a part of Internet Engineering Task Force (IETF) committee. 
www.ietf.org/html.charters/syslog-charter.html

[18] Security Advisories: www.cert.org, www.first.orgwww.ciac.org
CERT provide several useful firewall/hardening/intrusion detection papers online www.cert.org/tech_tips.
Technical Discussion of advisories: www.SecurityFocus.com/sun
[19] Security Newsletters: SecurityFocus, SANS.
[20] IPfilter
IP Filter Based Firewalls HOWTO
Firewalling with IPF
Introduction to IP Filter
Introduction to IP Filter Part 2.
[21] Routing:
Sun's Routing Support Document/FAQ is an old, but comprehensive overview of routing, how it works in Solaris and how to configure/debug routing.
Gated is a better routing daemon: www.gated.org 
[22] Solaris C2 security module: BSM
Solaris_bsm.html
[23]


Other useful links:


Changes to this article

25.Oct.'99  First Publication.
08.Nov.'99 Thanks to the following people for providing feedback and suggestions after the initial publication: Glenn Brunette, Andrew van der Stock, Darrel Goeddel and Kamal Kantawala.
28.Jan.'00 Integrate first Yassp version
08.Mar.'00 Rearrange links and references.

21.Apr.'00 Rewrite. Adapt for yassp beta3, Solaris 8, Sunscreen, Apache. New: /etc/weekly script.
13.May.'00 Update: Links, Venema's tools, Yassp beta5, tripwire, feedback Jean Chouanard
                New: RPC, smtp. (Second Publication)
16.May'00 Update: yassp#5 deinstall problems, rpc.
23.May'00 Update: tripwire URL and check parameters. CERT references. Fix Links.
20.Jun'00  Update: typos in OS section,More Solaris patches, Disk mounting (vfstab options).
17.Jul'00   New: rewrite to use Yassp tarball beta#9. Saveit. Add new tripwire link [5]
02.Oct'00 Update for Yassp beta#11 (release candidate). Update Sunscreen example rules, patches. New: mirror_boot.sh, IPfilter references. Move General Application hardening into a separate document. Update Sol8 3rd part tools, Man+SUNWlibc
13.Nov.00 Update: Yassp beta#12
17.Nov.00 Update: New SUID section, minor improvements, Yassp beta#13
22.Nov.00 Update: Beta#15. New: useradd, BSM/C2.
13.Dec.00 Update: SUID files, feedback from Reg, new Patch section
25.Jan.01 Updated: account deleting, TOC, picl, CheckPatches, RPC hosts.allow example, SUID examples.

08.Mar.01 Update: RPC, mirror_boot
25.Jun.01 Update: SUID files


SeŠn Boran is an IT security consultant based in Switzerland and the author of the online IT Security Cookbook.

© Copyright 2001,  SeŠn Boran, All Rights Reserved, Last Update: 18 avril, 2002