Windows NT Event Logging

8/3/2019 Windows NT Event Logging

1/26

vent LoggingWindows NT E

By James D. Murray1st Edition September 19981-56592-514-9, Order Number: 5149316 pages, $34.95 Includes CD-ROM

Chapter 2.

The Event Logging Service

In this chapter:Components of NT Event LoggingAccessing Remote Event LogsThe Event Log FilesLocalization and Event Message ResourcesEvent Logging and the RegistryMaintaining the Event LogsSecurity and Reliability

Event logging is implemented under Windows NT as asystem service. In the Win32 operating system, a service isa process that runs in the background, is controlled by theService Control Manager (SCM), and performs tasksnecessary to the operation of the system or otherprocesses. Because the event logs must be protected bythe highest level of security Windows NT can offer, theevent logging service is designed as a component of theWindows NT operating system.As I discussed in Chapter 1,About Event Logging, theevent logging service is responsible for governing all

access to the Windows NT event logs. Applications anddrivers are not allowed to directly read and write the eventlogs. They must instead request that the event loggingservice retrieve and write event data for them and performbasic log maintenance operations (backup, clear, etc.) ontheir behalf. Having a single access point to the event logsinsures that all operations on the logs will always becorrectly performed, users with insufficient privileges will
http://www.oreilly.com/catalog/winlog/chapter/ch02.html#42475http://www.oreilly.com/catalog/winlog/chapter/ch02.html#17308http://www.oreilly.com/catalog/winlog/chapter/ch02.html#23503http://www.oreilly.com/catalog/winlog/chapter/ch02.html#40421http://www.oreilly.com/catalog/winlog/chapter/ch02.html#40421http://www.oreilly.com/catalog/winlog/chapter/ch02.html#28631http://www.oreilly.com/catalog/winlog/chapter/ch02.html#20618http://www.oreilly.com/catalog/winlog/chapter/ch02.html#36643http://www.oreilly.com/catalog/winlog/chapter/ch02.html#42475http://www.oreilly.com/catalog/winlog/chapter/ch02.html#17308http://www.oreilly.com/catalog/winlog/chapter/ch02.html#23503http://www.oreilly.com/catalog/winlog/chapter/ch02.html#40421http://www.oreilly.com/catalog/winlog/chapter/ch02.html#28631http://www.oreilly.com/catalog/winlog/chapter/ch02.html#20618http://www.oreilly.com/catalog/winlog/chapter/ch02.html#36643


2/26

be disallowed access, and only a single, uniform API will beused by all processes needing to access the event logs andtheir information.

Components of NT Event Logging

The Windows NT event logging facility consists of a numberof components, with the event logging service itself at theheart. Event log files, the registry, Event Viewer, messageresource files, and an event logging API library are allrequired to read, write, and maintain NT's event logs.Figure 2-1 shows the interaction of all of the components ofthe event logging service with a Win32 application (which,in this figure, is Event Viewer).

Figure 2-1.Interaction of a Win32 program with the event logging service

When Windows NT boots, it starts the SCM, which in turnstarts all of the services configured for automatic start-up.One of these services is the Event Logging service(EVENTLOG.EXE). When a user-mode process needs to
http://www.oreilly.com/catalog/winlog/chapter/ch02.html#32471http://www.oreilly.com/catalog/winlog/chapter/ch02.html#32471


3/26

access the event logs, it must make a request to the eventlogging service to perform the desired operation (read,write, back up, query, or clear). The request is made bycalling one or more of the functions defined by the eventlogging API.

The API is made available to Win32 processes in the%SystemRoot%\SYSTEM32\ADVAPI32.DLL Dynamic LinkLibrary (DLL). (This is the same DLL that contains severalother APIs, including those of the Service Control Manager,NT security, and the registry.) The event logging API istherefore the gateway to the information stored in theevent logs and the only mechanism available to reportevents to NT's event logging service. (The event loggingAPI is described in Chapter 4, Windows NT SecurityAuditing, and Chapter 5, The Event Logging API.)When the operating system, device driver, or application

reports an event, it is actually sending the report to theevent logging service. The service then stores theinformation associated with each event as a record in oneof the three event log files located on the local systemdisk.The registry also plays a very important part in eventlogging. All event sources must be registered to beproperly recognized. The event logging service uses eachsource's registration information to find the localizedstrings for each event message and for other information.The registry is also where the event logging service's

parameters are stored (you'll find out more about this inthe following sections).When a user-mode process needs to write an event reportto an event log, it requests the handle of an event logusing the name of a registered event source. The eventlogging service searches the registry to determine whichlog is used by the event source, and passes a handle to thelog back to the process. The log handle is then used tosend the information on each event reported to the eventlogging service.When a user-mode process needs to retrieve event

information from an event log file, it uses the event loggingAPI to request a handle to the log, and then uses additionalAPI calls to specify which records are read from the log file.The event logging service reads the event record data fromthe log file and passes it back to the process. The processmust then read the registry to find the message files ofeach event source whose records were read, read the


4/26

localized strings from the message file, and use the stringsto format the event descriptions.

The event logging API may be called only byuser-mode applications.[1] Programs that run

exclusively in kernel mode, such as mostWin32 device drivers, cannot directly call theevent logging API. Instead, they must reportevents using functions provided by the NT I/OManager specifically for reporting eventsindirectly to the event logging service. Kernel-mode programs may only report events; theymay not read, back up, query, or clear theevent logs.

See Appendix E, Kernel-Mode Event Logging,

for more information on implementing eventreporting in Win32 kernel-mode programs.

Accessing Remote Event Logs

The event logging API allows the event logging service onremote NT systems to be accessed by processes runningon the local system. The event logging API communicateswith the event logging service on remote Windows NTsystems using Remote Procedure Calls (RPCs). A processneeding to access the event logs of a remote system callsthe event logging API as it would to access the event logsof the local system. But it must also specify the name ofthe remote system using the Microsoft Universal NamingConvention (UNC). (Chapter 5 describes this convention.)All requests to read, write, back up, and clear the remoteevent logs are then forwarded by the local event loggingservice to the remote system using RPC. The use of RPC bythe event logging service and API is completely transparentto the calling process.The event logging service does not support the reading orwriting of the event logs using other forms of interprocesscommunication, such as named pipes or Network DynamicData Exchange (NDDE). If you need a way to access theevent logs other than calling the event logging API, thenyou must write a proxy service which interfaces with theevent logging API on the remote system and makes theevent logging information available to you using thedesired mechanism.
http://www.oreilly.com/catalog/winlog/chapter/#footnote-1http://www.oreilly.com/catalog/winlog/chapter/#footnote-1


5/26

The Event Log Files

The information in each of the three event logs is stored ina separate event log file. By default, the three log files arelocated in the %SystemRoot%\SYSTEM32\CONFIG

subdirectory in the files:APPEVENT.EVTApplication event logSECEVENT.EVTSecurity event logSYSEVENT.EVTSystem event logEach event log file stores information using the EVT binaryrecord format. One record is stored per event written tothe event log. Only the event logging service directly readsand writes the event log files. User-mode applications

access the event log data using the event logging API. It isnot necessary to understand the internal format of theevent log files, but you may find a peek inside interesting.Figure 2-2 shows a hex dump of the SECEVENT.EVTfile,containing only a single event log record. The darklyshaded areas at the top and bottom of the dump are theheader and trailer of the event log file. The lightly shadedarea in between is that of the single event log record. Theformat of the data in this record is the same as theEVENTLOGRECORD data type defined in the WINNT.H file.Each record will be at least 56 bytes in length.

Figure 2-2.A hex dump of the security event log containing one event


6/26

If we were to look at this event using Event Viewer's EventDetail window, we would see the record informationdisplayed as in Figure 2-3.

Figure 2-3.Event detail of the security event log containing one event

Comparing the contents of Figures See and See , we cancorrelate all of the data in the event log record with theinformation displayed in the Event Detail dialog box. Butyou can see in the Description box several strings that arenot present in the event log record ("The audit log wascleared", "Primary User Name: ", etc.). Where does EventViewer find these strings? Read on . . .

Localization and Event MessageResources

A requirement of Windows NT is that all event log reportsbe written using the language of the locale of the WindowsNT system -- regardless of the human language used bythe application logging the event. For example, an English-only Win32 application running on a Spanish Windows NTsystem should report events using event descriptionsrendered in Spanish and not English.The use of event message resources by the event loggingservice makes this easy to do, but it is up to the softwaredevelopers to provide a translation of each event reportdescription in the dozens of human languages supportedby Windows NT. The capability is beyond most developers
http://www.oreilly.com/catalog/winlog/chapter/ch02.html#35979http://www.oreilly.com/catalog/winlog/chapter/ch02.html#30841http://www.oreilly.com/catalog/winlog/chapter/ch02.html#35979http://www.oreilly.com/catalog/winlog/chapter/ch02.html#35979http://www.oreilly.com/catalog/winlog/chapter/ch02.html#30841http://www.oreilly.com/catalog/winlog/chapter/ch02.html#35979


7/26

and, as a result, most Win32 applications report eventsusing only English descriptions.As I mentioned in Chapter 1, all language-dependentinformation is referred to as localized information.Localized strings used by an application will change based

on the primary language and sublanguage used by aWindows NT installation.[2] For example, "initializing,""initialising," and "inicializando" are all localized strings ofthe same word. The format used to display time, date, andcurrency information is also locale-dependent.The localized information in an event report includes thename of the event category, the format of the time anddate stamp, some types of parameter data, and the eventdescription itself. Nonlocalizedinformation includes allstrings and data which remain the same regardless of thesystem locale, such as file names, common and standard

acronyms, process and logon identifiers, and mostparameter data.The localized strings in event reports are not stored in theevent log files themselves. If they were, then event logswould quickly fill with records containing many redundant,localized event descriptions, most of which would never beseen in Event Viewer. Instead, the localized strings for eachevent report are (or should be) stored outside of the eventlogs in message table resources attached to the reportingprocess's executable file or to an event message file.When the event logging service reads, at the request of a

process, a record from an event log file, it must also readfrom the registry to determine where the localized eventstrings for the record are kept. The event source named inthe event record is matched to a list of registered eventsources in the registry. If a match is found, the location ofthe message resource file is determined from the source'sregistry values; the strings matching the language of thelocal system are read from the indicated message resourcefiles(s); the description strings are merged with any non-localized data stored in the event log record; and thecomplete record is returned by the event logging service. If

an event source match is not found, then an error will bereturned and Event Viewer will display its very helpful "Thesystem cannot find the file specified" message.In the previous section describing the event log files, Inoted that some of the strings in the event descriptiondisplayed in the Event Detail window were not present inthe event record data. These strings are localized datastored inside the message file(s) used by the event source


8/26

reporting the event. Event Viewer located the specificmessage files and read the strings using information in theevent log record and the registry (see the next section).Event message files are a very good way to isolatelocalized information from both applications and the event

log files. If any description strings need to be changed,added, or removed, only the DLL (dynamic link library)needs to be recompiled, not the entire application. If thisisn't a major advantage to your design, then you can doaway with the event message file altogether and store thelocalized description strings in the application's executablefile itself.There is one major drawback that is inherited from the useof message files. If the wrong version or an out-of-dateevent message file is referenced by the event loggingservice, the description strings may not be found, or the

wrong description may be read. This is especially aproblem when viewing event logs on a remote system.Event Viewer will read the event record data from theremote log files, but will search the registry of the localsystem for the corresponding event message files. If thecorrect version of the event message file is not installed onthe local system, an incorrect string may be displayed, or amessage indicating that the string associated with theevent ID could not be found will result.

Event Logging and the Registry

The Windows NT registry is used to store all of the eventlogging service's configuration and policy information.There are several keys that indirectly affect how eventlogging is performed and how the logs are accessed.All configuration information for the event logging serviceis located in the registry under theHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog key. Under this key are three subkeys,Application, Security, and System, which containinformation for NT's three event logs:HKEY_LOCAL_MACHINESYSTEMCurrentControlSet

ServicesEventLogApplicationSecuritySystem


9/26

The EventLogkey contains the configuration parametersfor the event logging service. These values are used by theService Control Manger when loading the event loggingservice:HKEY_LOCAL_MACHINESYSTEMCurrentControlSet

ServicesEventLogErrorControl 0x00000001Group "EventLog"ImagePath "%SystemRoot%\system32\services.exe"ObjectName "LocalSystem"PlugPlayServiceType 0x00000003Start 0x00000002Type 0x00000020

Under normal circumstances, you should never need toadd any values or modify any of the data stored directly

under the EventLogkey. One notable exception is when anevent log file become corrupt and must be manuallydeleted.[3] The event log files can't be deleted becausethey are always kept open by the event logging service;the service can't be stopped using the Services applet inControl Panel because so many other services depend onit. The registry editor must therefore be used to change theEventLog\Start value from 0x02 to 0x04, and the systemmust be restarted. This will prevent the event loggingservice from being started by the Service Control Managerand will allow the corrupt file to be removed.

Event Log Subkeys

Each of the three event log subkeys stores informationused for locating and accessing its corresponding eventlog. This information includes the location of the event logfile, a map of the registered event sources associated withthe log, and the log's retention policy and maximum size.These values are used by the event logging API and aremodified only by Event Viewer. All of these values are readby Event Viewer each time it is started and when it is used

to clear an event log. The EventLogkeys and valuesappear as follows:HKEY_LOCAL_MACHINESYSTEMCurrentControlSet

ServicesEventLogApplicationFile "%SystemRoot%\System32\config\AppEvent.Evt"


10/26

MaxSize 0x00010000Retention 0x00000000Sources 57 69 6e 6c 6f 67 6f 6e 00 57 69 6e 64 6f 77

SecurityFile "%SystemRoot%\System32\config\SecEvent.Evt"MaxSize 0xffff0000

PrimaryModule "Security"Retention 0xffffffffSources 53 70 6f 6f 6c 65 72 00 53 65 63 75 72 69 74

SystemFile "%SystemRoot%\System32\config\SysEvent.Evt"MaxSize 0x00080000RestrictGuestAccess 1Retention 0x00093a80Sources 53 70 6f 6f 6c 65 72 00 53 65 63 75 72 69 74

Table 2-1 lists the names and values stored under eachevent log subkey.

Table 2-1:Event Source Values

Name Type Description

FileREG_EXPAND_SZ

The name and location of thefile used to store records for theevent log. This value must bechanged to relocate the eventlog files to a different folder orpartition.

MaxSize REG_DWORD

The maximum physical size thelog file may grow to. This valuemust be specified in 64Kb(0x00010000) increments.Nonconforming values arerounded upward to the next64Kb boundary by the eventlogging service. The default is512Kb (0x00080000).

PrimaryModuleREG_EXPAND_SZ

The name of the primarymodule (event source) usingthe event log. This key is usedonly by the security log.

RestrictGuestAccess

REG_DWORD

Guests and null accounts have

read access to the system andapplication event logs bydefault. Setting this key to 1 willdisallow these accounts accessto the event logs. The securitylog is always protected fromaccess by guest and nullaccounts.


11/26

Retention REG_DWORD

The possible values for this keyare 0x00000000 (overwriteevents as needed) and 0xffffffff(do not overwrite events). Anyother value is interpreted as

"overwrite events older than Ndays." The value of "N days" isexpressed in seconds(0x00015180 for one day and0x01e13380 for 365 days). Thisvalue must be in increments of86400 seconds. Nonconformingvalues will be adjusted to thenearest day by Event Viewer.The default Retention key valueis 0x00093a80 (7 days).

Sources REG_BINARY

A listing of all event sourcesregistered with the event log.The name of each registeredsource is delimited by a NULLcharacter, and the entire list isterminated by two consecutiveNULLs. The last name in the listis that of the event log. Thisvalue is automatically updatedby the event logging serviceeach time a new event source isadded to an event log subkey.

Again, you should never need to add any names or directlymodify any of the values stored under the event logsubkeys, although there are two exceptions. If you want tochange the location of the event log files themselves, you'llhave to modify the File value manually using the RegistryEditor.[4] You'll also need to modify the Sources valuedirectly when removing an event source from the registry.The Sources value is stored in the registry as binary data,and it's difficult to see how the event source names are

stored. The following dump shows the Sources value underthe Security event log key on my NT system:0000 53 70 6f 6f 6c 65 72 00 Spooler.0008 53 65 63 75 72 69 74 79 Security0010 20 41 63 63 6f 75 6e 74 Account0018 20 4d 61 6e 61 67 65 72 Manager0020 00 53 43 20 4d 61 6e 61 .SC Mana0028 67 65 72 00 50 72 6f 67 ger.Prog0030 4e 61 6d 65 53 65 63 00 NameSec.


12/26

0038 4e 6f 72 74 6f 6e 5f 53 Norton_S0040 70 65 65 64 44 69 73 6b peedDisk0048 5f 53 65 63 75 72 69 74 _Securit0050 79 4c 6f 67 00 4e 65 74 yLog.Net0058 44 44 45 20 4f 62 6a 65 DDE Obje0060 63 74 00 4c 53 41 00 53 ct.LSA S

0068 65 63 75 72 69 74 79 00 ecurity.0070 00 .

When an event source key (explained in the next section)is added to the registry, the name of the event source isautomatically added to the Sources value of thecorresponding event log subkey by the event loggingservice. The Sources value is not actually updated until thenew event source registry key is closed. If the new eventsource registry key fails to close properly, then the eventsource may be misregistered and may not be usable byEvent Viewer. If this happens, you should delete andrecreate the event source key.An event source is simply removed by deleting its key fromthe registry. However, the event logging service does notimmediately remove the event source name from thecorresponding event log subkey's Sources value. Instead,the Sources value is rebuilt each time the event loggingservice is started (usually only when the system boots). Anapplication removing an event source may also manuallyupdate the Sources value, but it really isn't necessary.

Event Source Keys

Under each event log subkey are zero or more eventsource subkeys. Each of these subkeys is named after anevent source that may be used to report events. Everyevent source is therefore associated with a specific eventlog. To avoid confusion, an event source name should notappear under two or more of the event log subkeys. It isthe name of the event source subkeys that is passed to theevent logging service's RegisterEventSource API function(detailed in Chapter 5). There may be dozens or evenhundreds of event sources registered under any log key.

Each event source subkey contains information needed bythe event logging service to interpret the event source'sevent record data. Such information includes the numberof event categories and event types used by the eventsource, and the location of the event source's messagefiles. (Message files are explained in detail in Chapter 6,Message Files.) The following excerpt from the NT registryshows the root EventLog key, the three event log subkeys


13/26

(Application, Security, and System), and one event sourcesubkey (ntbackup, Security, and eventlog) under eachevent log subkey:HKEY_LOCAL_MACHINESYSTEMCurrentControlSet

ServicesEventLogApplicationntbackupEventMessageFile %SystemRoot

%\System32\ntbackup.exeTypesSupported 0x00000007

SecuritySecurityCategoryCount 0x00000007CategoryMessageFile %SystemRoot

%\System32\MsAuditE.dllEventMessageFile %SystemRoot%\System32\MsAuditE.dll

ParameterMessageFile %SystemRoot%\System32\MsObjs.dllTypesSupported 0x0000001c

SystemeventlogEventMessageFile %SystemRoot%\System32\netevent.dllTypesSupported 0x00000007

Table 2-2 lists the names and values that may be storedunder each event source subkey.

Table 2-2:Event Source Key Values

Key Type Description

CategoryCount REG_DWORD

The number of event

categories that are supported.This name and value ispresent only if the eventsource uses event categories.

CategoryMessageFile

REG_EXPAND_SZ

The location of the categorymessage file(s). Multiple filenames are delimited bysemicolons. This name andvalue is present only if theevent source uses eventcategories.

EventMessageFileREG_EXPAND_SZ

The location of the eventmessage file(s). Multiple filenames are delimited bysemicolons. This name andvalue must appear, as everyevent source must have atleast one event message file.


14/26

ParameterMessageFile

REG_EXPAND_SZ

The location of the parametermessage file(s). Multiple filenames are delimited bysemicolons. This name andvalue is present only if the

event source uses aparameter message file.

TypesSupported REG_DWORD

This mandatory valuecontains a bitmask of thesupported event types. Thisvalue is created by ORing oneor more of the followingvalues:

EVENTLOG_ERROR_TYPE0x0001

EVENTLOG_WARNING_TYPE0x0002

EVENTLOG_INFORMATION_TYPE 0x0004

EVENTLOG_AUDIT_SUCCESS0x0008

EVENTLOG_AUDIT_FAILURE0x0010

Print Spooler

TheHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Providers\EventLog key is used to control thereporting of print spooler events. Under Windows NT 3.x,this key value is used to enable (1) or disable (0) thereporting of all print spooler events to the system event

log. Under Windows NT 4.0, this key value is a bitfield usedto indicate which print spooler events are reported byevent types:

Event TypeBitfiel

d


15/26

Error events 0x01

Warning events 0x02

Informationevents

0x04

See the section for information on how to change this

registry value using the Printer applet in Control Panel.More information on this registry key is found in theMicrosoft Knowledge Base.[5]

CrashOnAuditFail

One last, and very significant, event logging registry key isHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\CrashOnAuditFail. Setting this key's value to 1 causesthe local system to halt with a STOP message and a bluescreen when the security log is filled. This is to prevent the

situation in which the system is unable to log any auditableevents that may occur on the system because the securitylog is filled to its capacity. CrashOnAuditFail does not causethe system to be stopped if the application or system logsare filled.Just before the system is halted, the operating systemchanges the key's value to 2, indicating that when thesystem is restarted, only an account belonging to theAdministrators group may initially log on.[6] Changing thekey's value back to 1 enables normal logon sessions. Thesystem must be restarted each time the CrashOnAuditFailvalue is changed. And this key must be deleted from theregistry to disable this feature.

The CrashOnAuditFail feature should not beused in most deployments of Windows NT. Itexists only to satisfy the operationalrequirements used by some classified militarysystems. It is not required in most commercialand private deployments of Windows NT.

Maintaining the Event LogsEvent logging is an automated facility--that is, it requiresno user intervention to work. NT's event logging service isalways running and available when any process needs toread an event log or (more commonly) report theoccurrence of events. However, a few bookkeeping and
http://www.oreilly.com/catalog/winlog/chapter/#footnote-5http://www.oreilly.com/catalog/winlog/chapter/#footnote-6http://www.oreilly.com/catalog/winlog/chapter/#footnote-5http://www.oreilly.com/catalog/winlog/chapter/#footnote-6


16/26

housekeeping chores are the responsibility of the NTsystem administrators.Under Windows NT 4.0, most administrative tasks areperformed using the applications found in the StartAdministrative Tools (Common) menu, or in the

Administrative Tools group box under NT 3.x. And as Imentioned in the previous section, the primary tool used toperform event log maintenance is Event Viewer.If you are not a system administrator, or if you only useyour NT system as a stand-alone workstation, then youprobably haven't experimented much with NT's system anduser administration. If you plan on seriously using eventlogging for system security and troubleshooting, you needto realize that there is some maintenance involved.

Backing Up the Event Logs

Event Viewer is capable of making a backup copy of anyevent log file. Backing up the event logs is necessary onlyif you need to keep a historical record of the logs createdon an NT system. Such archives are useful for collectingstatistics on system usage or for determining how long aparticular condition has been present. They may also comein handy for reviewing changes made to system security,and they can also be subpoenaed by a court of law. (I'lldiscuss this aspect of event logs in Chapter 4.)Event Viewer does not have a mechanism for performing

automatic backups of the event logs or maintaining anarchive of event log backup files. You must resort to usingEvent Viewer to manually back up each event log and thenarchive the resulting backup files using a file archiving ordocument control system of your own choosing. Suchdrudgery, especially if dozens or hundreds of NT systemsare involved, will quickly prompt you to write or buysoftware to do the work automatically for you. (SeeAppendix A, References and Resources, for a listing ofseveral such timesavers.)If you will be performing regular backups of the event logs,

you will need to choose an appropriate event log retentionpolicy. The default retention policy is to overwrite olderevent records with newer event reports when an event logfile is full. This is not a good thing when you need topreserve event log information! The retention policy,however, can be adjusted to prevent newer event reportsfrom overwriting existing event log records. (See "EventLog Retention Policy" later in this chapter.)
http://www.oreilly.com/catalog/winlog/chapter/ch02.html#40921http://www.oreilly.com/catalog/winlog/chapter/ch02.html#40921http://www.oreilly.com/catalog/winlog/chapter/ch02.html#40921http://www.oreilly.com/catalog/winlog/chapter/ch02.html#40921


17/26

Clearing the Event Logs

You will clear the event logs when you want to "start fresh"with a blank event log. Clearing is most often performedimmediately after making a successful backup of an event

log to ensure that the same log entries are not stored inmultiple log backup files. Clearing is also necessary after achange is made in the event log retention policy, as itforces the event logging service to reread its configurationparameters from the registry. It is also possible to back upand clear the logs in a single operation, but this can resultin an error if the backup is saved to a remote system.[7]When an event log is filled to its physical capacity, and theretention policy settings for the log do not allow any moreevent reports to be written to it, the event logging service(i.e., the EventLog event source) will report error event

6000 to the system log. The event description will indicatewhich log is full -- unless it's the system log that is full; inthis case, you will not see this event report.On rare occasions, you may see a message box on thedesktop informing you that one of the event log files is full.[8] This message is generated by the event logging serviceitself as an immediate, unsolicited notification to the userthat events are not being written to an event log. Thenormal procedure is to click the OK button on the messagebox, start Event Viewer, back up the event log, possiblychange the log settings to increase the size of the log file

or to allow newer event reports to overwrite older eventrecords, and, finally, clear the filled event log.A bit of mystery surrounds the "event log file is full"message box. People have pondered, "If the filled event logis cleared by a remote system, and the OK button on themessage box displayed on the local system is not clicked,is the event logging service blocked from writing any newevent reports to the log file until the message box iscleared?" The answer is "no." The appearance of themessage box does not block the operation of the eventlogging service or any other process running under NT (i.e.,

the message box is not system modal). In fact, if you want,you can just move the message box aside and let NTremove it the next time you shut down the system.

Event Log Retention Policy

A primary concern with enabling any type of event loggingis the amount of disk space consumed by the log files. Any


18/26

type of tacitly written logging file (error, debugging,auditing, etc.) has the potential of being the source of amysterious disappearance of available disk space.One solution to this problem is found in the design of manyembedded systems that retain logs but have no local disks.

They record significant events in a fixed block ofnonvolatile memory (EEPROM) allocated as log storage.When the log memory is full, the newest event overwritesthe record of the oldest event. This design is called a wraparoundor a roll over log.This design is the default recordretention policy of the Windows NT event logs, and it ispart of the responsibility of the event logging service tofollow this policy.The event log record retention policy is used by the systemadministrators to specify the maximum possible physicalsize the three event log files may reach, and how to handle

an event log that has filled to its capacity. In such a case,the default is for the oldest events in the log to beoverwritten by the newest recorded events. You canoverwrite this default by saying that you want to overwriteonly events older than a specific number of days (1 to 365days, with 7 days being the default), or that you do notwant to overwrite any existing recorded events and insteaddrop all newly-reported events until the log is cleared.Each event log file may range from 64Kb to (theoretically)4Gb in size. The maximum possible log file size is really thesize of the disk partition where the log file is stored. The

practical maximum size is, of course, much smaller. Thedefault size of each event log file is 512Kb, and a "cleared"event log file is always 64K in size.

The retention policy for each event log file isset using Event Viewer, and is explained inChapter 3, Event Viewer.

Security and Reliability

Although we would like to consider all files and programson our computer systems secure and reliable, this just isn'tthe case. Security is very much determined by the systemconfiguration, which is controlled by the systemadministrator. And reliability is a factor not only with thesystem's hardware, but also with the design and quality ofthe software that it runs.


19/26

I have mentioned that event logging is an extremelyimportant part of system troubleshooting and security.Event logging must therefore be protected from bothaccidental and deliberate corruption. The bottom line isthis: the event logs are no more secure than the system

itself. Windows NT contains a considerable amount ofsecurity that is enabled by default. But unless you havetaken deliberate steps to prevent users from successfullytampering with your system, you run a very good chanceof leaving security holes open that may be exploited by anintruder.Securing computer systems running the Windows NToperating system is a topic beyond the scope of this book.But we will take a brief look at the possible securityproblems and question of reliability of the Windows NTevent logging facility itself. (See Chapter 4 for more

information on Windows NT security.)

Missing Events

One question of reliability is raised by incomplete eventpairs. An event pairconsists of two event reports thatindicate an object has been opened/closed,started/stopped, allocated/deallocated, and so forth. Forevery "open" event reported, you would expect to see theassociated "close" event also reported, right?Well, sifting through even a modestly sized security event

log using an automated search and report generation tool(see Appendix A) will reveal many unmatched pairs. Anattempt to match up event pairs may indicate that objectshave been opened (560), processes have been created(592), and users have been logged on (528), but neverclosed (562), terminated (593), or logged off (538). Onecould blame this inconsistency on buggy software, butthese events are reported by Windows NT itself!Initially, the problem of open event pairs lies with theauditing policy itself. For example, if you are only trackingfailures, but not successes (probably to conserve log

space), then any object that was successfully opened, butfailed to properly close, will result in an open event pair.This won't be the case with closing events that can't fail.For example, the logoff event (538) can only be logged assuccessful. To NT there is no such thing as a bad logoff.Sometimes the fault with missing event reports lies withthe reporting applications themselves. Perhaps a call madeto an event logging API function returned an error, and the


20/26

calling application did not handle it properly, or theapplication simply gave up and didn't attempt to retryreporting the event. Flaws in the application's logic maycreate circumstances under which an event is notreported, although it should be. And the abnormal

termination of a process or thread may cause a failure ofobjects to properly close.Another source of open pairs is when the system is shutdown. The event logging service is just another processrunning under NT that must be shut down with all the rest.If event logging is stopped before all the other objects areterminated, their closing will not be recorded in the auditlog, and open pairs will result. The primary example of thisoccurrence is from the event logging service itself. Whenloaded, the event logging service reports in the system log"The event log service has started," but it never reports

"The event log service has stopped" when the system isshutting down. (Actually, if the event logging service wereable to log this event after it had actually stopped, then NTwould truly be a spooky operating system.)If shutting down the system resulted in a significantnumber of open event pairs, it would seem that we couldconsider the System Shutdown event (513) to be theclosing event for all open pairs. There is a problem,though: this could be true, but without explicit log entriesthere is no way to know if each open event closedsuccessfully or not. This concept also fails because the

Windows NT shutdown event is never recorded in thesecurity log. System Startup (512) and System Shutdown(513) are themselves always an open event pair!

Starting and Stopping the Event LoggingService

A key part of event logging security is the inability forusers--even system administrators--to pause or stop theevent logging service. Using the Services applet in ControlPanel, it is possible to configure how the event logging

service is to be started by the Service Control Manager. Itmay be automatically started when the system boots (thedefault), may be stopped on startup and manually startedby the system administrator, or may be disabled. Once theevent logging service is started, however, it can't bepaused or stopped, even by a system administrator.[9]Event logging is available immediately when the eventlogging service is started.


21/26

All services started by the SCM run within the context ofthe Local System account[10] and inherit the securitycontext of the SCM. The event logging service does notappear as a separate process under Task Manager, but canbe listed with all other services using the SCList utility

included with the Windows NT Resource Kit.

Event Logging Overload

The event logging service is a passive mechanism that justwaits in the background until it is prompted by a system ornetwork process to service a request. And like any othersystem process, it is affected both by the current systemload (CPU and disk usage) and the amount of work it isbeing asked to perform.It is possible that the system may be under such a high

load, and/or that so many events are being reported, thatthe event logging service may fail to log events that arereported to it, or may even crash. I have not personallyattempted to push NT's event logging service to thebreaking point, nor have I come across any specific reportson how much stress it can take. But there is at least oneofficial bug report indicating that NT's event loggingservice can hang.[11]The event logging service may also be the target of anaccidental or deliberate denial of service attack. In such acase, the event logging service is flooded with event

reports in the hope that the new, bogus reports willoverwrite the older, incriminating reports when the eventlog is filled. The reports will come from an application thatthe intruder has planted on the system, or from an existingapplication that can be easily manipulated to generate alarge number of event reports in a short period of time. Aproblem for the intruder is that the event logging retentionpolicy can be configured so new reports do not overwriteolder event log records.Denial of service attacks also include attempts to exploitmisconfiguration of the system or unhandled exceptions in

the system software. For example, the system may crash ifthe maximum size of the event log file is greater than theamount of available disk space on the volume where itresides. By filling the log with extraneous event reports, allavailable disk space on the volume will be consumed, butthe log will not yet have reached its maximum configuredsize. If this situation is handled badly by any runningsystem or user application (and most likely it will be), then


22/26

a system-disabling or even more catastrophic problem mayresult.

False Event Reports

If an intruder cannot edit or clear the event logs, then apossible recourse is to corrupt the logs withmisinformation. For the application and system logs, this iseasy to do, as any process has permission to write to theselogs. But events can only be reported to the security log byprocesses running under an Administrator-level account orthe Local System account.In the discussion of C2-level security in Chapter 4, I notethat C2-level certification requires only that the informationin each event record follow a specific format and that theevent logging files and facility be secure. There are no

requirements that an authentication mechanism mustverify the source of each event report, or that a validationmechanism be used to determine if reported eventsactually happened. For better or for worse, Windows NTevent logging follows both the C2-level statedrequirements and its omissions.There is no guarantee that the information appearing inany event log record is accurate, or that it was reported bythe event source that is indicated. Corruption of event logrecord data integrity may occur accidentally due tosoftware bugs, or deliberately by the reporting of

misleading events that impersonate other event sources.Intruders may plant an application on the system whichreports events that are designed to misdirect the systemadministrator away from their trail and on to anotherproblem. It is also possible to replace an event source'sevent message file(s) with a "Trojan horse" of sorts thatcontains erroneous messages.[12]

Attacks on the Event Logging Facility

The event logging facility of any computer operating

system is usually a prime target of attacks made byintruders. If the computer's auditing or logging facility canbe disabled, then system administrators will have norecord of what illegal activity was attempted andsuccessfully performed on the system. For this reason, it isvery important that the event logging service's executablefiles, registry keys, and event log files themselves be


23/26

secured with the proper file system and registrypermissions.Unfortunately, on systems that allow the users to installsoftware applications, the EventLogregistry key must bewriteable to allow installation programs to register (create)

new event sources. Registry keys are therefore vulnerableto attack. The message files used by such applications arealso vulnerable to attack due to the inability of a typicaluser account to place the installed files underAdministrator-only control.It is also possible that a deliberate attack may be directedtowards the event log files themselves. A common attackinvolves the attempt to clear or delete the security log filewhere incriminating evidence is usually stored. But anattacker would need to log on to the system using anAdministrator-level account to succeed.

If this type of brute-force attack were successful, it wouldimmediately tip off an alert system administrator thatsomething abnormal had occurred on the system, butthere would be no logged evidence to indicate whatexactly had taken place. The proper policy would be toimmediately restrict all access to the system until it couldbe determined how, when, why, and by whom the securitylog was cleared. An intruder with a quest to obtainpermanent, ill-gotten access would not want this tohappen.A more sophisticated attack would involve simply editing

the security log and removing all records that indicatedillegal activity. But there is no native NT utility for editingthe event log files on a per-record basis, so such a utilitywould need to be transferred to the system and removedwhen finished. But the event log files are not shared forwriting by the event logging service.The event log files are opened when the event loggingservice is started, and are not closed until the service isshut down. A sharing violation will result if a process otherthan SERVICES.EXE attempts to write directly to any of thelog files or to read from the security event log. This is true

even for processes running under an Administrator-leveluser account.The log files aren't even easy to directly copy. When theSCM opens each event log file it changes several bit valuesin each file's header to indicate that the file is open. Theevent logging service interprets these byte values as anindication that the log file is corrupt. Applications such asEvent Viewer are able to successfully read the event log


24/26

files because they obtain the handles of the open log filesfrom the event logging API rather than attempting to openthe log files directly. To successfully copy an event log youmust use the Log Save As menu command in EventViewer, or use the BackupEventLog function in the event

logging API.Unfortunately, the event log files are completely vulnerableto attack if the system is shut down and restarted underMS-DOS--even if the logs are stored on an NTFS partition.[13]

Secure Event Log Viewing

It is possible to disallow guest accounts and NULL sessionsto view the application and system event logs using theRestrictGuestAccess value under each event log key (see

Table 2-1). If your %SystemRoot% directory is on an NTFSvolume, it is also possible to disallow the viewing of allthree logs by remote accounts, even if they are logged onas a member of the Administrators group and have the"Manage auditing and security log" user right. The steps tosecure the event log are as follows:

1. Set theHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\[LogName]\RestrictGuestAccess value for theEventLog\Security key to 1.

2. Using Windows NT Explorer, highlight an event log file,select the File Properties menu item, click the Security tab, andthen click the Permissions button.3. Click the Remove button to remove the Everyone group.4. Click the Add... button, double-click to add theAdministrators, Authenticated Users, and SYSTEM names, andthen click the OK button.5. Set the Type of Access for Authenticated Users to Read, setthe Administrators and SYSTEM to Full Control, and click the OKbutton.6. Set the permission on the event log files to allow access

only by members of the Administrators groups and the LocalSystem account.7. Repeat steps 1 through 6 for the system and application logkeys and files.

1. Under Windows NT, an application or driver may executein kernel-mode or user-mode. Kernel-mode is a privileged
http://www.oreilly.com/catalog/winlog/chapter/#footnote-13http://www.oreilly.com/catalog/winlog/chapter/ch02.html#27313http://www.oreilly.com/catalog/winlog/chapter/#footnote-13http://www.oreilly.com/catalog/winlog/chapter/ch02.html#27313


25/26

processor mode that allows access to system memory andhardware. Most low-level device drivers and the systemexecutive run in kernel-mode. User-mode is anonprivileged processor mode in which all userapplications, high-level drivers, and protected subsystems

(Windows On Windows, POSIX, etc.) execute. User-modeapplications cannot access system memory and hardwareexcept by calling kernel-mode system services and drivers.2. Refer to WINNT.H for a listing of primary languages andsublanguages supported by NT.3. See Microsoft Knowledge Base, "How to Delete CorruptEvent Viewer Log Files," article Q172156.4. See Microsoft Knowledge Base, "Moving Security andSystem Logs to Another Location," article Q111534. Theevent logs are typically relocated to a volume that containsgreater security and/or a greater amount of storage space,

or simply in an attempt to reduce the fragmentation of the%SystemRoot% volume.5. See Microsoft Knowledge Base "EventLog Registry ValueDoes Not Enable Print Event Logging," article Q143132,"Unable to Disable Print Event Logging in Windows NT 3.5,"article Q124549, and "Turning Off Print Job Logging in theSystem Log," article Q115841.6. See Microsoft Knowledge Base "How To PreventAuditable Activities When Security Log Is Full," articleQ140058, and "Only Admins May Log in After Applying C2Security from Reskit," article Q155076.

7. See Microsoft Knowledge Base "Access Denied WhenSaving Event Log," article Q164430.8. The appearance of this message box is not reliable, noris it guaranteed. Experimentation has shown that it maynot appear until many failed attempts to write to the filledlog file have occurred; after the log is cleared and filledagain, it may not reappear at all.9. Several pieces of Microsoft documentation, including theEvent Viewer help file itself, claim that the event loggingservice may be paused and/or stopped. This is only trueunder Windows NT 3.x and not under NT 4.0. Too many

other services depend on the event logging service toallow it to be paused or stopped.10. Local System (or, simply, the "System" account) is apredefined account under NT that is used to start allservices and local system processes. It is not a useraccount and has no associated credentials (i.e., domain,username, and password).


26/26

11. See Microsoft Knowledge Base "Event Logging FrozenWhile Doing Heavy Logging," article Q164938.12. An excellent argument for including the eventdescription message table resource inside the application'sexecutable file. See the discussion of message files in

Chapter 6, Message Files.13. Utilities that can read and write NTFS partitions fromMS-DOS and Windows 95 include NTDOSUtils, available athttp://www.sysinternals.com.

Date post:	06-Apr-2018
Category:	Documents
Upload:	smilealwplz
View:	238 times
Download:	0 times

Windows NT Event Logging

Documents