Intrusion Detection: Network Security Beyond the Firewall:Traditional Network Security Approaches









































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




Network Node I&A
Even though users and groups are not always needed in network protocols, individual network nodes must be distinguishable from each other via some identifying information. Otherwise, the network would not know where to deliver messages. At a minimum, a source and a destination address for the network packet are required for uniquely designating the endpoints of the communication session. A network node can be a computer, a router, or even a printer attached directly to the network. When two computers communicate with each other, they must be able to establish their identities and authenticate each other.
The early days of the Internet were characterized by trusting souls. Although early critiques of Internet protocols identified weaknesses (Morris, 1985; Bellovin, 1989), defenses were not widely erected to thwart the threats. Many different types of network attacks exist today, but a frequent underlying theme is the capability to impersonate a network entity. If you are able to forge network traffic with the address of another entity, then a number of doors are opened. Any authentication scheme based solely on the self-proclaimed identity of a network entity is flawed. This practice is like letting users log in to a system by entering only their user names and completely discarding the requirement for a password. In other words, self-proclaimed I&A in networked environments only gives you the I without the A.
A node that claims to have a particular network address may not be telling the truth. Therefore, in network security, you cannot assume a trustworthy environment if you rely only on address-based authentication.
Recall from Chapter 2 that an authentication server is a useful facility for a network of systems. If an attacker can impersonate the authentication server, then havoc would reign in the network. In networks in which users can be trusted to refrain from network address impersonation attacks, applications and protocols may depend on address-based authentication. However, when network traffic must pass through an untrusted or hostile network, the communicating systems must not rely on cleartext addresses for authentication. Network address can be used for identity, but the values can be trusted only if they are somehow protected with cryptography.
Network nodes do not always use mutual authentication, but this guideline is a good one to follow, too.
Software Can Be a Network Entity
With network computing comes the lure for peer-to-peer or client-server distributed applications. Software serving the role of a client or a server is also a network security entity. As in the case of Lotus Notes discussed previously, the application has an operating system security context. Sometimes, the operating system security context is sufficient for authentication between clients and servers. More frequently used is application level authentication in which the communicating processes are forced through a strong I&A exchange before sending messages.
Application level authentication is a subset of application level security, which also includes communication privacy and integrity. Cryptographic techniques are especially applicable here, and each communicating server is required to demonstrate knowledge of a shared secret.
Users can demonstrate knowledge of a secret via an interactive dialogue. However, client or server processes that are often started automatically by the system cannot wait for a user or administrator to enter a secret for each application. Instead, the secret is often stored on disk after undergoing a transform to prevent easy guessing. As part of its initialization steps, the server may read the secret from disk or from some other hardware device.
An interesting performance tradeoff occurs here. Good security programming dictates that passwords are not kept in memory for an extended period. Following this guideline, a software server process would read its server-specific password file each time the password is needed. This I/O can become a bottleneck if the server is very active and constantly initiating new connections. Reading the password once and storing it in volatile memory is one work around. However, sometimes this can backfire. A user might be able to force the system to dump core, and if the core file contains the server’s address space, the password might be discovered.
As you can see with I&A in network security, plenty of stuff is available for the hacker to play with—impersonating the identity of a user, impersonating the identity of a network node, impersonating a remote software program, sniffing network packets, and locking out one of the nodes by flooding it with network messages. Even before you get to network access control, you can see why intrusion detection is needed beyond traditional network security.
Network Access Control
Network communications also require some form of access control. Explicit access control, such as a feature that limits outbound network connections to only a specific set of users, is possible. Implicit access control also is possible through the use of cryptography in network communications. If a network layer receives a packet that cannot be cryptographically authenticated, the packet will be dropped. Any node or anyone not in possession of the appropriate cryptographic credentials, or key, will not be allowed to access the other node. Packets can be sent, but they will be ignored.
Network access control is most recognizable in the form of network packet filtering in firewalls or routers. Special network software or hardware is installed at a junction point between two networks to regulate the flow of packets across the networks. Routers provide access control by deciding whether packets are allowed to flow in a particular direction. Firewall packet filter modules compete with routers but claim more functionality, such as the capability to evaluate more complex access control rules. The defining feature of this level of access control is that decisions are made in the lower layers of the network stack. In most firewalls, this capability is provided by enhancing or replacing the operating system kernel level of the network.
Network Application Access Controls
Network access control can occur at any layer of the network stack. Therefore, an application can introduce its own access control constraints in addition to whatever the operating system may be doing.




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.