Intrusion Detection: Network Security Beyond the Firewall:The Role of Access Control in Your Environment









































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




Audit consolidation is performed by the emitter daemon running on each node and the collector daemon on the audit server. Both daemons support configuration files in which the output format, filters, and log file characteristics can be defined. Audit records include a sufficient amount of information, roughly equivalent to what is found in audit records from the base operating system. APIs are provided for accessing the audit records in binary form. The events reported in normal auditing of SeOS are primarily access control events or login events.

How does SeOS decide what to audit? When users or resources are defined, the security administrator sets the audit characteristics for those entities. Again, the events for users might be successful or unsuccessful logins. For resources such as files, events include access successes or failures. Individual file auditing is thus supported. Resource access can be set to notify so that each time someone accesses a particular file, for example, e-mail can be sent to a set of addresses. At this time, the response capability does not seem to be configurable, although custom responses are possible in the TME Event Console when SeOS is used as part of Tivoli’s Security Manager product.
Audit logs can be scanned or reported on using CLI or the interactive GUI. A separate audit server is not required. The audit logs can be examined on each system. Filters include the following:

•  Login/audit ID
•  Terminal or workstation (if network attached)
•  Originating host (for consolidated logs)
•  Resource class
•  Start/stop dates and times
•  Status (success, failure, warning, and notify)
•  IP service name, port
•  Trusted program name
•  Startup/shutdown
•  SeOS administrator name

Filters for viewing audit records can be wildcards or specific entries. Indeed, for many of the fields in a given access control constraint, wildcards are accepted. Possibilities include “Joe can access file /home/foo only when requested through program /bin/v*.”

The Trace log is similar to the audit log and can be configured to store its output in the audit log. Trace logs include more detailed information including process create, fork, exec, process death, setuid() calls, setgid() calls, and more as the documentation claims. Many of the Trace events are SeOS related. These events include administrator activities such as “user XYZ ran the seadmin command with these parameters…” The entire set of Trace messages provided is contained in roughly 25 pages of documentation in a SeOS publication appendix.
Other SeOS Features
SeOS protects against su, SUID, and SGID escalation with access control rules. Individual SUID programs can be limited with the types of variables described in this chapter (user, group, time of day, and so on). SeOS will scan the system for SUID programs, for example, or you can enter names individually. This additional level of access security addresses some of the concerns regarding SUID and SGID programs. An administrator can specify some very complex predicates that are used to limit normal user access to privileged programs. Because hackers often look for privileged programs to exploit, this feature is valuable. One simple approach is to disallow running of privileged programs from users that login remotely. This approach actually requires some fine tuning, because programs such as e-mail fall into this category.

Many customers complain about UNIX because it permits the same user to log in more than once simultaneously to the same system. Others see this feature as an advantage. In any event, like mainframes, SeOS can limit individual users to a single active login session per node.
SeOS can be configured to disable logins based on failed login attempts. Flexibility exists in how this can be done. For example, N failed logins from a given source would block logins only from that source IP address, terminal, or X-station. Although most operating systems support login disabling after a configured number of failures, blocking from a specific source is designed to reduce the denial of service threats due to login failures. (Remember this from Chapter 2?)
Going beyond SeOS
The Tivoli Management Environment (TME) layers a uniform security model on heterogeneous operating systems. Like the individual privileges or rights that a user on NT can be assigned, the TME security model supports granular privileges using a role-based model. Role-based access control is both a practical and a research topic, meaning that you can find both commercial products and formal papers about the area. Essentially, a role is a collection of operations or privileges. A user can belong to one or more roles. When an operation is initiated by the user, various access rights are verified based on the roles assumed by the user.
A role-based architecture, such as the one provided by TME, is flexible enough to permit arbitrary definitions of roles beyond the predefined set in NT, for example. Roles can be defined for the operating system as well as for application-level programs. Depending on the situation, a program may need to be modified to be aware of the role-based model, or the model can be layered over an existing environment including much of the UNIX operating system. Unfortunately, when layered over UNIX, the root access problem still persists. That is, you or a hacker can always bypass the processes on the system implementing the layered approach and work directly with system programs or processes. Still, role-based architectures provide promise for access granularity for systems management and application programs beyond what is delivered in off-the-shelf operating systems today.
Why You Still Need Intrusion Detection
One of the main points to remember from this chapter is that the success of access control depends heavily upon knowing the subject of the request. Who the system thinks you are is controlled at login time by I&A processes detailed in the preceding chapter. In this chapter, you also saw how you could change who you are in the system through privilege escalation in UNIX and impersonation in NT. As part of the normal activities on a system, various programs increase and decrease their privileges on a regular basis. This basic behavior is one of the most often exploited characteristics of systems. Hackers look for weaknesses in privileged programs to gain superuser access to a system.



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.