Solaris Security Digest Tips: May-Dec. 2000

By Seán Boran (sean at boran.com)

December 20, 2000 - The Solaris Security Digest came to life in May 2000, and each week we have tried to include a useful tip. This document collects those tips in FAQ style. Just browse the table of contents to find items that interest you.

Thanks for reading the Digest this year. Enjoy the holidays and look forward to 2001. Feedback and comments are welcome as usual.

Sun documentation
Cold mirroring with mirror_boot.sh
The "ok" prompt
Version control of configuration files with SAVEIT
ntop
TCT: The Coroner's Toolkit (TCT)
Sara and Tara
SunShield BSM/C2
Disk mounting (vfstab options)
Host Auditing: audit1.sh audit2.pl
tocsin
Using TSIGs in BIND
"useradd" and "defadduser"
Securing Sendmail for typical workstation usage
IPFilter
Tuning Syslog
Limiting SUID Files
Improving Disksuite Security
Resources for Hardening Solaris
C2, TFTPD
Yassp beta#13
Improving "usermod"
Reconfiguring devices: boot -r
Solaris on Headless PCs
The dreaded patches: Patch management strategies & tools

Sun Documentation

Sun now publishes all user manuals, administration manuals, reference guides, etc., on docs.sun.com in several languages. Likewise, iPlanet documents are available on docs.iPlanet.com.

Cold Mirroring with mirror_boot.sh

Minimum downtime and prevention of data loss is important for most servers. The traditional solution is to use a RAID box to cover for disk failures. However, if the root /usr /var filesystems are on RAID and the raid controller goes, you have a problem (unless you have a fully redundant raid). I've been caught out twice over the last years by failed fiber channels and controllers, and I now use RAID for data disks, put system files on a normal disk, and mirror to an identical disk each night. If the boot disk dies, boot from the second disk.

The script mirror_boot.sh has been developed to do just that. Sample out is in mirror_output.txt. Read carefully the comments at the top of the script before using it!

How it works: Each night the offline disk is mounted and synchronized with the primary disk. The script is called from the root cron nightly. It mounts the spare disk under /newroot, copies all filesystems, installs a boot block and copies over a new vfstab. This creates a fully updated bootable spare disk. The results of the script are sent to the administrator via email.

Advantages: This solution is very simple (no complex hardware or software) and easy to understand in a crisis (when RAID complexity can be hell).

Disadvantages: Hot failover is not available, and a downtime of say 15 minutes has to be acceptable.

The "ok" Prompt

The "ok" prompt has a few hidden treasures. Bootprom is a very useful feature that gives Sun hardware an advantage above the rest: the possibility to remotely (via the serial line console) diagnose hardware problems, boot from disk/cd/network, or remotely install Operating Systems.

I've been using commands like go, resume, boot, reset, sync, printenv, setenv, probe-scsi, probe-scsi-all, test-all, etc., for many years, but had missed some obvious ones that are very useful, such as the following.
Note that "^" means "hold Ctrl key."

^P: previous command	^A/E: jump to line start/end
^N: next command	escB/F: jump to previous/next word
^L: list lines	^K: delete to end of line
^R: repeat line	^W/D: delete previous/next word

show-devs [device-path] Display all the devices directly under the specified device in the device tree; without device-path it shows the entire device tree.	disk-info: List all disks such that their path can be copied and used in the nvalias command (saves on lots of typing)

Warning: some commands like watch-net and test-net have caused systems to hang (for me); a cold restart was needed.

See also Sun's OpenBoot Collection documentation and its search feature.

Version Control of configuration files with SAVEIT

It's a good idea to keep previous versions of configuration files, to allow rollback, have an audit trail and coordinate between several administrators. Some sysadmins use rcs, some copy the configuration file to file.DATE beforehand, some do nothing :).

Francisco Mancardi from U&R Consultores [fman@uyr.com.ar] has written a simple script that can be used to save a copy of a file or directory before doing modifications.

Saveit is a little tool to make a backup of config files before you change them. It saves a copy under /Backup.d/DATE/ and logs "who saved what file" in /Backup.d/log-DATE. The existing directory structure is preserved under the backup directory.
It's a simple, but useful version control tool for text files. E.g.,

etc/[9]% saveit vfstab
copying file vfstab ===> /Backup.d/20000707/etc/vfstab

etc/[61]% saveit vfstab
copying file vfstab ===> /Backup.d/20000707/etc/vfstab.13:37

etc/[10]% ls -l /Backup.d/20000707/etc/vfs*
-rw-r--r-- 1 root sys 386 Mar 14 08:31 /Backup.d/20000707/etc/vfstab
-rw-r--r-- 1 root sys 386 Mar 14 08:31 /Backup.d/20000707/etc/vfstab.13:37

etc/[11]% tail /Backup.d/log-20000707
Backup base directory /Backup.d
Backup requested by root
Date (dd/mm/aaaa) 07-07-2000
Time 11:36
/etc/vfstab
--------------------------------------------------------------
Backup base directory /Backup.d
Backup requested by root
Date (dd/mm/aaaa) 07-07-2000
Time 13:37
/etc/vfstab

The advantages of this tool are: simplicity, and no clogging up the current directory with old versions of files, rcs directories, etc. It has been tested on Linux, Solaris 2.6/7 and OpenBSD 2.6.

Three versions of the script can be downloaded:

Francisco's original Spanish version: saveit-sp.sh
Francisco's version with English messages: saveit-en.sh
My tweaked version: saveit (less verbose messages, fix for OpenBSD, English translations and if target exists save with a time postfix).

ntop

What's ntop?

ntop is a tool that shows the network usage, similar to what the popular top Unix command does [for processes]. ntop is based on libpcap and it has been written in a portable way in order to run on virtually every Unix platform and on Win32 as well. . .
ntop comes with two applications: the "classical" ntop that sports an embedded web server, and intop (interactive ntop) is basically a network shell based on the ntop engine.

If you're wondering who's using what bandwidth on a server or local network, ntop is a useful tool that is simple to install and has a pretty good GUI. It was first presented to the public in spring, and several papers have been written about it, for example Improving Network Security Using Ntop which discusses using it as an IDS sniffer.

A binary package of an older Solaris7 version is available on sunfreeware.com, the latest version's source doesn't (yet) compile for me on Solaris8. The Solaris7 package does run, however, on Solaris8, but doesn't have the interactive interface.

Ntop runs as root, and listens for http connections on port 3000. On connecting with the browser, several statistic tables, graphics, etc., show the network usage. It's not advised to run it on sensitive systems, until the security and availability issues have been fully understood.

I hope to get the newest ntop tested over the next few weeks. Results will be posted here.

TCT: The Coroner's Toolkit (TCT)

Once your system has been penetrated by an attacker, what do you (apart from panic!)?

The Coroner's Toolkit (TCT) by Dan Farmer and Wietse Venema can help with the analysis of the system in an effort to find out what happened, how and when.

Tips

Don't reboot or switch off the system, just yet. . .
Download the TCT.
Run TCT and unplug the network interface. If you can't work on the console, do the analysis via the serial port.
Copy coroner data to another machine.
Now the machine can be switched off (if desired). It's important to run TCT before rebooting or cleaning up to get a copy of intruder activities. Some daemons may be running that will not run after a reboot.

Preparation

Tools: TCT needs perl and works even better if lsof is installed. TCT also needs to be compiled, so do it on a trustworthy machine first.
Other tools such as traceroute and nmap will be useful during the analysis.
To be able to detect without doubt whether files have changed, either an MD5 hash or tripwire will have to be run on the system before it was hacked (TCT uses MD5 and will make a list of hashes after the hack).
Running an network IDS like snort before the attack will allow data analysis from a different angle, i.e., analysis of the host-based evidence can be corroborated.

SARA and TARA

Advanced Research Corporation is providing free updates to Satan and Tiger, two old but useful auditing tools.

The Security Auditor's Research Assistant (SARA) is an updated version of the venerable SATAN network auditing tool.

CVE standards support
Enterprise-level search module
Standalone or daemon mode
Free-use open license
Updated twice a month
User extension support

Satan was a useful tool, with a good user interface, but it was not updated except for the Saint derivative. Bob Todd, the SAINT author, has been working on SARA since 1999. Some useful features in SARA include integrated support for nmap, samba and DDoS tools. A report writer for pretty summary reports is also available.

Tests show that it works on Solaris 8 and OpenBSD.

It needs a Web browser, but lynx is acceptable as well as the GUI browsers (configured in config/paths.pl). For Netscape I had to change the ".pl" handling as noted in the FAQ.
I did have frequent errors like "Initialization in progress, SARA is initializing, please try again later" when using lynx.
The "html/docs" subdirectory contains detailed HTML documentation. It's worth a read first.
Start with the "-n" option to integrate nmap.
Do not scan production systems unless you know exactly what you are doing. SARA (like Satan before it) can cause servers to have hung sessions, etc., especially with older (buggier) OSes.

Problems:

Sara still reports a "red" error for NFS read-only exports, something that I never agreed with in Satan. It should be "yellow."
"Email relay problem" does not actually check if relaying works, it just indicates that sendmail is present.
"rstatd" suffers from the same problem.
It is slow.

TARA is an update of the 1994 "Tiger scripts" for host-based security auditing.

Since 'tiger' has not been updated since 1994, there were numerous changes made to the 'systems' directories. Output was streamlined to provide a more readable report file. Also, minor bugs in the 'scripts' directory were corrected. TARA was tested under Red Hat Version 5.x, 6.x, SGI IRIX 5.3, 6.x, and SunOS 5.x.

This is also a useful update. It has a "-H" option to produce HTML output. It's worth taking time to customize tigerrc to your needs before running it.

Problem: no signature DBs are available for newer Solaris versions.

SunShield BSM/C2

Francisco Mancardi from U&R Consultores [fman@uyr.com.ar], who gave us the "saveit" script five weeks back, has scripts to make it easier to read the Sun's C2 (SunShield BSM) auditing logs. The scripts and files described here can be downloaded. First we'll briefly run though setting up C2 (SunShield BSM) audit logs.

What is SunShield BSM?

Sun delivers a "C2" level auditing system for both SunOS (Sunshield) and Solaris (Sunshield BSM). It is bundled with Solaris 2. BSM allows the actions of specific users to be recorded and written to an audit file. However, the auditing is at the system-call level, meaning huge logs may be generated by simple user actions. Performance is also affected. The standard analysis tools praudit and auditreduce offer no high-level analysis of audit trails. Applications may also write to the audit trail.
Reference documentation: "SunShield Basic Security Module Guide" (Standard Solaris 2.x documentation). Man pages: audit(1m), audit_startup(1m), audit_warn(1m), auditconfig(1m), auditreduce(1m), bsmconv(1m).

Enabling and configuring SunShield BSM:

To enable, go to single user and run "bsmconv":
init 1
cd /etc/security; ./bsmconv
Note: this modifies /etc/system, disabling Stop-A. It is suggested that you re-enable Stop-A by putting a "*" in front of the appropriate line in /etc/system:
*set abort_enable = 0
Set an email alias for "audit_warn" in /etc/aliases.
Enable command-line argument recording by editing /etc/security/audit_startup and adding the following line:
auditconfig -setpolicy +argv
To enable recording of all commands issued by every user, edit /etc/security/audit_control and change the "flags" line to:
flags:ex
To audit root actions in detail, edit /etc/security/audit_user and change the "root" line to:
root:lo,ex,fd,fc,fm,fw:no
Reboot and login. There should be an "auditd" daemon running.

Install the audit2info scripts:

Install gawk (no, Sun's awk won't work)
Extract the files into /opt/install.
If you install it anywhere else, then edit audit_lib and set AUDIT_HOME to the install directory.

Try out audit2info:

First, produce an ASCII file on C2 auditing activity :
cd /opt/audit; auditreduce | praudit > audit-data.txt

We can now analyze this output in different ways using the "audit2info" script. Links are provided to sample results.

Let's make the output from auditreduce | praudit above more readable:
./audit2info audit-data.txt > outfile

Show only activity concerning one username:
./audit2info -u bill audit-data.txt > outfile

Show only login/logout activity:
./audit2info -l ok audit-data.txt > outfile

Show only login failure activity:
./audit2info -l ko audit-data.txt > outfile

Show the complete output from auditreduce |praudit, but filtering out records that have fields with the string listed in the filter file default "filtro_audit"
./audit2info -f default audit-data.txt > outfile

The above example can be mixed as desired. . .

Notes using SunShield BSM:

It creates huge logs; watch it carefully. Ensure that the audit trail is stored on a partition with enough space.
Don't bother auditing if you don't have an expert capable of interpreting the logs.
There is no way of auditing file access depending on the filename. E.g., all write attempts to /etc/passwd cannot be simply audited. Neither is it possible to trace user actions on a high level.
To disable SunShield BSM: go to single user and run "bsmunconv":
```
init 1
cd /etc/security;
./bsmunconv 
```
Certain commands are not recorded in a useful way: Example: kill only registers the pid, so when you read the audit results, you don't know the relationship between this PID and the name of the binary file.
Workaround: write a wrapper script for kill - not a very elegant solution.
When auditing all the commands executed, the pathname of the files being worked on is not provided. For example,
cd /etc/host; vi hosts
cd /tmp; vi hosts
give records that show vi activity on a file name hosts, twice.
Workaround: enable the flags to audit file creation and file modification. This events save the pathname.

Disk Mounting (vfstab Options)

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 harddisks, e.g., 18 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 lots of file accesses are expected.
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 is 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), but it saves time fscking when shutting down, 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 CD-ROM 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

Host Auditing: audit1.sh audit2.pl

Auditing the security of an existing Solaris system can be time-consuming, and often requires on-site visits. There are several commercial tools and a few free ones (e.g., Titan and the Coroner's Toolkit) that help, but they can be complicated and require local installation. A few weeks back we presented a small Bourne shell script for simple auditing. This has now been updated and complemented with a second script.

Purpose:
• For situations where a "quick audit" of the system is required.
• simple to run; the auditor could even give it to the sysadmin, ask him to run it at night and send the results back to the auditor (perhaps by encrypted email).
• Its simplicity makes it easy to verify; it is not as thorough as other tools, but it is small and easy to understand.
• This script automates the gathering of the information only; of course, the difficult part is the interpretation and deciding what countermeasures to take.

This has now developed into two scripts:

audit1.sh (Bourne shell): This script is designed to run quickly and gather as much information as possible about the system. No file searches are conducted, to keep it fast.
Tested on: Solaris 2.6/7/8, OpenBSD 2.6, RH Linux 2.2.12-42 (Solaris is best supported)
audit2.pl (perl): This second script searches the entire filesystem, listing SUID, SGID, world-writeable, group-writeable files. It also lists trust files and their contents. Finally it lists files with weird names (e.g., containing punctuation characters), which might be danger or a sign of penetration. On a large server with 100GB disks, this can take a few hours to run.
Tested on SunOS 5.5/6/7/8, OpenBSD 2.6.

Please read the headers in the scripts before using.

tocsin

Doug Hughes (Doug.Hughes@Eng.Auburn.edu) wrote tocsin, a "featherweight network intrusion detection system" back in 1996. It is a free tool that listens for network scans. Tocsin only needs to be installed once per subnet, unless switches are used, i.e., all nodes do not see all traffic. It uses DLPI [see note 1] 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 syslog "auth" startup and shutdown messages are logged to "daemon."

Over the last few weeks tocsin has been significantly improved and version 2.1.1.2 released.

• fixed log file permissions
• new tcp or udp options (:t or :u) per service
• ported to Solaris 8 sparc/Intel
• new common package for Solaris sparc/Intel
• change UID to nobody after binding to the network
• new man page and startup file "S70tocsin" added
• New options: -T tcp only, -D destination network only, -O log IP options, -I invert port matching filter conditions.

This amazing little tool (it's only 20kB) is simple, but works quite well. The new options allow significant reduction of false positives. For this article, it was tested on Solaris 2.7-2.8/sparc and Solaris 2.8/Intel, but it should run on Solaris 2.6 and possibly 2.5.1 also.
tocsin can be downloaded in source form (tocsin.tar.gz), or a Solaris package (AUBtocsin), from:
ftp://ftp.eng.auburn.edu/pub/doug/

Doug has done great work with tocsin. If you've been waiting for an simple but effective IDS, this is worth a look.

Note 1: DLPI is the Datalink Provider Interface (a standard based on ISO 8886 and 8802 for Streams-based kernel implementations of packet filtering)

Using TSIGs in BIND

The DNS server, BIND, provides some advanced security features in its latest release. Here we examine one: the use of TSIGs (transaction signatures) to authenticate zone transfers. Zone transfers are usually limited to a list of IP addresses (via the ACL mechanism) which correspond to official DNS servers for a zone. Since only IP addresses are used, this mechanism is open to spoofing. BIND 8.2 and later allow authentication and verification of zone data. A key is configured on primary and secondary name servers, and the servers are configured to use this key to sign messages exchanged between the servers. It's important that the server times are synchronized. If the transfer is not authenticated with the correct key, no zone transfer may take place.

Let's look at an example where we use TSIG to restrict the zone transfers between a DNS primary "prim" (IP address 10.1.1.2) and DNS slave secondary "sec1" (IP address 10.1.2.2).

a) Generate an MD5 key, which will be used as a shared secret between the DNS servers. The "dnskeygen" tool is used; the key is written to a file.

# /usr/local/sbin/dnskeygen -H 128 -h -n prim-sec1. 
Generating 128 bit HMAC-MD5 Key for prim-sec1. 
Generated 128 bit Key for prim-sec1. id=0 alg=157 flags=513

# cat Kprim-sec1.+157+00000.private
Private-key-format: v1.2
Algorithm: 157 (HMAC)
Key: bFs2bXnLTYTI7r0WJv7HMA==

b) Create an identical key entry on both servers in named.conf:

key prim-sec1 {
	algorithm hmac-md5;
	secret "bFs2bXnLTYTI7r0WJv7HMA==";
};

c) Add an ACL on both servers to limit transfers to specific hosts, e.g.,

acl "my-nameservers" {
	localhost;
	10.1.1.2;
	10.1.2.2;
};

d) For each host in the ACL, tell the BIND which key to use (do this for each server), for example on the primary:

server 10.1.2.2 {
	transfer-format many-answers;
	keys { prim-sec1 ; };
};
zone "mytestdomain.com" {
          type master;
          file "mytestdomain.hosts";
          allow-query    { any; };
          allow-update   { none; };
          allow-transfer { my-nameservers; };
}

d) Restart both named servers (send a HUP signal), then check the (syslog) logs for errors.

Testing if it works:

On the secondary, stop named, delete one of the zone files and restart. Watch the logs; a message indicating a successful zone transfer should come, and the corresponding zone file will be created.
To make sure the TSIG key is really being used, change the key on the primary (e.g., add the letters "TEST" as the first few letters), stop both name servers, delete the zone file on the secondary, and restart both named. The zone transfer will not take place, an error message like
named-xfer[16280]: [ID 745729 daemon.notice] SOA TSIG verification from server [10.1.1.2], zone mytestdomain.com: BADKEY (-17)
appears in the log, and the zone file is not recreated. Changing back the key on the primary and restarting BIND on primary and secondary fixes our deliberate fault.

So it's really not so difficult to significantly increase the security of your zone transfers. It is important that the file permissions on named.conf be restrictive so that it cannot be read by everyone on a system; the secret string used in the key must remain secret.

"useradd" and "defadduser"

The useradd tool is a typical way of adding new accounts to the system. It adds a new user to the /etc/passwd and /etc/shadow (and on Solaris 8 /etc/user_attr) files. For example:

useradd -c "Seán Boran" -f 60 -g ftpusers -m boran

This creates the new user "boran" belonging to group "ftpusers," an appropriate home directory (with copies of skeleton files from /etc/skel) and sets the inactive timeout to 60 days.

Apart from adding users, system defaults can also be set (with the "useradd -D" option), so that it is easier to use. For example:

useradd -D -b /home -f 60 -g ftpusers

Here the default parent directory is /home, accounts are inactive if idle for 60 days, the default group is "ftpusers."

The first time "useradd -D" is run, a file /usr/sadm/defadduser is created, which contains the list of defaults. This file can be edited manually. For example, on a default Solaris 7 it contains:

defgroup=1 defgname=other defparent=/home defskel=/etc/skel defshell=/bin/sh definact=0 defexpire=

One would expect that the default shell could be changed with a command like the following, but this does not work on Solaris 7 or 8.

useradd -D -s /usr/local/bin/bash

So the only way is to edit the /usr/sadm/defadduser file manually, for example:

defshell=/usr/local/bin/bash

Solaris 8 contains a few additional defaults in /usr/sadm/defadduser for the new Role Based Authentication Control (RBAC):

defauthorization= defprofile= defrole=

If /usr/sadm/defadduser is copied from a Solaris 8 machine to a Solaris 7, the additional Solaris 8 settings are silently ignored. This is very useful, as one could synchronize this file across an array of Solaris servers without worrying about versions.

See also: useradd (1m), userdel (1m), usermod (1m)

Securing Sendmail for Typical Workstation Usage

On Unix and Linux, sendmail is invariably installed as an email server, running as a daemon. Many users/sysadmin think sendmail needs to run as a daemon on email clients and servers alike.

The sendmail daemon does not need to run on an 'Email Client'.

This erroneous installation behavior seems to be a default that goes back 15 years. It is difficult to understand why vendors have not corrected this. Few email servers are needed in an organization. The default should be to only send email, since most hosts are workstations or servers that do not need an SMTP server. Running sendmail as a daemon increases security risks:

A weakness may be found that would permit a remote penetration. Although sendmail has not been showing many weaknesses recently, it does have a checkered history and is a very complex piece of software.
Email relaying may be possible, if incorrectly configured.
A proper email server needs careful configuring for anti-relaying, anti-spam, virus & content checking etc. Therefore it makes sense to concentrate SMTP servers on specific, properly configured hosts.

So how is an email client set up? Assuming we want to deliver all email from our workstation to one SMTP server, the steps are:

1. Define the mail server: add an entry with the email server name and IP address to /etc/hosts. Then add an alias "mailhost" for this machine. There should also be an entry for the workstation, and workstation.DOMAINNAME.

2. Configure sendmail.cf (in /etc or /etc/mail), so that all email is sent via "mailhost":

DSmailhost
DRmailhost
DHmailhost
O FallbackMXhost=mailhost

3. Stop the sendmail daemon from starting automatically:

mv /etc/rc2.d/S88sendmail /etc/rc2.d/.no_S88sendmail

and kill the current daemon.

4. Add appropriate aliases to /etc/mail/aliases, for example:

root: Your.Name@Yourcompany.com

5. If email cannot be delivered immediately (due to server congestion for example), add the following entry to the root crontab to check for and send queued email every hour:

## process the email Q 0 * * * 1-5 /usr/lib/sendmail -q

6. Finally, test that email is being correctly delivered, by sending an empty test email to "root" (or some other local alias) and to your usual email address. The "-v" option is added to mailx so that we see the complete dialog with the email server, to convince us that it really is working correctly.

mailx -v -s test_email root </dev/null mailx -v -s test_email John.Doe@YourCompany.com </dev/null

Troubleshooting: look carefully at the output of the mailx commands above, and any error emails received in the root mailbox. Check that a "ping" to mailhost works as expected. The SMTP server may be configured only to accept emails from known workstations or workstations with a particular domain (in which case /etc/resolv.conf - DNS must be set up correctly and the workstation must use the same hostname as is listed in DNS).

Hopefully Sun and other vendors will wake up and stop the sendmail daemon by default in future OS releases. It would certainly help reduce the number of unwitting open email relays on the Internet.

Finally, here is a list of references for the SMTP server administrator:

Securing Sendmail sendmail.net/?feed=000705securitygeneral
SMAP & FWTK (Firewall Toolkit) www.fwtk.org
Sendmail www.sendmail.org
Postfix www.Postfix.org
Anti-Virus Mail Scanner amavis.org
Scan4Virus - Virus Scan Wrapper for Qmail www.geocities.com/jhaar/scan4virus
ORBS list of open relays www.orbs.org
MIME Defanger www.roaringpenguin.com/mimedefang

IPFilter

I had always wanted to try out Darren Reed's IPFilter firewall, and came across a great book on the topic, which I read cover to cover. It also covers ipchains. Although the book's focus is on using IPFilter on OpenBSD, it's equally valid for Solaris.

The book was detailed enough to see what IPFilter configurations look like in the real world. That's where I ran across two problems that seem like showstoppers to me, since I wanted to use IPFilter in a large, complex firewall:

No definition of host or network address groups is possible.
Likewise no definition of groups of protocols is available.

So my summary of IPF is:

Features: IPFilter offers filtering of protocol (UDP or TCP), IP fragments, ports (and ranges), IP options, TCP flags, ICMP type/code and provides NAT, logging, transparent routing, VLSM (Variable Length Subnet Masks). In addition, redirection of services "transparent proxy" and packet state can be analyzed to check that TCP packet ack/sequence numbers are correct.

Advantages: free, powerful, source code, works on many Unix variants, probably easier to use than ipchains.

Disadvantages: no GUI, requires expert configuration. No definition of address groups is possible, which could make the rules for a firewall protection of a large number of networks very complicated. Likewise, no definition of groups of protocols is available. The filter engine is not intelligent: it does not understand applications protocols like RPC, FTP which makes spoofing the "keep state" feature a risk.

If you're interested in IPF, some references:• A great book to buy is Building Linux and OpenBSD Firewalls, ISBN 0-471-35366-3 Sonnenreich/Yates/1999, and check out the companion Website www.openlysecure.org.
• cheops.anu.edu.au/~avalon/ip-filter.html
• ftp://coombs.anu.edu.au/pub/net/ip-filter
• mailing list at majordomo@coombs.anu.edu.au with a subject "subscribe ipfilter".
• IP Filter Based Firewalls HOWTO
• SecurityFocus Introduction to IP Filter, Introduction to IP Filter Part 2.

Tuning Syslog

The logging service delivered with Unix, syslogd, while very useful, is often not understood, badly documented and under-utilized. Here we provide a few tips to allow you to use syslog better. Note that Sun's syslog does not quite work like other variants such as Linux (not as good/flexible).

The syslog daemon runs by default on Solaris and collects messages from system and application daemons. Having collected the messages, it then either writes them to a file, sends them to a user or to a centralized syslog host. You can send messages manually to syslog via the logger tool (see the logger man page).

The file which determines syslog's behavior is /etc/syslog.conf. The default configuration (see link below) from Sun is many years old. What does it do?

Most messages are logged to /var/adm/messages.
Serious errors are written to the logon session of "operator" or "root." Emergency messages are sent to the terminals of all logged-on users.
Mail messages are logged to /var/log/syslog, or sent to a central server, if the "loghost" alias in /etc/hosts points to a machine other than the localhost.
Messages from "users" are sent to the loghost or written to a file, depending on the "loghost" alias.

How can we improve on this?

If we want to centralize logging on one server, it would be better to send all errors, not just user and email messages.
Why write email messages to one directory, most other messages to another file and ignore the rest? Either write one central file, catch important messages from all applications/daemons or write several log files - one for each daemon/application.
We could allow local logging of important messages and send all the rest to a central server.

So how do we change syslog's configuration?

The configuration file is a little quirky, and the man pages are not perfect, so first we look at the key elements.

Each line in syslog.conf is an instruction to send specific types of messages to a certain destination. The type of messages depends on the facility and priority.

The facility corresponds basically to the type/name of the application. There are 19 allowed values: kern, user, mail, daemon, auth, syslog, lpr, mark, news, uucp, cron, local0... local7. As you can see, many of the names correspond to typical Unix daemons. The kern facility corresponds to the Solaris kernel, and we find the boot messages there. The 8 facilities local0 to local7 have no special applications and can be attributed as desired. The facility used by most applications is the daemon facility. The mark facility is used to add regular timestamps.
Tip: An asterisk ("*") can be used to denote all facilities.

The message priority can be emerg, crit, err, warning, notice, info, debug or none. The least urgent/most verbose is debug, and conversely, emerg is reserved for very urgent messages.

The destination can be a filename (starts with a slash), a remote host (starts with an @), one or more usernames (separated by comma, or "*" to indicate all logged-in users).

So an entry like "auth.info /var/mylog" would mean all authentication messages of priority "information" or higher should be written to the file /var/mylog.

Gotchas

"mail.info" logs all mail messages of priority "info" or higher (i.e. not just priority &quotinfo").

You can do "*.priority" but not "facility.*"

"kern,mail.info" logs kernel and mail messages of priority info or higher. The same for other combinations.

Use tabs (not spaces) between message type and destination.

Maximum 20 (non-comment) lines are allowed; the rest are silently ignored.

Long lines don't work (from experience).

If the destination is a file, the file must exist and be writable.

Send a HUP signal, or restart syslogd after changing the configuration.

Debugging tips

Start syslogd with "-d"; it will show a matrix of what messages will be sent to what destinations. Then use the logger tool to send message with different facilities and priorities.

Security

Syslog uses udp transport, so message delivery is not guaranteed to remote loghosts - although if dedicated hosts are used inside critical zone, it should pose little problem. You may wish to keep a local copy of certain logs, even if a central log server exists. It is not advised to have your syslog port open to the Internet. An attacker may decide to fill your logs with junk.

By default syslog sits on the network, listens for messages from anywhere (local or remote) and processes them. This is fine for a syslog server, but the typical workstation/server does not need to receive messages. In Solaris 8, syslogd can be started with the "-t" option, which indicates that it should not listen to messages from remote hosts.

So now you've been introduced to syslog, how about a few sample configurations?

Our starting point is Sun's default:
http://www.boran.com/security/sp/solaris/syslog_sun.conf

Custom config #1: This example is a configuration I've used for 7 years with many machines. It's also used in YASSP beta 9 to beta 11.
http://www.boran.com/security/sp/solaris/syslog.conf
Function: If a loghost is defined, catch all messages and send to the log server - otherwise split messages to separate files per facility (I prefer not to have DNS messages mixed with SSH and POP messages), and copy all alert or higher messages into a separate file.

Disadvantages:

Since /var/adm/message is replaced by many individual files, some users/administrators won't be able to find the logs.

The "dmesg" command will not work, since it examines /var/adm/messages. Some people will rely on dmesg. I only found this out after using the configuration for 7 years!

It's more complex and hence more difficult to understand.

Given the above disadvantages, I now tend to recommend this configuration for central log servers, or large servers with many different applications and expert administrators.

Custom #2: For small servers and workstations.
Use /var/adm/messages rather than separate files per facility.
http://www.boran.com/security/sp/solaris/syslog_2.conf

All messages of priority "info" or higher are sent to the loghost or logged to /var/adm/messages. Minimal messages are sent to the console and users.

By uncommenting "section 5" in this example, a local log of "errors, authentication and system boot messages" will be kept, even if all messages are forwarded to a cental loghost.

We've covered syslog in quite a bit of detail and presented several examples that should help you get the best from your system logging. One more detail to note is that there are other implementations of syslog available. These offer either better security or improved functionality. I've not yet tested them, however, and can't make recommendations.

syslog-ng (tcp connections, content filtering, encryption, authentication)
http://www.balabit.hu/products/syslog-ng

secure syslog (encryption and authentication of a trusted auditors machine)
http://www.core-sdi.com/english/slogging/ssyslog.html

Nsyslogd (tcp connections & SSL)
http://coombs.anu.edu.au/~avalon/nsyslog.html

Limiting SUID Files

Files which have the SUID bit set (an "s" where the execute bit for the owner/group is shown in &quotls" 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 functions 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 overflows, 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 programs 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.

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

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

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

SUID references and further reading:

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

Improving Disksuite Security

Disksuite is a tool bundled with Solaris that allows disks to be mirrored or gathered into RAID sets. This is useful and a nice 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). RPC is a protocol that one tries to avoid having on sensitive servers, such as those on the Internet or in a DMZ. RPC uses dynamic ports and provides no standard access control methods.

How can Disksuite security be improved?

Don't run Disksuite. This is often my choice, mainly because of bad experiences with early versions of Disksuite 4-5 years ago. I don't forgive easily :-)
- Hardware RAID systems have the advantage that no special software (like Disksuite) is needed. This is better for secure systems (no RPC) 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. This tool was discussed in this digest a few weeks back.
  http://www.boran.com/security/sp/solaris/mirror_boot.sh
Run Disksuite and RPC, but use Wietse Venema's RPCBIND with access control restricted to localhost. This option is discussed in the YASSP post-install documentation:
http://www.yassp.org/after.html#RPC
Run Disksuite, but stop RPC altogether. I didn't know this was possible until a recent discussion on the YASSP discussion list. The &quotmetad" services in inetd.conf can be disabled, with the following consequences:
- &quotmetatool" won't work, but the command-line tools work fine. You'll probably need to know the command-line - well, for disaster scenarios with system disks anyway.
- Disksets can't be shared between systems.

Doug Hughes has documented tips and links on Disksuite, VxVM and the SparcStorage Array:
http://www.eng.auburn.edu/pub/mail-lists/ssastuff

Resources for Hardening Solaris

Over the last two years or so, several (free) useful tools and papers on hardening Solaris have appeared. Here we present a list with some comments.

My favorites are Titan and YASSP, but the idea is to provide a decent list of alternatives here, so you can learn from the various papers and pick an appropriate tool for your needs.
Titan and YASSP have different approaches and are useful in different situations. I would prefer YASSP for DMZ/bastion host hardening, but Titan is probably more useful for securing general workstations and multi-user servers. Also, each has features not found in the other.

Yassp (Yet Another Solaris Security Package)

YASSP
http://www.yassp.org
The goal is to install Solaris and have a good host security without having to spend hours in modification. According to Alan Paller, director of research at the SANS Institute, "When these scripts have been field tested, they will become the recommended solution for hardening Solaris systems and we will promote them widely."
YASSP is in final beta; the final release should be published very soon.

Hardening Solaris (Sean's articles on manual, Yassp and Jass based hardening)
http://www.boran.com/security/sp/Solaris_hardening.html

Interview with Jean Chouanard (main developer behind YASSP)
http://www.boran.com/security/sp/interview_chouanard.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 as to 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 methods 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 effect 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
These 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 (Sean's articles on manual, Yassp and Jass based hardening)
http://www.boran.com/security/sp/Solaris_hardening.html

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 is available in paper or PDF form, and is quite useful, but 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

C2, TFTPD

Back in August we had a brief look at Solaris C2 auditing / the 'BSM' module, and presented some scripts which make examining the audit logs easier. A new C2 article has been published in the special November supplement of Sysadmin magazine:

Implementing C2 Auditing in the Solaris Environment, by Kevin Wenchel and Stephen Michaels
http://www.sysadminmag.com/supplement/913c2.shtml

This article is easy to read and useful, and references a GUI developed by the authors.

The GUI, "BSM Event Viewer v1.1," is implemented in Perl/Tk and is easily compiled with gcc and Perl5. However, it crashed sometimes and I was unable to persuade it to open all the files in /var/audit or open individual log files. The author, Kevin Wenchel, thinks the problem might be with my X server (eXceed on NT4), so it may well work for you. A new release with some fixes is also on the way.

Despite these problems, the article is worth a read, and this space will be updated when we get the tools working.

TFTPD

On a different topic, I was on the hunt for a free TFTP server for Solaris with sources and came across utftpd v0.2.4.
http://www.ohse.de/uwe/software/utftpd.html

This server is interesting. It can be chrooted and run as a non-root user, and contains IP-level access control for clients (each client IP can be assigned create/read/write rights) and support automatic pushing and pulling of files from a version control system like SCCS or RCS (useful for managing router configuration files).

One minor change was needed to get it to compile on Solaris 8. In utftpd.c, change:
pid_t pi=waitpid(WAIT_ANY,0,WNOHANG);
to
pid_t pi=waitpid(0,0,WNOHANG);

YASSP beta#13

This week, I would like to shamelessly plug a project that I contribute to, which is a major benefit to the Solaris community. I would like to see many more of you involved in testing/reviewing/giving feedback. Below is an overview of YASSP, its features, disadvantages and advantages.

Now that the licensing issues have been sorted out, YASSP beta 12 and 13 were released this week, with the hope for releasing V1.0 very soon. The changes in the last two betas are documented in the previous section.

What is needed now, are testers for Solaris 2.6/2.7 SPARC and especially on Intel (nudge, nudge...).

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, which includes many useful precompiled security tools.

The first version appeared in summer 1999 and adhered pretty closely to the SANS Solaris Hardening Guide. We now have an improved YASSP beta#12 (Nov. 2000) that now goes 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.

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

Improves file permissions according to Casper Dik's "fix-modes" package [10].
Cleans the Solaris package database, so that it is consistent with installed files.
Tunes Solaris according to Jens-S. Vöckler's "nettune" [10], i.e., kernel and network parameters for better performance and resistance to denial of service attacks and buffer overflow attacks. Jean also added some ideas from the Titan Project [11].
Hardens the system for typical bastion host usage. The hardening has evolved from the original SANS paper and includes improvements from many other hardening scripts and documents.
The system administrator can selectively allow services by editing the (easy) /etc/yassp.conf.

There is also a tarball available in addition to SECclean. This tarball also includes "GNUgzip GNUrcs OPENssh WVtcpd PARCdaily" i.e., binary packages for SPARC and X86. The tools are installed in /opt/local, except tripwire, which goes in /secure/tripwire.

YASSP installation logs:

Debugging: Creating the file /var/tmp/seccleandebug before installation, will turn on a very verbose installation of SECclean, as it will do a "set -x" at the beginning of its [pre|post]install scripts.
A backup of all system configuration files that have been modified or replaced is kept in /yassp.bk/Before_DATE_TIME (where DATE and TIME are replaced with the installation time)
Changed files are also kept under /var/sadm/pkg/SECclean/save, so that if the SECclean package is removed (with pkgrm, or via de-install.sh), the original files are restored.
/var/sadm/clean-up/clean_up.log contains SECclean's activity

YASSP Advantages

Free (BSD license)
Documentation: HTML doc available online that is pretty good.
Comprehensive, works, tested by the author on Solaris 7/8 bastion hosts, Solaris 8 x86 web/mysql server and on a Solaris 2.6 workstation with CDE.
Can be backed out (great for testing), by doing
pkgrm SECclean.
Package format.
Includes Kasper's fix-modes and Jens's tuning scripts.
Supports supports Solaris 2.[678], and also the x86 arch.
/etc/yassp.conf allows sysadmins to configure what services they do and don't want.
Consensus of Solaris Security experts.

YASSP Disadvantages

Not much, doc could be improved. Some things cannot be easily customized on the install scripts (like PATH above).
See also the ToDo list on the YASSP home page [1], and suggested improvements below.

YASSP - Suggested Improvements

Consider adding chroot for DNS, anon ftp, user ftp, apache, syslog. . .
Automatically check patches, add patch management scripts.
Add scripts to reduce/harden SUID files.
Add more tools: tocsin, lsof (difficult due to architecture dependence), maybe ipfilter.
Update and add HTML pages to package (help is welcome).
Default config for tripwire has to be reviewed.
Other packages available on yassp.org to be deleted, as they are out of date.
/etc/syslog.conf: Change to workstation version by default, copy current version to /etc/syslog.conf.loghost

Yassp - References

[1]	www.yassp.org YASSP (yet another solaris security package) for Solaris 2.6/7/8 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 www.boran.com/security/sp/interview_chouanard.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]	Hardening Solaris with YASSP beta#13 (draft) www.boran.com/sp/security/Solaris_hardening3.html
[13]	Example YASSP beta#13 installation output www.boran.com/sp/security/solaris/yassp_install.txt

Improving "usermod"

In a discussion on "focus-sun" this week, Bennet Todd suggests a useful way of temporarily locking a user on Solaris, without destroying his/her password:

On other OSes, the command "usermod -L acct" prepends a "!" to the encrypted password field, and -U removes the "!". If you don't have something like that handy, it's easy enough to do with perl, something like:
perl -pi.bak -e 's/^'$user':/'$user':!/' /etc/shadow

The complementary command to unlock an account would be the very similar:
perl -pi.bak -e 's/^'$user':!/'$user':/' /etc/shadow

The usermod(1M) command is normally used to change a user's fields in /etc/passwd and /etc/shadow, e.g., home directory, shell, expiry date, login name. The idea is to write a script of the same name that accepts additional options "-L" and "-U" and otherwise calls the standard usermod. The script must be in the path before the real usermod command.

Note: This script directly edits /etc/shadow, so it won't work for NIS+ and must be run as root (hence permissions of 700 are suggested).

I've written an improved script that checks that the account really exists and confirms that the change has been made.

#!/bin/sh
#
# used wrapper:
#    make sure this is in your path before /usr/sbin
#
# If 1st argument is -L, locks users account by prepending
#    a '!' to the encrypted password in /etc/shadow.
# If 1st argument is -U, remove the '!'
# Otherwise call the normal Solaris 'usermod' tool.
#
# We check to make sure there is a valid entry in the shadow file first.
# A backup of the shadow is also made in /etc/shadow.bak

shadow="/etc/shadow";
usermod="/usr/sbin/usermod";

case "$1" in
-L)
  if [ `egrep -c "^$2:" $shadow` = 1 ] ; then
    perl -pi.bak -e 's/^'$2':/'$2':!/' $shadow
    echo "Account $2 now blocked."
  else
    echo "$0 Error: invalid account '$2'"                                       
  fi;;

-U)
  if [ `egrep -c "^$2:" /etc/shadow` = 1 ] ; then
    perl -pi.bak -e 's/^'$2':!/'$2':/' $shadow
    echo "Account $2 re-enabled."
  else
    echo "Error: invalid account '$2'"
  fi;;

*) $usermod $*;;

esac

"boot -r"

Solaris recognizes disk devices dynamically when booting and loads appropriate drivers. New devices are not automatically recognized (presumably for faster booting).

If a new disk is added, the system is typically rebooted and told to search for new devices. This can be done by several methods:

Halt the system and boot with the reconfigure option:
boot -r
Reboot the system with the reconfigure option:
boot -- -r
Or:
touch /reconfigure reboot

There is an easier way, even without rebooting.

Tell Solaris to update /devices and then create appropriate device links for disks (and possibly tapes or serial ports):

drvconfig disks ports tapes

Solaris 8 has a new command for managing devices, "devfsadm."

devfsadm(1M) maintains the /dev and /devices namespaces. It replaces the previous suite of devfs administration tools including drvconfig(1M), disks(1M), tapes(1M), ports(1M), audlinks(1M), and devlinks(1M).

devfsadmd(1M) is the daemon version of devfsadm(1M). The daemon is started by the /etc/rc* scripts during system startup and is responsible for handling both reconfiguration boot processing and updating /dev and /devices in response to dynamic reconfiguration event notifications from the kernel.

So this one command can be used for reconfiguring on Solaris 8:

devfsadm

Note: On my hardened Solaris 8 systems, the daemon "devfsadmd" is disabled without any obvious ill effects. It is probably necessary on systems like the Starfire which support dynamic changing of hardware.

Solaris on Headless PCs

Sun system administrators often manage the consoles of servers via serial lines: almost everything can be done remotely, including OS installations. This feature is possibly due to the powerful boot prom monitor included in Sun's SPARC systems (an advantage that Sun hardware has over all others I've seen so far).

The fun starts when trying to do the same with PCs running Solaris. The PC does not have an intelligent prom, so what Sun did was to implement the boot prom monitor in Software (it is called the Device Configuration Assistant). Booting a Solaris PC has several key steps:

The PC BIOS decides what devices will be used for booting, in what order and whether certain devices are disabled.
The SCSI controller (if there is one) can be configured to insist on its own boot device.
The boot disk has been now selected and activated.
Device Configuration Assistant detects devices and makes them visible to the boot manager. If Esc is pressed when this is booting, devices can be changed as can default boot order, boot disks, etc., via a menu-based interface. It is installed in the first few disk cylinders, in a separate partition (/boot).
Boot Manager: Allow options to be given to Solaris on booting, or using the boot interpreter.
Solaris

It is possible to get PCs to use the serial port A (COM1) as their console — you just need a null modem cable and a bit of patience. . . .

On Solaris 8, the following commands divert console input and output to the first COM port and ignore "carrier detect" signals (otherwise the machine won't reboot unless you are connected to the serial line). The Device Configuration Assistant can also be used to set these options.

eeprom ttya-ignore-cd=true eeprom input-device=ttya eeprom output-device=ttya

Note: Apparently the console redirection can also be activated by editing /platform/i86pc/boot/solaris/bootenv.rc and adding: "setprop output-device com1", "setprop input-device com1".

Connection to the Serial Console

If connecting from another Solaris box, say on its second serial port:

Set the speed for cuab to 9600 in /etc/remote
Connect using a command like:
tip cuab
Tips on using tip commands...
~? Get a summary of the tilde escapes.
~. Drop the connection and exit (you may still be logged in on the remote machine).
~! Escape to an interactive shell on the local machine (exiting the shell returns you to tip).
~# Send a BREAK to the remote system (THIS IS THE SAME AS STOP-A, but has no effect in x86 hosts).
If you use SSH to access the host which has its second port connect to the Console on the target, and you use tip, you'll find the tilde escapes giving SSH commands. So add an extra tilde to the front of the tip commands, e.g. ~~# for break.

Notes

The keyboard must often be left attached (e.g., test Compaq PC did not have a BIOS option to disable the keyboard).
There is no "STOP-A" equivalent to drop down to the boot monitor prompt on Intel.
These instructions should be valid for Solaris 2.56 and 7 also, but I've not tested them.

References

The Dreaded Patches

Patch Strategies

Weaknesses are continually discovered in Solaris and third-party applications. Not only do the weaknesses 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 simply ignored.

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

Get on all the mailing lists of organizations such as CERT/First, vendors like Sun, and especially Bugtraq. This can consume quite a lot of time.
Get on the mailing list of an organization which produces regular summaries of weakness/patches and security news, for example SecurityFocus, SANS or maybe this Digest :-). If a regular source of reliable information on Solaris and the applications that you use can be found, it may save much time.
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), but third-party applications will not be covered.
Check Sun's recommended patch bundles for changes every month or two: This requires little effort, but security is not as tight. Third-party weaknesses are not covered and the recommended bundles do not cover all security problems.

How do you decide whether a weakness is worth patching?

If the weakness concerns a remotely exploitable weakness in an active network daemon, exposed to a hostile environment like the Internet, install it soon.
If the weakness concerns a local exploit of a tool not normally used, not a daemon and on a host where only root or administrator accounts exist, it may be enough to install the patch together with a bundle at regular intervals (e.g., every six months).
If the weakness concerns a local exploit of a tool on a host where non-administrative users have accounts, then it depends on how critical the system is and how much the users can be trusted. Regular patches to multi-user systems are advised.
If the systems runs highly specialized software like databases, be very wary of installing kernel, I/O and driver patches. It is advisable to test patches on a separate system first.
Patches differ by Solaris version and architecture. So it makes sense to try and keep servers of the same OS/architecture on the same patch level and define a master host, whose patch level is automatically checked at regular intervals.

Patch Tools

Tools to help find patches relevant to your systems [1]

GetApplyPatch and CheckPatches are two Bourne shell scripts for Solaris patch management that I've tested quite a bit and can recommend.
1. CheckPatches is a script 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 you can use "-f" to download the Patch report via FTP).
  ./CheckPatches -f
2. GetApplyPatch is a script to get and apply a patch. Arguments are a list of patch numbers. If run from the command line, it is interactive and will ask you to confirm the download, show the patch readme, install the patch and delete the patch directory. It can also run without prompting in "batch mode."
  ./GetApplyPatch 108875-07
3. Both scripts can be used together to get each patch that is needed and install them (you are prompted each time).
  ./CheckPatches | ./GetApplyPatch
4. Additional features added 4th Dec 2000: Solaris Intel is supported, FTP proxies may be configured, and you can download from your local mirror rather than SunSolve. Cron scripts for automating steps 1 and 3 above and emailing the results are available (CheckPatches.cron, GetApplyPatch.cron).
5. Man pages are available.
If you have a Sun support contract, you can use the Patchdiag tool from SunSolve along with the latest patchdiag.xref to see what recommended and security patches are missing, then download and 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.com 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 active 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.
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 and getting the full patchdiag.xref file. It's written in Perl and does require quite a few Perl modules to be installed. Not yet tested in detail.

References [1]

Reg Quinton/Bruce Barnett's CheckPatches, CheckPatches.cron, GetApplyPatch, GetApplyPatch.cron scripts
http://ist.uwaterloo.ca/~reggers/drafts/

SunSolve sunsolve.sun.com (Patchdiag & XREF file)

A SunSolve Patch Primer
sunsolve.sun.com/pub-cgi/show.pl?target=content/content1

SecurityFocus Vulnerability calculator
SecurityFocus.com/focus/sun/form.html

Casper Dik's FastPatch
ftp://www.wins.uva.nl/pub/solaris/auto-install/

Joe Shambin's Patchreport
ftp://x86.cs.duke.edu/pub/PatchReport/index.html

Seán Boran (sean at boran.com) is an IT security consultant based in Switzerland and the author of the online IT Security Cookbook.

Published version: http://www.boran.com/solarisdigest/solaristips20001220.html