NT Event Log

There are really three different event logs in NT—system, application, and security. The security log is the one IDS vendors are most interested in watching. Records are stored in a log file as events occur. NT Administrators can control the behavior of the logging subsystem in a number of ways. Space is controlled by defining a limit on the size of the log file. When the threshold is hit, options include the following:

•  Overwriting events that are only N days old

•  Pushing out the oldest records as new ones come in

•  Halting the system to prevent loss of an audit trail

To configure auditing, you first decide which event categories you want to monitor:

•  Logins and logouts

•  File and object accesses

•  Changes in user rights

•  Processes or thread events, such as creation and termination

•  Changes to the security policy for the system, such as giving additional privileges to a user

•  Restart, shutdown, and other system events

When you know which categories of events to monitor, you must enable auditing for individual users and objects. Auditing is turned on for a user through the user and group manager application. To enable auditing for an object, such as a file or directory, you use the File Manager. For a file, you can select whether to monitor success or failures for the following access types:

•  Reads

•  Writes

•  Executes

•  Deletes

•  Permission changes

•  Ownership changes

A final choice for directory objects is whether to audit only the current directory or to enable auditing for all of its subdirectories. This simplifies the administrators task when auditing is being configured. Caution is necessary, though. If you turn auditing on for the NT system directories and subdirectories, your event-logging activities will slow down the computer. Because all major executables are in these directories, this is unfortunate. Watching for Trojan Horses in system directories is reasonable goal for an IDS. Your only alternative is to be more granular in configuring auditing. For example, you could monitor everything except for read and execute events. This should catch most Trojan Horse attempts. However, if there is a file that only administrators should access, you might want to monitor any activity against that file. Be selective, or you quickly will notice sluggishness in your system’s performance.

When you enable auditing for an object, the appropriate bits are set in that object’s SACL. This activity itself generates an event that shows up in the log. Therefore, if you have turned auditing on for an object, and later you see an event that turns auditing off for that object, something unpleasant might be going on in your system.

Although not all NT IDS vendors choose to do so, a program can attach to the security event log and monitor events in real time. Today, Kane’s Security Monitor and Centrax’s eNTrax tools both periodically read the event log rather than process events in real time. An option to read the logs on an interval basis or to capture events in real time probably will be seen in future versions.

Not all events in the NT log contain sufficient data for IDSs to work. For example, remote logins do not identify the originating IP address or node name in the event record. An IDS vendor needs to gather this information from elsewhere in the system and correlate the information with the appropriate events—no trivial task. If the IDS is loaded as a service when the system boots, then process trees for login users can be constructed by monitoring the event log. Process and thread identifiers are associated with kernel data structures for sockets, pipes, and other communications data. Therefore, coalescing this information is possible and the IDS can use it to disconnect a remote user, who is hacking the system.

There also have been cases in which events that an IDS depended upon were no longer emitted after service packs were installed. Ripple effects of bug fixes are the leading suspects for this problem. You undoubtedly have been hit by this same type of problem when vendors of other products choose to deprecate an interface that you were relying upon for an in-house application.

Event Records

Information provided in the NT event log record includes header fields followed by an event specific description. Header fields are listed in Table 10.1. Table 10.2 shows the fields usually found in an event description.

Not all fields are always filled in for the record. For example, if a user’s privileges are modified, in the Privileges field of the event record, you will find information describing what changed. Any time you see that someone has gained an administrator privilege, it’s time to investigate and determine whether the change was legitimate. Object accesses are reported in the Accesses field of the description. Both fields can contain multiple lines of information when inspected through the Event Viewer on NT or through your IDSs browser.

Luckily, if you have an IDS for NT, you do not need to sit and watch events as they appear in the event log. Instead the IDS will summarize the information and display alerts when necessary. If you have the option of deciding which attacks to watch for, or if your IDS will notify you about select individual events, then you might want to think about what you should monitor to catch NT attacks. The next few sections give recommendations and describe well-known attacks against NT. The topics covered are not meant to be exhaustive. New NT hacks are posted regularly. See the NTbugtraq archives maintained by Russ Cooper at www.ntbugtraq.com. He also moderates the NTbugtraq mailing list.