| Previous | Table of Contents | Next |
How do you know what to monitor on an NT system? First, you definitely want to watch for any well-known hacks. Most NT IDSs do this today. The next kind of event you want to know about is anything that might affect the security of your system. No doubt that sounds a bit broad. Unfortunately, this description is vague and does encompass a number of events. Here are some examples:
These types of activities are all single events that can affect the security of your system. Even a single login event is something you might want to monitor. How much to monitor depends on how tight your security must be. System monitors, such as KSM and eNTrax, have a predefined set of events or signatures they detect. If you don’t know which of these events to capture, select all of them until you have a better idea of what’s important. Two very important event categories to keep an eye on in NT are privilege changes and impersonation. Both are ways one can gain additional privileges.
When a user is created on the system, a set of default privileges is granted. Privileges allow a user to perform operations such as shutting down the system, adding other users, acting as part of the operating system, creating processes, logging in remotely, and backing up files belonging to others. DAC and privileges together limit what an individual user can do on the system.
A privilege vector is stored with the user definition in the system. Privileges associated with a group also are stored with the group information in the SAM. When a user logs in, the privilege vector is constructed from privileges assigned to that user and privileges defined for groups to which the user belongs. The complete set of privileges controls what kinds of operations that user is allowed to initiate while logged in to the computer. A privilege that enables a user to act as an administrator is something to be carefully monitored. The GetAdmin hack introduced earlier in the book grants administrator rights to an arbitrary user by exploiting an NT bug. The event log contains enough evidence to spot when this happens. To distinguish the GetAdmin hack from a legitimate change in privileges, the IDS must contain a signature relating multiple events. Nonetheless, the event log does allow an IDS to detect GetAdmin.
NT administration somewhat simplifies the task of assigning privileges to user and groups. Sets of common privileges are grouped into rights. Instead of assigning individual privileges to a user, you normally assign rights through the user and group manager application. If you want, you can select privileges one at a time and grant them to specific users, too.
The NT audit log reports privilege changes for users in distinct event records. IDSs watch the log for these entries to alert you to possible security problems. The privilege vector associated with an access token also can be altered through programming interfaces provided with NT. This means that the administrative GUI is not the only way for users to increase their privileges. You saw that UNIX systems had a number of facilities for increasing privileges. SUID programs in UNIX give users temporary privileges associated with the owner or group associated with that program. NT has similar capabilities through impersonation.
In earlier chapters, you learned that a critical component of computer systems is the capability for a process to act on behalf of another user. NT refers to this as impersonation. Recall that after a user logs into NT, an access token is created. In addition to containing a list of privileges and other fields, the token has a setting that defines the impersonation level for that token:
The impersonation level for a token can be changed any time during the lifetime of the token through NT APIs. If you are writing software, you can decide whether to allow remote systems to operate with the security context of your token. If you allow impersonation, other remote services can act on your behalf. This practice is necessary for accessing remote shares, for example. However, it also could be a security hole. A hacker who plants a bogus service with impersonation privileges will be able to use your credentials to impersonate you on other remote systems.
When you are logged into a system running NT, you might interact with system services and higher privileged processes many times. These process do have sufficient privileges to impersonate your access token. Because the system services run with very high privileges, they are essentially downgrading their capabilities when they create a thread to handle your request and associate your access token with the thread.
NT does not log all of the activities associated with impersonation. This is somewhat unfortunate because many unrecorded events affect the security policy of the system. Numerous system calls are provided to create access tokens, assign privileges to tokens, associate tokens with threads or processes, impersonate access tokens, and duplicate access tokens. A process must have very high privileges in order to successfully complete an operation through one of these interfaces. For example, a process must have the right to duplicate tokens if it wants to invoke the duplicate token system call. When this call is requested, it is the beginning of an attempt by one process to act on behalf of another. You can understand why this is an important event to monitor.
Other than security-relevant events that you want to track, NT has been hit by a number of hack attacks. You should know that many early attacks were found in NT 3.51 and were fixed in NT 4.0. Some intrusions have been reported on NT 4.0 as well, although service packs and patches are available to correct the bugs.
| Previous | Table of Contents | Next |