Intrusion Detection: Network Security Beyond the Firewall:Detecting Intruders on Your System Is Fun and Easy









































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




Detecting whether the root user ran /home/Joe/ls instead of /bin/ls is difficult to do from the accounting files. Information about any resources accessed by the user’s program are sketchy.

Axent’s Intruder Alert also watches syslog and other system logs for intrusive behaviors. ITA depends on a rule-based approach to look for problems on the system. The rule base is extensible for third-party applications. One useful benefit of this capability is that vendors who write messages to syslog can build rules for plugging into ITA. Because ITA also includes a distributed, heterogeneous, client-server event reporting framework, other vendors can develop rules that indicate intrusive behavior and watch the events get reported to the ITA console.
Unfortunately, syslog does not include all of the information necessary to detect a number of intrusive and misused behaviors. The OS audit logs are needed for a more detailed analysis. Which is better—syslog or audit logs? There is no simple answer.
If you are content to know about failed su events, failed logins, bad password changes, and other events reported by syslog, then this is a sufficient source of instrumentation. The question you must consider is whether other events, such as those described in the following sections, which you want to detect. Also, you must decide whether you can afford the price of auditing. When you turn on the auditing subsystem, performance implications will occur. On the other hand, if your site security policy requires auditing already, adding an IDS that processes this data further is probably acceptable.
Audit Trails
The OS audit trails contain a significant amount of data about system activities. Each OS reports on a different number of events, but almost any OS system activity is reported. For example, Solaris reports more than 240 audit events, AIX almost 100, and HP-UX around 125. Microsoft NT emits about 100 different events as well.
Unlike syslog and the accounting logs, audit records include important, security-relevant data values in each record. Figure 6.2 shows the audit header fields for AIX. Note that today AIX does not report the EUID or EGID of a process, which makes detection of buffer overflow attacks difficult.

Figure 6.2  Audit record header fields for AIX.
Among other values, the audit records contain the following:


•  Details about the object being accessed, such as the parameters passed to the program
•  Fully qualified path names of executables

When a user completes the login process, the kernel assigns as audit ID (AUID), which is the prefix for each audit record written for that user. Even if the user runs a SUID root program, the AUID remains the same. This means that a user cannot hide an activity by pretending to be someone else, whether root or another user. The AUID is what proves accountability for activities and identifies the user responsible for the event.
How reliable is the AUID? The answer depends on your environment. If most of your users log in using the normal mechanism, run various programs, execute commands, and then log out, the AUID will be a reliable indicator for accountability. However, in a couple of cases the AUID is not particularly helpful.
A number of daemon programs started automatically by the system will run with AUID=0. Any audit records cut for those programs will show that root initiated the activity, even though it did not happen from a login shell. If these programs are listening for interprocess communication from other programs run by normal users, assigning accountability gets a little more complicated. When your program sends a message to one of these daemons and asks it to perform an activity on your behalf, it is the root AUID that will appear as the prefix for the daemon’s audit records, not your UID.
A more complicated problem exists for Web servers and systems without login sessions. Systems of this type are usually running server programs that are listening for network connections from other nodes. The only AUID in the audit records might be the that of the root user. Even if you have created a special user ID under which you run your Web server, the AUID probably will be zero (root’s UID) because of the way in which the Web server is started by the system. If the server is started by an rc script or via the init program, the root AUID will be the prefix for the audit records.
The AUID can be changed by a privileged process, which is good because it provides a facility for programs to set the appropriate AUID value. However, this feature also means that an intruder who gains root access will be able to change the AUID. While this may seem nasty at first glance, this event itself will be logged with an audit record.
Can an attacker stop the audit subsystem from running? Yes. This process, too, will generate an audit record before the subsystem shuts down. The attacker then would either need to delete the entire audit log or try to modify it. Changing the audit log by editing portions of it is nontrivial, and there have been no public reports of this occurring successfully. Still, it is possible if the attacker understands the auditing subsystem.
If you look at security tool Web sites such as COAST, you will find a program called zap. It was written to hide intruder tracks and is likely to be the first program installed when your system is compromised. Specifically, it doctors the utmp, wtmp, and lastlog files so that they do not show evidence of the intruder’s logins. A second set of tools available as rootkit contains hacked versions of ps and other status tools that are designed to hide activities, too. So far, none of these treasure chests include tools for tricking the auditing subsystem. Chances are it’s just a matter of time.
Tracing the Path of Activity Can Be Difficult
An IDS traces the path of activity so that an operation can be traced back to a specific user. In other words, the IDS will look at more than one event to make a policy decision. This process is much different from an OS that relies on the credentials of the running process at the instant an access control decision is made. Consider the policy violation that occurs when a user is able to read a file for which that user is not granted explicit read access (see “Monitoring Policies”).




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.