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




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.
Table 10.1 Header Fields for an Event Record



date

time

event ID

source of the record (security, application, system)

type of event

category (object access, system event, user event, and so on)

computer node name

user name





Table 10.2 Event Description Fields



object server name
primary domain

object type (file or user, for example)
client user name

object name
client domain

a handle ID
client login ID

operation ID
information about any object accesses

process ID
information about any privileges changed

primary User Name




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.



Previous
Table of Contents
Next






























Products |  Contact Us |  About Us |  Privacy  |  Ad Info  |  Home


Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited.