Post installation steps (for beta#15)



After completing the SECclean installation, there are further configuration steps that may be necessary. Your choices will depend upon the applications installed, the type of usage, the hostility of the network environment, and other site specific criteria. These steps are outlined below.

References and further reading
Changes to this document

Yassp configuration

Workaround for limitations in Yassp beta #15:

  1. Secure Shell (SSH):
  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

Having installed 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
  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. "The Name Server Cache Daemon (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.

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

Back to top

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.

Back to top


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 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.
  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.

See also [4].

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

Back to top

General configuration

Back to top


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, "A SunSolve Patch Primer"  [1].

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?

Patching Gotchas:

Tools to help find and install patches relevant to your system [1]:

Back to top


Syslog logging: Yassp uses a modified syslog configuration /etc/syslog.conf which enables more logging than the default and saves logs in /var/adm/messages. An optional /etc/syslog.conf.server is also installed by Yassp, which is designed for loghosts and splits up services into separate logfiles.

Yassp has disabled the Solaris log pruning and other lines in the root cron. It added an entry to run the "daily" script, which you may wish to examine. This script prunes and compresses the logs listed in the LOGS variable (and moves them to /var/oldlogs), and uses rcs to backup configuration files in the BACKUPF variable to /var/backups. The default settings for these variables are:
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"

Improvements to consider:

Back to top

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 access to certain functions 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.

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
They are also listed in the package database /var/adm/install.

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:

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 package database so that 'pkgchk -n' would not report permissions errors after the SUID files had been adapted.

Back to top

File Integrity checking

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 clever tools). 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).

After the initial installation you should 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):

Regularly copy the configuration and database to floppy disk or write-once media and sign it with pgp or MD5. In a crisis it will be very useful.

Back to top

Minimising GUI daemons/services

The focus of this paper has been on preparing hardened headless servers. However it would be useful to present suggestions for running a GUI console on Workstations or on servers where this really can't be avoided. Refer to the RPC section for more ideas (e.g. using Wietse's RPCBIND).

a) Chris Calabrese suggests the following to run CDE without RPC.

  1. Disable rpc.ttdbserverd in inetd.conf
  2. Replace /usr/dt/bin/Xsession with a script like the following, designed for HP-UX (In Solaris, it looks like one could use /usr/openwin/bin/twm instead of /usr/bin/X11/mwm, and also /usr/openwin/bin/xsetroot instead of /usr/bin/X11/xsetroot):

    #!/sbin/sh -
    /usr/bin/X11/xsetroot -default &
    /usr/bin/X11/mwm &
    sleep 4
    /usr/dt/bin/dtterm -ls

  3. Then remove SUID access to CDE binaries:
    chmod ug-s /usr/dt/bin/dtaction /usr/dt/bin/dtappgather /usr/dt/bin/dtprintinfo /usr/dt/in/dtsession


b) Reg Quinton suggests a less drastic approach: leave RPC but reduce CDE daemons/services (e.g.on a desktop workstation).

  1. /etc/inetd.conf can be stripped of every single service
  2. /etc/rc2.d/S99dtlogin is required (for the CDE login panel)
  3. /etc/rc2.d/S71rpc is required (ttsession uses rpc)
  4. Restrict dtlogin to the console, for example by the 'sh' script:

    [ -d /etc/dt/config ] || mkdir -p /etc/dt/config
    [ -f /etc/dt/config/Xaccess ] ||
    cp /usr/dt/config/Xaccess /etc/dt/config/Xaccess

    ed - /etc/dt/config/Xaccess >/dev/null 2>&1 <<EOF
    g/^*/s//# HARDEN #*/

Side effects: You will give up some minor CDE tools e.g. the calendar manager has been stripped by 1). The cmsd can be re-enabled in inetd.conf, although be aware that it has been a source of remote holes.

Back to top

Final Note

You now have a system that is quite resistant to attack. To maintain this security, caution is needed:

Back to top

References and further reading

[1] Patches:

[2] Further reading on Hardening:

Hardening Solaris (based on Yassp beta15)
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. For Solaris 8, the Sunscreen EFS lite firewall is also presented.
Interview with Jean Chouanard
The Titan project
Titan is a collection of programs, each of which either fixes or tightens one or more potential security problems with a particular aspect in the setup or configuration of a Unix system. Conceived and created by Brad Powell, it was written in Bourne shell, and its simple modular design makes it trivial for anyone who can write a shell script or program to add to it, as well completely understand the internal workings of the system.
Sun's hardening tool, Jass
Jass has a restrictive license and is still in beta. It was tested in Oct'00 and didn't seem ready for prime time.
Sun's hardening documentation:
  • Solaris Operating Environment Security
    Discusses how to enhance system and network service security in Solaris.
  • Solaris Operating Environment Network Settings for Security:
    Discusses the many low-level network options available within Solaris and their affect on security.
  • Solaris Minimization for Security:
    A Simple, Reproducible and Secure Application Installation Methodology: Discusses OS minimization  and a simple method for duplicating installations on large numbers of servers.
  • JumpStart Architecture and Security Scripts for the Solaris Operating Environment Part 1
    This article is part one of a three part series presenting the JumpStart Architecture and Security Scripts tool (Toolkit) for Solaris. The Toolkit is a set of scripts which automatically harden and minimize Solaris Operating Environment systems. The modifications made are based on the recommendations made in the previously published Sun BluePrints online security articles.
  • These documents are often behind the latest Solaris release.
More Hardening Papers
SecurityFocus, list of Sun relevant articles
Lance Spitzner's white papers
This papers are useful and referenced by many people. Worth a read.
Securing Solaris Servers - A Checklist Approach, by Paul D. J. Vandenberg and Susan D. Wyess

This material is excerpted from an internal U.S. Government document on web security, which the authors played leading roles in preparing. This material has been officially reviewed, and the authors have been granted permission to use this material in a non-official publication.
Hardening Solaris, by SeŠn Boran
tcp tuning under solaris, by Jens-S. VŲckler
UNIX IP Stack Tuning Guide, by Rob Thomas
Security: How to Documents, Information Systems and Technology, University of Waterloo
Hardening Solaris CSNC, by Ivan Butler
This PDF document provides a step by step tutorial for creating a Solaris system resistant to various method of attack, based on the Titan scripts.Looks good but I've not tested it in detail. It does not reference Yassp (yet).
Wietse Venema's tools and papers (tcp wrapper, rpcbind/portmapper, postfix, Satan, ....)
Solaris Security Guide, Sabernet
Solaris Security Step by Step, from SANS
This available in paper or PDF form, is good, but not free.
Security Improvement Modules: UNIX, by CERT
IT Baseline Protection Manual (itbpm)
by Bundesamt for Sicherheit in der Informatik (German Federal Computer Security Agency)
Softpanorama University Pages: Solaris Hardening and Security
This site is an index to many Solaris security papers and tools
Securiteam: Hardening Solaris SPARC/x86 security for Firewall usage - a step by step guide
More hardening Tools
Hal Pomeranz's scripts that accompany the SANS "Solaris Security: Step-by-Step" guide
New Approaches to Making Solaris More Secure, by Rich Teer (including hardening scripts)
Securing Solaris, by Ido Dubrawsky
Casper Dik's fixmode (improves Solaris file permissions)
Chris Calabrese's Harden script
Alberto Begliomini's SECUR

[3] Integrity /Tripwire Checking links:

Free version V1.2 (last updated in 1994).
Commercial Version ($495.-/server) also runs on NT and Linux.

Sunworld article on tripwire:
Cert article on Tripwire:

Sean's scripts for running tripwire: trip_host.sh , trip_all

AIDE, a GPL file integrity checker http://www.cs.tut.fi/~rammer/aide.html
CU - script for using AIDE http://nitzer.dhs.org/ICU/ICU.html

Fcheck, a GPL file integrity checker: Intrusion detection and Policy enforcement / auditing software for Unix & Windows NT/9x/3.x platforms. http://www.geocities.com/fcheck2000

[4] General Application Hardening:


A script for cold mirroring of Solaris systems: www.boran.com/security/sp/coldmirroring20010306.html

[5] Email/sendmail links:

SMAP & FWTK (Firewall Toolkit), Sendmail, Postfix,
Qmail, Life with qmail
Anti-Virus Mail Scanner for Sendmail amavis.org
Scan4Virus- Virus Scan Wrapper for Qmail

[6] IPfilter

IP Filter Based Firewalls HOWTO
Introduction to IP Filter
Introduction to IP Filter Part 2
Securing your Solaris server (includes a section on setting up IPF)

[7] 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

[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].

Solaris 2.6: http://ist.uwaterloo.ca/security/howto/2000-08-22.html
Solaris 8: http://ist.uwaterloo.ca/security/howto/2000-08-17.html

Titan's ziplock module
Example listing of SUID/SGID files on a Solaris 7 system:
Example listing of SUID/SGID files on a Solaris 8 system:


Doug Hughes (Doug.Hughes@Eng.Auburn.edu) wrote tocsin, a "featherweight network intrusion detection system" back in 1996. It is a free tool that detects network scans. Tocsin only needs to be installed once per broadcast subnet, unless switches are used i.e. all nodes do not see all traffic. It uses Data Link Provider Interface (DLPI) kernel level packet filtering and runs out of the box on SunOS and Solaris to catch port and stealth scans (SYN, FIN, ACK, Xmas, RST, etc). Alert messages are logged to the syslog 'auth' facility, startup and shutdown messages are logged to the 'daemon' facility. In August 2000, tocsin was significantly improved and version released.
Recommendation: Install one Tocsin per subnet, or on several sensitive hosts if switches rather than hubs are used (which they should be), since all subnet traffic cannot be monitored by one Tocsin daemon.

Back to top

Changes to this document

10.Jul'00 sb Draft#1

22.Jul'00 sb Spelling & grammar. Fix link.

31.Jul'00 sb Serial port break, minor fixes, new logging & tripwire sections, improve vfstab.

1.Aug'00 sb Update 2: NTP, routing, rpc, tripwire, spelling/grammar. (Thanks to Reg, Richard, Doug for feedback).
New: logging/"daily"

3.Aug'00 sb Update 3: Lots of little corrections after feedback from Jean, Reg, Doug, Sweth, Warren,..
New: Add References section, ToDo, Add note on umask in Yassp config section.

11.Aug'00 sb Update 4: routing, inetd, email server, rpc logging, tripwire, Email server, patches, IPF links. New: ROOTALLOWED, smrsh/qmail/postfix refs, refs to Sun Security docs, Final Note (Feedback from Jean, Doug,Paolo,Alex, Laurie).

18.Aug'00 sb New: SUID files. Update: add "ro" to vfstab options.

23.Oct'00 sb Update: [2] Further reading on Hardening

15.Nov'00 sb Freshen for beta#12

21.Nov.00 sb Separate SUID section. Add Disksuite notes to RPC section.

01.Dec'00 sb Beta 15 tweaks & corrections, New: useradd, BSM/C2, Sunsolver patch primer[1]. Several minor fixes after review by Reg Quinton.

05.Dec'00 sb Rewrite Checkpatches/GetapplyPatch. Add 2nd note on NSCD (from Rich Fuchs)

06.Dec'00 sb Added rlim_fd_max, new Patches section.

13.Dec'00 sb Updates to Patches(Warren Belfer), Eeprom (Reg), /etc/system (Jens), SUID (Sean), Running CDE without RPC (Chris). HTML clean up by Jean.

26.Jan.01 sb: Minor tweaks after DL feedback: SUID: nis/yppasswd are links to passwd, so don't remove SUID. picl, CheckPatches, RPC hosts.allow example.

27.Jan.01 sb CheckPatches updates, fix link.

02.Feb.01 sb New section Minimising GUI daemons/services, Add /etc/primes

22.Feb.01 sb Add notes on pt_cnt, picld. New references: Hal Pomeranz's scripts. Spelling/grammar corrections from Reg, patching gotchas.

30.Mar.01 sb IPF, tripwire links, RPC, Update Jens + Beutler links, Fcheck.

13.Apr.01 sb SUID improvements. Reference to Sun Patch Check

19.Apr.02 sb Update SecurityPortal links=>boran.com

Back to top

SeŠn Boran Last Update 19 avril, 2002