Securing UNIX: Part 1/2

General

Documentation

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 SunOS4

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 crippled efforts to include advanced encryption mechanisms in UNIX for many years. Now that it has opened up (Sep.2000) new opportunities exist. OpenBSD 2.9 for example include lots of strong crypto tools in the default install.
• 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, ftp, SSH commands authenticate by asking the user for a username and password.
• SSH can also use RSA keys to authenticate users.
• 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).
• Add trusted hosts and networks to /var/yp/securenets to prevent domain spoofing. This requires a special version of ypserv. (Patch 100482 on Solaris 1). See also the ypx tool.
• There is a key used in the making of the DBM files called YP_SECURE, that ensures that NIS servers only answer questions from a client on privileged ports.
• 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.
• Don't put the root account in NIS.
• 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 +

• Note: Years after writing this section, I came across the NIS+ FAQ, which seems like a useful resource to check for any NIS+ sysadmin.
• 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:
  tar cf - /var/nis | compress > /opt/backup/nis.tar.Z
  
• Check table ownership's/permissions regularly, for example: 
  nisls -l TABLE_NAME or niscat -o TABLE_NAME
  
• nisls -l
  org_dir.server1.mydom.ch.:
  T ----rmcdrmcdr--- server1.server1.mydom.ch. Thu Feb 23 16:59:50 1995 passwd
  T ----rmcdrmcdr--- server1.server1.mydom.ch. Thu Feb 23 16:59:51 1995 group
  T r---rmcdrmcdr--- server1.server1.mydom.ch. Thu Feb 23 16:59:52 1995 auto_master
  T r---rmcdrmcdr--- server1.server1.mydom.ch. Thu Feb 23 16:59:52 1995 auto_home
  T r---rmcdrmcdr--- server1.server1.mydom.ch. Thu Feb 23 16:59:53 1995 bootparams
  T r---rmcdrmcdr--- server1.server1.mydom.ch. Thu Feb 23 16:59:54 1995 cred
  T r---rmcdrmcdr--- server1.server1.mydom.ch. Thu Feb 23 16:59:55 1995 ethers
  T r---rmcdrmcdr--- server1.server1.mydom.ch. Thu Feb 23 16:59:56 1995 hosts
  T r---rmcdrmcdr--- server1.server1.mydom.ch. Thu Feb 23 16:59:56 1995 mail_aliases
  T r---rmcdrmcdr--- server1.server1.mydom.ch. Thu Feb 23 16:59:57 1995 sendmailvars
  T r---rmcdrmcdr--- server1.server1.mydom.ch. Thu Feb 23 16:59:58 1995 netmasks
  T r---rmcdrmcdr--- server1.server1.mydom.ch. Thu Feb 23 16:59:59 1995 netgroup
  T r---rmcdrmcdr--- server1.server1.mydom.ch. Thu Feb 23 17:00:00 1995 networks
  T r---rmcdrmcdr--- server1.server1.mydom.ch. Thu Feb 23 17:00:00 1995 protocols
  T r---rmcdrmcdr--- server1.server1.mydom.ch. Thu Feb 23 17:00:01 1995 rpc
  T r---rmcdrmcdr--- server1.server1.mydom.ch. Thu Feb 23 17:00:02 1995 services
  T r---rmcdrmcdr--- server1.server1.mydom.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. Investigate: 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.server1.mydom.ch.:
     T ----rmcdrmcdr--- admin.server1.mydom.ch. Thu Feb 23 16:59:50 1995 passwd
     T ----rmcdrmcdr--- admin.server1.mydom.ch. Thu Feb 23 16:59:51 1995 group
     T r---rmcdrmcdr--- admin.server1.mydom.ch. Thu Feb 23 16:59:52 1995 auto_master
     T r---rmcdrmcdr--- admin.server1.mydom.ch. Thu Feb 23 16:59:52 1995 auto_home
     T r---rmcdrmcdr--- admin.server1.mydom.ch. Thu Feb 23 16:59:53 1995 bootparams
     T r---rmcdrmcdr--- admin.server1.mydom.ch. Thu Feb 23 16:59:54 1995 cred
     T r---rmcdrmcdr--- admin.server1.mydom.ch. Thu Feb 23 16:59:55 1995 ethers
     T r---rmcdrmcdr--- admin.server1.mydom.ch. Thu Feb 23 16:59:56 1995 hosts
     T r---rmcdrmcdr--- admin.server1.mydom.ch. Thu Feb 23 16:59:56 1995 mail_aliases
     T r---rmcdrmcdr--- admin.server1.mydom.ch. Thu Feb 23 16:59:57 1995 sendmailvars
     T r---rmcdrmcdr--- admin.server1.mydom.ch. Thu Feb 23 16:59:58 1995 netmasks
     T r---rmcdrmcdr--- admin.server1.mydom.ch. Thu Feb 23 16:59:59 1995 netgroup
     T r---rmcdrmcdr--- admin.server1.mydom.ch. Thu Feb 23 17:00:00 1995 networks
     T r---rmcdrmcdr--- admin.server1.mydom.ch. Thu Feb 23 17:00:00 1995 protocols
     T r---rmcdrmcdr--- admin.server1.mydom.ch. Thu Feb 23 17:00:01 1995 rpc
     T r---rmcdrmcdr--- admin.server1.mydom.ch. Thu Feb 23 17:00:02 1995 services
     T r---rmcdrmcdr--- admin.server1.mydom.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.

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.isc.org/isc/bind/ or www.isc.org/view.cgi?/products/BIND/index.phtml .  BIND has more features (than UNIX vendor vensions), is easier to debug (with dig) and is updated quickly when security problems are found.
• See also Hardening the BIND DNS Server (sp/bind_hardening.html)
• 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_processes.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:
  • A great tool for testing active domains is www.uniplus.ch/direct/testtool/dnstest.html
  • Checking Swiss WHOIS entries for sample domain swisscom.ch:
      www.switch.ch/cgi-bin/info/whois?Query=sun.ch&Server=whois.nic.ch

Domain registration notes:

• The .CH domains are created modified via the Web, see www.nic.ch/cgi-bin/preprocessor/register   . It will take ~2weeks.
• .com domains are different:
  • You need to register contact "handles" e.g. SB10345 might point to Sean Boran. To change handles, see: http://rs.internic.net/cgi-bin/itts/handle   These can also be changed by downloading, completing & emailing a template (my preference). See: http://rs.internic.net/help/templates.html   
  • Host names/IP of primary and secondary DNS servers must be registered and be correct. These are changed by downloading, completing & emailing a template. See: rs.internic.net/help/templates.html  
  • Finally domains can be modified and user/host handles changed at: rs.internic.net/cgi-bin/domain   These can also be changed by downloading, completing & emailing a template (my preference). See: http://rs.internic.net/help/templates.html  

  Note that .COM changes are in fact very fast and easy, once you get the hang of it. Changes are often completed in 24 or 48 hours.

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. 

See also Solaris C2/BSM security notes (sp/Solaris_bsm.html).

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

            Previous   Next   Top   Detailed TOC  IT Security Cookbook, 14 août, 2002