273-276.html

入侵检测的相关教程

			<option value="/reference/dir.intranetandextranetdevelopment1.html">Intranet Dev
			<option value="/reference/dir.middleware.html">Middleware
			<option value="/reference/dir.multimediaandgraphicdesign1.html">Multimedia
			<option value="/reference/dir.networkservices1.html">Networks 
			<option value="/reference/dir.operatingsystems.html">OS
			<option value="/reference/dir.productivityapplications1.html">Prod Apps
			<option value="/reference/dir.programminglanguages.html">Programming
			<option value="/reference/dir.security1.html">Security	
			<!-- <option value="/reference/dir.ewtraining1.html">Training Guides -->
			<option value="/reference/dir.userinterfaces.html">UI
			<option value="/reference/dir.webservices.html">Web Services
			<option value="/reference/dir.webmasterskills1.html">Webmaster
			<option value="/reference/dir.y2k1.html">Y2K
			<option value="">-----------
			<option value="/reference/whatsnew.html">New Titles
			<option value="">-----------
			<option value="/reference/dir.archive1.html">Free Archive		
			</SELECT>
			</font></td>
	</tr>
	</table>
	</form>
<!-- LEFT NAV SEARCH END -->

		</td>
		
<!-- PUB PARTNERS END -->
<!-- END LEFT NAV -->

<td rowspan="8" align="right" valign="top"><img src="/images/iswbls.gif" width=1 height=400 alt="" border="0"></td>
<td><img src="/images/white.gif" width="5" height="1" alt="" border="0"></td>
<!-- end of ITK left NAV -->

<!-- begin main content -->
<td width="100%" valign="top" align="left">


<!-- END SUB HEADER -->

<!--Begin Content Column -->

<FONT FACE="Arial,Helvetica" SIZE="-1">
To access the contents, click the chapter and section titles.
</FONT>
<P>
<B>Intrusion Detection: Network Security beyond the Firewall</B>
<FONT SIZE="-1">
<BR>
<I>(Publisher: John Wiley & Sons, Inc.)</I>
<BR>
Author(s): Terry Escamilla
<BR>
ISBN: 0471290009
<BR>
Publication Date: 11/01/98
</FONT>
<P>
<form name="Search" method="GET" action="http://search.earthweb.com/search97/search_redir.cgi">

<INPUT TYPE="hidden" NAME="Action" VALUE="Search">
<INPUT TYPE="hidden" NAME="SearchPage" VALUE="http://search.earthweb.com/search97/samples/forms/srchdemo.htm">
<INPUT TYPE="hidden" NAME="Collection" VALUE="ITK">
<INPUT TYPE="hidden" NAME="ResultTemplate" VALUE="itk-full.hts">
<INPUT TYPE="hidden" NAME="ViewTemplate" VALUE="view.hts">

<font face="arial, helvetica" size=2><b>Search this book:</b></font><br>
<INPUT NAME="queryText" size=50 VALUE="">&nbsp;<input type="submit" name="submitbutton" value="Go!">
<INPUT type=hidden NAME="section_on" VALUE="on">
<INPUT type=hidden NAME="section" VALUE="http://www.itknowledge.com/reference/standard/0471290009/">

</form>


<!-- Empty Reference Subhead -->

<!--ISBN=0471290009//-->
<!--TITLE=Intrusion Detection: Network Security Beyond the Firewall//-->
<!--AUTHOR=Terry Escamilla//-->
<!--PUBLISHER=John Wiley & Sons, Inc.//-->
<!--IMPRINT=Wiley Computer Publishing//-->
<!--CHAPTER=9//-->
<!--PAGES=273-276//-->
<!--UNASSIGNED1//-->
<!--UNASSIGNED2//-->

<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="270-273.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="276-279.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
<P><BR></P>
<H4 ALIGN="LEFT"><A NAME="Heading13"></A><FONT COLOR="#000077">The Network IDS Is Not the Destination Node</FONT></H4>
<P>Recently, Ptacek and Newsham (1998) identified several weaknesses in intelligent network sniffers. Similar concerns about network IDSs were simultaneously identified by Paxson (1998). At the heart of the discussion is the fact that a network IDS cannot know for sure what is happening on the network nodes themselves. An inbound packet has a destination IP address for the intended recipient. The network IDS does not know for sure whether the destination node will accept a packet or discard it. To really know the behavior of the remote node, the network IDS must contain a good deal more knowledge than it does today.
</P>
<P>For example, operating systems handle fragmented packets differently. Some OSs will discard a packet if it contains overlapping sequence numbers with previously received packets. Other OSs will accept the packet and process it; thereby overlaying existing data received earlier.</P>
<P>One example given by Ptacek and Newsham is the checksum on a packet. Most systems will discard a packet with a bad checksum, but some network IDSs do not currently check this as part of packet inspection. Now that the issues have been publicly indicated, you can expect future IDS releases to include this feature. Because the IDS is <I>not</I> the real recipient of the packet itself, the IDS cannot know for sure how the destination node will really handle the packet. Many factors, such as memory limitations, determine whether a packet is dropped or processed by the intended receiver. The IDS cannot possibly know all of these variables for each node on the subnet it monitors.</P>
<P>This subtle point&#151;not knowing for sure how the destination node will respond&#151;can lead to some interesting attacks. In an <I>insertion</I> attack, an adversary will inject a packet that the IDS will accept but which the destination node will reject or drop. The IDS and the destination node are thus <I>in different states</I> because they are processing different data. A few clever hacks show how to sneak a phf (or similar) attack past current network IDSs even though they will be executed successfully on the destination machine. As a teaser to completely read the referenced papers, think about how you could send a string such as &#147;ppppphhhhhhhffffffff?rrrrmmmm *&#148;. You could send individual one-byte packets formed in a such a way that the destination node would drop all packets except those that combine into &#147;phf?rm*&#148;.</P>
<P>You also can inject SYN packets that can trick the IDS into resetting its state, even though the target node ignores the packet. When the IDS resets its state, pattern matching that was in progress is restarted; thus, losing any attacks in progress for that TCP session.</P>
<P>In an <I>evasion</I> attack the destination node accepts a packet that is ignored by the IDS. For example, the attacker could send extra packets with the same sequence number as a previous packet but with different data. The IDS might drop the packet because the sequence number was already used. The destination node (depending on the OS) would accept and process the packet, replacing a previous substring with one that turns the entire message into a hack. Many other evasion attacks are possible because of protocol problems with IP, TCP, or UDP.</P>
<P>Another problem to watch for is denial-of-service launched against the IDS itself. While sniffing network traffic, the IDS maintains a queue for incoming packets. The amount of memory that is allocated for these queues often can be configured, but it is eventually bounded by some constraint&#151;whether physical memory or virtual memory. If a hacker knows what the IDS is looking for, it&#146;s not difficult to inject a number of packets that must be processed. The IDS can run out of resources.</P>
<P>Recall that network IDSs operate in passive mode and sniff the network. They do not block packets, which is one thing that firewalls do for you. When a firewall fails, it (generally) does not let any packets through, and thus your security policy is not violated. If a network IDS fails due to resource exhaustion, your policy can be violated because the IDS does not block packets; it works by alerting you when there is a problem.</P>
<P>In this section, you&#146;ve seen a number of problems with network IDSs. Don&#146;t let this discussion give you the impression that these IDSs are weak products. No security tool is perfect. Network IDSs are critical for improving security at your site. These IDSs also are very useful for catching a number of attacks against your network. Vendors have been responsive to concerns such as those mentioned previously and have speedily added fixes in new releases.</P>
<H4 ALIGN="LEFT"><A NAME="Heading14"></A><FONT COLOR="#000077">Getting around the Encryption Problem</FONT></H4>
<P>The encryption issue is a particularly sticky one for network IDSs. It is highly likely that over time, you will see more encryption of application-level data. You need encryption for secure communications. There isn&#146;t much you can do to change the limitations on network IDSs when encryption hides the network packet content. IDS vendors do have a few alternatives, though.
</P>
<P>Instead of spelling the demise of network IDSs, encryption argues for a repositioning of the technology. If a large number of applications rely on SSL, for example, the SSL libraries could be enhanced to invoke network IDS routines <I>after</I> the packets are decrypted. <I>The added advantage is that the IDS routines also would be running on every node that uses SSL, thus providing previously unavailable opportunities for misuse detection</I>.</P>
<P>A similar approach would be to embed the network IDS routines directly in the network stack of the operating systems. As data from a socket is read by the application, the IDS routines optionally could be called to look for attacks. A socket option that each application could set would provide granular control over when to invoke the IDS routines. A system-wide switch to enable the IDS for all socket reads is another configuration possibility. The IDS routines would be running on each node with the advantage for misuse detection again.</P>
<P>Repackaging network IDSs as a set of library APIs is another possibility. As applications read data from sockets, they optionally could call the IDS routines to check for problems. This is a slight variation on the socket option suggested above. One difference is that it would be easier for a vendor to market network IDS libraries than it would be to convince a number of OS providers to embed the code. Unfortunately, if the APIs are optional, it&#146;s difficult to encourage programmers to modify existing software to take advantage of the libraries. When the IDS routines are a default option in the network stack of the OS, the solution is more transparent and easier for application programmers to use.</P><P><BR></P>
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="270-273.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="276-279.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>


<!-- all of the reference materials (books) have the footer and subfoot reveresed -->
<!-- reference_subfoot = footer -->
<!-- reference_footer = subfoot -->

<!-- BEGIN SUB FOOTER -->
		<br><br>
		</TD>
    </TR>
	</TABLE>

		
	<table width="640" border=0 cellpadding=0 cellspacing=0>
		<tr>
		<td align="left" width=135><img src="/images/white.gif" width=100 height="1" alt="" border="0"></td>
		
		
<!-- END SUB FOOTER -->

<!-- all of the books have the footer and subfoot reveresed -->
<!-- reference_subfoot = footer -->
<!-- reference_footer = subfoot -->

<!-- FOOTER -->
			
		<td width="515" align="left" bgcolor="#FFFFFF">
<font face="arial, helvetica" size="1"><b><a href="/products.html"><font color="#006666">Products</font></a>&nbsp;|&nbsp; <a href="/contactus.html"><font color="#006666">Contact Us</font></a>&nbsp;|&nbsp; <a href="/aboutus.html"><font color="#006666">About Us</font></a>&nbsp;|&nbsp; <a href="http://www.earthweb.com/corporate/privacy.html" target="_blank"><font color="#006666">Privacy</font></a> &nbsp;|&nbsp; <a href="http://www.itmarketer.com/" target="_blank"><font color="#006666">Ad Info</font></a> &nbsp;|&nbsp; <a href="/"><font color="#006666">Home</font></a></b>
		<br><br>
		
		Use of this site is subject to certain <a href="/agreement.html">Terms &amp; Conditions</a>, <a href="/copyright.html">Copyright &copy; 1996-1999 EarthWeb Inc.</a><br> 
All rights reserved.  Reproduction whole or in part in any form or medium without express written permision of EarthWeb is prohibited.</font><p>
</td>
		</tr>
</table>
</BODY>
</HTML>

<!-- END FOOTER -->