Event Log

The event logs record events that happen on the computer. Examining the events in these logs can help you trace activity, respond to events, and keep your systems secure. Configuring these logs properly can help you manage the logs more efficiently and use the information they provide more effectively.

Windows Vista® has a new event system that saves event log files into XML files that can be reported on and managed as part of a collective reporting schema. There are several additional log providers and categories that you can monitor.

Event Viewer in Windows Vista tracks information in a number of logs, including:

• Application. Events in this log are classified as error, warning, or information, depending on the severity of the event. An error is a significant problem, such as loss of data. A warning is an event that is not necessarily significant, but might indicate a possible future problem. An information event describes the successful operation of a program, driver, or service.
• Security. This log contains security-related events, which are called audit events, and are described as successful or failed, depending on the event, such as whether a user's attempt to log on to Windows® was successful.
• Setup. Computers that are configured as domain controllers will have additional logs displayed here.
• System. System events are sent to this log by Windows and Windows system services, and are classified as error, warning, or information.
• Forwarded Events. Events are forwarded to this log by other computers.

Each of these logs each have attributes, such as maximum log size, access rights for each log, and retention settings and methods, that can be defined in the Event Log section in Group Policy.

Event Log Settings

You can configure the event log settings in the following location within the Group Policy Management Console:

Computer Configuration\Windows Settings\Security Settings\Event Log\

The following sections describe the options and issues for configuring event log settings for better system management and security.

Maximum event log size

This policy setting specifies the maximum sizes of the Application, Security, and System logs. Although the user interfaces (UIs) of both the Group Policy Object Editor and Event Viewer allow you to enter values as large as 4 gigabytes (GB), the effective maximum size for these logs is much smaller in the 32-bit version of Windows Server 2003. If you are using the 64-bit version of Windows Server 2003, you can use the 4-GB maximum value. However, larger log file sizes can affect system performance.

The Event Log service uses memory-mapped files, and it runs as one of the services under the Services.exe process as Eventlog.dll. When files are loaded in this way, the entire file is loaded into the computer's memory. All of the current versions of Windows have an architectural limitation with regard to memory-mapped files: no process can have more than 1 GB of memory-mapped files in total. This limitation means that all of the services that run under the Services.exe process must share the 1-GB pool. The memory is assigned in contiguous 64-kilobyte (KB) portions, and if the computer cannot assign additional memory to expand memory-mapped files, problems will occur.

For the Event Log service, the use of memory-mapped files means that regardless of the amount of memory that a maximum event log size setting specifies, events can no longer be recorded in the log when the computer has no more memory available for the memory-mapped file. Error messages will not be displayed; the events will simply not appear in the event log, or they might overwrite other events that had been recorded previously. Fragmentation of the log files within memory has also been shown to lead to significant performance problems on busy computers.

Because of these limitations—even though the theoretical limit for memory-mapped files suggests otherwise and the Event Viewer and Group Policy Object Editor user interfaces allow you to specify as much as 4 GB per log—we have verified that the practical limit is approximately 300 megabytes (MBs) on most 32-bit servers running Windows Server 2003—that is, 300 MBs for all of the event logs combined. On Windows XP-based computers, member servers, and stand-alone servers, the combined size of the Application, Security, and System logs should not exceed 300 MBs. On domain controllers, the combined size of these three logs plus the Directory Service, the DNS Server service, and File Replication Service logs should not exceed 300 MBs.

Although there is no simple equation to determine the best log size for a particular server, you can calculate a reasonable size. The average event takes up about 500 bytes within each log, and the log file sizes must be a multiple of 64 KB. If you can estimate the average number of events that are generated each day for each type of log in your organization, you can determine a good size for each type of log file.

For example, if your file server generates 5,000 events per day in its Security log and you want to ensure that you have at least four weeks of data available at all times, then you should configure the size of that log to about 70 MB (500 bytes * 5000 events/day * 28 days = 70,000,000 bytes). Then, check the servers occasionally over the following four weeks to verify that your calculations are correct and that the logs retain enough events for your needs. Event log size and log wrapping should be defined to match the business and security requirements you determined when you designed your organization's security plan.

Possible values:

• User-defined value in KBs between 64 and 4,194,240, which must be a multiple of 64
• Not Defined

Vulnerability

If you significantly increase the number of objects to audit in your organization and if you enabled the Audit: Shut down system immediately if unable to log security audits setting, there is a risk that the Security log will reach its capacity and force the computer to shut down. If such a shutdown occurs, the computer will be unusable until an administrator clears the Security log. To prevent such a shutdown, you can disable the Audit: Shut down system immediately if unable to log security audits setting that is described in Security Options, and increase the Security log size. Alternatively, you can configure automatic log rotation as described in article 312571 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkID=100879).

Countermeasure

Enable sensible log size policies for all computers in your organization so that legitimate users can be held accountable for their actions, unauthorized activity can be detected and tracked, and computer problems can be detected and diagnosed.

Potential impact

When event logs fill to capacity, they stop recording information unless the retention method for each is set so that the computer will overwrite the oldest entries with the most recent ones. To mitigate the risk of loss of recent data, you can configure the retention method so that older events are overwritten as needed.

The consequence of this configuration is that older events are removed from the logs. There are many ways that attackers can take advantage of event log configurations. If the log is set to overwrite events, attackers could overwrite evidence of their attack by generating a large number of spurious events that fill the log after performing some malicious activity. If the log is set to not overwrite events, an attacker could generate enough events to fill the logs first and then perform the malicious actions that would not be recorded. If the log is set to shut down the computer if unable to write logs, the attacker could use this to provoke a denial of service (DoS). The only ways to circumvent these vulnerabilities are to set an event log size large enough not to be easy to fill, to frequently monitor and export logs, to set audit policy to only log useful events, and to filter access to the systems so that it is difficult for malicious users to perform actions that result in spurious events being recorded.

Ideally, all specifically monitored events should be sent to a server that uses System Center Operations Manager 2007 or other automated monitoring tool. Such a configuration is particularly important because an attacker who successfully compromises a server could clear the Security log. If all events are sent to a monitoring server, you will be able to gather forensic information about the attacker's activities.

Prevent local guests group from accessing event logs

This policy setting determines whether guests can access the Application, Security, and System logs.

Possible values:

• Enabled
• Disabled
• Not Defined

This policy setting only affects computers that run Windows 2000 and subsequent versions of Windows.

Vulnerability

Attackers who successfully log onto a computer with guest privileges could learn important information about the computer if they are able to view the event logs. They could then use this information to implement additional exploits.

Countermeasure

Enable the Prevent local guests group from accessing event logs setting for the policies of all three event logs.

Potential impact

None. This is the default configuration.

Retain event log

This policy setting determines the number of days of event log data to retain for the Application, Security, and System logs if the retention method that is specified for the log is By Days. You should only configure this setting if you archive the log at scheduled intervals and you ensure that the maximum log size is large enough to accommodate the interval.

Possible values:

• User-defined number in days between 1 and 365
• Not Defined

A user must be assigned the Manage auditing and security log user right to access the Security log.

Vulnerability

Retaining event logs introduces a greater risk of both a DoS attack by filling up the event log and an evidence obfuscation method by preventing critical information about an attack from being logged due to lack of space during the interval period.

Countermeasure

Configure the Retain event log setting for the policies of all three event logs to Not Defined. If you decide that you must retain the event log and set up a scheduled interval to archive the log, you can partially mitigate the risk introduced to your systems by configuring the setting as follows:

1. Open the Properties dialog box for this policy setting.
2. Specify the appropriate number of days in the Retain application log setting.
3. Select Overwrite events by days for the event log retention method.

Also, ensure that the maximum log size is large enough to accommodate the interval.

Potential impact

None. This is the default configuration.

Retention method for event log

This policy setting determines the wrapping method for the Application, Security, and System logs.

Possible values:

• Overwrite events by days
• Overwrite events as needed
• Do not overwrite events (clear log manually)
• Not defined

To prevent the archiving of the Application log

1. Open the Properties dialog box for the Retention method for application log policy setting.

2. Select the Define this policy setting check box.

3. Click Overwrite events as needed, and then click OK.

To archive the Application log at scheduled intervals

1. Open the Properties dialog box for the Retention method for application log policy.

2. Select the Define this policy setting check box.

3. Click Overwrite events by days, and then click OK.

4. Open the Properties dialog box for the Retain application log policy.

5. Select the Define this policy setting check box.

6. Specify the appropriate number of days in the Retain application log box, and then click OK. Ensure that the maximum log size is large enough to accommodate the interval.

To retain all the events in the Application log

1. Open the Properties dialog box for the Retention method for application log policy.

2. Select the Define this policy setting check box.

3. Click Do not overwrite events (clear log manually), and then click OK.

This option requires that the log be cleared manually. In this configuration, new events are discarded when the maximum log size is reached.

Vulnerability

If you significantly increase the number of objects to audit in your organization, there is a risk that the Security log will reach its capacity and force the computer to shut down. If such a shutdown occurs, the computer will be unusable until an administrator clears the Security log. To prevent such a shutdown, you can disable the Audit: Shut down system immediately if unable to log security audits setting that is described in Security Options and then increase the Security log size.

If you set the Retention method for event log to Manual or Overwrite events by days, it is possible for important recent events to not be recorded or for a DoS attack to occur.

Countermeasure

Configure the retention method for all three event logs to the option Overwrite events as needed. Some resources recommend that you configure this setting to Manual; however, the administrative burden that this setting imposes is too great for most organizations.

Ideally, all significant events will be sent to a monitoring server that uses Operations Manager 2007 or other automated monitoring tool.

Potential impact

When event logs fill to capacity, they will stop recording information unless the retention method is set so that the computer can overwrite the oldest entries with the most recent ones.

Delegating access to the event logs

In Windows Server® 2003, Windows Vista, and Windows Server® 2008, it is possible to customize the permissions on each event log on a computer. This capability was not available in previous versions of Windows. Some organizations may want to grant read-only access to one or more of the System event logs to some members of the IT team, such as auditors. The access control list (ACL) is stored as a Security Descriptor Definition Language (SDDL) string, in a REG_SZ value called "CustomSD" for each event log in the registry. The following procedure shows how to delegate read-only access for an event log. You will need to repeat this procedure for each event log that you wish to delegate read-only access to by changing the registry key as needed.

To delegate access to an event log using the registry

1. Open Registry Editor.

2. Navigate to the following registry path:

   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EventLog

   You will see that there are keys available for each event log. Select the event log for which you want to delegate read-only access.

3. Add a new key with the name CustomSD to the event log you selected.

4. Add a new String value to the CustomSD key. The name of this string is not required, but it represents the access control list for the event log in the Security Descriptor Definition Language (SDDL) syntax. In this procedure this value will be referred to as SDDLACL.

5. Set the value of the SDDLACL to the following:

   O:BAG:SYD:(D;;0xf0007;;;AN)(D;;0xf0007;;;BG) (A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x5;;;SO)(A;;0x1;;;IU)(A;;0x1;;;SU) (A;;0x1;;;S-1-5-3)(A;;0x2;;;LS)(A;;0x2;;;NS)

Once you edit this value and restart the computer, the new setting will take effect. Be certain that you fully understand SDDL and the default permissions that are placed on each event log before you use this procedure. Also, be certain to test any changes thoroughly before you implement them in a production environment, because you could accidentally configure the ACLs on an event log in such a way that no one could access it.

Additional references

The following links provide additional information about event logging in Windows Server 2003 and Windows Vista:

• For more information about how to configure security for event logs in Windows Server 2003, see article 323076 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=100968).
• For more information about SDDL, see Security Descriptor Definition Language (https://go.microsoft.com/fwlink/?LinkId=100970).
• For more information about events in Windows Vista, see Event Viewer and Resulting Internet Communication in Windows Vista (https://go.microsoft.com/fwlink/?LinkId=100973).