Subjects in NT are processes and threads. Each process and thread is associated with an access token that is a complex data structure defining characteristics of the subject. One of the most important attribute lists in the access token is its privileges. Any time a process or thread is able to increase its privileges, that subject is able to access other resources that might normally be off limits.
Access control lists are associated with objects. Two different ACLs—object ACLs and system ACLs. Object ACLs control access requests by subjects. System ACLs control activities, such as auditing for that object. Depending on the type of object, the ACL entries vary. For example, access control entries (ACE) for files are different than they are for registry keys.
Based on this simple review, you probably see some of the important events to monitor on NT systems. Any time a change is made to a user's privilege list in the user database you want to be notified. Changes to ACLs for important system files and directories also are potential preludes to an attack. As in UNIX systems, you should watch for attempts to install Trojan Horses. Especially serious is any attempt—successful or not—to increase the privileges associated with a thread or process.
Sources of Data for NT IDSs
By now, it should be apparent to you that intrusion detection is a special case of monitoring. Performance monitoring tools track network traffic, system resource utilization, and application behavior. IDSs also need data from various sources to operate effectively.
Vulnerability scanners that assess the state of your machines operate in one of two modes. Remote assessments are carried out from a central console and targeted at individual nodes in your network. With a remote scan, no special software is needed on the target machines. Local assessments are undertaken by software specifically installed on the node. When a scan is activated by a remote manager station or by a scheduled job, the local scanning software runs on the target node itself.
NT local vulnerability assessment tools operate much the same way as UNIX scanners. They look at configuration information on the system, inspect the contents of files, scour through registry entries, and attempt to crack passwords in the SAM. Other features, such as file-integrity checkers, are supported as well. Recall that a local scanner has the advantage of operating on the system as a login user. This means that the local scanner can read files and access other resources that a remote scanner cannot. Of course, you must install the local scanning code on each target.
Remote scanners against NT systems probe for known network configuration problems, check for back-level programs with holes, and attempt to gain access to the system by breaking in as normal users or as the administrator. The source of data for these IDSs is primarily feedback that comes from interacting with NT network services or applications, such as the Internet Information Server (IIS). Remote scanners benefit from the fact that they do not run client code directly on the target. For this reason, vendors can combine both NT and UNIX probing into the same product. As in the case of UNIX remote scanners, it is possible to peer into some of the internals of an NT system even though you are not running a process on that system. For example, if the trust relationship is configured to permit remote access, some NT registry entries can be inspected. Microsoft's Server Message Block protocol also divulges information to remote scanners, including the list of currently logged in users.
Network sniffers for UNIX and NT often are combined into one product, too. The source of data is the same for UNIX and NT network sniffers. Only the attacks monitored varies between the two operating system types. Many attacks are equally applicable to the IP stacks on both, such as SYN Flood.
System-level IDSs in UNIX and NT rely on different datastreams. NT provides an event log (or audit log) that tracks many important activities on the system. Vendors, who write system-level IDSs for NT, such as Centrax and Kane, depend on the event log for the data that drives their engines.
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:
No comments:
Post a Comment