Threats and Countermeasures

The event log records events on the computer, and the Security log records audit events. The event log container of Group Policy is used to define the attributes that are related to the Application, Security, and System event logs, such as maximum log size, access rights for each log, and retention settings and methods. The Microsoft® Excel® workbook "Windows Default Security and Services Configuration," which is included with this guide, documents the default event log settings.

On This Page

	Event Log Settings
	More Information

Event Log Settings

You can configure the event log settings in the following location within the Group Policy Object Editor:

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

Maximum event log size

This policy setting specifies the maximum size of the Application, Security, and System event logs. Although the user interfaces (UIs) of both the Group Policy Object Editor and the Microsoft Management Console (MMC) Event Viewer snap-in allow you to enter values as large as four GB, certain factors make the effective maximum size for these logs much smaller.

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 Microsoft Windows® have an architectural limitation with regard to memory-mapped files: no process can have more than one 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 one GB pool. The memory is assigned in contiguous 64 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 the Maximum event log size setting specifies, log events may 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 may 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 UIs allow you to specify as much as four GB per log—Microsoft has verified that the practical limit is approximately 300 MB on most servers-- that is, 300 MB for all of the event logs combined. On Microsoft Windows XP, member servers, and stand-alone servers, the combined size of the Application, Security, and System event logs should not exceed 300 MB. On domain controllers, the combined size of these three logs plus the Active Directory® directory service, DNS, and Replication logs should not exceed 300 MB.

These limitations have caused problems for some Microsoft customers, but the only way to remove the limitations requires fundamental changes to the way system events are recorded. Microsoft is rewriting the event log system to resolve these problems in the next version of Windows.

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 4 weeks of data available at all times, then you would want to 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 your calculations 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.

The possible values for the Maximum event log size setting are:

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 you enabled the Audit: Shut down system immediately if unable to log security audits setting. 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 Chapter 5, "Security Options," and increase the Security log size. Alternatively, you can configure automatic log rotation as described in the Microsoft Knowledge Base article "The event log stops logging events before reaching the maximum log size" at http://support.microsoft.com/default.aspx?kbid=312571.

Countermeasure

You should 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 will 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 will be removed from the logs. Attackers can take advantage of such a configuration, because they can generate a large number of extraneous events to overwrite any evidence of their attack. These risks can be somewhat reduced if you automate the archival and backup of event log data.

Ideally, all specifically monitored events should be sent to a server that uses Microsoft Operations Manager (MOM) or some 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, then 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 event logs.

The possible values for the Prevent local guests group from accessing event logs setting are:

Note: This policy setting does not appear in the Local Computer Policy object.

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

Vulnerability

An attacker who has successfully logged onto a computer with guest privileges could learn important information about the computer if they were able to view the event logs. The attacker 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 logs

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. Configure this setting only if you archive the log at scheduled intervals and you make sure that the maximum log size is large enough to accommodate the interval.

The possible values for the Retain event logs setting are:

Note: This policy setting does not appear in the Local Computer Policy object.

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

Vulnerability

If you archive the log at scheduled intervals:

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

Countermeasure

Configure the Retain event logs setting for the policies of all three event logs to Not Defined.

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.

If you do not want to archive the Application log:

If you want to archive the log at scheduled intervals:

If you must retain all the events in the log:

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

The possible values for the Retention method for event log setting are:

Note: This policy setting does not appear in the Local Computer Policy object.

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 Chapter 5, "Security Options" and then increase the Security log size.

If you set the Event log retention method 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 MOM or some 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 Microsoft Windows Server™ 2003, 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. 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, as in the following example:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EventLog\CustomSD
Create a REG_SZ registry value 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)

If you edit this value and restart the computer, the new setting will take effect.

Caution: Be careful when you edit the registry values, because there is no "undo" function in the Registry Editor tool. If you make a mistake, you will have to correct it manually. Also, you could accidentally configure the ACLs on an event log in such a way that no one could access it. Be certain that you fully understand SDDL and the default permissions that are placed on each event log before you proceed. Also, be certain to test any changes thoroughly before you implement them in a production environment.

For more information about how to configure security for event logs in Windows Server 2003, see "How to: Set Event Log Security Locally or by Using Group Policy in Windows Server 2003" at http://support.microsoft.com/default.aspx?kbid=323076.

For more information about SDDL, see "Security Descriptor Definition Language" on MSDN® at http://msdn2.microsoft.com/en-us/library/Aa379567.

Top of page

More Information

The following links provide additional information about event logging in Windows Server 2003 and Windows XP.

Top of page

7 of 14