Intrusion Detection: Network Security Beyond the Firewall:Intrusion Detection for NT
function GetCookie (name) { var arg = name + "="; var alen = arg.length; var clen = document.cookie.length; var i = 0; while (i < clen) { var j = i + alen; if (document.cookie.substring(i, j) == arg) { var end = document.cookie.indexOf (";", j); if (end == -1) end = document.cookie.length; return unescape(document.cookie.substring(j, end)); } i = document.cookie.indexOf(" ", i) + 1; if (i == 0) break; } return null; } var m1=''; var gifstr=GetCookie("UsrType"); if((gifstr!=0 ) && (gifstr!=null)) { m2=gifstr; } document.write(m1+m2+m3);
Keyword Title Author ISBN Publisher Imprint
Brief Full
Advanced Search Search Tips
Please Select ----------- Components Content Mgt Certification Databases Enterprise Mgt Fun/Games Groupware Hardware IBM Redbooks Intranet Dev Middleware Multimedia Networks OS Prod Apps Programming Security
UI Web Services Webmaster Y2K ----------- New Titles ----------- Free Archive
To access the contents, click the chapter and section titles.
Intrusion Detection: Network Security beyond the Firewall
(Publisher: John Wiley & Sons, Inc.)
Author(s): Terry Escamilla
ISBN: 0471290009
Publication Date: 11/01/98
function isIE4() { return( navigator.appName.indexOf("Microsoft") != -1 && (navigator.appVersion.charAt(0)=='4') ); } function bookMarkit() { var url="http://www.itknowledge.com/PSUser/EWBookMarks.html?url="+window.location+"&isbn=0"; parent.location.href=url; //var win = window.open(url,"myitk"); //if(!isIE4()) // win.focus();
}
Search this book:
Previous
Table of Contents
Next
Chapter 10Intrusion Detection for NT
In this chapter, you will read about NT vulnerabilities and attacks. Each of the types of IDSs defined—vulnerability assessment scanners, system level, and network sniffers—are available for NT as well as for UNIX. Some products, such as eNTrax from Centrax are designed exclusively for NT. Before learning about the products, it is important to review some of the underlying concepts that an IDS must handle.
NT Security Review
In Chapter 2, “The Role of Identification and Authentication in Your Environment,” you had a chance to dig into the I&A process in NT. Chapter 3, “The Role of Access Control in Your Environment,” described how everything in the system is treated as an object, and that all object access requests go through a single reference monitor—the Security Reference Monitor (SRM). 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—were discussed in Chapter 3 as well. 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.
In Chapter 7, “Vulnerability Scanners,” you learned that 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.
Previous
Table of Contents
Next
Products | Contact Us | About Us | Privacy | Ad Info | Home