• Printing Access Control
• Access Control to Applications
• Floppy Drive Access Control
• Device Access Control
• Login Access Control
• Job Scheduler (at / cron) Access Control
• File system security
• Secure system startup
• Object reuse:  Solaris BSM  Unischred

• Network Peer entity authentication
• Trusted hosts:  Ssh (Secure Shell)
• Network Data confidentiality
• Network Data Integrity:  MD5  PGP
• Non repudiation of origin / receipt
• Network Access control
  • Inetd (Internet demons) - inetd.conf
  • RPC (portmapper/rpcbind)
  • NFS
  • UUCP (UNIX to UNIX copy program)
  • FTP    Anonymous ftp    TFTP (Trivial File Transfer Protocol)
  • Dial-up Access Control (TBD)

• Routing
• SNMP
• Other: ARP, RARP, bootp, bootparams

• Backup and restore
  • Sample Backup Products
• Availability Monitoring
• Prevention of Resource Abuse
• Change/release management <
  • User notification
    • Online notification
    • /etc/issue (Solaris 2.4 & later)
    • /etc/motd (Message of the Day)
  • Change Logs
  • Remote Installation (UC)
  • Remote Consoles
  • Patches
    • C library patch
    • HP Security Patches (UC)
    • IBM AIX Security Patches (PTF: Program Temporary Fixes)
    • DEC Security Patches (UC)
    • IRIX (Silicon Graphics) Security Patches (UC)
    • Sun Security Patches
  • Redundancy
    • Disk mirroring / RAID: Sample Products
    • File Replication (rdist)
    • Complete system redundancy
  • Disaster Recovery
    • Journalling File Systems
    • Crash dumps
      • Initial Crash dump analysis
• X windows
• Checklists
  • Unix Auditing checklist
    • System Configuration
    • Identification & Authentication
    • Access Control
    • Auditing / Logging
    • Diverse
    • Availability/Reliability of service
• Tools
  • Monitoring Tools (UC)
    • OpenVision SecureMax 3.2 (Dec. 1994)
    • Raxco ESM 4.0 (Mar. 1995)
    • Solaris 2: ASET (UC)
  • Central Management Tools
  • One-time auditing Tools (UC)
    • Satan 1.1 (new version due April 1997 ?)
    • Merlin
    • ISS (Internet Security Scanner): Dec 1995 UC
    • Pingware, Netprobe: TBD
    • TAMU tiger
  • Standard UNIX utilities
  • UNIX Security Tools - Public Domain
    • Perl (June 1996)
    • Diverse Goodies

Access Control

Printing Access Control

• BSD systems using the native lpd system can restrict printer access via /etc/hosts.lpd on a host basis. It is imperative to use this file to restrict printer access rather than hosts.equiv.
• SYSV: The "lpadmin -u" commands can be used to restrict printer access on a user basis.
• On most systems the printer subsystem runs under a dedicated user (e.g. lp). The password for this account should be blocked. In particular IRIX comes delivered with the lp UNIX account having no password. Block this account immediately after installation. See CERT CA-95:15.lp.vul. 

Access Control to Applications

UNIX (Sun) systems do not (yet) provide ACLs for limiting which applications are executable by which users.

=> However, by allowing execution of a program only by the owner and group and adding users to that group, the same effect can be achieved. This method is difficult to maintain however. 

Floppy Drive Access Control

Floppy drives are very useful for exchanging information, but they are also a source of concern for more secure systems. Their use is not recommended on class systems.

Disable floppy drives on Workstations, or only allow them on the workstations of "trusted individuals":

• Solaris 1 - edit /usr/kvm/sys/sun4m/conf/KERNEL_NAME and comment out the lines:

#options PCFS
#device-driver fd
and rebuild the kernel (see README in above directory), then reboot

• Solaris 2 - add exclude fd to /etc/system, delete the device and reboot. 

Device Access Control

• Do not connect external devices to the Workstation SCSI bus.
• Devices should only be in /dev or /devices.
• (Raw) Disk Devices used for special applications (e.g. databases) should only be readable & writeable by the application user.
• On Solaris, access to system devices (keyboard, mouse, screen / frame buffer, speaker / audio device) is restricted to the login user, unless /etc/logindevperm has been changed.
• How are special devices (keyboard, mouse, screen, speaker, microphone, camera, terminals, console, frame buffer ...) protected on your system?
• Can other users read the keyboard or frame buffer? On SunOS (/dev/fbtab) and Solaris (/etc/logindevperm) permissions can be set and need to be checked. 

Login Access Control

• If the file /etc/nologin exists, certain programs (e.g. ssh, xdm and with Solaris 2.5 or later rlogin) will refuse the user access and print the contents of this file on the users terminal. This feature is normally used for server maintenance. Root accounts can normally still login.
• Direct root login should not be possible over the network , or on the console , unless the console is in a physically secure zone. Also, the root password should be entered to access single user mode.
  Solaris 1 (/etc/ttytab):
  • Allow root to login only on the console:
    console "/usr/etc/getty cons8" sun on local secure
    Remove secure from all other lines.
  • Do not allow root login from anywhere and the root password must be entered to access single user mode:
    Remove secure from all lines.

Solaris 2 (/etc/default/login):

• Allow root to login only on the console:
  CONSOLE=/dev/console
• Do not allow root login from anywhere:
  CONSOLE=/dev/null

On other systems, look for /etc/ttys (e.g. OSF/1 & BSDI) or /etc/security or /etc/securetty (HP-UX) . Make sure this file is owned by root and has permissions are 644.

• Inetd wrappers or TCP wrappers: The so called Inetd or TCP wrappers were written by Wietse Venema in Holland. Inetd services (e.g. telnet, rlogin, ftp, rsh...) can have access restricted according to hostname or IP address. Although not fool proof, they do provide a good first barrier to unauthorised access. The tcp wrapper also logs all successful and unsuccessful connections, improving the usefulness of the system logs.
  • TCP wrappers should be installed where possible and configured restrictively.
  • Since this is a public domain utility, a version should be reviewed internally and then made available. It is not recommended that they be taken from the Internet, unless PGP signatures from a trusted source have been verified.
  • HP-UX: HP have integrated this utility into their base system (bravo HP!). It is configured in /etc/inetd.sec.

  Disadvantages: The hosts.allow file is not integrated into NIS+. Difficult to maintain large populations of this file. 

Job Scheduler (at / cron) Access Control

The standard UNIX schedulers at and cron should be carefully configured. Configuration files are in /var/spool/cron.

• User access to the at command can be restricted by adding the users to at.deny.
• Access to the cron program can be controlled via cron.allow & cron.deny. On Solaris 2.x, by default system accounts such as smtp, bin etc. are listed in cron.deny and normal users can use cron.
• Ensure that the system crontabs are only readable by their owner:
  chmod og-rwx /var/spool/cron/crontabs/* 

File system security

For standard UNIX filesystems:

• SUID or SGID scripts should not be used. Use a compiled program or (tainted) Perl. If a SUID scripts cannot be avoided, use a wrapper to protect the script (see Appendix D).
• Scan the system for SUID/SGID scripts regularly ( weekly, daily). Be wary of such files not in system directories. e.g.

      ncheck -s /dev/DISK_DEV_NAME (Solaris 2)
or
   /bin/find / -type f \( -perm -004000 -o -perm 002000 \) -exec ls -alg {} \;

• Scan the system for files with no name or group regularly ( weekly, daily).
  /bin/find / -nouser -o -nogroup -print
• Scan the system for strange file or directory names regularly ( weekly, daily), e.g. those named "...", ".. ", ".. ^B", " " etc.
  If such directories are found use ncheck -I INODE DEVICE to show other links to this object. (refer to the kill_baddies.pl script in Appendix D)
• Scan the system for world writeable files & directories regularly ( weekly, daily). e.g. /bin/find / -type f -perm -22 -exec ls -l {} \;
  /bin/find / -type d -perm -22 -exec ls -ld {} \;
• Set the sticky bit on world writeable directories. This prevents one user form deleting another user's files, although he can read them. e.g. chmod 1777 /var/tmp
• Set the sticky bit on /tmp. e.g. chmod 1777 /tmp
• Solaris 2.1-2.4: /tmp is normally in swap and by default the sticky bit is off (fixed in 2.5).This opens up a security hole when using the program ps (see CERT advisory CA-95:09). Therefore protect /tmp on startup. Create the file /etc/init.d/tmpfix with the following contents:
  
  #!/bin/sh
  if [ -f /tmp ] ; then
  /usr/ucb/chown sys.sys /tmp
  /usr/ucb/chmod 1777 /tmp
  fi
  
  Then create the following link and reboot the machine:
  ln -s /etc/init.d/tmpfix /etc/rc3.d/S79tmpfix
  
• Solaris 1: restore has a security hole if SUID. Since it is normally used by root, removing the SUID should not hinder operations. chmod u-s /usr/etc/restore
• Watch for files/directories owned by a different user than would be expected in a particular directory.
• Mounting filesystems: Consider mounting filesystems with either the ro (read-only) or nosuid options, even when they are mounted from local disks. The read-only option is useful for program disks that rarely change, the nosuid option for disks that should contain data (but not SUID system programs). Note that if /usr is to be mounted read-only, it needs have the remount option in addition, since /usr is automatically mounted by the system, before fstab is read.
• Miscellaneous file permissions need to be tightened. See the example script in Appendix D. Check that the following files are as specified:
   

Filesystems with ACLs:
AIX 4.x (not discussed here) and Solaris 2.5 provides ACLs (see [unix5], page 1212) for fine-grained access control.

Solaris 2.5: Basically a list of users and groups can be added to the permission list (ACL) for a particular file or directory. An ACL mask can also be added, which set the maximum allowed permissions for all users and groups except the owner. On a directory level, default permissions may be set for owner, group, other and mask as well as default for specific users and groups.
Examples:

Secure system startup

• Use an EPROM password where possible (and keep it in written form in a locked safe).
  eprom secure=command [for Sun4]
  eeprom secure-mode=command [for Sun4m,d,c]
• Single user mode should only be possible after entering the root password. (Default on Solaris 2.x, Solaris 1.x: enable eeprom password).
• Startup files with passwords: files such as .tiprc and .netrc may contain passwords. They should only be readable by their owner! (chmod og-rwx FILE). Class systems should avoid files containing clear text passwords.
• "dot" files: In users' home directories, there are often a multitude of files beginning with "." (dot). These range from application settings files (e.g. .mailrc, .newsrc) to login settings (.profile, .login, .cshrc etc.). These files should be writeable only by the owner. Preferably they should also only be readable by the owner or at most his group. 

Object reuse

Prevention of information transfer through object reuse is primarily prevented by:

• each user having a separate identity (UID) on the system.
• the umask being set restrictively.
• file permissions being correctly set.
• device access being properly controlled (normally via permissions). 

Solaris BSM

The Solaris BSM allows device allocation and deallocation between users. When devices are deallocated, they are "cleaned" to prevent subsequent users from accessing data not attributed to them. Deallocation routines for standard devices such as CD-ROM, 8mm tapes, QIC tapes etc. are provided as standard.

BSM must be activated to use the device allocation features (see bsmconv(1m)). 

Secure data exchange / communications

Network Peer entity authentication

See section on NIS & NIS+. 

Trusted hosts

By configuring .rhosts or hosts.equiv and using the Berkley "r" commands (such as rlogin), it is possible to login to remote machines without entering a password. This has the advantage that passwords do not traverse the network (in clear text) and the disadvantage that one host completely trusts the other. If one is compromised, it is highly likely that the other will also be compromised.

• Consider ssh for a replacement of telnet/rlogin which includes advanced authentication and full session encryption.
• Do not use hosts.equiv. It is too general and dangerous.
• Use hosts.lpd rather than hosts.equiv to restrict printer access.
• If /.rhosts is used, it should only be used between machines of the same security classification and administered by the same persons. It should also be regularly checked that the /.rhosts contents are correct. Permissions should be 600, belonging to the user. Never use the "+" entry.
• If hosts.lpd is used, permissions should be 600, belonging to root.
• A Perl script kill_baddies.pl is available (see Appendix D) to regularly check, report and delete "non conform" /.rhosts and hosts.equiv.
• If .rhosts is used, add entries with both username and host, e.g. if the current machine should trust the user Freddie on host sun_server, the rhosts entry would be "sun_server freddie".
• Never use the character "#" or "!" in .rhosts or hosts.equiv or hosts.lpd (these files don't have a comment character), it would allow a host with the name "#" access.
• Use tcp wrappers where possible. See the description in the section "Login Access Control".
• Monitor the permissions and modification dates of /.rhosts and /etc/hosts.equiv. If an automated script is used for this is should reset the permissions and ownership automatically.
• The contents of user .rhosts files can be controlled. To achieve this, there must be no way that the user can change his .rhosts. This would offer two possibilities
  1).rhosts can be setup to allow users trusted access to certain machines, but not to others.
  2) an empty .rhosts can be setup to ensure that trust is never used.
  
  Here is a method for each (commands are executed as root):
  1. Each user will work in a subdirectory of $HOME ($HOME/work), not $HOME itself. The user does not have write access to $HOME and cannot change any files there. He can however change any file in $HOME/work.

chmod 111 ~$USER
mkdir ~$USER /work
touch ~$USER /.rhosts
chmod 640 ~$USER /.rhosts
chown root ~$USER /.rhosts
chmod 700 ~$USER /work
chown -R $USER ~$USER /work

2.
chmod 111 ~$USER
mkdir ~$USER /.rhosts ~$USER /work
chmod 0 ~$USER /.rhosts
chmod 700 ~$USER /work
chown -R $USER ~$USER /work 

Ssh (Secure Shell)

Ssh is a program to log into another computer over a network, to execute commands on a remote machine and to copy files from one machine to another. X11 connections and arbitrary port connections can be secured by passing through the ssh secure channel. Basically, ssh is a secure replace for the Berkley "r" commands: rsh, rlogin, rcp and telnet with lots of other possibilities. Since this software was developed outside the U.S., it does not fall within U.S. Government export restrictions, unless resold by a U.S. vendor.

See the ssh page for a more complete description.

Network Data confidentiality

• Standard login utilities such as telnet, rlogin, ftp transfer passwords in clear text over the network. Avoid them, use ssh.
• Don't allow network sniffers on Workstations, regularly check for network interfaces in promiscuous mode (see the example script kill_baddies.pl in Appendix D). 

Network Data Integrity

The TCP/IP transport protocols check the integrity of data transmitted, albeit with a weak checksum algorithm. 

MD5 Tool

MD5 is a (public domain) utility which uses the RSA MD5 algorithm to generate a hash for a file. This can be used for file integrity checking (e.g. tripwire), more commonly for checking the integrity of patches downloaded from the Internet or as a component in the secure transmission of documents. 

PGP

Another alternative is PGP which can be used to sign files and thus detect unauthorised changes.

Non repudiation of origin / receipt

Not supported directly by UNIX. 

Network Access control

Inetd (Internet demons) - inetd.conf

• Make sure the file has permission 600 and is owned by root.
• Use the tcp_wrappers or the FWTK netacl for better logging and IP based access control. See the section "Login Access Control".
• Change walld so that it runs as user nobody in inetd.conf.
• Disable the following services unless absolutely necessary: rexd, rexecd, fingerd, systat, netstat, rusersd, sprayd, uucpd, tftpd.
• Disable ALL services except ftpd. (especially tftpd, rexec, rexd, rusers, sprayd). Use ssh for remote login.
• Enable inetd logging, if available (-t option on Solaris).
• AIX: See the CERT advisory CA-92:05.AIX.REXD.Daemon.vulnerability. 

RPC (portmapper/rpcbind)

• Install latest vendor patches.
• See CERT advisory CA94:15 for Solaris1.
• Class systems could use a version of portmapper/rpcbind with access control (i.e. those from Wietsa Venema). 

NFS

NFS is a very flexible method of sharing filesystems over heterogeneous environments. However it does have a few security weakness (it is a frequent penetration point) and requires careful configuration.

• NFS version 2 is supported by most vendors.
• In late 1995, Sun released Solaris 2.5, supporting NFS version 3 which allows:
  • tcp (as opposed to udp) connection based protocol, implying improved integrity (spoofing is more difficult).
  • ACL (access control lists) for more fine grained access control, if ACLs are available on the server UFS filesystem. 

NFS Servers
The NFS server is configured in /etc/dfs/dfstab (Solaris 2) and /etc/exports (Solaris 1). After changing these files, update NFS via
shareall (Solaris 2) or exportfs -ua; exportfs -a (Solaris 1).

• Never export directories read/write to the world.
• Export directories only where you need it an then readonly where possible.
• Don't export to localhost and keep export lists to less that 256 characters.
• Export only to named hosts/netgroups (with option access= ).
• Consider exporting with -nodev, so that devices are no inadvertently exported.
• Netgroups: Solaris 2 does not use /etc/netgroup, only the netgroup NIS/NIS+ table. Usernames have no effect in the /etc/netgroup (or netgroup NIS/NIS+ table), it should only contain computer names. For example:
  
  mail_clients (my_computer,,) (apollo,,) (dinky,,)
  
  Note that an empty computer name is trusted as a wildcard, meaning that any computer can access. Be careful and test!
• Do not export filesystems with the root= option if possible, as it allows root accounts on client systems to have root access (instead of nobody access) to mounted file systems.
• Check list of mounted directories regularly (using showmount and nfsstat [14]).
• Use fsirand on all exported partitions to scramble inode numbers. The filesystem must be unmounted to do this, so it is simplest to do in single user mode.
• Consider configuring the server to only accepting requests from privileged ports (this makes no sense where PCs as NFS clients are in use). On Solaris 2.x, add to /etc/system: set nfs:nfs_portmon = 1, on SunOS, add the following line after rpc.mountd is started in /etc/rc.local: echo "nfs_portmon/W1" | adb -w /vmunix /dev/kmem .
• Solaris1: start biod processes on clients only, nfsd on servers only (in /etc/rc.local). This is automatic on Solaris 2 (but to be extra sure, mv /etc/rc3.d/S15nfs.server /etc/rc3.d/.S15nfs.server).
• Solaris1: Regularly check the number of nfsd running (it is a common name for Trojan horses). NFS is multithreaded on Solaris 2, so there is only one process visible with ps -ef. 

PC NFS Server
PCs who mount NFS partitions from UNIX server require an authentication daemon to the running on the server: rpc.pcnfsd.

• Unfortunately this daemon has a bug[15] in it's handling of printer requests which allows unauthorised users to chmod any directory on the system and a different hole through insecure passing of parameters to a system() call. A fixed version is available for download from ftp.cert.org:/pub/tools/pcnfsd or apply the patch in the Cert Advisory CA-96.08. Some vendors also offer a fix - see the advisory for details.
• Don't use PC-NFS for sensitive data.
• Make sure that /var/spool/pcnfs has mode 755.

NFS Clients
NFS clients are configured in /etc/vfstab (Solaris 2), /etc/fstab (Solaris 1 & BSD), /etc/filesystems (AIX) and /etc/checklist (HP). After changing these files, update NFS via mountall (Solaris 2) or umount -a; mount -a (Solaris 1).

• Mount partitions nosuid if possible.
• Workstations should not be NFS servers. Disable nfsd. (automatic on Solaris 2, in /etc/rc.local on Solaris 1).
• On Solaris 2.5 and later, mount /var/mail with the actimeo=0 option to avoid file locking problems. 

Secure NFS
Secure NFS requires a secured naming serviced to run. This means that it is very difficult to run on SunOS. On Solaris 2, if NIS+ is running OK, then Secure NFS is easy enough to setup.

• Use Secure NFS for read-write directories if possible.
• Synchronise time (via NTP, rdate or some such tool) between hosts. Then reduce the time window from the default value.
• Put keylogout in the .logout file. 

UUCP (UNIX to UNIX copy program)

If UUCP is not needed, disable it. If it is needed, configure as in [unix1] page 193-219.
To disable UUCP:

Solaris 1: Disable in.uucpd in /etc/inetd.conf and /etc/rc.
Solaris 2: Disable in.uucpd in /etc/inetd.conf. Disable all lines in the uucp crontab. 

FTP

• Disable in.ftpd in /etc/inetd.conf if not needed.
• Consider using the West university wu-ftpd, for better logging, access control and features. Get the latest version or patch according to the CERT advisories CA-93:06, CA-94:07, CA-95:16 and AA-97.03 (check for later advisories too)
• Configure /etc/ftpusers to list system accounts, so they cannot not be used for ftp.
• Update /etc/shells if non standard shells are used in /etc/passwd.
• FTP can be protected on an IP address or hostname basis with the tcp wrappers (see also the "Login Access Control" section).
• FTP can be selectively enabled per user via /etc/ftpusers or by using the following trick: For users who shouldn't have ftp access to this machine, give their accounts a non-standard shell (such as bash or tcsh) and don't enter this new shell into /etc/shells. FTP access will be denied. Conversely, if a non-standard shell is required, it must appear in /etc/shells for FTP to work correctly.
• Enable logging (by adding the "-l" option on Suns). 

Anonymous ftp

• Very careful configuration is required for anon ftp.
• Put the anonymous area on a separate disk partition and mount it nosuid. For Solaris, follow the instructions in the Solaris 2.5 man page for in.ftpd. Note that the instructions in the in.ftpd man pages in versions prior 2.5 are wrong.
• If the Western university ftp server is used (wu-ftpd), it must be patched according to the CERT advisories CA-93:06, CA-94:07, CA-95:16 and AA-97.03 (check for later advisories too). It is often used for anonymous ftp because of it's added features, however the added complexity also results in more security holes.
  use "-a" option to enable /etc/ftpaccess config file.
• A sample configuration script for Solaris 2 is included in Appendix D.
• Avoid allowing uploads. If it is necessary, don't allow downloads of uploaded files, hide uploaded file names and don't allow them to be overwritten (otherwise you may end up as an illegal software repository). 

TFTP (Trivial File Transfer Protocol)

Tftp is used for diskless booting, X terminals, remote installs (Jumpstart) etc. See also the CERT advisories CA-91:18, CA-91:19, CA-93:05.

• Remove tftpd from /etc/inetd.conf if not needed.
• Restrict access to this service via tcp wrappers.
• Solaris 1: Make sure it is started with the -s /tftpboot option to indicate the tftp home directory, otherwise any file on the machine can be read/written by any other machine on the network!! (This option is the default on Solaris 2).
  tftp dgram udp wait nobody /secure/tcpd /usr/sbin/in.tftpd -s /tftpboot
• OSF/1 V3.2: Make sure it is started with the -r /usr/users/bootfiles option to indicate the tftp home directory. There is no "secure" option (as in the Solaris -s option), but the scope of get and put commands can be limited by giving a list of directories on the command line. So:
  • Enable logging to syslog via the -d option. Default logging sends the messages to /var/adm/syslog.dated/DATE/daemon.log. Although not all errors are written to the log, all files transferred are logged.
  • Limit the directories accessed by tftpd, the inetd.conf entry with the tcp wrappers would look like:
    tftp dgram udp wait root /secure/tcpd /usr/sbin/tftpd -d -r /usr/users/bootfiles /usr/users/bootfiles
  • The names of files to be transferred can be limited by adding them to /etc/tftptab. 

Dial-up Access Control

Solaris: see [unix5], page 1227 for instructions on configuring dialup passwords in /etc/dialups and /etc/d_passwd. 

Network components

Routing

Only routers should route data, i.e. computers should not route between subnets. This can be ensured by using static routing or starting the routing daemon is "quiet mode". It is recommended to configure static routing on all hosts:

• Solaris 1.x and 2.1-4: For in.routed create /etc/defaultrouter, enter the router IP address(es), then reboot. gated is not provided on Suns. If the Sun has two interfaces, then
  • Solaris 2.5: create /etc/notrouter to ensure that routing daemon is started in quiet mode.
  • Other versions: in.routed should be started in quite mode (make sure it is started with the -q option in /etc/rc.local or /etc/init.d/inetinit).
• AIX: TBD: stop gated and routed. Edit /etc/gated.conf?
• HP-UX: Create /etc/netlinkrc and add the following, then reboot: (is mode=1 correct?)
• /etc/route add default MY_ROUTER_ADDR mode
• OSF: Routing daemons are controlled by variables in /etc/rc.config: ROUTER=NO, GATED=NO. The default gateway is set in /etc/routes.
• Turn off source routing & IP forwarding on multiple interface systems:
  • AIX, add the following to /etc/rc.net:
    /usr/sbin/no -o ipfowarding=0
    /usr/sbin/no -o ipsendredirects=0
    /usr/sbin/no -o nonlocsrcroute=0
  • Solaris 2: edit /etc/rc2.d/S69.inet:
    ndd -set /dev/ip ip_forwarding 0
    ndd -set /dev/ip ip_ip_forward_src_routed 0
  • Solaris 1:
    echo "ip_forwarding/W 0" | adb -w /vmunix /dev/kmem
• Debugging routing: Use traceroute or start the routing daemon with the debugging options (e.g. in.routed -t). 

SNMP

Unless you have a central management team monitoring the network via snmp, disable it. If you want to use snmp:

• Define a standard for the use of snmp in your organisation and install all clients accordingly.
• Consider allowing read-only access to clients. Configure to accept requests only from named computers/IP addresses.
• Consider not configuring snmp traps or alerts.
• Consider sending alerts if requests come from unknown computers.
• Certain UNIX Versions don't deliver snmp clients with the OS (e.g. Sun), so you have to buy one (e.g. Sun Net manager) or persuade them to give you one free (preferable!). All vendors should supply a V2 snmp client - tell them that! 

Other: ARP, RARP, bootp, bootparams

ARP: T he Address Resolution Protocol is used to translate IP addresses to Ethernet (or MAC - Media Access Control) addresses. When hosts on the same subnet need to communicate, then need to have each others' MAC addresses. These are collected by either passively watching the network, or by sending an arp request containing the IP whose MAC address is required.

RARP: Reverse ARP is used to translate MAC addresses to IP numbers. It is used to dynamically configure booting client machines (often used during automatic installs such as Jumpstart).

Bootp & bootparams: These protocols are used to remotely configure an array of parameters for clients. The idea is to reduce the amount of configuration needed on clients. Used by Jumpstart, Printers etc..

All of the above protocols have a certain security weaknesses: they ask for information on the local network, without authentication (they don't really know who responds).

Availability

Backup and restore

• Keep index of backups on paper or on an off site machine.
• Account for all media.
• Consider encrypting data backed up to tape.
• Backup media should be stored in locked safes or locked rooms.
• Backups should only be transported by secure methods (like money transport).
• It is very useful to always have a spare external boot disk with backup software.
• Regular backups of critical directories to disk useful for recovering quickly from administrator errors. e.g. tar /var/nis and /etc regularly to a file on a separate machine. 

Sample Backup Products

Legato Networker: This client/server backup system needs a UNIX machine as server (e.g. Solaris, HP-UX..) and has clients for UNIX, NT, OS/2, DOS. It works with many jukeboxes and keeps detailed online indices. Users can restore files belonging to them without the administrators help - as long as the correct cassette is available. The author has positive production experience with this product using Solaris 1, Solaris 2 and test experience with NT clients.

Disadvantages: Expensive. Large online indices. Tapes are not in dump format. Some jukebox drivers are buggy and can cause system crashes.

Amanda: This public domain backup utility is designed for network-wide backups of many servers. Works only with UNIX. Amanda is an extension of the standard UNIX dump. Supports jukeboxes and has good performance. Amanda is in production on Solaris 1 & 2. Recommended for backups of large amounts of data, where restores are very rare.

Disadvantages: No vendor support (although an email discussion group does exist). No GUI, more difficult to use. User cannot restore files himself. 

Availability Monitoring

Several utilities allow the administrator to see what systems are up and running.

• Perfmeter is a (very useful) standard Sun graphical utility which can show diverse statistics in graphical form for the local or remote host(s). Perfmeter is particularly useful for simple monitoring of say, up to 10 servers on one console. A polling time of 15 seconds or greater is recommended.
• uptime is a standard UNIX utility, providing the following information:
  2:35pm up 21 day(s), 4:29, 16 users, load average: 0.09, 0.17, 0.23 A load average of 0-4 is normal, 4-9 high and 10 indicates a problem. 

Prevention of Resource Abuse

Disk Quotas
Quotas restrict how much space (i.e. space in Megabytes or number of inodes) a particular user may occupy on a particular disk partition. They are essential in preventing users from filling disks, or taking more than their fair share, especially on large mult-user servers. Quotas affects performance, so for example, they are recommended on /home and /var/mail partitions, but not on the root partition.

• Quotas are installed[16] for a particular filesystem, by adding the rq option in vfstab, creating a quotas file with permissions 600 on the filesystem, and issuing the quotaon -v -a command.
• Quotas can be switched off for a particular filesystem with quotaoff -v /usr.
• Or course a quota still needs to be created for each user. This can be achieved by editing a users quota with the command edquota johnny, or by using an existing users quota to create quotas for new users edquota -v johnny mathieu fabrice (create 2 new quotas based on that used currently by Johnny).
• Checking quotas (Solaris):
  quota -v Johnny [list quotas attributed to Johnny]
  quota -v 512 [list quotas attributed to Userid 512]
  repquota -va [show quotas for all users on all filesystems]

C-Shell
The C-Shell (csh) offers quite a few possibilities for preventing accidental resource abuse:
 

If your disk is full, the following will list all files in the current directory and subdirectories which are bigger than 0.5MB (1000 blocks) and newer than 7 days (on Suns):
find . -xdev -mtime -7 -size +1000 -ls

The following are useful for finding out why an application or service is malfunctioning:

Change/release management

User notification

Online notification

UNIX offers a wealth of small utilities for inter user communication.

• Wall allows a message to be sent to all users logged on.
• Talk allows an interactive "chat" session between two on-line users.
• Email allows user notification on a "send-now-read-later" basis.

/etc/issue (Solaris 2.4 & later)

The contents of this file are printed before the login prompt is presented to the user. Therefore, make use of it to inform users of the classification level of the machine and possible consequences of abuse. E.g.
***************************************************************************
*** Only authorised users should connect to this system. *****
*** Attempts to breach system security may result in *****
*** prosecution. *****
***************************************************************************

• ssh currently ignores this file.

/etc/motd (Message of the Day)

The contents of /etc/motd is seen by the user on login (unless xdm or ~/.hushlogin is used). Therefore, make use of it to:

• inform users of impending downtime for maintenance.
• changes to the system, new/updated applications. 

Change Logs

It is recommended that a file be kept on each server, detailed what changes were made to what files/subsystems, when, by whom. This is particularly important when more than one person administers the same machine. 

Remote Installation (UC)

TBD: Jumpstart (bootparams, ARP, root, package, patch servers), diskless booting, Solstice AutoClient 

Remote Consoles

Most UNIX consoles (e.g. Suns) can be remotely administered via the serial port. This is VERY useful feature.

1. Connect up a null-modem cable between ttya on the server and (say) ttyb on the other machine (let's call it the workstation).
2. Stop the server, remove keyboard & screen and then reboot.
3. On the workstation, start up an xterm and execute "cu -l ttyb -s 9600", then press return a few times. The login prompt or other console messages should be visible. Tip can be used together with /etc/remote instead of cu.
4. For Suns: To halt the server via this console type "~%b", equivalent to "STOP-A".
5. To quit the console, type "~.". Don't forget to log out of the console first! 

Patches

• New systems must be installed with the latest security patches.
• Regularly check vendor patch lists and email lists such as CERT for new security related patches ( weekly).
• Dangerous problems highlighted by FIRST, CERT or CIAC should be acted upon immediately.
• Test patches before installing them on production machines! 

C library patch

On certain platforms the gets() library function may have a weakness. To check, enter:
yes | tr -d '\012' | dd bs=256 count=3 | telnet <host> 79
If this command leaves a core file behind, gets() is insecure and hence any programs calling gets() can be insecure. Contact the system vendor for a patch.

This has been tested on Solaris 1 & 2, it is not a problem. TBD: OSF, AIX , Linux, IRIX & HP-UX?? 

HP Security Patches

HP patches are available via email (see Appendix C). HP have many different hardware & OS versions. Here a few sample patches for HP-UX 10.01 are shown:

PHCO_6595 Security vulnerability in syslog(3). e Fixed in HP-UX 10.10 

IBM AIX Security Patches (PTF: Program Temporary Fixes)

ftp://ftp.auscert.org.au/pub/mirrors/software.watson.ibm.com/aix-patches

DEC Security Patches

Ultrix: Upgrade to minimum V4.4 and apply Security Enhancement kit.
OSF/1: Upgrade to minimum V2.0 and apply Security Enhancement kit.

Some patches are available from:

ftp://ftp.auscert.org.au/pub/mirrors/ftp.service.digital.com/osf/
ftp://ftp.auscert.org.au/pub/mirrors/ftp.service.digital.com/osf/<v>/ssrt
ftp://ftp.service.digital.com/pub/osf/<v>/ssrt*
ftp://ftp.auscert.org.au/pub/mirrors/ftp.service.digital.com/ultrix /<v>/ssrt*
ftp://ftp.service.digital.com/pub/ultrix/<v>/ssrt*

where <v> is the version of the OS. 

IRIX (Silicon Graphics) Security Patches

IRIX has had quite a few serious security holes, mainly due to the fact that the systems are designed to be user friendly with little regard for security. See Appendix C for sources.
See  ftp://ftp.auscert.org.au/pub/mirrors/ftp.uu.net/sgi/security.Z  

Sun Security Patches

The following list is a sample of Sun patches, to give you a feel for actual problems. Dates are given to show when each list was last updated. OK, they are old, but it's not worth trying to keep them up to date, sunsolve do a much better job (that they did 4 years ago... :).

• On Solaris 2, to see what patches are installed, use showrev -p or:
  installpatch -p | awk '{print $2}' | sort
• The best way to keep up to date is to have a service contract with Sun and automatically be notified of new patches via the Sunsolve notification server on sunsolve.sun.com  (or sunsolve.sun.ch for Switzerland).
• Another (free) useful tool is PatchDiag (available from sunsolve). Install it with the latest patch reference list, run it and it will tell you exactly what recommended, y2k and security patches are needed for you system. A great time saver... pity it won't fetch the appropriate patches too!

Solaris 1.1 (SunOS 4.1.3, 16.11.95):
100103-12 SunOS 4.1.3;4.1.3_U1: set file permissions to more secure mode
100173-12 SunOS 4.1.3: NFS jumbo
100296-04 SunOS 4.0.3;4.1;4.1.1;4.1.2;4.1.3: netgroup exports to world
100377-22 SunOS 4.1.3: sendmail jumbo patch
100383-06 SunOS 4.0.3;4.1;4.1.1;4.1.2;4.1.3: rdist security and hard links enhancement,.
100424-01 SunOS 4.1.1: NFS fsirand security fix.
100448-03 OpenWindows 3.0: loadmodule is a security hole.
100482-07 SunOS 4.1;4.1.1;4.1.2;4.1.3: ypserv, ypxfrd, DNS fix.
100567-04 SunOS 4.1,4.1.1, 4.1.2, 4.1.3: mfree and icmp redirect security patch
100630-02 SunOS 4.1.1;4.1.2;4.1.3: SECURITY: methods to exploit login su
100631-01 SunOS 4.1.1;4.1.2;4.1.3: env variables can be used to exploit login.
101080-01 SunOS 4.1.1 4.1.2 4.1.3: security problem with expreserve
101200-03 SunOS 4.1.3: Breach of security using modload
100224-13 SunOS 4.1.1,4.1.2,4.1.3: /bin/mail jumbo patch
100257-06 SunOS 4.1.3c,4.1.3: ldd and ld.so incorrectly finds libXp.so
100272-07 SunOS 4.1.3: Security update for in.comsat.
100305-15 SunOS 4.1.1, 4.1.2, 4.1.3: lpr Jumbo Patch
100359-08 SunOS 4.1.1;4.1.2;4.1.3: streams jumbo patch
100444-74 OpenWindows 3.0: OpenWindows V3.0 Server Patch 3000-122
100452-72 OpenWindows 3.0: XView 3.0 Jumbo Patch
100478-01 OpenWindows 3.0: xlock crashes leaving system open
100507-06 SunOS 4.1.3: tmpfs jumbo patch
100593-03 SunOS 4.1.3: Security update for dump.
100630-02 SunOS 4.1.1, 4.1.2, 4.1.3: SECURITY: methods to exploit login/su
100631-01 SunOS 4.1 4.1.1 4.1.2 4.1.3: env variables can be used to exploit login
100726-28 SunOS 4.1.3: sun4m jumbo patch for kernel performance and memory bugs
100890-12 SunOS 4.1.3: domestic (US only) libc jumbo patch
100891-13 * SunOS 4.1.3: international libc jumbo patch
100909-03 SunOS 4.1.1;4.1.2;4.1.3: Security update for syslogd.
100988-04 SunOS 4.1.3: UFS File system and NFS locking Jumbo Patch.
101072-02 SunOS 4.1.1;4.1.2;4.1.3: Non-related data filled the last block tarfile
101080-01 SunOS 4.1.1 4.1.2 4.1.3: security problem with expreserve
101200-03 SunOS 4.1.3: Breach of security using modload
101480-01 SunOS 4.1.1;4.1.2;4.1.3: Security update for in.talkd.
101481-01 SunOS 4.1.3: Security update for shutdown.
101640-03 SunOS 4.1.3: in.ftpd logs password info when -d option is used.
102023-03 SunOS 4.1.3: Root access possible via forced passwd race condition

Solaris 2.0(Dec 1994):
101119-01 SunOS 5.0: fixes security hole in expreserve
100723-01 SunOS 5.0: installs create security hole
Solaris 2.1 (Dec 1994):
101352-03 SunOS 5.1 x86: security fixes for extraneous data, disk file problem
101089-01 SunOS 5.1: fixes security hole in expreserve
101707-01 SunOS 5.1 x86: mail uucleanup security fixes
Solaris 2.2 (Dec 1994):
101301-03 SunOS 5.2: security bug & tar fixes
101090-01 SunOS 5.2: fixes security hole in expreserve
101842-01 SunOS 5.2: sendmail jumbo patch - security
101268-01 SunOS 5.2: nispasswd puts questionable values in shadow fields
Solaris 2.3 (Dec 1994):
101235-01 SunOS 5.3: POINT PATCH: sendmail
101327-08 SunOS 5.3: security and miscellaneous tar fixes
101545-02 Tmpfs permissions TBD
101736-03 SunOS 5.3: nisplus patch
101739-07 SunOS 5.3: sendmail jumbo patch - security
101769-02 SunOS 5.3: nisupdkeys fixes
101889-03 OpenWindows 3.3: filemgr forked executable ff.core has a security hole.
102034-01 SunOS 5.3: portmapper security hole
102168-01 SunOS 5.3: nistbladm fix
102268-01 SunOS 5.3: nismkdir dumps core creating non-root masters
Solaris 2.4 x86 (May 1995):
101982-02 SunOS 5.4_x86: login & security fixes
102064-04 SunOS 5.4_x86: sendmail bug fixes
102106-01 SunOS 5.4_x86: nisd occasionally dies without core dumping
102293-02 OpenWindows 3.4_x86: security hole
102712-01 Tmpfs permissions

Solaris 2.4 SPARC (Nov. 17, 1995, tested):
101878-11 OpenWindows 3.4: Xview Jumbo
101945-34 SunOS 5.4: jumbo patch for kernel
101973-14 SunOS 5.4: fixes for libnsl and ypbind
102044-01 SunOS 5.4: bug in mouse code makes root attack possible.
102049-02 SunOS 5.4: linker fixes
102066-04 SunOS 5.4: sendmail bug fixes
102070-01 SunOS 5.4: Bugfix for rpcbind portmapper
102105-01 SunOS 5.4: nisd occasionally dies without core dumping
102216-02 SunOS 5.4: klmmod and rpcmod fixes
102218-03 SunOS 5.4: Libbsm fixes.
102273-01 SunOS 5.4: nisupdkeys -a does not deal properly with multi-homed systems
102277-02 SunOS 5.4: nss_nisplus.so.1 fixes
102292-01 OpenWindows 3.4: security hole
102303-05 SunOS 5.4: POINT PATCH: linker fixes
102319-01 SunOS 5.4: Sendmail point patch
102336-01 SunOS 5.4: NIS+ passwd aging fix.
102656-01 SunOS 5.4: /dev/qec should protect against being opened directly.
102680-03 SunOS 5.4: fixes for ufsdump and wall
102704-02 SunOS 5.4: jumbo patch for NIS commands
102711-01 SunOS 5.4: creation of /tmp/ps_data is security problem
102756-01 SunOS 5.4: expreserve still has security problem
102922-03 SunOS 5.4: Inetd fixes.

Solaris 2.5 SPARC (June 1996, tested):
103279-01 SunOS 5.5: nscd breaks password shadowing with NIS+
102832-01 OpenWindows 3.5: Xview Jumbo Patch
102835-01 OpenWindows 3.5: Filemgr Jumbo Patch
102837-01 OpenWindows 3.5: Calendar mgr doesn't display Fri March 1 in a leapyr
102839-01 OpenWindows 3.5: Mailtool attachments with subtype have wrong icon
102841-01 OpenWindows 3.5: OLGX (libolgx) Xsun memory leak with Caption widgets
102846-01 OpenWindows 3.5: Imagetool can't display pgm files properly
102850-01 OpenWindows 3.5: OLIT Jumbo Patch
102971-01 SunOS 5.5: vipw fix
102980-04 SunOS 5.5: sendmail fixes
102979-01 SunOS 5.5: memory leakage in be driver
102982-01 SunOS 5.5: csh fix
102984-01 SunOS 5.5: sd driver fix
103009-02 SunOS 5.5: ppp fixes
103017-04 SunOS 5.5: Jumbo point patch for SPARCstorage Array (SSA) 2.0
103026-01 SunOS 5.5: hme driver fixes
103048-02 SunOS 5.5: automountd fixes
103060-01 SunOS 5.5: nis_cachemgr fix
103066-01 SunOS 5.5: rpc.nisd hangs in write(2)
103093-02 SunOS 5.5: kernel patch
103135-01 SunOS 5.5: arch does not work correctly on non-SMI sparc systems
103136-01 SunOS 5.5: bugfix for renice
103162-01 SunOS 5.5: cp, mv and ln fix
103187-02 SunOS 5.5: libc fixes
103210-04 OpenWindows 3.5: Server (Xsun) Jumbo Patch
103226-03 SunOS 5.5: /kernel/sys/nfs and /kernel/fs/nfs fixes
103238-01 SunOS 5.5: Using sigprof and libaio will cause program to segfault
103242-02 SunOS 5.5: linker patch
103244-01 SunOS 5.5: ftp tests may cause system hang on Ultrasparc systems
103246-03 OpenWindows 3.5: patch for DPS and fonts
103251-02 OpenWindows 3.5: user cannot insert appointments into calendar
103276-01 SunOS 5.5: /bin/mail generates IOERR return code for quota exceeded
103282-02 OpenWindows 3.5: nohup cmdtool hangs up when parent dies
103285-01 SunOS 5.5: make and cpp fixes
103295-01 SunOS 5.5: fold loses data if files contain no newline
103300-02 OpenWindows 3.5: ff.core security patch
103301-02 OpenWindows 3.5: ff.core security patch
103318-01 SunOS 5.5: kernel/fs/fifofs and kernel/sys/pipe fixes
103325-01 SunOS 5.5: mount causes the system to panic Data fault
103381-01 OpenWindows 3.5: Patch for DGA client library FFB overlays
103468-01 SunOS 5.5: statd security problem

New Patches Released, but not yet tested by the author:
103226-06 SunOS 5.5: /kernel/sys/nfs, /kernel/fs/nfs & /kernel/misc/nfssrv fixes
103009-03 SunOS 5.5: ppp fixes
103076-03 Creator 2.5: FFB Patch
103526-01 SunOS 5.5: When fdc_sec_size is 128 or 256, it becomes an error
103241-01 SunOS 5.5: Undefined symbol in libc.so.1.9
103247-04 Solaris 2.5: admintool patch
103266-01 SunOS 5.5: nissetup default permissions for password table not secure
103454-01 OpenWindows 3.5: patch for Japanese input method in text of OLIT
103476-01 SunOS 5.5: bpp fixes
103477-01 SunOS 5.5: RPC: Unable to send/receive
103492-01 SunOS 5.5: autofs is not MT-safe
103505-01 OpenWindows 3.5: snapshot fails on FFB when default visual is overlay
103506-01 OpenWindows 3.5: Main window not redrawn correctly after unmapping
103516-01 SunOS 5.5: IPX/SPX and IPX Gateway hangs on heavy server load.
103661-01 SunOS 5.5: nisaddent fixes
103723-01 SunOS 5.5: cron fixes

Redundancy

On high availablility systems, either RAID 5 or mirroring is advised. It is recommended that separate (i.e. not built-in) RAID 5 be used. If two RAID 5 disks in a set fail, the recovery time can be very long (perhaps 12-24 hours) - so perhaps mirroring is preferable for certain systems. 

Disk mirroring / RAID: Sample Products

• The Data General Clariion (Jan 1995) external RAID system works on NT, SunOS, Solaris, AIX, etc. The author has had good reliability and performance experience with Solaris 2.4 and Sybase 4.9.2.
• The Sun SPARCstoragearray (Jan 1995) is a possible solution for Solaris systems, but performance is not as good as the Clariion and special software must be installed on the Sun system. It does not allow hot swapping of disks, nor does it work on any other architecture. It does have some interesting options though, a dual fibre optic interface which can be up to 3Km long, graphical configuration software and good pricing (sometimes!).
• Sun Disksuite  is a pure software solution to mirroring/RAID 5 or can be used for managing the storage array. V3.0 was tested in production and was stable, although the command line interface is heavy/hairy. V4.0 has a graphical interface which isn't bad (but I don't trust it), but you still need the command line. Disksuite only runs on Suns. 
• Since the first versions of this book, RAID has progressed alot, but I still prefer (for some systems), to have a second disk that I mount at night, copy from the first, adapt /etc/vfstab, install a boot block and unmount. This is useful in firewalls, where I don't like RPC services such as Disksuite, is easy to fix (just boot from second disk), but a downtime of 30 minutes a possible dataloss up to 24 hours has to be acceptable. Big standalone disks are cheap these days. Simple is beautiful...

File Replication (rdist)

Rdist is a very handy way of synchronising files between machines and ensuring that important files are not changed. It uses the Berkeley rsh protocol for communication, meaning it has the strengths and weaknesses or rsh (See the "Trusted Hosts" section), but (with V6.1.2) you can use SSH for the transport, which makes it a really secure. Recommended.

Uses:

• Replicating files between multiple machines, updating only files which change e.g. "Warm backups".
• Monitoring changes in important files from a central machine. If, for example, an attacker changes the DNS configuration file on a server, and this file is monitored by rdist each night, then it will automatically be changed by rdist to it's correct setting and the administrator will be notified.

Recommendations:

• Install the public domain version (6.1.2 in June 1996), it has more functionality and less security holes than (for example) Sun's version.
• Don't make it SUID. Use it only for root, if possible.
• Consider using ssh instead of rsh as the transport (this improves security _a lot_). Rdist 6.1.2 and ssh work very well together on Solaris2.
• If you use rsh, consider using the tcp wrappers to provide access control and logging.
• Secure the central rdist machine well, don't allow normal user accounts if possible.
• Synchronise by UID, not username - especially in heterogeneous environments. 

Complete system redundancy

• IBM's HACMP (Nov. 1995) offers complete system redundancy for AIX 4.1 machines. Not yet tested, but has been recommended from several sources. Two machines have simultaneous access to a RAID box, and monitoring software on the hot standby constantly monitors the master server and takes over if the master doesn't respond. The master's IP address is used on the standby. Presumably software running on the master with hostid-based licensing is still a problem.
• Data General (1994) offers a software for use with Clariions which allows redundancy on the system level. Not tested (quite expensive: ~$18k). 

Disaster Recovery

Journalling File Systems

Most modern UNIX variants (AIX4, Solaris 2.6...) offer journalled filesystems. Basically, changes to the filesystem are written first to a log, then to disk. When the disk write has been successful, the entries from the log may be removed or "checkpointed". This process allows for improved recovery after a crash or power failure and has been used in the database world for years. Journalling does incur a performance penalty though.
==> Switch on Journalling for filesystems where availability is important and where data is often written (e.g. /, /var and /home, but not /usr). 

Crash dumps

If a UNIX system crashes (also called a "panic") it has the possibility of writing the entire contents of memory to disk for later analysis. It is highly recommended to enable so called crash dumps on UNIX servers. Care must be taken that enough disk space is available (e.g. on large db servers with 500MB memory, it may not be possible to dump to swap space).

See also the man pages for: savecore, crash, adb, kadb .

• Solaris 1 enable dumps: Uncomment the lines as follows in /etc/rc.local:

#
# Enable savecore (default is disabled)
#
mkdir -p /var/crash/?hostname?
echo -n 'checking for crash dump... '
intr savecore /var/crash/?hostname?
echo ''

• Solaris 2 enable dumps: Uncomment the lines as follows in /etc/init.d/sysetup:
  ##
  ## Enable savecore (default is disabled)
  ##
  if [ ! -d /var/crash/?uname -n? ]
     then mkdir -p /var/crash/?uname -n?
  fi
  echo 'checking for crash dump...\c '
     savecore /var/crash/?uname -n?
  echo ' '
• It is recommended to add the following line to the above files, to prevent unauthorised access to the dumps. The dumps could have highly confidential information since they contain all application memory space at the time of the crash.
  chown -R root.staff /var/crash
  chmod -R 600 /var/crash
• If a file minfree exits in the crash directory, the number in this file specifies how many kilobytes of space must remain free on this filesystem once savecore has completed.
• Dump to a special (i.e. not the swap) device is possible. On Solaris 1, add the line to the kernel configuration file (assuming you want to use device sd1b) and rebuild the kernel (see man config):
  config vmunix swap on sd1b
  On Solaris 2, it's a bit trickier, adb must be used.
• If the several system crashes are expected, compress previous dumps. They often compress to only 5% of the original size. The same goes for dumps which are archived.
• Crash dumps MUST be analysed on the same OS version as architecture as they were created (with savecore). 

Initial Crash dump analysis

The following commands can be used to analyse what was going on in the system before the panic occurred. Refer to [unix4] for a nice tutorial on UNIX crash debugging.

ADB macros are kept in /usr/lib/adb (Solaris 1) or /usr/kvm/lib/adb (Solaris 2).
Notes on panic messages:

• Memory address alignment or data fault normally indicates a bad kernel pointer.
• Panic zero normally indicates a STOP-A. 

X windows

See the X windows section in the "Securing Applications" chapter. 

Checklists

A few short, practical check lists are presented here for

• auditing UNIX systems
• checking for a break-in TBD

See also [unix1] for some good checklists. 

Unix Auditing checklist (Dec. 11, 1996)

System Configuration

Document the configuration of the system being audited:
Architecture (OS version), hardware (CPU, memory, disks, peripherals), machine name & IP address, list of running processes, list of well known services NOT running (by experience), list of rpc services available and list of network interfaces.

Useful commands (on Sun) for getting the above:
uname -a, dmesg, format, showrev -p, ifconfig -a, ps -auwx or ps -ef, rpcinfo -p HOST, netstat -rn. 

Identification & Authentication

1. Make a list of non-blocked accounts, check for empty passwords or run crack on the password file. Are any accounts installed with default passwords? Scan the system for accounts with UID 0 or no passwords:
   awk -F: '{if ($3=="0") print $1}' /etc/passwd
   awk -F: '{if ($2=="") print $1}' /etc/passwd ["logins -p" on Solaris]
2. NIS: /var/yp/securenets installed?
3. NIS+: NIS+ is much better than NIS. Passwd / shadow table permissions OK? Running at level 2 security? All users allows access to all machines (nis_compat entries)? /var/nis regularly backed up? Replicas?
4. Password rules & aging?
5. Default file creation mask for each account. What is the system default (e.g. what mask is used for files uploaded by ftp)? Is a secure value set in the system startup files?
6. Umask e.g. 077 (no group or world access), 027 (group read, no world access) or 022 (group & world read)? Other values such as 002 are highly suspect. 

Access Control

1. Routing: What kind of routing is used? Static, route daemon in quite mode or full routing? Examine tables (netstat -rn).
2. Inetd:
   • disabling of unneeded services?
   • TCP wrappers?
   • Inetd logging (add -t option to inetd command line on Solaris 2.4) ?
   • Is UUCP disabled?
   • FTP: Is FTPD logging switched on?
     • Does /etc/shells exist? With what entries? (Accounts with these shells can use ftp).
     • Anonymous ftp is configured? Securely?
     • /etc/ftpusers: Which valid accounts can(not) use ftp?
     • If TFTPD is necessary, configure it correctly (-s option), otherwise disable it.
   • Have the "r" commands been replaced by ssh?
3. Login: Is root login restricted to the console (/etc/ttytab or /etc/default/login)?
4. SU on BSD systems: Restrictions on who can su to root by using the wheel group?
5. NFS client: Enabled? Are filesystems mounted from trustworthy machines? Is SUID disabled on mounting?
6. NFS server: Enabled? Check rw, root options? What hosts are given access? Are they in the hosts list? Are they trustworthy? Is Secure NFS used?
7. X11: Is xauth or xhosts used? Is "xhosts +" used? Is xhosts used on a multi-user machine?
8. Trusted Hosts (what other machines have direct access to this host?): hosts.equiv, hosts.lpd, .rhosts, .shosts. What hosts are allowed access for what accounts? Are (invalid) comments or "+" used? Are tcp wrappers or other mechanisms used to increase resistance to attack?
9. EEPROM: password control? Solars1: The system can be completely reconfigured in single user mode without knowing any passwords, if access to the console is possible. If passwords are used are they written down and kept in a safe place?
10. Physical access: are the systems in a open or protected zone? Audit trail of persons entering/leaving? Any obvious weaknesses?
11. Cron/at: What users are allowed to use these programs (cron.deny/at.deny)? Are the cron file permissions/ownership's correct?
12. PATH: is dot (".") in the root or other administrator's command line path? It makes trojan horses easier.
13. File permissions:
    • User "dot" files.
    • Make a list of SUID files:
      ncheck -s /dev/DISK_DEV_NAME (Solaris 2 only)
      find / -type f \( -perm -004000 -o -perm 002000 \) -exec ls -alg {} \;
    • Scan the system for files with no name or group:
      find / -nouser -o -nogroup -print
    • Make a list of world writeable files & directories. Is the sticky bit set on directories (e.g. chmod 1777 /tmp)?
      find / -type f -perm -22 -exec ls -l {} \;
      find / -type d -perm -22 -exec ls -ld {} \;
    • Miscellaneous file permissions need to be tightened. Check that the following files are as specified:
       

Auditing / Logging

1. What logging is carried out (C2, Syslog, Sulog, loginlog, cron log, accounting, /etc/utmp, utmpx, wtmp, wtmpx, lastlog , SAR logs, NIS+ transaction log, ...).
2. Are syslog messages centralised on a specially configured log server? Are all priorities/services logged?
3. Are log files protected (file permissions)?
4. Are they automatically pruned / compressed? How often?
5. Are they automatically analysed (how often, where) and alerts generated? 

Diverse

• Sendmail: Switched off on all clients except mail servers? Mail servers updated to latest sendmail patch?
• Are all the recommended (especially the security) patches installed?
• Are any security checkers (e.g. Satan, COPS, Tripwire, ESM, ASET, SecureMax...) run regularly? How often? Where are the results?
• Have etherfind/snoop been deleted/only executables by root?
• Look at current open network connections (netstat -a), do any look strange?
• Is DNS running? Are there are least two servers? Are the trustworthy? Are DNS host names used for access control? 

Availability/Reliability of service

• Backup and restore policies/mechanisms/procedures?
• Redundancy: RAID, mirroring, replicas, hot standby etc.?
• Is /tmp in root? Is it regularly emptied or emptied on boot?
• Is /var in root? If so are all logs automatically pruned, so that the root filesystem can never fill up?
• Special measures for preventing "denial-of-service" attacks? (e.g. monitoring TCP_SYN, file system full, user quotas...). 

Tools

Unischred (Apr.'93)

Unischred (from LAT) is a utility for completely deleting information on a hardisk. Price is about $229. Unischred Pro is a second utility with more features (US government DoD certified - meets military standards) and costs about $829.

Contact:
Sales Europe - Simon Goodfellow, simon@sdirect.demon.co.uk
US - Gary Kremen, Los Alto Technologies, gary@lat.com 

Monitoring Tools

This section is pretty old, a more recent review is available in the mechanisms document.

OpenVision SecureMax 3.2 (Dec. 1994)

This commercial product, originally from the VAX world, allows monitoring a number of systems via the network. Used on Solaris 1.1 and Solaris 2.3, 2.4.

Contact: Openvision, Wiesbaden, Germany
Advantages:
* Reliable: Works quite well for a small number of machines (10 or so).
* Correction scripts may also be generated.
* Command line and GUI interface.

Disadvantages:
* The product has not advanced for the last two years.
* Stability problems with more than 10 clients.
* No hierarchical management structure (each client has only one console).
* Console is quite expensive (approx. 4000.- CHF).
* no foreign language dictionaries.
* no local sales office in Switzerland (nearest is Wiesbaden, D).
* Templates for new OS versions (e.g. Solaris 2.4) were slow to appear. 

Raxco ESM 4.0 (Mar. 1995)

ESM is a commercial product, showing much promise as a future Enterprise wide UNIX security manager. Tested on Solaris 2.4. A new version was expected around the end of 1995 addressing known problems.

Advantages:
* can detect more security problems than SecureMax.
* very flexible (hierarchical structure, policy can reflect business structure).
* easy to use GUI.
* fast (only differences are reported between agent and console).
* local sales office in Switzerland.
* supports many platforms.
* The current version is highly recommended for conducting one-time system audits.

Disadvantages:
* Difficult to automate - it requires too much administrator time (this should improve in the new version 4.1).
* Solaris 2 version not in package format.
* No command line interface, no deinstall script, no foreign language dictionaries, no man pages.
* Very primitive scheduler, cannot output to pipe, cannot edit, cannot email reports.
* Cannot "update" for a group of clients.
* Cannot auto-install clients.
* Small, incomplete documentation.
* Raxco promise more than they can deliver!

Contact: http://www.raxco.com/  

Solaris 2: ASET

• Included as standard with Solaris 2.x, ASET (Automated Security Enhancement Tool) monitors changes to system files. (See man aset). ASET was originally developed as part of the C2 kit for Solaris 1.
• There is no GUI (only command line), so it can be difficult to use at first.
• However, it's use is recommended where Securemax or ESM are not available. 

Central Management Tools

The two principle tools which claim to offer centralised, rule based management of a heterogeneous network of UNIX machines are Tivoli and CA-Unicenter. The author has no experience with either, but they are known to have weaknesses (1994).

For AIX, IBM offers SMIT and distributed SMIT, which work for basic system management. However, they do not obliviate the need for the command line. SMIT is interesting for learning AIX because it can show what commands it is going to execute to complete an operation. A curses based terminal equivalent to SMIT (called smitty) is also available. A commendable effort from IBM! 

One-time auditing Tools

In addition to regular system monitoring (normally by the system administrator), one-time system audit should be conducted (e.g. once per year). These audits should be carried out by an independent auditor (not the administrator). The following are a sample of such auditing tools. 

Satan 1.1

Satan is a public domain software (based on Perl and a WWW browser) which allows a large number of hosts to be scanned on a network for weaknesses in network software. It does not test for all known weaknesses, but it is easy to use and can scan entire subnets of hosts. A graphical user interface based on html browser (e.g. Netscape) makes it easy to use and extend. Links CERT advisories etc. make it very interesting for a security administrator with WWW access to the Internet. Highly recommended.

Satan tests for the following security weaknesses:

• Are NFS file systems exported to unprivileged programs, arbitrary hosts or via the portmapper?
• Is there a NIS password file access or rexd or rsh access from arbitrary hosts?
• Is arbitrary file access available via tftp?
• Is X server access control disabled?
• Is there a writeable anonymous ftp directory?
• Is there an insecure version of sendmail or wu-ftpd in use?

Recommendations:

• Never use Satan on a network unless the system administrators and helpdesk have been informed.
• Satan should not be made generally available to users or first level support.
• Since Satan is "well known" on the Internet, all machines exposed to the Internet must be regularly scanned.
• Internal sensitive machines should also be regularly scanned by security personnel.
• Don't use version 1.0, it has a security bug. Use V1.1 instead.
• Do not use the WWW browser for both Satan and Internet browsing at the same time.
• Install a "Satan detector" to notify the administrator immediately if anyone is scanning your servers! See the example in Appendix D.
• Satan was designed to be easily extensible and it would be interesting to extend it to cover other know weaknesses and recognise other architectures and list Operating Systems by version. Of course, it requires a company or university to sponsor such an event, but it would be worthwhile. 

Merlin

Merlin is a nice HTML front end to certain Security checking utilities such as: Tiger, COPS, tripwire...

It is useful when first using these products (easy to learn and use), but doesn't allow detailed configuration of the utilities. 

ISS (Internet Security Scanner): Dec 1995

The Internet Security Scanner is a "Satan like" network scanner. A public domain and commercial version are available. I couldn't compile the public domain version, the commercial version is quite expensive ($4000.- to check 100 devices) and evaluation copies only work on one machine. Support is limited to SunOS4.x, Solaris 2.3, HP-UX and AIX 3.2. 

TAMU tiger (Dec 1995)

The tiger scripts, from the University of Texas are used to scan a machine and report possible security problems. This utility can go into great detail, but so much so that it requires considerable effort to automate it so that "normally" on a clean system there is no output. It finds more holes than any commercial product so far tested. No correction scripts are created, so correction of problems is manual and time consuming. Solaris 1.x and 2.x are well supported, but it is not clear how well they work on AIX , OSF and HP-UX.

• Recommendation: use as an auditing tool, if no commercial utilities such as SecureMax or ESM are available. 

Standard UNIX utilities

UNIX Security Tools - Public Domain

Most security tools for UNIX are from the public domain. Interested parties can contact t he author for further details, if they can't find them by the usual search engines. 

Perl

• Perl integrates the features of sh,csh,sed,awk,tr and provides direct access to certain standard library C functions (e.g. socket calls, IPC, passwd & host table manipulation...). The current version is 5. Perl can be used to write scripts which implement specific security functions, e.g. monitor a system for Satan scans, monitor .rhosts, hosts.equiv files on a system and delete those not conforming to policy.
• It is recommended that Perl be used as a standard scripting language where possible. Perl runs on most UNIX machines as well as VMS, NT, OS2 etc.. 

Diverse Goodies (a bit dated....)

• Top is a utility for monitoring active processes, memory usage etc. Recommended. 
• Contool: is a read-only console window for Suns, providing audio alerts and extra logging. Useful for syslog console machines. Recommended. 
• Nfswatch: On Solaris 1&2, NFS can be monitored in real time. Recommended on Solaris 2.
• Ofiles and lsof (recommedned) show all open files, devices and services.
• monitor_process.pl is a script from the author which checks to see that certain processes are running. Can be used on servers (via cron) to make sure all important daemons are running.
• monitor_socket.pl (from the author) watches for socket connections, such as those from Satan or Sybase. It (as a daemon) listens to local TCP sockets (via a list supplied on the command line, or Sybase defaults 2025 & 2026) and emails the connection details to $user. If the connection appears to come from Sybase, it prints the Sybase connection data in readable form. Tested on Solaris 1.1, 2.3, 2.4.
• Proctool is a graphical utility for monitoring processes (on Suns), setting alerts etc.
• Top is a great little command line utility for monitoring processes. Recommended.
• Swatch monitors log files, and takes actions (e.g. send an email to an administrator) according to customised rules. Written in Perl. Highly customisable.
• Sudo allows delegation of certain tasks normally performed by root in a controlled manner.
• Shadow allows Solaris 1 to use shadow password files and hence increase security.
• Tripwire: from Gene Kim and Gene Spafford, is available from ftp://cert.org/pub/tools/tripwire . It is used to see if any files have changed on the system. very comprehensive and works on many platforms. Tripwire can use many popular hash functions for creating file signatures (e.g. MD2, MD5, SHS ...). Recommended.
• wrapper.c: This is an SUID wrapper program for use with scripts which need SUID access.
• Ypx is a public domain utility which checks for a security hole in the NIS databases.
• smrsh: For sendmail issues, see the section "sendmail" in the "Securing Applications" chapter.
• COPS is similar to tripwire, but also checks accounts, devices and vital files.
• anlpasswd: A proactive password checker, that runs a series of checks on passwords at the time users set them and refuses password that fail the tests. It is designed to work with shadow password systems. See ftp://ftp.auscert.org.au/pub/mirror/info.mcs.anl.gov/*
• Crack: is good for checking the strength of your password file now and then. See ftp.auscert.org.au/pub/cert/tools/crack
• cpm: checks to see if your network interfaces are running in promiscuous mode.
• rscan checks for a number of common IRIX-specific security bugs and problems. It is from: ftp.auscert.org.au/pub/mirrors/ftp.vis.colostate.edu/rscan/*
• Sources for ftp can be found at ftp.uu.net:/packages/bsd-sources.
• XNTP or NTP is the Network Time Protocol utility, that allows a network of machine to keep time with great accuracy. It is useful when using Secure NFS or time based authenticators (such as SecurID). Included in Solaris 2.6 and laterftp.udel.edu/pub/ntp/ .
• Other stuff : xtr, sush, shadow, securelib.

[11] If passwords are synchronised across machines, the weakest machine determines the security level.
[12] "Avalon Security Research" published details of this hole along with scripts ("slammer") to exploit it on the Internet (Nov.'95).
[13] A utility for automatically generating /etc/.rootkey is available from the author.
[14] A script is required for this, no standard utilities are available.
[15] "Avalon Security Research" published details of this hole along with scripts to exploit it ("slugger") on the Internet (Nov.'95).
[16] Example commands are for Solaris 2.4.