YASSP

Post installation steps (Updated for beta#12)

Overview

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.

• Yassp configuration
• Mounting file systems restrictively in /etc/vfstab
• RPC
• General configuration
• Logging
• Integrity Checking: Tripwire
• Final Note

References and further reading
Changes to this document

Yassp configuration

After installing Yassp, it may be necessary to change the configuration to allow specific services disabled by yassp. Typically nothing needs to be enabled for bastion hosts. The configuration file /etc/yassp.conf is well commented, easy to understand and documented in the man pages yassp.conf(4) and yassp(1).

• Accounts
  • cleanup_passwd disables, but does not remove user accounts from /etc/passwd (by default). The USERDENIED variable in yassp.conf contains the default list. Add any non-standard application accounts (that you likewise want to be disabled).
  • If you prefer that certain accounts are actually deleted, set the USERDELETED list in yassp.conf and rerun cleanup_passwd. Note: This may result in orphaned files and corrupt the package database if these accounts owned files.
  • The ROOTALLOWED variable lists accounts that are allowed to have a UID of 0, cleanup_passwd will disable any UID 0 accounts not listed. It is not recommended to create other such accounts, but there may be situations where it is necessary.
  • The default umask for daemons and users are both set to 077 in /etc/yassp.conf (no group or world access). In many environments, it makes sense to change the user umask to 027, for example (allowing group read access by default).
• Cron:
  • If any user other than root needs to use at/cron, then the allow/deny files in /etc/cron.d/ will need adapting.
  • The root cron was replaced rather than edited, if you already had added entries, they will have to be re-added. The old cron is backed up under /yassp.bk.
  • If you don't want to run the Yassp example daily script for log pruning, comment it out in the root cron.
• Yassp has installed an SSH client and server, with a pretty tight configuration.
  • This version of SSH is "tcp wrapper" enabled, so access must also be granted in /etc/hosts.allow, by default no access is possible.
    • To enable any host to access this ssh server, add the following to /etc/hosts.allow:
    sshd : ALL
    • To allow X11 forwarding to work with SSH, add the line:
    sshdfwd-X11: LOCAL
  • Tip: Do not use reverse fingers in the SSH rules in hosts.allow/deny.
  • Check the default server configuration /etc/sshd_config and client configuration /etc/ssh_config. For example, consider only allowing specific users and hosts to access SSH. Deny daemon accounts access.
• 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="" in /etc/yassp.conf.
• If INETD services are needed, set RUNINETD to YES in yassp.conf 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 adapt the tcp wrapper access control files /etc/hosts.allow /etc/hosts.deny accordingly.
• Edit login banners to warn users about unauthorised access, you'll 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.

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

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.

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

RPC

RPC is a major security problem due it's lack of authentication, encryption and it's use of dynamic ports. Normally RPC should not be run on bastion or other sensitive hosts. However, some programs insist on having RPC e.g. CDE, OpenWindows, Disksuite and Legato Networker. If at all possible, avoid RPC (for example, the author prefers manual mirroring with a cpio script for warm standbys, rather than Disksuite). If RPC really is necessary, then....

• If you are using Solaris 8, the bundled (free) Sunscreen EFS lite Firewall can be used [2] to filter who can access the rpc services (since the Sunscreen includes an RPC state filter engine), or...
• IPfilter [6] can also be used as local firewall to prevent access to RPC services.
  • It's free and works on older Solaris, not just 2.8.
  • It doesn't have an RPC state based engine though (so it can't filter on RPC program names or allow RPC to specific destinations),
  • But it can be used to allow all localhost RPC traffic (enough for some RPC applications such as Disksuite or CDE) and deny all remote traffic except, say, HTTP or whatever service is provided to remote hosts.
• Use Wietse Venema's RPCBIND (included in the Yassp tarball), which provides tcp wrapper-like access control and logging for the portmapper/rpcbind. Note that it does not provide access control to the actual RPC programs themselves, the RPC service may still listen on a port even if RPCBIND had been killed. Summary of features (extract from the README):
  - host access control on IP addresses. The local host is considered authorized. Host access control requires the libwrap.a library that comes with recent tcp wrapper implementations.
  - requests that are forwarded by the rpcbind process will be forwarded through an unprivileged port.
  - the rpcbind process refuses to forward requests to rpc daemons that do (or should) verify the origin of the request: at present, the list includes most of the calls to the NFS mountd/nfsd daemons and the NIS daemons.
  - the rpcbind process refuses REMOTE requests sent to high-numbered UDP ports (instead of TCP or UDP ports 111). High-numbered ports are opened by the rpcbind server as a side effect of other activity. These ports could be abused to bypass packet filtering restrictions. See the advisory (and addendum) on http://www.secnet.com/
  • It is based on the Solaris 2.3 sources for rpcbind, which were made publicly available by Sun in 1994. A code review was also conducted (by W.Venema) on the differences with Solaris 2.7's RPCBIND, the differences were minimal.
  • The additional logging is useful. If RPC is restricted to localhost, and 'rpcinfo -p' is attempted from another host, the following is logged:
    Aug 4 14:55:15 myserver rpcbind: refused connect from 160.97.24.221 to dump()
  • By default, logging is to syslog MAIL.INFO, which is a little strange, so it's recommended to change it to AUTH.INFO in the Makefile before compiling. [Note: Yassp beta#12 should fix this]
  • Switch on this RPCBIND by setting  RPC=YES and WVRPCBIND=YES in /etc/yassp.conf. By default, access is only allowed to localhost, otherwise 'rpcbind' entries will have to be added to /etc/host.allow|deny for IP level access control

General configuration

• Routing:
  • For default routes, add the IP address of the router to /etc/defaultrouter
  • or for static routes, create a startup file in /etc/init.d/static_routes and a symbolic link under /etc/rc2.d/S99static_routes using the 'route' command.
  • route just for specific network, e.g.:
      route -f add net 129.97 `cat /etc/defaultrouter`
  • or if you really want to run the routing daemon, make sure you understand how it works, read [7] as it can mess up your network. Consider running in quiet mode ('-q'), or tell the interface not to publish routes with the 'private' option to ifconfig. To run in quiet mode, set SUNSTARTUP=YES in /etc/yassp.conf and make sure no default router is specified.
• Patches: Now that the system is reasonably secured, it's time to get the most recent versions of security patches. 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 for new patches.
  If the recommended/security patch bundle was not yet installed, do it now, see Sunsolve [1].
  
  Patch tools/scripts that may be useful, depending on your environment  [1]:
  • If you have a support contract, get the Patchdiag tool from Sunsolve along with the latest patchdiag.xref and run it to see what recommended and security patches are still missing, then download & install the missing ones.
  • Consider checking with the SecurityFocus vulnerability calculator. Execute the following:
  showrev -p | cut -f2 -d' ' | xargs
  and then paste it into the window on SecurityFocus and select OS version, architecture and hit run. This will probably result in a long list of vulnerabilities, most of which are not relevant. Go through the list looking for applications or services that are arctive on your host, that then need fixing.  A link is provided for each vulnerability, where more details and fixes can be found. This list of vulnerabilities includes not just Solaris, but all third party applications.
  • GetApplyPatch: A bourne shell script to get and apply a patch from Sunsolve. Arguments are a list of patch numbers. Solaris 8 is also supported.
  Problems: You'll need direct ftp access to the Internet as  ftp is used, so you can't go via proxies (how about lynx or wget?). Workaround: setup a local anonymous ftp mirror (an alternative mirror can be specified in newer versions).
  • CheckPatches: is a script (available in Perl and sh) that uses showrev to see what patches are installed, compare this against the Solaris patch report, and make a list of recommended and security patches that need installation. It expects to find 'SolarisX.PatchReport' in the current directory (or use '-f' to get the Patch report). Both these scripts can be used together to get each patch that is needed and install them (you are prompted each time). perl ./CheckPatches | ./GetApplyPatch
  Problems: If both scripts are used together, patches that are recommended and security will be got twice!
  • FastPatch is a replacement for patchadd, the same but a lot faster.
  • Patchreport is a script that does everything CheckPatches and GetApplyPatch do, plus checking integrity of patches via MD5, logging in to sunsolve to get the public patch reports or if you have a Sunsolve ID, get the full patchdiag.xref file. It's written in Perl and does require quite a few Perl modules to be installed.
  
• Configure /etc/hosts with a list of critical machines (which you don't want resolved via DNS).
• DNS client (avoid if not needed): add domain name & DNS servers to /etc/resolv.conf. Add a DNS entry for "hosts" in /etc/nsswitch.conf.
• Environment: /.cshrc /.profile: set aliases, variables (such as VISUAL, EDITOR and PATH - don't include ".").
  
• Email client: If hosts are not supposed to send email outside the subnet, don't configure the mailhost alias (in /etc/hosts). Delete /usr/lib/sendmail if you don't need any kind of email. Otherwise,
  • edit /etc/mail/aliases (at least point root to a real address)
  • set mailhost in /etc/hosts and add a hostname.YOURDOMAIN.COM alias for this machine
  • in /etc/mail/sendmail.cf set the following to ensure all outgoing email is channeled over mailhost:
       Dj$w.YOURDOMAIN.COM.
       DSmailhost
       DRmailhost
       DHmailhost
       O FallbackMXhost=mailhost
  • Add a root cron entry to re-send spooled email every hour:
       /usr/lib/sendmail -q
  • send a test email to check the config:
       mailx -v -s test_email root </dev/null
    
• Email server: If you really need to receive Email (i.e. run an SMTP server), it's not a trivial task. Refer to [4].
  
• On high availability servers where the console is exposed:
  • Switch on EEPROM security (requires a password to be entered each time the prom prompt is accessed):
    eeprom security-mode=command
    This should also be used with care, as forgetting the password can render a machine useless.
  • The Stop-A keyboard sequence can be disabled by setting KEYBOARD_ABORT to disable in /etc/default/kbd.  Of course "STOP-A; sync" won't work anymore which can be a major inconvenience, so it's suggested only for physically insecure environments.
  • If managing a console via serial cable, an alternate BREAK signal can be set up to prevent terminal power cycles causing a stop of the console and to allow the break signal to be sent from terminal emulators that cannot send a BREAK signal properly (e.g. HyperTerminal). STOP-A behavior from a graphical console will not be affected by this setting.
    The change is available as follows:
    2.5.1 or lower - upgrade to 2.6 or better
    2.6 - requires patch 105924-10 or later
    7 - requires patch 107589-02 or later
    8 - functionality is already integrated.
    - To enable the new break signal (which is <RETURN> <TILDE> <CONTROL-B>), edit /etc/default/kb and set KEYBOARD_ABORT=alternate. (Make sure Tilde works correctly on your keyboard first!).
    
• Time Synchronisation:
  • If you think you might have to produce evidence in court, use NTP to synchronise time, not rdate. Prosecutions have failed because, on busy servers, a few seconds difference could be used to insist that there is a doubt about the identity of a session. (This happened to a bank in Australia trying to prosecute an Internal Attacker).
  • If using NTP, either get a (cheap) radio clock (if you are near an appropriate transmitter - e.g. the Stuttgart transmitter in Germany), or setup a dedicated bastion host as a 2nd stratum NTP server, which uses three 1st stratum sources.
  • Setup the firewall filter to allow only NTP from the bastion NTP server to the three 1st stratums and allow Intranet hosts to query the bastion.
  • Other hosts can synchronise to the NTP servers via a simple cron command, they don't have to run the ntp daemon:
    /usr/sbin/ntpdate -s ntp1 ntp2 ntp3
  • NTP can also be setup for higher security by configuring DES+MD5 authentication keys on server and client, see man xntpd.
  
• If you are using multiple network interfaces, you may want to use a different MAC address for each of them. By default, Solaris will use the same MAC addresses for all the network interfaces connected to the same box (It will use the MAC address which is burnt in the EEPROM motherboard). If you want each network interfaces to use its own MAC address, type:
  eeprom local-mac-address\?=true
  

• 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:

  • Remove the package containing the offending file
  • Disable the program (e.g. chmod 000 FILENAME)
  • The SUID bit can be removed (e.g. chmod ug-s FILENAME)
  • Restrict the file to a group of users (first remove world access: "chmod o-rwx", then allow a group "chgrp MYGROUP MYFILE") .

  What SUID files need to be limited?

  • On sensitive systems where users have accounts, or where key daemons run as non-root users, disabling a maximum of SUID files is desirable.
  • One suggestion for paranoid systems is to disable all except 'pt_chmod', 'utmp_update' and 'su'.
  • Reg Quinton explains each Solaris SUID file and recommends settings, together with an appropriate script that can be customised. The recommended settings are for "medium" security systems.
  • Some tools like uucp are almost never needed. If possible remove the SUNWbnuu package or disable the setuid bits.
    pkgrm SUNWbnuu
    chmod ug-s /usr/bin/cu /usr/bin/uu* /usr/lib/uucp/*
  • Another often unused suite of tools is kcms (Kodak Color Management System), so either remove or disable:
    pkgrm SUNWkcspg SUNWkcsrt 
    chmod ug-s /usr/openwin/bin/kcms*
  • Other tools are useful, but only root needs to use them (on most hosts) so remove the SUID bit, e.g.:
    chmod ug-s /usr/sbin/snoop /usr/bin/netstat /usr/local/bin/top /usr/local/bin/lsof
  • We could check that all SUID files on the system are in the package database and haven't been changed:

    find / -perm -u+s -exec pkgchk -p {} \;  | more

    The package DB only uses "checksums" (not hashes/signatures) and could easily be modified by an attacker, so don't trust the package commands as 'proof' that binaries are non modified, rather an indication.

  • Or we could list all SUID files, with details and see what packages they belong to:

    find / -perm -u+s -exec pkgchk -l -p {} \; | more

  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.

   

• Check others Solaris hardening papers such as [2].

Logging

Syslog logging: Yassp uses a modified syslog configuration /etc/syslog.conf which enables more logging than the default and splits up services into separate logfiles (in /var/log).

Yassp has disabled the Solaris log pruning & 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 /v ar/log/newslog /var/log/cronlog /var/log/local0log /var/log/local2log /var/log/loc al5log /var/log/alertlog"

Tweaks to consider:

• Syslog client: Designate one machine as the loghost (in /etc/hosts).
• Test that logging to the server works correctly:
  /usr/ucb/logger -p mail.warn "test of syslog"
  and check that it appears in the server logs.
• Disable local logging of SSH activity, by commenting out the following line in /etc/syslog.conf:
  #local6.debug /var/log/sshlog

Integrity checking (tripwire)

It is desirable to 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 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?

• Tripwire [3]: There are both free and commercial versions (which costs ~$500.-/host).
  • The free version can be tricky to get working correctly and has a few bugs. Source code is provided. It may crashes on very large disks. This is the version included with Yassp.
  • The commercial version is a bit pricey, reports are verbose (you'll need filter scripts - V2.2.1 is better in this regard, then again 2.2.1 is buggier than 2.0.1), more configuration examples should be provided. It is more stable than the free version, also runs on RH Linux and NT and offers enhanced security by cryptographic signing of policy and configuration files. Support (even when paid for) is not great.
  • Neither version supports the use of regular expressions when defining policy rules. e.g. you can't specify a rule for "/home/*/www/cgi-bin" files, that would work even when new directories are added under /home.
  • Apparently, Tripwire will be released as OpenSource for Linux (but not Solaris?) near then end of 2000.
  • A good mix is to use the commercial version on a secured central host, which then runs the free version remotely via SSH on all other hosts.
• PGP can also be used, by signing files to be protected (creating lots of signature files), then writing a script to check the validity of signatures. This will not catch permission, link, inode or modify date changes though.
• MD5 signatures could also be used in a similar way, but the list of MD5 signatures should not be stored on the system being monitored, unless it is PGP signed or encrypted.
• Aide is a new GPL tripwire replacement that looks interesting, I've not had a chance to test it so far. [3]

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

• Use the Yassp installed version in /secure/tripwire/tripwire with an example configuration tw.config, or pick up the sources and compile.
• Adapt tw.config for your site, if needed.Next, the "initial state" of the system needs to be saved:
  ./tripwire -i 2 -initialise -c tw.config
  This will create a new file database (which may take 5-15 minutes).  Lots of warnings like "No such file or directory" may appear, just gnore them. Note: we run tripwire with the "-i 2" option to increase speed (it disables one checking algorithm, snerfu, but SHA1 and MDS 5 are still used).
• The checking can be run each day from cron, or manually via:
  ./tripwire -i 2 -c tw.config
• To tell Tripwire that (changes to) files or entire directory trees are OK:
  tripwire -update [/file1 /file2 /patch3....]
• Improvements:
  • For increased security and automated checking of several systems from one trusted host, copy tripwire & it's database and run it remotely at regular intervals using SSH. Delete the tripwire database on the target after checking.
  • This makes it difficult for an attacker to know that tripwire is being used to check the system. In addition, immediately update the tripwire database, so that only differences are reported by successive runs.
  • See the sample script trip_host.sh  [3] for doing exactly this and filtering all those annoying "No such file or directory" warnings. It must be run from the 'master' host which has an SSH trust to the target.

  To run the first time:
  /secure/tripwire/trip_host.sh -init HOST
  Each time after that:
  /secure/tripwire/trip_host.sh -check HOST

  To automate for many hosts, this script is then called from another script for each host that needs to be monitored. See the sample script trip_all [3]. This script also assumes that the commercial tripwire is used on the central trusted host (only). The commercial tripwire allows signing of the tripwire database, which makes it more secure.

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

Final Note

If you've followed our suggestions up to now, you now have a system that is quite resistant to attack. To maintain this security, caution is needed:

• be careful when adding services, application and users to the system.
• keep patches up to date on active services.
• be minimalist, only install what is necessary.
• monitor and regularly check the system for intrusions.
• browse through the references below for more specific information.

References and further reading

[1] Patches:
      Sun sunsolve.sun.com sunsolve.sun.ch
      Patchdiag: sunsolve.sun.ch/private-cgi/show.pl?target=resources/tools
      Patch XREF file: sunsolve.sun.ch/private-cgi/show.pl?target=patches/patch-access
      SecurityFocus Vulnerability calculator SecurityFocus.com/focus/sun/form.html
      Reg Quinton/Bruce Barnett's CheckPatches and GetApplyPatch scripts
      Casper Dik's FastPatch, Joe Shambin's Patchreport.

[2] Further reading on Hardening:

YASSP

Hardening Solaris (based on Yassp beta12)
http://www.securityportal.com/topnews/solaris_hardening20000523.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 - beta11. For Solaris 8, the Sunscreen EFS lite firewall is also presented.

Interview with Jean Chouanard
http://securityportal.com/cover/coverstory20000821.html

Titan

The Titan project
http://www.fish.com/titan/
http://www.fish.com/titan/TITAN_documentation.html
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.

Hardening Solaris - Compass Security Draft 0.82, by Ivan Butler 
http://www.csnc.ch/download/sources/Hardening-Solaris V0.82.pdf  
This PDF document provides a step by step tutorial to creating a Solaris system resistant to various method of attack, based on the Titan scripts.

Sun

Sun's hardening tool, Jass
http://www.sun.com/blueprints/tools
Jass has a restrictive license and is still in beta. It was tested a few weeks back in 'Tip of the Week' and didn't seem ready for prime time.

Sun's hardening documentation:

• Solaris Operating Environment Security
  http://www.sun.com/blueprints/0100/security.pdf
  Discusses how to enhance system and network service security in Solaris.
• Solaris Operating Environment Network Settings for Security:
  http://www.sun.com/blueprints/1299/network.pdf
  Discusses the many low-level network options available within Solaris and their affect on security.
• Solaris Minimization for Security:
  http://www.sun.com/blueprints/1299/minimization.pdf
  A Simple, Reproducible and Secure Application Installation Methodology: Discusses OS minimization as a technique for reducing system vulnerabilities; a simple method for duplicating these installations on large numbers of servers is also introduced
• JumpStart Architecture and Security Scripts for the Solaris Operating Environment Part 1
  http://www.sun.com/blueprints/0700/jssec.pdf
  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.

More Hardening Papers

SecurityFocus, list of Sun relevant articles
http://www.securityfocus.com/focus/sun/menu.html?fm=0&action=unfold

Lance Spitzner's white papers
http://ww.enteract.com/~lspitz/papers.html
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
http://www.usenix.org/sage/sysadmins/solaris/index.html#host
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 (pre Yassp), by Seán Boran
http://www.securityportal.com/coverstory19991025.html
This article presents a step-by-step approach to securely installing Solaris for use in a firewall DMZ. It's a bit old now and not as comprehensive as it should be, but it is useful for those who wish to 'manually harden' their system.

tcp tuning under solaris, by Jens-S. Vöckler
http://www.rvs.uni-hannover.de/people/voeckler/tune/EN/tune.html

Security: How to Documents, Information Systems and Technology, University of Waterloo
http://ist.uwaterloo.ca/security/howto/

Wietse Venema's tools and papers (tcp wrapper, rpcbind/portmapper, postfix, Satan, ....)
ftp://ftp.porcupine.org/pub/security/index.html

Solaris Security Guide, Sabernet
http://www.sabernet.net/papers/Solaris.html

Solaris Security Step by Step, from SANS
http://www.sans.org
This available in paper or PDF form, is quite useful, but it's not free.

Sunworld

• Sunworld security columns
  http://www.sunworld.com/sunworldonline/common/swol-backissues-columns.html
• Solaris Security FAQ
  http://www.sunworld.com/common/security-faq.html  
• Padded Cells
  http://www.sunworld.com/swol-01-1999/swol-01-security.html

Softpanorama University Pages: Solaris Hardening and Security
http://www.softpanorama.org/Security/sos.shtml
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
http://www.securiteam.com/unixfocus/Hardening_Solaris_SPARC_x86_security_for_Firewall_usage_-_a_step_by_step_guide.html

More hardening Tools

New Approaches to Making Solaris More Secure, by Rich Teer (including hardening scripts)
http://www.sysadminmag.com/supplement/web_feature1.shtml

Securing Solaris, by Ido Dubrawsky
http://www.sysadminmag.com/supplement/913secsol.shtml

Casper Dik's fixmode (improves Solaris file permissions)
ftp.wins.uva.nl:/pub/solaris

Chris Calabrese's Harden script
ftp://ftp.freebird.org/unixware/freebird/internet/systools/harden  

Alberto Begliomini's SECUR
ftp://ftp.coldstone.com/secur

[3] Tripwire links:
      Free version V1.2  (last updated in 1994).
      Commercial Version  (starts at $495.-/server) also runs on NT.
      SecurityPortal article using Tripwire for Linux (useful examples)
      Sunworld article on tripwire.
      Sean's script for running tripwire: trip_host.sh , trip_all
      AIDE, a GPL file integrity checker

[4] General Application Hardening: LINKS TO BE DEFINED
[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
     Firewalling with IPF
     Introduction to IP Filter
     Introduction to IP Filter Part 2

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

[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].
http://ist.uwaterloo.ca/security/howto/1999-04-21.html
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
http://www.titan.org

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

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

Express Installation Home

Seán Boran SecurityPortal