18.3 Security-related auditing

The auditing system of an operating system keeps track of all activities that occur on a computer system. It gathers not only security-related information, but also application- and system service-related information.

18.3.1 The Event Viewer and the Event Logs

When discussing auditing in Windows Server 2003, we must address two topics: Event Logs and the Event Viewer. Windows Server 2003 gathers all events in Event Log files. By default, these files (*.evt) are located in the <%systemdirectory%>\config\ subdirectory. The default log files are named Appevent.evt, Secevent.evt, Sysevent.evt, ntds.evt, dnsevent.evt, and ntfrs.evt. The Event Logs are governed and fed by a system’s Local Security Authority (LSA); see Chapter 2 for information on the LSA.

The Event Viewer is Windows’ primary Event Log viewer. The Event Viewer also allows you to filter the Event Logs and display only certain categories of events. For every Event Log entry, the Event Viewer shows an event description, the account that caused the event, the event type (warning, error, or information), the event ID, the source of the event (originating service), and the date and time of the event. From a troubleshooting point of view, the event description and the event ID are the most important fields. The event ID allows you to uniquely identify the event so you can, for example, look up its meaning in the Microsoft Knowledge Base. Earlier chapters of this book contain examples of event IDs related to specific security processes. For example, for logon-related event IDs, see Chapter 4.

You may have some difficulty locating the Event Viewer in the Windows 2000, Windows XP, and Windows Server 2003 interface. It is now integrated with the Computer Management MMC snap-in. You can also view it from the Event Viewer MMC snap-in. As in NT4, you can launch the event viewer from the command prompt by typing eventvwr.

Compared to its NT4 predecessor, the Event Viewer has been extended: It includes a set of new folders to gather auditing information related to OS core services such as the Directory Service, the DNS Service, and the File Replication Service. Also, the description portion of the events has been extended, facilitating troubleshooting. Some events even include an HTTP pointer to the Microsoft online support site. Last but not least, the event logs can now also be accessed using a WMI (Windows Management Instrumentation) management interface.

Like NT4, the Event Viewer includes an application (to log application- specific information), security (to log security events), and system log (to log system-related events). The application log entries are fixed and set by the application developer. The system log entries are fixed as well and set by the OS. By default, no security entries are logged. The security entries that are logged can be configured by an administrator, as is explained in the next section. An important exception to this in Windows Server 2003 is domain controllers: They now have security auditing enabled by default for successful account logon and logon events.

The Windows Server 2003 Event Log files have, like their NT4 and Windows 2000 predecessors, a limited size. In Windows Server 2003, the default log file size has been increased to 32 Mb; In earlier Windows versions (including Windows 2000 and Windows XP), this was 512 Kb. The maximum log size has been increased to 4 Gb. The size of a log file can be set per individual event viewer container, as illustrated in Figure 18.15 for the Security event log container. Because all event logs are permanently kept open in system memory, the practical maximum log file size limit is around 300 Mb.

Figure 18.15: Security event log properties.

To cope with this limited size, different retention policies can be set per individual container:

• Overwrite events as needed: When this option is set, the oldest events will automatically be overwritten with newer events when the log file fills up. Keeping in mind the above practical log file size limit (300 Mb each), “overwrite events as needed” is the recommended retention policy. This is not true for systems that have the crashonauditfail security policy option enabled (this option is explained below).

• Overwrite events older than X days: When this option is set, only events older than X days will be overwritten. If all events older than X days are overwritten, no more events are logged. Logging will start again from the moment some older events expire (or reach the X days limit).

• Do not overwrite events: When this option is set, no events are over- written. When the log is full, logging stops. Logging can only be started again by manually clearing the logs.

A critical event log file is the security log. To read and clear the security logs of a Windows system of a Windows system, a user must have the “Manage auditing and security log” user right (SeSecurityPrivilege). By default, this privilege is given only to members of the Administrator group. To write to the security log, you must have the “Generate security audits” user right (SeAuditPrivilege). In addition to using these two user rights, you can also modify the access control permissions on the security event log file (secevent.evt) to better protect against unauthorized access to the security event log.

Both the Security Configuration and Analysis (SCA) tool and the security portion of the Windows Server 2003 GPOs include important event logging-related configuration settings. The settings are listed in Table18.10, together with their corresponding registry entry. The first four settings can be set for the application, security, and system log and are set from the Event Log container in the Security Settings. The last three can be set from the Security Options in the Security Settings’ Local Policies container. Table 18.11 lists the recommended values for these settings for Windows Server 2003 Domain Controllers and Member Servers.

Table 18.10: Event Logging-Related Registry Hacks

Setting	Registry Entry:
	HKLM\System\CurrentControlSet\Services\Eventlog\<log name>\
Maximum log size	MaxSize (REG_DWORD)
Restrict local guests group from accessing log	RestrictGuestAccess (REG_DWORD)
Retain log	Retention (REG_DWORD)
Retention method for log	Retention (REG_DWORD)
	HKLM\System\CurrentControlSet\Control\LSA\
Audit: Audit the access of global system objects	Auditbaseobjects (REG_DWORD)
Audit: Audit the use of Backup and Restore privilege	Fullprivilegeauditing (REG_BINARY)
Audit: Shut down system immediately if unable to log security audits	CrashOnAuditFail (REG_DWORD):

Table 18.11: Event Logging-Related Registry Hacks Recommended Settings

Setting	Recommendation for Domain Controllers	Recommendation for Member Servers
Maximum log size	32 Mb for System, Application, and Security logs; make sure that no log data are lost by backing up the log files at regular intervals	16,384 Kb for System, Application, and Security logs; make sure that no log data are lost by backing up the log files at regular intervals
Restrict local guests group from accessing log	Enabled for System, Application, and Security logs	Enabled for System, Application, and Security logs
Retain log (Retention method for log)	Overwrite as needed for System, Application and Security logs.	Overwrite as needed for System, Application and Security logs.
Audit: Audit the access of global system objects	Disabled	Disabled
Audit: Audit the use of Backup and Restore privilege	Enabled	Disabled
Audit: Shut down system immediately if unable to log security audits	Depends on importance of AD data	Disabled

RestrictGuestAccess and CrashOnAuditFail are two critical parameters from a security point of view. RestrictGuestAccess prohibits members of the Guests group to view the information in one of the event log containers.

CrashOnAuditFail prevents that unauthorized actions can occur when they cannot be logged in the security log. When it is enabled, Windows will crash the computer if it is unable to write an event to the event logs. The system crash occurs as a blue screen that contains a STOP error code and displays {Audit Failed} along with a description of why the audit failed. When the computer crashes, the CrashOnAuditFail value is automatically changed from 1 to 2 and the type of CrashOnAuditFail registry entry is changed from REG_DWORD to REG_NONE. After a CrashOnAudit- Fail-initiated crash, only a local administrator or a member of the Domain Admins group can log in. Before other users are allowed to log back in, the CrashOnAuditFail registry value must be deleted and readded to the system registry as a REG_DWORD with a value of either 0 or 1.

18.3.2 Setting up security-related auditing

The security auditing system in Windows Server 2003 is very closely related to the access control system. Like access control settings, auditing settings can be set on individual objects and are stored in an object’s security descriptor. Each time an object is accessed, its auditing settings are checked to see whether this type of access needs to be audited. Next we will focus on how to set up security-related auditing in Windows Server 2003.

To set up security event logging, you must define a security audit policy and set auditing properties for several event categories on the object level. Once set up, Windows will log the security-related events to the security container of the Event Viewer. To look at the content of this container, you must be a local administrator on the system.

A Windows Server 2003 audit policy defines which categories of audit events will be recorded in a computer’s local security log. It is defined through Group Policy Object settings on the domain, site, or OU level. You can find the audit policy in the GPO computer configuration, underneath Windows Settings\Security Settings\Local Policies\Audit Policy. You can also set the audit policy locally using the Local Security Policy configuration tool.

Table 18.12 shows the event categories that can be logged. For all categories, you can set auditing for both successful and failed attempts. Table 18.13 shows the recommended audit settings for Windows Server 2003 domain controllers and member servers.

Table 18.12: Audit Policy Categories

Audit Policy Category	Meaning
Audit Account Logon Events	Monitors logon attempts against a Windows security database (SAM or AD).
Audit Account Management	Monitors creation, deletion, and modification of security principals (user, computer, and group accounts).
Audit Directory Service Access	Monitors administrative access to AD objects in the configuration and schema naming contexts. The domain naming context is covered by the “Audit Account Management” category.
Audit Logon Events	Logs events at the machine where the authentication takes place. During an interactive logon this is at the local computer. During a network login, this is at the machine where the resource is located.
Audit Object Access	Monitors access to all objects that have a system ACL (SACL).
Audit Policy Change	Logs events for audit policy changes.
Audit Privilege Use	Logs events when a security principal exercises a user right.
Audit Process Tracking	Logs events for attempts to create and end processes.
Audit System Events	Logs events for changes to the computer’s operating environment. This includes changing the system time, clearing the security event log, and shutting down the computer.

Table 18.13: Recommended Audit Policy for Domain Controllers and Members Servers

Audit Policy Category	Domain Controller Configuration	Member Server Configuration
Audit Account Logon Events	Success, Failure	Success, Failure
Audit Account Management	Success, Failure	Success, Failure
Audit Directory Service Access	Failure	Failure
Audit Logon Events	Success, Failure	Success, Failure
Audit Object Access	Success, Failure	Success, Failure
Audit Policy Change	Success, Failure	Success, Failure
Audit Privilege Use	Failure	Not enabled
Audit Process Tracking	Not enabled	Not enabled
Audit System Events	Success, Failure	Success, Failure

To set up auditing on the object level, right-click the object and select properties; then open up the Security tab, click Advanced, and select the Auditing tab. You will see that you can set up auditing based on the account or group performing an action and the type of action being performed (as illustrated in Figure 18.16). As with authorization, Microsoft included some important object auditing changes in Windows 2000 and Windows Server 2003:

• Windows 2000 and Windows Server 2003 permit a much finer granularity for object and property auditing than NT4. Just as with access control, auditing settings can be defined based on object types and object properties.

  
  Figure 18.16: The eventcombmt tool.

• Windows 2000 and Windows Server 2003 include the capability to define auditing setting inheritance between parent and child objects.

• The object auditing administration interface has been extended to reflect the changes mentioned previously and is integrated with the new ACL editor.

18.3.3 Event log–related tools

To archive the log file content, you can rely on your standard backup utility. To make sure that no log entries are lost, you must align the log settings described earlier with the archival procedure. To dump the content of the event log, you can use command-line tools such as Microsoft’s dumpel.exe or Systinternals’ psloglist.exe. The first one can be downloaded from the MS Downloads Web site. The second one is available from the Sysinternals Web site. The following dumpel command will dump all events in the security log on a server named Myserver to a file named security.xls:

dumpel -f security.xls -s myserver -l security

Dumpel can also filter out certain event types when it dumps the event log content. For example, to filter out event ID 528 in the above example, type:

dumpel -f security.xls -s myserver -l security -e 528

A great resource kit tool to query the local and remote event logs is the eventcombmt.exe (illustrated in Figure 18.17) Resource Kit utility. It allows an administrator to look for occurrences of a single event ID, multiple event IDs, a range of event IDs, specific event types or sources, or a specific event message text. The eventcombmt tool drops the results of its query in the eventcombmt.txt file in a system’s temporary folder.

Figure 18.17: Setting up auditing.

A brand-new tool is the Microsoft Audit Collection System (MACS), which provides a security log collection service. MACS facilitates role separation between Windows system administrators and IT system auditors. Before MACS, Microsoft customers had to turn to products like Sentry or Microsoft MOM to provide this kind of functionality. MACS is made up of a client (the MACS agent) and a server component (the MACS collector). The MACS server stores the security log data in a SQL Server or MSDE database. Transport of the log data happens in a secure way. MACS agents locate the MACS collector using a DNS SRV record (named _adtserver). Here MACS agents can authenticate to the MACS collector using Kerberos or SSL (in non-domain environments). MACS provides an API that can be used by application developers to build host-based intrusion detection systems (IDSs). MACS is an add-on service to Windows Server 2003. The first release of the service will be made available as a free Web download; later releases may be integrated with the Microsoft Operations Manager (MOM). At the time of writing, MACS was planned to run on Windows 2000, Windows XP, and Windows Server 2003.