067-069.html

入侵检测的相关教程

			<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=2//-->
<!--PAGES=067-069//-->
<!--UNASSIGNED1//-->
<!--UNASSIGNED2//-->

<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="065-067.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="069-072.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
<P><BR></P>
<P><FONT SIZE="+1"><B><I>The Lure of X.509</I></B></FONT></P>
<P>A major benefit of certificates is that they are based on public-key technology. One of the problems with Kerberos is that the principals and the Kerberos server must share a secret key. No such requirement exists for the X.509 approach to authentication. Public-key cryptography takes advantage of the relationship between the public key and private key. Because the keys can be used for complementary cryptographic operations, entities in the network do not have to share a secret key to prove identity. An example will help clarify how this works.
</P>
<P>Let P<SUB>x</SUB> be the public key of user <I>X</I> and S<SUB>x</SUB> represent the secret key of the pair. To verify the identity of user <I>X</I>, <I>Y</I> chooses a random nonce <I>N</I> value and encrypts it with P<SUB>x</SUB>. <I>Y</I> then transmits &#123;N&#125;P<SUB>x</SUB> to <I>X</I>. To prove identity <I>X</I> decrypts &#123;N&#125;P<SUB>x</SUB> using S<SUB>x</SUB> and transmits this value <I>N</I> back to <I>Y</I>. Only <I>X</I> who secretly knows the mathematical inverse key S<SUB>x</SUB> for the public key P<SUB>x</SUB> could have successfully decrypted the challenge. As a final twist, if two-way authentication is required, <I>Y</I> can be challenged to prove knowledge of S<SUB>y</SUB> in a similar fashion. To improve the protocol <I>X</I> could encrypt <I>N</I> with the public key of <I>Y</I> before sending the response. Even this change is not sufficient for a complete protocol, because an attacker between <I>X</I> and <I>Y</I> can still modify the messages in transit. More detailed protocols that also provide <I>message integrity</I> are covered in Chapter 4, &#147;Traditional Network Security Approaches.&#148;</P>
<P>To see how public-key cryptography can be further utilized for establishing secure network communications, consider that the nonce value <I>N</I> can become the session key between <I>X</I> and <I>Y</I>. Not only is authentication of the entities accomplished, but they also now share a secret key for encrypting exchanged messages. Another consequence of the inverse relationship between the key pairs is that <I>Y</I> can ask <I>X</I> to digitally sign some message <I>M</I> with the secret key S<SUB>x</SUB>. At a future time, it can be shown, by decrypting <I>the digital signature</I> &#123;M&#125;S<SUB>x</SUB> with P<SUB>x</SUB> to obtain <I>M</I>, that only <I>X</I> could have provided the signature. To be precise, the digital signature is not computed as an encryption function as the notation &#123;M&#125;S<SUB>x</SUB> implies. Rather, the signature is normally derived with a cryptographic hash algorithm.</P>
<P><FONT SIZE="+1"><B><I>Contents of an X.509 Certificate</I></B></FONT></P>
<P>The X.500 standard defines a naming syntax for a universal directory structure that can be used to store information about important entities in a network. An X.500 name consists of several <I>attribute-value</I> pairs. The syntax of a <I>distinguished name</I> uniquely identifying an entity, such as a user, would like something like the following:</P>
<!-- CODE SNIP //-->
<PRE>
C=US, O=IBM, OU=&#147;Software Security&#148;, CN=&#147;John Doe&#148;
</PRE>
<!-- END CODE SNIP //-->
<P>Names of entities or objects are derived in a hierarchical fashion. Because the standards are international, different portions of the naming tree are assigned to various registration authorities who are responsible for further assigning subtrees to other authorities. In the example, the root of the naming tree is the attribute <I>C</I> representing the <I>country</I>. Other attributes are <I>O</I> for <I>organization</I>, <I>OU</I> for <I>organizational unit</I>, and <I>CN</I> for <I>common name</I>. Internally in a program, the representation of a distinguished name is much more complex, and like Kerberos V5, the naming is based on ASN.1 data types. For the purposes of this discussion, though, all you need to know is that each digital certificate is created for a particular entity identified by the distinguished name.</P>
<P>The certificate also includes the public key of its owner, an expiration value indicating when the certificate is no longer valid, a serial number, and other administrative fields. An important field appearing in the certificate is the digital signature of the <I>Certificate Authority</I> (CA) which issued the certificate. The signature could have been computed with any one of several cryptographic hash algorithms, so the certificate also includes information identifying which algorithm was chosen.</P>
<P><FONT SIZE="+1"><B><I>Certificate Authorities</I></B></FONT></P>
<P>Why are certificates issued by a CA? Although X.509 certificates simplify the process of distributing shared session keys and authenticating users, a trusted third-party authentication server is still needed for strict verification of identities. Certificates are designed to be public and published in a way that makes them easily accessible to other network entities. In some environments, the data store or directory used to publish certificates might be tightly controlled. Also, two users wanting to communicate over an insecure network may already trust each other and gladly exchange certificates without hesitation. However, in public networks, you should be concerned about whether a certificate is genuine. Products are readily available for creating X.509 certificates, and any user may be able to advertise a certificate claiming to be another party. Only by verifying the authenticity of the X.509 certificate can one be sure that impersonation is not a threat.
</P>
<P>Various companies including IBM and Verisign currently offer CA services. The belief is that if a certificate is generated and signed by a respectable authority, users of the certificate can trust its authenticity. The CA generates the digital signature by using its secret key and then publishing its public key. The signature can be verified because of the relationship between the secret and public keys of the CA. The important points include the following:</P>
<DL>
<DD><B>&#149;</B>&nbsp;&nbsp;<I>X</I> wanting to communicate with <I>Y</I> obtains <I>Y</I>&#146;s X.509 certificate.
<DD><B>&#149;</B>&nbsp;&nbsp;<I>X</I> verifies the authenticity of the certificate by verifying digital signature of the CA that issued it.
<DD><B>&#149;</B>&nbsp;&nbsp;When satisfied that the signature is legitimate, <I>X</I> can use the contents of <I>Y</I>&#146;s certificate to communicate securely.
</DL>
<P>You are not limited to having a single X.509 certificate. Indeed, you can obtain multiple certificates from different CAs and decide where to publish each one.
</P>
<P>If the secret key for a user is compromised in some way, the CA must <I>revoke</I> the corresponding certificates. Each CA must maintain a <I>certificate revocation list</I> (CRL). Before a certificate can be employed as the basis for secure communications, it should be compared to the CRL at the CA to verify validity. Creating a usable public key infrastructure, which includes providing CAs, is a major challenge facing many companies and governments today.</P><P><BR></P>
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="065-067.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="069-072.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 -->