Intrusion Detection: Network Security Beyond the Firewall:UNIX System-Level IDSs









































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




A Word about Sequences
A pattern-matching IDS can look at a sequence of events to detect a problem. For example, if someone is suddenly removing dozens or hundreds of files, you might be faced with a disgruntled employee about to leave a system in an irreparable state. If you wanted to detect such an attack, you could configure your monitor to look for a sequence of N file deletions in a row by the same user, and ask the system to alert you when this threshold is hit. The first challenge to your thinking is the interval problem.
Suppose someone has 100 sensitive source files that are not backed up on any other system. This practice is bad to begin with, but it really does happen. If this intruder knows you are looking for successive file deletes, one possible way to escape detection is to delete one file each day for the next 100 days (or any number of deletions per day less than N). If the scope of your detection pattern is a login session, or a day, or a week, the pattern will not detect the problem because the threshold is not hit before a new scope boundary is hit. The pattern must reset its counter when a scope begins. Within each scope there can be any number of intervening events between successive file deletes. This is not a problem for the signature because it is happily counting the events as they occur, regardless of whether each delete command is followed by ls or any other command.
Most IDSs do not enable you to define a scope for resetting thresholds. Instead, the simplifying assumption is that a login session defines the scope of interest. Thus, if the user deletes N files between login and logout events (in the same way that parenthesis bound a related comment), the pattern will fire. The problem with this approach is that it will not catch the trick mentioned previously.
An alternative approach would be to track N file deletes regardless of the number of intervening events. The problem here is still to define the scope. If the scope is defined broadly as “from the very first event for this user on this system” up until “now,” the pattern will be of little use. Over a period of years, an employee is sure to delete many files. The pattern would fire every day for some user. Defining scope as a week, or as a day, or some other calendar duration is a good idea, but IDSs do not provide this capability today.
A statistical anomaly detector suffers from the same dilemma. Usually, these tools take a per day approach to computing the baseline, giving the number of average file deletes by each user per day. To catch a tricky hacker, per week or per month metrics also would be needed. If the perpetrator is someone who deletes hundreds of files per week as normal behavior, catching the disgruntled employee described before will be tough.
Focusing on Local Attacks
Think about a single system for which you are responsible. One type of attack can originate from a user logged on to your system. Another possibility is that the crack is launched via a network connection to the system. For each of these two categories, different attack severities range from denial-of-service up through gaining superuser privileges.

A system with a network adapter thus faces threats from users who are logged in and running programs and from users who connect to this computer from other nodes in your network. The goal of a hacker who has a login account on the system is to gain superuser privileges to have complete control. The goal of a hacker who does not have an account on the system is usually to establish an account on the system. The usually is added in the last sentence because it is not necessary for a hacker to have an account on a system to wreck things. Network connections to programs with security weaknesses can be exploited by crackers to do things just as if they had a login account on the system. Getting a login account just makes it easier to explore or trash a system.
In these sections, the focus is on attacks that can occur when a user eventually has login access to your system. In the next chapter, you will see how some of these same kinds of attacks can occur when someone communicates with your system over the network. In the worst case, a remote user without an account is able to gain superuser privileges on your system. For the moment, though, you should focus first on how local login users can exploit your system’s weaknesses.
To recap the increasing severity of local problems, remember that the list goes as follows:

•  Denial of service
•  Local account gains read access to a resource
•  Local account gains write access to a resource
•  Local users gain privileges, especially of superuser

An IDS Limitation
At this point, you should see a limitation of IDSs that is shared with other tools. If you do not configure the tool properly, it will not catch intrusions or misuse by insiders. You must specify what you want to monitor, unless you monitor everything. To use an IDS, you must state your monitoring policy, particularly if you want to monitor resources not predefined in the IDS, such as application binaries. As you can see, the IDS might make some assumptions that a knowledgeable hacker can use to avoid detection. This doesn’t mean that IDSs do not work, it just means that catching hackers is really hard and requires tuning of the tools.



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.