?? 194-198.html
字號:
<!-- 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=""> <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=6//-->
<!--PAGES=194-198//-->
<!--UNASSIGNED1//-->
<!--UNASSIGNED2//-->
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="191-194.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="198-201.html">Next</A></TD>
</TR>
</TABLE>
</CENTER>
<P><BR></P>
<P>Also, no reason exists to prevent the routines that make up products such as RealSecure and NetRanger to be embedded in the firewall logic. Sure, all of these products drag along their own systems management frameworks for configuration and event reporting. The core IDS logic could be easily combined with a firewall to add network IDS capabilities. Whether this is practical is another question altogether. Would you rather pay the performance penalty of adding IDS code to the firewall packet filters, or would you rather put an IDS sniffer inside the secure network immediately after the firewall? Different sites would prefer one approach over the other.
</P>
<H4 ALIGN="LEFT"><A NAME="Heading10"></A><FONT COLOR="#000077">Relying on Others for Data</FONT></H4>
<P>If your IDS philosophy is to rely on data sources provided by others, you do not pay performance penalties for intercept or replacing calls. Depending on another software component for data has its drawbacks, though:
</P>
<DL>
<DD><B>•</B> The data is emitted by the component after the event has occurred.
<DD><B>•</B> The amount of data provided may not be sufficient for the IDS model. You might not get the UID of the offending process, for example.
<DD><B>•</B> The events you are interested might not be reported by the system.
<DD><B>•</B> At some point, the net value of generating data decreases as the amount of resources a system consumes emitting the data increases. In other words, if the system is spending most of its time reporting events instead of running the payroll, you should question the value of your approach.
<DD><B>•</B> The component emitting the data can change the format of log records. This change happens often enough so that IDS vendors are required to modify their software to keep up with OS or application changes.
<DD><B>•</B> The data may not be regularly reported for that system.
</DL>
<P>This last point is particularly important. System, application, and network logging can be an expensive operation. If a customer already is accustomed to storing large log files, rolling an IDS into the environment is not going to add additional requirements. If a customer does not regularly run the auditing subsystem, some convincing is necessary if the IDS relies on the audit trails. OS auditing can generate a fairly large number of records, although all of these records do not need to be stored if the IDS runs in real time, or if the environment does not require post investigative analysis of system audit logs.
</P>
<H3><A NAME="Heading11"></A><FONT COLOR="#000077">System Data Sources</FONT></H3>
<P>For monitoring systems, the two main sources of information about OS activity are <I>syslog</I> and the <I>audit trail</I>. In NT, the audit trail is called the <I>event log</I>. Audit log and audit trail are used interchangeably.</P>
<H4 ALIGN="LEFT"><A NAME="Heading12"></A><FONT COLOR="#000077">syslog</FONT></H4>
<P>UNIX provides a common service for logging events called <I>syslog</I>. The syslogd daemon supports logging across systems, relying on IP address authentication for accepting remote log entries. By far, the more common approach is for processes to create syslog record entries and call the OS interfaces to log the event to the local syslogd daemon. The syslog configuration file controls whether events are reported to the console, a file, or both. Events from syslog also can be piped to other processes.</P>
<P>No commonly agreed upon standards exist for the format of messages logged to syslog. The record format consists of some header fields including the following:</P>
<DL>
<DD><B>•</B> name of the logging program
<DD><B>•</B> priority
<DD><B>•</B> facility generating the message
<DD><B>•</B> text of the message itself
</DL>
<P>The priorities for syslog in decreasing order of severity are as follows:
</P>
<DL>
<DD><B>•</B> emer(gency)
<DD><B>•</B> alert
<DD><B>•</B> crit(ical)
<DD><B>•</B> err(or)
<DD><B>•</B> warning
<DD><B>•</B> notice
<DD><B>•</B> info
<DD><B>•</B> debug
<P>Facilities provide a convenient way of indicating that the message came from a particular component of the OS. Common facility definitions include the following:
</P>
<DL>
<DD><B>•</B> kern(el)
<DD><B>•</B> user (user processes)
<DD><B>•</B> mail
<DD><B>•</B> lpr (line printer)
<DD><B>•</B> auth(orization subsystem)
<DD><B>•</B> daemon (a system daemon)
<DD><B>•</B> news
<DD><B>•</B> uucp
<DD><B>•</B> local<I>0..n</I>
</DL>
<P>The syslog configuration file contains entries of the following form with wildcards supported in each of the two fields of the first parameter:
</P>
<!-- CODE SNIP //-->
<PRE>
facility.priority [TAB] action
</PRE>
<!-- END CODE SNIP //-->
<P>One or more tab characters must separate the first parameter from the action. Possible actions are as follow:
</P>
<DL>
<DD><B>•</B> A destination log filename
<DD><B>•</B> A user name, list of names to which the message is mailed (<SUP>*</SUP> means to all logged in users)
<DD><B>•</B> The form @hostname that identifies the remote syslogd to which the message should be sent
<DD><B>•</B> The pipe character “|” followed by a program name
</DL>
<P>The syslog daemon listens on UDP port 514 by default and accepts unauthenticated datagrams from any system. Therefore, the syslog daemon is not to be run across an untrusted network. Also, syslogd will accept messages from any program. It’s possible for a user program to emit <I>any</I> message onto the console.</P>
<P>Quite a bit of useful information about system behavior is available from syslog. Important information that an IDS looks for includes the following:</P>
<DL>
<DD><B>•</B> Failed and successful login events
<DD><B>•</B> Failed and successful su events
<DD><B>•</B> Password changes
<DD><B>•</B> System reboots
</DL>
<P>For many people, the amount of information provided by syslog is sufficient for watching their systems. However, activities are logged into other files. The UNIX OS also emits other useful logs including the following:
</P>
<DL>
<DD><B>•</B> <I>sulog</I> that shows the use of the su command
<DD><B>•</B> <I>utmp</I> recording each current login session
<DD><B>•</B> <I>wtmp</I> in which login, logout, shutdown, and restart events are written
<DD><B>•</B> <I>lastlog</I> in which the most recent successful and unsuccessful login events are recorded for each user
<DD><B>•</B> A log file, dependent on the OS, in which bad login attempts are kept (/etc/security/failedlogin for AIX)
<DD><B>•</B> Accounting files
</DL>
<P>ITA also looks at accounting files for evidence of intrusions. Accounting files are designed for charge back systems. Therefore, their entries include information such as which command a user ran, how much CPU time the command consumed, whether the user was a privileged user, whether the command ran as the result of a fork() operation, and the time the process executed. Important information you do <I>not</I> get from accounting logs is as follows:</P>
<DL>
<DD><B>•</B> The full path name of the program executed
<DD><B>•</B> The arguments passed to the program
</DL>
<P><BR></P>
<CENTER>
<TABLE BORDER>
<TR>
<TD><A HREF="191-194.html">Previous</A></TD>
<TD><A HREF="../ewtoc.html">Table of Contents</A></TD>
<TD><A HREF="198-201.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> | <a href="/contactus.html"><font color="#006666">Contact Us</font></a> | <a href="/aboutus.html"><font color="#006666">About Us</font></a> | <a href="http://www.earthweb.com/corporate/privacy.html" target="_blank"><font color="#006666">Privacy</font></a> | <a href="http://www.itmarketer.com/" target="_blank"><font color="#006666">Ad Info</font></a> | <a href="/"><font color="#006666">Home</font></a></b>
<br><br>
Use of this site is subject to certain <a href="/agreement.html">Terms & Conditions</a>, <a href="/copyright.html">Copyright © 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 -->
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -