The IT Security Cookbook - Securing UNIX

Overview

UNIX was not designed to be a secure operating system. It was designed to be flexible, "open", portable and simple in concept. Now, at 28 years of age, UNIX is one of the major server operating systems and looks likely to remain so in the coming years. However it is causing major security headaches. Most vendors have improved security over the years, with the result that the current systems are better than their precedents, but vendors still don't put nearly enough effort into cleaning the UNIX source code, or can't (for compatibility). Technical innovation seems to be the major selling point for UNIX systems and security is being neglected. It requires significant system administrator know-how to run UNIX systems securely. [The same applies for VMS and NT incidentally]

UNIX has many variations, for example: Next, SGI, AIX, HP-UX, AUX, SunOS, Solaris, SCO, Ultrix, Digital UNIX (OSF/1) and Unixware. The UNIX trademark now belongs to X/Open Ltd. UNIX has two principal flavours: BSD (developed at Berkeley University) and SYSV (System 5 from AT&T, later USL, Novell and now SCO).

SVR4 and OSF are based on both BSD and SYSV with SVR4 being the defacto standard today. Most commercial systems are based on SVR4 or have certain components from SVR4. DEC, IBM and HP systems have lots of OSF features.

BSD: SunOS (Solaris 1.x), BSDI, Ultrix, OSF/1, NeXTstep, HP-UX
SVR4: Solaris 2.x, HP-UX, Unixware and (sort of) IRIX5, HP-UX10
OSF: Digital Unix
Weird: AIX (SVR3+BSD+OSF+IBM). AIX is a mixture between BSD, System V release 3 and major non-standard changes. Hardly any subsystem in AIX is managed in the same way as on BSD or SVR4. Lot's of fun to administer.

In this section SunOS (Solaris 1.x) and Solaris 2.x are mainly considered. AIX, Digital UNIX, IRIX and HP-UX will also be added bit-by-bit. However, most of these systems are similar to either SunOS or Solaris, so this chapter should be useful for non Sun admins.

  • No single tool yet exists that can secure a system according to the following specification. For the moment, I recommend Raxco's ESM product (or Tripwire + TAMU tiger scripts if you can't afford ESM) for securing important servers and Satan for network-wide security checking, together with some home made scripts for monitoring logs, login times, dangerous files, network interfaces, and empty passwords (e.g. the example scripts provided in Appendix D). Tripwire is a great little tool for detecting unauthorised changes on non-multiuser hosts such as firewall bastions.
  • Use Solaris 2.x rather than Solaris 1.x (SunOS) where possible, it is more secure and easier to administer. If you must use Solaris 1, install 4.1.4 rather than 4.1.3, it has security patches integrated.
  • Trusted UNIX systems (e.g. TCSEC "B" approved) are not discussed here yet. They tend to be quite different from commercial UNIX. Perhaps sometime in the future?

A quick guide to securing UNIX

  • Users: Ensure that good passwords are used by users and staff. Disable or change default passwords.
  • Check through the resources listed in Appendix C.
  • Solaris/SunOS: Use the instructions in Appendix D to strip unnecessary services from the system, especially for firewalls and critical servers.
  • Switch off sendmail on all clients that mount /var/mail and none mail servers. Run sendmail from cron. Install the latest V8 sendmail on mail-servers.
  • Install the latest patches with new installations. If possible, automate patch installation (via Jumpstart on Suns) to allow easy synchronising of patch versions on all machines.
  • Export and import NFS filesystems restrictively.  Use secure NFS.
  • Use NIS+ rather than NIS.
  • If TFTPD is necessary, configure it correctly (-s option), otherwise disable it.
  • Enable inetd logging on important servers (add -t option to inetd command line on Solaris 2.x) if you have lots of space on the syslog server.
  • Monitor logs ( weekly,  daily) for strange behaviour. Automatically generate alerts.
  • Run a security checker regularly ( every 6 months,  every month) on servers (e.g. Tripwire, COPS, ESM, ASET, SecureMax...). Tripwire could be run several times per day.
  • Use a scanner (ISS/Satan/nmap) to scan the network regularly ( every 6 months, every month): from the inside and from the outside if you are in charge of a firewall. Never use a scanner without the system/network administrators permission.
  • Use ssh instead of rlogin, rsh, rcp & telnet.
  • Use xauth rather than xhost with X11. Never use "xhosts +". If you use ssh, the xauth is automatic and X11 comms are encrypted.
  • Switch off inetd daemons you don't need (on firewalls: remove everything except maybe ftp and use ssh for login).
  • Configure UNIX proxies & Firewalls according to the Firewalls chapter.
  • Get yourself onto a FIRST security alert email list. See Appendix C.
  • Delete sniffers such as etherfind and snoop. 

General

Documentation

Ref. Document number  Title Date Author
[unix1] ISBN 1-56592-148-8  "Practical UNIX Security", O'Reilly & Associates. 
2nd Edition in April 1996 (much bigger) 		 June 1991  Garfinkel / Spafford 
[unix2] Unixworld magazine  Encrypting Shell Scripts  Sept. 1992  R. Schwartz 
[unix3] ISBN 0-201-63357-4  Firewalls and Internet Security  1994 Cheswick / Bellovin 
[unix4] ISBN 0-13-149386-8  Panic! UNIX system crash dump analysis.  1995 Drake / Brown 
[unix5]   Solaris 2.5 Documentation: 
"System Administration Guide, Vol2" 		 1995 SunSoft
    Solaris 2.5 Documentation: 
"System Administration Guide, Vol1" 		 1995 SunSoft
  ISBN 0-13-151051-7  UNIX System Administration Handbook, 
Prentice Hall 		 1995 Nameth /Snyder.... 
  ISBN 1-56592-124-0  "Building Internet Firewalls", O'Reilly & Associates  1995 Chapman / 
Zwicky 
    Solaris 2.5 Documentation: 
"SunSHIELD BSM Guide" 		 1995 SunSoft
  SunWorld The Solaris Security FAQ (online)
SunWorld security columns		 1998
1995-9		 Peter Galvin
P.Galvin/Carole Fennelly

Assurance

For assurance choose an OS version which has been certified to ITSEC or TCSEC levels. See the "Operating System Overview" chapter. Most UNIX versions are available with C2. 

"C2" for SunOS

This package should allow a solaris1 machine to conform to C2 level security. Practical experience shows that it is difficult to administer, requires many patches, is complex, provides huge logs and even writes clear text passwords to these logs. It is recommended to upgrade to Solaris 2, rather than use this package. 

Principal dangers / problems

  • System and user accounts with no passwords, weak passwords or default passwords (e.g. IRIX and vendor installed systems).
  • Eavesdropping:
    • Access to (encrypted) passwords:^UNIX systems using NIS or not having shadow password files (BSD, SunOS, OSF/1, Ultrix, HP-UX V9...) are open to dictionary attacks[11].
    • Access to clear text passwords: many UNIX services transfer passwords in clear text (e.g. ftp, telnet). Network sniffers are a standard part of the attackers Toolkit. Many UNIX systems are shipped with network sniffers.
  • Buggy software:
    • The sendmail program is still continuing to produce new holes and dangers.
    • Vendors often concentrate more on innovation than correcting the problems in current software.
    • Buggy protocols: The principal communication protocols used by UNIX machines, TCP/IP have several security weakness which can be exploited.
  • Bad configuration: NFS and TFTP are often badly configured leaving machines completely open, often due to a lack of knowledge on the administrators behalf.
  • Complexity:
    • Few standard security tools exist which work on most dialects of UNIX. No tools cover all aspects.
    • UNIX System administration is complex and hence error prone.
    • Many manufacturers are protectionist , developing their own brand of UNIX to be something very different to other dialects (e.g. AIX). Support for POSIX interfaces alleviates this problem somewhat.
    • Source code for some variants of UNIX (e.g. BSD) is available to hackers. This increases the probability of attack on these systems, but also allows thorough verification of their security algorithms.
  • Cryptography:
    • The USA's export policy is crippling efforts to include advanced encryption mechanisms in UNIX.
    • No secured email system (e.g. PGP) is included as standard or supported by the mail clients. 

Accountability

Identification / authorisation

Introduction

Standard UNIX identifies users through user ids (UID), which are a number attributed to the user's login name. Users are authenticated by use of a password.

  • The login, xdm, telnet and ftp commands authenticate by asking the use for a username and password.
  • NIS (supported by most vendors) is based on the above principle, but identifies and authenticates users to a group (called a domain) of machines.
  • NIS+, a completely new revamped NIS, is based on Secure RPC (See the "Security Mechanisms" chapter), which also authenticates the machine used by a user and identifies a user by his net name, which is unique domain-wide. Strong (but not invincible) encryption methods are used (Diffie-Hellman public key encryption with 512 bit keys).
  • The "r" commands (rlogin, rsh, rcp) authenticate users based on their UID and the name of the originating machine. Access is granted without a password if the files .rhosts or hosts.equiv on the target machine are correspondingly configured.

Standard UNIX authentication methods (telnet, ftp, "r" commands, NIS) are easy to cheat on a network of UNIX machines, if a user has root access to his own workstation. 

UNIX accounts: General Guidelines

Most of the following guidelines are tested by utilities such as COPS, TAMU Tiger, ESM and SecureMax:

  • Implement a defined password policy (e.g. that in the chapter "Policy"). The (aging/choosing/changing) policy is enforceable with the following proactive mechanisms:

Solaris 2: /etc/default/passwd, /etc/shadow, commands nispasswd, passwd, admintool
Solaris 1: passwd, yppasswd
HP-UX:  In trusted mode, see /tcb/files/auth/..
AIX:       /etc/security/login.cfg
Other PD utilities, proactive: npasswd, passwd+. reactive: COPS, scripts to check for empty or bad passwords (with crack).

  • Consider using the restricted shell (/usr/lib/rsh) for users who require little access.
  • Users should be trained to check the "last login" time displayed when they login to a system.
  • Scan the system for accounts with UID 0 regularly.
    awk -F: '{if ($3=="0") print $1}' /etc/passwd
  • Scan the system for accounts with no password, use "logins -p" on Solaris, or:
    awk -F: '{if ($2=="") print $1}' /etc/passwd
  • Check regularly for easy to guess passwords (e.g. via "crack").
  • The files .login, .logout, .cshrc, .profile, .xinitrc should be correctly configured for each user. They should only be writeable by root or the owner. If possible use template versions when installing new users (Solaris 2: use /etc/skel).
  • Solaris 1: Restrict who can su to root by using the wheel group (TBD: possible on HP & AIX?).
  • Do not put "." (i.e current directory) in the root default path or the path of administrator accounts.
  • Set umask (the file creation permission mask) as restrictively as possible, especially for administrator accounts e.g. 077 (no group or world access) for sensitive accounts and 027 (group read, no world access) for normal users.

The following are not necessarily check by the tools mentioned above:

  • New accounts should not be created without a password.
  • When using su, use the absolute path - do not rely on the default path. i.e. use /bin/su
  • The user database should be regularly checked against personnel records.
  • Remind users to check the last login messages on login.
  • The system accounts (e.g. uucp, bin, adm, lp, listen, noaccess, audit, sys, ftp, nobody, daemon, news, sync) should have a "*" in the password field (Solaris 1) or "NP" in /etc/shadow (Solaris 2) and the shell should be set to /bin/false (except for uucp).
  • Solaris 1: Install shadow password files (e.g. via the Sun C2 software or John F.Haugh's substitute library for login,passwd which is public domain. To get this utility, search for shadow using archie). Neither have been tested by the author.
  • HP-UX : enable shadow passwords.
  • On some versions of Linux and AIX, the login program has a "-f" option that disables authentication, allow any user to become root with the command /bin/login -f root. If this works, then upgrade to a newer version. 

NIS

  • Use NIS+ rather than NIS if possible, it is very easy to get a password file from a NIS server. NIS also defeats password shadowing (if available) on the server.
  • Install the latest NIS patches (see the "Change/Release Management" section).
  • Use /var/yp/securenets to prevent domain spoofing. This requires a special version of ypserv. (This requires patch 100482 on Solaris 1). See also the ypx tool.
  • Check that there is a "*" in the password field of any entries beginning with "+" or "+@" in /etc/passwd. These entries allow NIS users or netgroups of users access to the machine. A line with only "+" allows all NIS users to access the machine. Similarly entries with -name or -@ disallow access to particular users or groups of users.
  • The "+" and "-" entries can also be used in /etc/group to allow/disallow NIS group recognition
  • The "+" and "-" entries can also be used in /etc/hosts.equiv, "+" means that all members of NIS groups are trusted, "+@group1" or -"@group1" means that all members of group1 are trusted /not trusted.
  • There is a major security hole[12] when rpc.ypupdated is used with keyserv. The only workaround (Nov.28 '95) is not to use rpc.ypupdated!
  • Use NIS only on a network which has a packet filter to less secure networks.
  • NIS slave masters should not use NIS for password information.
  • Solaris 2 clients: Bind using a list of servers, rather than broadcast. See ypinit -c.
  • Solaris 1 clients: specify the NIS server name in /etc/passwd, i.e. +server instead of +::-:0 [13]

NIS +

  • Solaris 2.x: Install the latest NIS+ Jumbo patch.
  • Use level 2 security.
  • Avoid NIS compatibility mode.
  • High Availability: Install replica servers, backup /var/nis at least daily on NIS+ master servers. A simple tar file may be created via a cron job (e.g. tar cf - /var/nis | compress > /opt/backup/nis.tar.Z).
  • Check table ownership's/permissions regularly (e.g. via nisls -l TABLE_NAME or niscat -o TABLE_NAME).
  • nisls -l
    org_dir.gdv023.vptt.ch.:
    T ----rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 16:59:50 1995 passwd
    T ----rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 16:59:51 1995 group
    T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 16:59:52 1995 auto_master
    T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 16:59:52 1995 auto_home
    T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 16:59:53 1995 bootparams
    T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 16:59:54 1995 cred
    T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 16:59:55 1995 ethers
    T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 16:59:56 1995 hosts
    T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 16:59:56 1995 mail_aliases
    T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 16:59:57 1995 sendmailvars
    T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 16:59:58 1995 netmasks
    T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 16:59:59 1995 netgroup
    T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 17:00:00 1995 networks
    T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 17:00:00 1995 protocols
    T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 17:00:01 1995 rpc
    T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 17:00:02 1995 services
    T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 17:00:03 1995 timezone

    Notes:

    1. The permissions column above lists (left to right) nobody (unauthenticated users), owner, group, world (all authenticated users) permissions.
    2. Unauthenticated users can read all tables except passwd and group. It is very important to protect these two tables.
    3. TBD: Is world read access to the passwd & group tables really necessary?
    4. The table auto_direct (for direct automounter maps) does not exist by default in Solaris2.x. It must be manually created (using nistbladm).
    5. All the tables above can be written by a group. The following shows what group is assigned to each table:
      nisls -lg
      org_dir.gdv023.vptt.ch.:
      T ----rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 16:59:50 1995 passwd
      T ----rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 16:59:51 1995 group
      T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 16:59:52 1995 auto_master
      T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 16:59:52 1995 auto_home
      T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 16:59:53 1995 bootparams
      T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 16:59:54 1995 cred
      T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 16:59:55 1995 ethers
      T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 16:59:56 1995 hosts
      T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 16:59:56 1995 mail_aliases
      T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 16:59:57 1995 sendmailvars
      T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 16:59:58 1995 netmasks
      T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 16:59:59 1995 netgroup
      T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 17:00:00 1995 networks
      T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 17:00:00 1995 protocols
      T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 17:00:01 1995 rpc
      T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 17:00:02 1995 services
      T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 17:00:03 1995 timezone
  • Assign members to the admin group carefully. Members of this group can change most NIS+ tables. Check group members via nisgrpadm -l admin.
  • Each table allows the same permission detail to be assigned per column. To examine the permissions on the columns in the password table, for example, try
  • niscat -o passwd.org_dir | egrep "Name|Access"
  • The permissions in certain Solaris 2.5 NIS+ installations are insecure (see CERT Advisory CA-96.10).
  • Normally with NIS+, all users can log into all machines in a NIS+ domain. This is not always desirable, for instance normal users should not be able to log on to a DNS server. This can be achieved by setting the passwd entry in /etc/nsswitch.conf to be:

passwd: compat
passwd_compat: nisplus
group: compat
group _compat: nisplus

Then each user to be allowed login access requires an entry in /etc/passwd and /etc/shadow of the form:

+fred:x:::::: /etc/passwd
+fred::::::: /etc/shadow 

Passwd replacements

Passwd+, npasswd, Obvious are public domain utilities which enhance the choice of passwords chosen by the user. Passwd+ and npasswd were evaluated by the author in 1994, but they had no NIS+ support at the time. Npasswd in particular seemed easy to extend and verify.

Consider one of the above programs to ensure that good passwords are used. 

DES encrypted scripts

Class  systems should not have root or administrator passwords in clear text scripts, even if the scripts are only readable by the owner. However such scripts are often necessary for database management (for example). One solution is to encrypt the entire script and decrypt it during encryption by using a modified shell which decrypts the script on-the-fly.

  • The utilities des, despasswd, descsh, deswrap and desscript are available for this purpose.
  • TBD: examples, where to find sources. 

DNS:  Domain Name Service

Most UNIX variants include both a DNS client (called a resolver) and DNS server. Vendor versions tend to be old and not without problems (e.g. cache corruption problems, domains that return large amounts of data, security etc.).

  • Use the latest BIND (Berkeley Internet Name Server) from ftp://ftp.isc.org/isc/bind or www.isc.org/view.cgi?/products/BIND/index.phtml .  Use 8.1.2 or later to avoid security problems (current version is 8.2.1 in July 1999)
    BIND has more features, is easier to debug (with dig) and is updated quickly when security problems are found.
  • Troubleshooting:
    • Use nslookup & dig to check server results.
    • Solaris:
      • Check /etc/nsswitch.conf  and /etc/resolv.conf if you're having DNS client side problems. Start nslookup with the "-d2" option to get buckets of debugging info.
      • Try killing the nscd daemon.
      • Use spaces and not tabs in Sun's old /etc/named.boot (bind uses named.conf).
      • See www.ebsinc.com/solaris/dns.html
    • Start named with the debug option "-d" and read the console & logs.
    • Typically logs are found in the syslog "daemon" section.
    • To get statistics from the name server, do the following
           kill -ABRT `cat /etc/named.pid`
      This puts the statistics into the file /usr/tmp/named.stats. (See 'DNS and BIND' book, from O'Reilly & Assoc. pages 142-149).
    • I've had problems with BIND dying, run a cron script like monitor_process.pl to check that it is alive.
    • Send a HUP signal to named, to reread the config file after changes.
          kill -HUP `cat /etc/named.pid`
  • Auditing/ testing:

Domain registration notes:

Audit trail

Monitoring system changes

One needs to know what the filesystem permissions and checksums should be, set these permissions, take snapshot & make these read-only. Regularly remake snapshot and compare with the original for changes. The system should automatically reset permissions.

  • Tripwire is a public domain utility that runs on many platforms. It contains several secure hashing algorithms for detecting file changes.
    • For example, use tripwire to take a snapshot on the system, check that the snapshot looks OK. Then copy the snapshot to read-only media (or to another machine and mount it read-only via NFS). Next run tripwire regularly (e.g. once per week or daily), to create a snapshot of the system and compare it with the read-only master.
    • Or, use configure SSH and .shosts so that remote commands can be safely executed on the target system. Each time the target has to be checked, copy the tripwire files and snapshot database to the target, run tripwire, upload the results and delete all traces of tripwire on the target. This makes it difficult for an attacker to known that the target is being monitored.
  • Solaris 2 is delivered with the ASET utility, allow scanning of the system for changes or weak configuration. The author prefers tripwire however.
  • The rdist utility can be used to distribute and synchronise files across machines. It will also report if files have changes and reset them back to their correct values, making it interesting from a security point of view. Of course rdist needs careful configuration to be used securely (e.g. use the public domain version 6.2 or later with SSH, not rsh).
  • Other commercial utilities such as Securemax (from OpenVision), ESM (from Raxco) have also proven their worth. They both have a GUI, making initial use easier. 

Auditing

Auditing is the monitoring of security related events, the writing of these events in an audit trail and the reporting and analysis of these audit events. Auditing should allow the actions of users to be monitored with a view to detecting abuse of the system. Auditing tools are different from system logging tools (which indicate system errors and help in solving system administration problems).

Sun Shield / BSM

Sun deliver a "C2" level auditing system for both SunOS (Sunshield) and Solaris (Sunshield BSM). It is bundled with Solaris 2. The Solaris 2.4 BSM is discussed here. 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).

  • Audit only an absolute minimum of user actions.
  • Don't bother auditing if you don't have a system expert capable of interpreting the logs!
  • If you switch on auditing, then write a script which analyses the audit trail in real time and raise alerts when necessary.
  • Analysis of the audit trail should take into account existing processes analysing syslog or other system 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 use actions on a high level.
  • Ensure that the audit trail is stored on a partition with enough space, consider centralising audit trails of several machines via secure NFS and auditreduce. 

Log Files

A system administrator who regularly checks logs will learn a lot about how the system functions, can guarantee less downtime and at the same time should notice when security breaches occur, especially if alerts are used. Monitoring logs should not be regarded as a boring job, but a chance to understand the guts of the system!

On UNIX systems, there are various sources of logging information, most of which are kept in the /var partition. These logs need to be monitored.

  • Syslog: is a centralised logging service used extensively on most UNIX systems (see next section). Syslog stores log data in /var/adm/messages or /var/adm/syslog or /var/log depending on configuration.
  • Process accounting (/var/adm/acct, pacct*): most UNIX systems provide accounting, but are normally switched off by default. Accounting degrades performance somewhat. See the accounting section below.
  • Audit trail: see the Auditing section above.
  • utmp and utmpx: A log of who is logged in is kept in utmp, normally to be found in /var/adm, /etc or /usr/adm. There is no utmpx in SunOS.
  • wtmp and wtmpx: A log of logins, logouts, reboots are kept in these files. They are also used for system accounting (in Solaris). These are automatically trimmed if accounting is switched on, otherwise a cron entry should be created to trim then just before the year end (if there's enough disk space). The wtrim.pl utility is perfect or this task. The last command is typically used to examine wtmp , but the commands finger, users, whodo, w and who also access these files for information. There is no wtmpx in SunOS.
    => Experienced attackers may have scripts which erase their trail in utmp or tmp, therefore, don't rely on them too much.
  • The binary file /var/adm/lastlog contains a log when a user last logged in and is displayed to the user on login.
  • The public domain utility wu-ftp logs to /var/adm/xferlog by default.
  • Service specific logs on Solaris:
    • A log of all users of the su command may be kept in /var/adm/sulog if SULOG is defined in /etc/default/su, but this is hardly necessary since all su attempts are also logged to Syslog (if SYSLOG=yes in /etc/default/su).
    • All attempts to use su are logged to the console if the CONSOLE option is set in /etc/default/su. Recommended.
    • A log of a failed login attempts is kept in /var/adm/loginlog if this file exists, belongs to root and is only writeable by root. Recommended.
    • PPP activity is logged to /var/adm/log/asppp.log, if PPP is installed.
    • All cron activity is logged to /var/cron/log if CRONLOG=Yes in /etc/default/cron. However cron logging via syslog is also possible and preferable since it allows centralisation of logs for several machines.
    • The volume manager (manages access to floppy & CD-ROM drives) logs activity in /var/adm/vold.log. Useful for problem diagnosis.
    • /var/adm/aculog: Records of modem activity (uucp and tip), not very useful.
    • uucp logs to /var/uucp/.log
    • /var/adm/passwd: TBD
    • /var/adm/sa/*: sar performance monitoring.
    • Printer logs are kept in /var/lp/logs/{lpNet,lpsched,requests}. These files are useful for problem diagnosis.
    • NIS+ writes it's transaction log to /var/nis/trans.log
    • The diagnostics tool sundiag logs to /var/adm/sundiaglog/sundiag.err.
    • BSM audit logs are stored in /etc/security/audit.
    • Accounting files are kept in /var/adm/acct.
  • Applications: many applications do not use Syslog, but create their own logs.
  • Firewall-1 logs to /var/opt/SUNWfw/log/fw.log
  • Sun NetManager logs to /var/opt/snm/event.log
  • The TIS firewall proxies, SSH and the tcp wrappers log to syslog (normally to the daemon facility).

General Recommendations:

  • Store logs in /var, not root or /etc or /usr. Create a (large) separate partition for /var, so that if it fills up, it should not cause major problems. Note that /var cannot be a softlink under Solaris 2.
  • Logs should be regularly pruned and archived. Many systems automatically prune and delete some of the logs, but rarely all the logs in a consistent manner. For example, each Sunday log files are to be moved, compressed and backed up. After 7 weeks the compressed log is deleted from disk. A simple but powerful public domain utility for this purpose is rotate_log. An example of cron entries for rotate_log is to be found in Appendix D.
  • Monitor the login log (via the last command) for logins at unusual times (e.g. during the night - see logins_today.pl in Appendix D).
  • In Appendix D, a script monitor_auth.pl is provided which monitors the syslog files alertlog, authlog and daemonlog for strange entries. 

Syslog

Syslog is a centralised logging utility used extensively on most UNIX systems providing 8 priorities and 18 facilities. The principal users of Syslog are the kernel, news, uucp, sendmail and login services. The logger utility can be used to send messages to syslog in scripts or to test Syslog. The Syslog daemon is called syslogd.

AIX: Although syslogd is supported on AIX, it is useless since no system utilities report their messages to it!

Security Bug (Jan 1996): The 8lgm security mailing list found serious problems with string handling in syslog. They were discovered in June 1995 and some vendors have yet to produce a corrective patch. This problem was currently being exploited in sendmail. HP has released patches, get the security bulletin HPSBUX9602-029 from the HP patch server (See section on patches "Change/Release management") as have Sun (Solaris 2.5 has this fix integrated).

On most UNIX systems Syslog offers some interesting possibilities:

  • Centralise server logs on a separate (more secure) machine, with no user logins.
  • Console messages of all servers can be displayed on the administrators console.
  • Error messages can be written to a file, emailed, written to the console or broadcast to all terminals.
  • Error messages are assigned priorities.
  • Configure /etc/syslog.conf to separate messages into services. An example syslog.conf which can be used on both syslogd clients and log console (on SunOS & Solaris) is provided in Appendix D. In this example, a separate log called authlog is created for authorisation messages. The changes in this log should be examined daily (see the example script monitor_auth.pl in Appendix D).
  • Debugging can be fun, have a look at the header in the above mentioned configuration file.
  • Enable inetd logging (add -t option to inetd command line in /etc/init.d/inetsvc on Solaris 2) if you have lots of space on the syslog server. The logging volume can be huge if naughty daemons like rpc.cmsd (calendar manager) misbehave!

Beware!

  • Syslog uses UDP, so delivery is not guaranteed, so consider keeping a local copy of high priority messages on class  machines.
  • Anyone can send entries to a syslog server, so beware of false entries! 

Process Accounting 

Accounting software is a set of tools that can be used to work out how much users should pay for system usage. It is interesting from a security perspective because it reports who is using the system and what commands are being used.

Solaris Accounting

Commands are in /usr/lib/acct, reports are in /var/adm/acct/fiscal/fiscrptMM (numbers) and /var/adm/acct/sum/rprtMMDD (user summary reports).

  • It is recommended to create "weekly" as opposed to "daily" reports. This will increase disk space required, but also increases the chances greatly that someone will actually read the reports!
  • Installation:

ln /etc/init.d/acct /etc/rc2.d/S22acct
ln /etc/init.d/acct /etc/rc0.d/K22acct
sh /etc/rc2.d/S22acct start

crontab -e adm
# Check /var/adm/pacct size:
0 * * * * /usr/lib/acct/ckpacct
# Create weekly report:
0 2 * * 0 /usr/lib/acct/runacct 2> /var/adm/acct/nite/fd2log
# Create monthly accounting summary:
0 7 1 * * /usr/lib/acct/monacct

crontab -e root
0 22 * * 4 /usr/lib/acct/dodisk

vi /etc/acct/holidays [set your local holidays]

Two principal reports are produced, the daily report showing command usage and the monthly report showing the system usage per user. The following is a typical extract from daily command summary:

TOTAL COMMAND SUMMARY
COMD. NUM. TOTAL TOTAL TOTAL MEAN MEAN HOG CHARS BLOCKS
NAME CMDS K-MIN CPU-MIN REAL-MIN SIZE-K CPU-MIN FACTOR TRNSFD READ
sh 1082 85.98 0.57 183.20 149.67 0.00 0.00 218296 14
lpstat 886 84.49 0.53 3.08 159.36 0.00 0.17 749192 1
uname 682 39.38 0.38 0.43 103.64 0.00 0.89 3964 4
hostname 194 14.49 0.15 0.30 96.82 0.00 0.49 98552 1
sed 209 14.01 0.17 0.38 84.82 0.00 0.43 407197 0
ssh 71 12.26 0.54 41.66 22.85 0.01 0.01 2539679 87
csh 99 12.10 0.48 1.51 25.15 0.00 0.32 744715 94
sendmail 46 10.30 0.15 0.65 67.25 0.00 0.24 10724864 297

TOTALS 4300 364.04 14.61 12068.92 24.91 0.00 0.00 1626266848 21308

A monthly report looks like:

2 date changes
28 system boot
2 run-level 6
2 run-level 3
1 runacct
1 acctcon

LOGIN CPU KCORE CONNECT DISK # OF # OF # DISK FEE
UID NAME PRIME NPRIME PRIME NPRIME PRIME NPRIME BLOCKS PROCS SESS SAMPLES
MINS
0 root 0 9 16 205 9 133 0 2453 79 0 0
4 adm 0 0 1 0 0 0 0 13 0 0 0
71 lp 0 0 0 1 0 0 0 24 0 0 0
200 ftp 0 0 0 0 3094 5040 0 0 6 0 0
315 boran 2 3 165 15 10298 25740 0 1810 24 0 0
TOTAL 2 12 182 221 13401 30913 0 4300 109 0 0

What would be nice is a report of what commands are being used by what users on a regular basis. This is not available in the standard reports, but the lastcomm command shows what commands were last executed by a particular user since the last accounting update (e.g. weekly or daily). Lastcomm can be used by the Administrator to monitor a user's activities, but also by an attacker to monitor the administrators activities (since any user can execute lastcomm). Therefore:

  • Make accounting files available only to root, to prevent an attacker (not yet root) being able to use them to monitor root:
    chmod og-rwx /var/adm/pacct*
  • Only allow administrators access to accounting reports and files:
    chmod -R o-rwx /var/adm/acct
  • The commands can be examined by user, or by process name, or by terminal .e.g.:
    lastcomm billyjoe
    lastcomm netscape
    lastcomm pts/27 

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

Receive all the latest articles by email!

Get all articles delivered directly to your mailbox as and when they are released on WindowSecurity.com! Choose between receiving instant updates with the Real-Time Article Update, or a monthly summary with the Monthly Article Update.



Receive all the latest articles by email!

Receive Real-Time & Monthly WindowSecurity.com article updates in your mailbox. Enter your email below!
Click for Real-Time sample & Monthly sample

Become a WindowSecurity.com member!

Discuss your security issues with thousands of other network security experts. Click here to join!

Community Area

Log in | Register

Solution Center

Readers' Choice

Which is your preferred network auditing solution?