Intrusion Detection: Network Security Beyond the Firewall:Sniffing for Intruders
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 Sniffers Do Not See All Packets
A network IDS works by running a network adapter in promiscuous mode to capture all of the packets coming into and going out of a particular subnet. Notice that this is not the same as watching all of the network traffic that appears on a subnet. Look at Figure 9.2. Here, the physical arrangement of the nodes is in a ring with node B sitting between node A and the node running the IDS. The packet Hello B is sent from node A to node B. However, because A and B are directly adjacent, B grabs and processes the packet sent by A. The node running the IDS never has a chance of seeing the packet.
Figure 9.2 An IDS does not see all packets on a subnet.
This means that a network IDS is not designed to track all the network activities on a subnet. Instead, the IDS is positioned to look for inbound and outbound packets at the entry/exit of the subnet. Following terminology introduced earlier in the book, the network IDS catches intruders, but it does not always catch internal misuse. If the packet from A to B had been a misuse or internal hack, the IDS node would miss it. To catch attacks between nodes, an intelligent IDS sniffer would need to be run on each node.
Network Sniffers Are Blinded by Encryption
Many sites rely on encryption for privacy of network traffic. In some cases, two corporate sites are connected by an IP tunnel. A firewall at each site implements the IP tunnel so that all traffic is encrypted as it passes across the unsecure Internet. After a firewall receives an encrypted packet from another site, the packet is decrypted and sent on to the target node in the secure network. A configuration like this does not hinder network intrusion detection. The packet appears in the clear as it leaves the firewall. Because the network IDS is the first node after the firewall (see Figure 9.1), the encryption does not impact the solution.
In some cases, though, an IP tunnel is established between two arbitrary nodes in a network. The nodes could be in the same subnet, or they could be communicating across the Internet. The IP traffic is not decrypted until the receiving node reads the packet from its network adapter. The network IDS has no way of seeing the cleartext version of the packets. Any attack signatures that require cleartext packets will not work when two nodes use an IP tunnel. Again, one possible solution to this problem is to run a sniffer on each node. Note that the sniffer must be in the OS network stack after the packets are decrypted.
When you connect from a browser to a Web server using secure sockets (SSL), the packets from your computer are not decrypted until they reach the Web server application itself. SSL packets flow through the firewall and remain encrypted. The packet arrives at the Web server node, moves up through the kernel stack, and is read by the Web server program from a socket. It is not until this last step, which only the Web server program itself controls, that the packet is decrypted. This type of application-level encryption also blinds network sniffers to many attacks such as the phf hack.
Missed System-Level Attacks
As mentioned in Chapter 6, Detecting Intruders on Your System Is Fun and Easy, system-level monitoring has access to important events such as privilege transition. A new attack that causes a buffer overflow and gives root privileges to a remote user will not be seen by a network IDS. If the attack signature is written properly, the system-level IDS will detect and respond to this type of situation.
Two general classes of attacks exist that a network IDS cannot detect, but a system-level IDS can. You can think of the first class as unknown side effects. When an activity on the system happens as the result of receiving a network packet, its possible that a side effect will occur that violates your security policy. Examples include the following:
Creation of a world-writable file by a privileged program as a result of processing a network packet
Downgrading the security of an existing resource, such as making /etc/passwd world writable
Upgrading the privilege of a user, such as changing the UID of a normal user to zero in /etc/passwd
Creation of a back door, such as any program that can lead the user to a root shell
Unless the hacks that led to these breaches already are known in the security community, the network IDS will not see these events, but the system-level IDS will. If you have a scanner, some of these problems will be caught the next time it runs. In some sense this argument seems unfair because it merely states that if the attack is not known in the community, the network IDS vendor cannot build a signature to catch the attack. However, even if the initiation sequence for the attack is unknown, a system-level IDS can detect that a SUID root program was created. What this says to you is that you need both types of IDSssystem and networkto catch all of the attacks you face.
The other class of system-level problems that a network IDS misses are attacks that are not based on sending or receiving network packets. Examples include any hacks launched by directly attached terminals or TTYs. If you are connected to the computer system with a terminal, you can start a nasty brute force password guessing program, and no network sniffer will be able to detect it. Most midrange hardware vendors still sell a significant number of dumb terminals to customers. Naturally, these threats are posed mostly by insiders rather than intruders.
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.
Wyszukiwarka
Podobne podstrony:
272 27314 (273)268 270Śpiewnik 2702013 03 KWP Rzeszów sprawozdanie za 2012rid(273273 2773500classic RM 272 RM 273 schematics v1 0index (273)272 273Warunki techniczne zmiana 2002 12 16 Dz U 2003 33 270demo cgi 27001 (273)więcej podobnych podstron