• To Audit or Not to Audit . . .
• Windows NT Auditing
• Windows 2000 Auditing
• Windows XP Auditing
• Windows Server 2003 Auditing
• UNIX and Linux Auditing
• Mac OSX Logging
• Additional Suggestions
• Conclusion
  

  << Back to Desktop Security

  _____________

Have you enabled auditing on your system? If your system is Windows 95, 98, or ME or a Macintosh prior to MacOS 10.X, there is no reason to read any further; these systems have no auditing capabilities. But if your system runs Unix, Linux, Windows NT, Windows 2000, you need to read further.

To Audit or Not to Audit . . .

Suppose that something goes wrong with your system. What happened? In almost every case you won't be able to find out unless you have audit data to examine. Having audit data is particularly important if you suspect that someone or something has attacked your system in some manner. You may be able to determine the network address of the system that was used to launch an attack, what time the incident occurred, the type of attack, whether or not the attack was successful, and possibly even who the attacker is.

Is there any reason to leave auditing disabled? Possibly, but not normally. Some users fail to turn on auditing because they fear that their system's performance will suffer. If you have an older hardware platform, this may be true, but most modern computer hardware has more than enough memory, a fast processor, and other things that preclude the possibility of performance impairment.

This posting explains how to enable and configure auditing in Windows NT, Windows 2000, UNIX, and Linux, systems.

Windows NT Auditing

Windows NT auditing is disabled by default—not at all a good thing for security! To enable auditing in any Windows NT system, go from Start to Programs to Administrative Tools to User Manager or User Manager for Domains (depending on the type of Windows NT system you have). Pull down the selections in the Policies menu bar at the top to Auditing. Click on Audit These Events, then to the particular categories of events you want to audit. These categories include:

• Logon and Logoff
• File and Object Access (access to files, directories, Registry keys, and other objects that you choose to audit)
• Use of User Rights (e.g., changing the system time, making a backup)
• User and Group Management (e.g., creating new accounts and/or groups, changing group membership, and so on)
• Security Policy Changes (e.g., changes to the audit policy or trust relationships between domains)
• Restart, Shutdown and System (e.g., certain system-related events)
• Process Tracking (e.g., user attempts to start and stop programs)

The number of categories you need to enable depends on the level of security you need. On most workstations enabling only Logon and Logoff is sufficient. On a critical server (e.g., one used to run critical scientific applications) enabling several categories such as Logon and Logoff, Use of User Rights, User and Group Management, and Security Policy Changes might be appropriate.

Note that for each category you can choose Success (e.g., to record successful attempts) or Failure or both. Think this through carefully. If you enable only Success for a particular category such as Logon and Logoff, auditing will miss unsuccessful logon attempts. It is best, therefore, to enable both Success and Failure for each category you select.

Next, you need to set a few audit log parameters. Go from Start to Run, then enter eventvwr (or, alternatively, go from Start to Programs to Administrative Tools to Event Viewer) and click on OK. Pull down the Log menu bar to Properties. Ensure that the log name is Security Log if this is not the name of the log that is visible. (Just use the pulldown menu immediately under the name of the log that is displayed.) Increase the log size to something like 5000K or more and then choose Overwrite Events as Needed so that no audit data get overwritten unless the log file fills up.

Be sure to not only enable the appropriate amount of auditing for your needs, but also to regularly look at the audit data. Bringing up the Run menu (by going from Start to Run), then typing in eventvwr, then clicking on OK produces a display of one of the Event Logs (System Log, Security Log, or Application Log). Go to the Log menu bar and pull down the name of the log you want to view. Of the three types of logs, however, only the Security (Audit) Log will have security-related data such as the account name and time of unsuccessful logons, new accounts that have been created, additions to groups (watch the Administrators and Domain Administrators groups most closely!), access to files and/or directories, etc. The particular data that will be available will depend on the way you have configured Security Logging.

Windows 2000 Auditing

Windows 2000 auditing is similar but not identical to Windows NT auditing. Again, as in Windows NT, Windows 2000 auditing is disabled by default. To enable auditing go to Administrative Tools (either via Programs or the Control Panel, depending on the particular version of Windows 2000), then to Local Security Policy, then to Security Settings, Local Policies, Audit Policy. Click on the Audit Policy container; nine audit categories will be displayed on the right side of the screen:

• Audit account logon events (for tracking logon/logoff attempts against accounts)
• Audit account management (equivalent to User and Group Management in WNT)
• Audit directory service access (for recording attempts to access W2K's Active Directory objects)
• Audit logon events (for tracking non-account-related logon/logoff attempts)
• Audit object access (equivalent to File and Object Access in WNT)
• Audit policy change (for recording changes in the Audit Policy)
• Audit privilege use (equivalent to User of User Rights in WNT)
• Audit process tracking (equivalent to Process Tracking in WNT)
• Audit system events (equivalent to Restart, Shutdown, and System in WNT)

Instead of enabling or disabling auditing (as in Windows NT), you must enable the particular audit categories you desire. So, for example, if you want to audit account logon events, highlight this category, then pull down from Action to Security. A dialog box that will allow you to enable this category will appear. Be sure to also choose the appropriate Success and Failure options for each category you select. In general, it is best to choose both Success and Failure for each selected category so that you will obtain data about both successful and unsuccessful attempts to do things.

As in Windows NT, you must also configure audit parameters. Enter eventvwr in the Run Menu (or go to Administrative Tools to Event Viewer). Highlight the Security Log, then right click to Properties. Set the size of the Security Log to 5000K or so and click on Overwrite Events as Needed. To view the Security Log (ideally, daily) double click on the icon for the log.

Windows XP Auditing

To enable a baseline of logging in Windows XP psystems, go to the Control Panel, Administrative Tools, Local Security Policy, Security Settings, Local Policies, and then to Audit Policy. Double-click on the Audit Policy container to view the audit options. To enable any type of auditing, double-click on the name and in the sheet that will appear (under Audit these Attempts) click on both Success and Failure. Enable:

• "Audit Account Logon Events” (success and failure)
• "Account Management” (success and failure)
• "Audit Logon Events” (success and failure)
• "Audit Policy Change” (success and failure)
• "System Events” (success and failure)

Set the Security Log properties so that security logging will run properly. Go to the Control Panel, Administrative Tools, Local Security Policy, Security Settings, Local Policies and then to Event Viewer. Right-click on Security Log and go to Properties.

Select the following settings:

Maximum Size-set the maximum size of the System and Application Logs to 4,096K and the maximum size of the Security Log to 10,240K. The default of 512K for each log is much too small.

Retention Method (you have three choices):

1. Overwrite events as needed: The oldest events will be overwritten independently of any time requirements (best).
2. Overwrite events by days: Event data that are older than the retention period are overwritten; if the log fills before the retention period expires, there will be a gap in logging.
3. Do not overwrite events (clear log manually): In general, do not choose this option, because your system's Event Logger will stop if you have forgotten to manually purge your Security Log, and it fills up.

Check your system's logs regularly (daily, if possible) to determine whether your system has been attacked.

Windows Server 2003 Auditing

In Windows Server 2003 you should enable the following Audit Policy settings:

• "Audit account logon events" (success and failure)
• "Audit account management (success and failure)
• "Audit directory service access" (but only if host is a domain controller) (success and failure)
• "Audit logon events" (success and failure)
• "Audit policy change" (success and failure)
• "Audit privilege use" (success and failure)

To set these parameters in member servers, go from Start -> Administrative Tools -> Local Security Policy -> Security Settings -> Local Policies -> Audit Policy.

To check this in DCs, go from Start -> Administrative Tools -> Domain Security Policy -> Security Settings -> Local Policies -> Audit Policy.

Enable the following Event Log settings for the security log:

• Maximum security log size - 16384 kilobytes
• Prevent local guests group from accessing security log - Enabled
• Retain security log - Not defined
• Retention method for security log - Overwrite events as needed

To set these parameters in member servers, go from Start -> Administrative Tools -> Local Security Policy -> Security Settings -> Event Log.

To check this in domain controllers, go from Start -> Administrative Tools -> Domain Security Policy -> Security Settings -> Event Log.

Check your system's logs regularly (daily, if possible) to determine whether your system has been attacked.

UNIX and Linux Auditing

Chances are, quite a bit of auditing is already enabled by default on your UNIX or Linux system. Major types of logging include utmp, wtmp, acct or pact, and ps. The commands you can use to access audit data, the files in which audit data are stored, and the contents of these files are listed immediately below.

You can test whether a particular type of logging is enabled by entering the appropriate command that causes log data to be displayed. For example, if you enter who, you should obtain the following kind of output if utmp and wtmp are enabled:

If logging has been disabled or never enabled, the way you must enable logging depends on the particular flavor of UNIX or Linux. For example, in Solaris 8 to enable utmp, ensure that the file S88utmpd is in the /etc/rc2.d directory.

Another important logging capability is syslog, which allows the system administrator to log system messages into various files. You'll need to configure syslog in /etc/syslog.conf. You'll need to define logging priorities: emerg (highest), alert, crit, err, warning, notice, info, or debug (lowest), as well as the types of loggable messages: kernel, users, mail, daemon, auth, lpr, local. auth means authorization, and is thus the most important type as far as security goes. It records events such as bad login attempts (which are recorded in /var/adm/messages, /var/logs/messages, or another path, depending on the particular flavor of UNIX and Linux) and the user's last login date (which is recorded in loginlog, the path of which will again vary).

One of the best features of syslog is that you can send syslog data just about anywhere you want. Reading through syslog output on each individual system is potentially confusing and overwhelming. Sending syslog to a single host makes it possible to view all output by accessing that host.

Below is a sample /etc/syslog.conf file. Note in the second line that all error events, any kernel events with debug priority, and any auth events with notice priority are sent to the console, but in the third line we see that any events with info level priority are sent to /var/adm/messages.

Mac OSX Logging

Syslog is the system logging, a very flexible type of logging that can record a wide range of events, such as bad login and su attempts, debugging errors, and so on. To configure system logging, add the following lines to /etc/syslog.conf:

kern.* /var/log/kernel
*.warn;*.err /var/log/syslog
*.err @<loghost_address>
authpriv.*;auth.* @<loghost_address>

Create /var/log/syslog and /var/log/kernel if they do not already exist, and set the permissions for both to 600.

Your system will need the appropriate files to send syslog data; you need to create these files and to protect them with appropriate permissions. To create these files, enter:

# touch /var/log/syslog /var/log/kernel

To set the appropriate permissions, enter:

# chmod 600 /var/log/syslog /var/log/kernel

Make syslog read the new configuration file.

Enter:

# /etc/rc.d/init.d/syslog restart

Additional Suggestions

• Some flavors of UNIX, FreeBSD in particular, also by default send critical system and security data to root. The necessary entries to do this are in crontab.
• Rotate logs on a systematic basis. Make sure that you retain log data long enough to have the luxury of viewing them before they are purged or overwritten.
• Supplement system logging with logging by logdaemon or the TCP wrapper tool (see http://cerias.purdue.edu/tools).
• Set extra protections on log files (if available). Attackers love to delete or modify these files. FreeBSD and Linux provide support flags that can make files appendable, but nothing more. This provides an excellent way to protect your system's log files.

Conclusion

This posting has explained how to enable and access audit data in systems that are widely used throughout LBNL—Windows NT, Windows 2000, UNIX, and Linux. Even if you have carefully configured and patched your system, if auditing is not enabled, your system is not really secure. Send questions to eeschultz@lbl.gov.