ch11.htm

来自「Maximum Security (First Edition) 网络安全 英文」· HTM 代码 · 共 1,114 行 · 第 1/4 页

<P>For reasons that must now seem obvious, the size of the file is also a poor index
by which to measure its alteration. So, to recount: Date, date of last access, time,
and size are all indexes without real meaning. None of these alone is suitable for
determining the integrity of a file. In each, there is some flaw--usually inherent
to the platform--that makes these values easy to alter. Thus, generating a massive
database of all files and their respective values (time, size, date, or alteration)
has only very limited value:

<DL>
	<DD>...a checklist is one form of this database for a UNIX system. The file content
	themselves are not usually saved as this would require too much disk space. Instead,
	a checklist would contain a set of values generated from the original file--usually
	including the length, time of last modification, and owner. The checklist is periodically
	regenerated and compared against the save copies, with discrepancies noted. However...changes
	may be made to the contents of UNIX files without any of these values changing from
	the stored values; in particular, a user gaining access to the root account may modify
	the raw disk to alter the saved data without it showing in the checklist.
</DL>

<P>There are other indexes, such as checksums, that one can check; these are far
better indexes, but also not entirely reliable. In the checksum system, the data
elements of a file are added together and run through an algorithm. The resulting
number is a <I>checksum</I>, a type of signature for that file (bar-code readers
sometimes use checksums in their scan process). On the SunOS platform, one can review
the checksum of a particular file using the utility sum. sum calculates (and prints
to <TT>STDOUT</TT> or other specified mediums) the checksums of files provided on
the argument line.</P>
<P>Although checksums are more reliable than time, date, or last date of modification,
these too can be tampered with. Most system administrators suggest that if you rely
on a checksum system, your checksum list should be kept on a separate server or even
a separate medium, accessible only by root and other trusted users. In any event,
checksums work nicely for checking the integrity of a file transferred, for example,
from point A to point B, but that is the extent of it.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>Users who have performed direct
	file transfers using communication packages such as Qmodem, Telix, Closeup, MTEZ,
	or others will remember that these programs sometimes perform checksum or CRC checks
	as the transfers occur. For each file transferred, the file is checked for integrity.
	This reduces--but does not eliminate--the likelihood of a damaged file at the destination.
	If the file proves to be damaged or flawed, the transfer process may begin again.
	When dealing with sophisticated attacks against file integrity, however, this technique
	is insufficient.<BR>
	
<HR>
</P>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>Tutorials about defeating
	checksum systems are scattered across the Internet. Most are related to the development
	of viruses (many virus-checking utilities use checksum analysis to identify virus
	activity). A collection of such papers (all of which are underground) can be found
	at <A HREF="http://www.pipo.com/guillermito/darkweb/news.html"><TT>http://www.pipo.com/guillermito/darkweb/news.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<H3><FONT COLOR="#000077"><B>MD5</B></FONT></H3>
<P>You're probably wondering whether any technique is sufficient. I am happy to report
that there is such a technique. It involves calculating the <I>digital fingerprint</I>,
or signature, for each file. This is done utilizing various algorithms. A family
of algorithms, called the <I>MD series</I>, is used for this purpose. One of the
most popular implementations is a system called <I>MD5</I>.</P>
<P>MD5 is a utility that can generate a digital signature of a file. MD5 belongs
to a family of one-way hash functions called <I>message digest</I> <I>algorithms</I>.
The MD5 system is defined in RFC 1321. Concisely stated:

<DL>
	<DD>The algorithm takes as input a message of arbitrary length and produces as output
	a 128-bit &quot;fingerprint&quot; or &quot;message digest&quot; of the input. It
	is conjectured that it is computationally infeasible to produce two messages having
	the same message digest, or to produce any message having a given prespecified target
	message digest. The MD5 algorithm is intended for digital signature applications,
	where a large file must be &quot;compressed&quot; in a secure manner before being
	encrypted with a private (secret) key under a public-key cryptosystem such as RSA.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>RFC 1321 is located at
	<A HREF="http://www.freesoft.org/Connected/RFC/1321/1.html"><TT>http://www.freesoft.org/Connected/RFC/1321/1.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>When one runs a file through an MD5 implementation, the signature emerges as a
32-character value. It looks like this:</P>
<PRE><FONT COLOR="#0066FF">2d50b2bffb537cc4e637dd1f07a187f4
</FONT></PRE>
<P>Many sites that distribute security fixes for the UNIX operating system employ
this technique. Thus, as you browse their directories, you can examine the original
digital signature of each file. If, upon downloading that file, you find that the
signature is different, there is a 99.9% chance that something is terribly amiss.</P>
<P>MD5 performs a one-way hash function. You may be familiar with these operations
from other forms of encryption, including those used to encrypt password files.</P>
<P>Some very extreme security programs use MD4 and MD5 algorithms. One such program
is S/Key, which is a registered trademark of Bell Laboratories. S/Key implements
a one-time password scheme. One-time passwords are nearly unbreakable. S/Key is used
primarily for remote logins and to offer advanced security along those channels of
communication (as opposed to using little or no security by initiating a normal,
garden-variety Telnet or Rlogin session). The process works as described in &quot;S/Key
Overview&quot;<I> </I>(author unknown):

<DL>
	<DD>S/Key uses either MD4 or MD5 (one-way hashing algorithms developed by Ron Rivest)
	to implement a one-time password scheme. In this system, passwords are sent cleartext
	over the network; however, after a password has been used, it is no longer useful
	to the eavesdropper. The biggest advantage of S/Key is that it protects against eavesdroppers
	without modification of client software and only marginal inconvenience to the users.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>Read &quot;S/Key Overview&quot;
	at <A HREF="http://medg.lcs.mit.edu/people/wwinston/skey-overview.html"><TT>http://medg.lcs.mit.edu/people/wwinston/skey-overview.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>With or without MD5, object reconciliation is a complex process. True, on a single
workstation with limited resources, one could technically reconcile each file and
directory by hand (I would not recommend this if you want to preserve your sanity).
However, in larger networked environments, this is simply impossible. So, various
utilities have been designed to cope with this problem. The most celebrated of these
is a product aptly named <I>TripWire</I>.
<H4><FONT COLOR="#000077"><B>TripWire</B></FONT></H4>
<P>TripWire (written in 1992) is a comprehensive system-integrity tool. It is written
in classic Kernhigan and Ritchie C (you will remember from Chapter 7, &quot;Birth
of a Network: The Internet,&quot; that I discussed the portability advantages of
C; it was this portability that influenced the choice of language for the authors
of TripWire).</P>
<P>TripWire is well designed, easily understood, and implemented with minimal difficulty.
The system reads your environment from a configuration file. That file contains all
filemasks (the types of files that you want to monitor). This system can be quite
incisive. For example, you can specify what changes can be made to files of a given
class without TripWire reporting the change (or, for more wholesale monitoring of
the system, you can simply flag a directory as the target of the monitoring process).
The original values (digital signatures) for these files are kept within a database
file. That database file (simple ASCII) is accessed whenever a signature needs to
be calculated. Hash functions included in the distribution are</P>

<UL>
	<LI><FONT COLOR="#000000">MD5</FONT>
	<LI><FONT COLOR="#000000">MD4</FONT>
	<LI><FONT COLOR="#000000">CRC32</FONT>
	<LI><FONT COLOR="#000000">MD2</FONT>
	<LI><FONT COLOR="#000000">Snefru (Xerox secure hash function)</FONT>
	<LI><FONT COLOR="#000000">SHA (The NIST secure hash algorithm)</FONT>
</UL>

<PRE></PRE>
<P>It is reported that by default, MD5 and the Xerox secure hash function are both
used to generate values for all files. However, TripWire documentation suggests that
all of these functions can be applied to any, a portion of, or all files.</P>
<P>Altogether, TripWire is a very well-crafted package with many options.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>TripWire (and papers
	on usage and design) can be found at <A HREF="ftp://coast.cs.purdue.edu/pub/tools/unix/TripWire/"><TT>ftp://coast.cs.purdue.edu/pub/tools/unix/TripWire/</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>TripWire is a magnificent tool, but there are some security issues. One such issue
relates to the database of values that is generated and maintained. Essentially,
it breaks down to the same issue discussed earlier: Databases can be altered by a
cracker. Therefore, it is recommended that some measure be undertaken to secure that
database. From the beginning, the tool's authors were well aware of this:

<DL>
	<DD>The database used by the integrity checker should be protected from unauthorized
	modifications; an intruder who can change the database can subvert the entire integrity
	checking scheme.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>Before you use TripWire,
	read &quot;The Design and Implementation of TripWire: A File System Integrity Checker&quot;
	by Gene H. Kim and Eugene H. Spafford. It is located at <A HREF="ftp://ftp.cs.purdue.edu/pub/spaf/security/Tripwire.PS.Z"><TT>ftp://ftp.cs.purdue.edu/pub/spaf/security/Tripwire.PS.Z</TT></A>.<TT>
	</TT>
<HR>


</BLOCKQUOTE>

<P>One method of protecting the database is extremely sound: Store the database on
read-only media. This virtually eliminates any possibility of tampering. In fact,
this technique is becoming a strong trend in security. In Chapter 21, &quot;Plan
9 from Bell Labs,&quot; you will learn that the folks at Bell Labs now run their
logs to one-time write or read-only media. Moreover, in a recent security consult,
I was surprised to find that the clients (who were only just learning about security)
were very keen on read-only media for their Web-based databases. These databases
were quite sensitive and the information, if changed, could be potentially threatening
to the security of other systems.</P>
<P>Kim and Spafford (authors of TripWire) also suggest that the database be protected
in this manner, though they concede that this could present some practical, procedural
problems. Much depends upon how often the database will be updated, how large it
is, and so forth. Certainly, if you are implementing TripWire on a wide scale (and
in its maximum application), the maintenance of a read-only database could be formidable.
Again, this breaks down to the level of risk and the need for increased or perhaps
optimum security.
<H4><FONT COLOR="#000077"><B>TAMU</B></FONT></H4>
<P>The TAMU suite (from Texas A&amp;M University, of course) is a collection of tools
that will greatly enhance the security of a UNIX box. These tools were created in
response to a very real problem. As explained in the summary that accompanies the
distribution:

<DL>
	<DD>Texas A&amp;M University UNIX computers recently came under extensive attack
	from a coordinated group of Internet crackers. This paper presents an overview of
	the problem and our responses, which included the development of policies, procedures,
	and sdoels to protect university computers. The tools developed include `drawbridge',
	an advanced Internet filter bridge, `tiger scripts', extremely powerful but easy
	to use programs for securing individual hosts, and `xvefc', (XView Etherfind Client),
	a powerful distributed network monitor.
</DL>

<P>Contained within the TAMU distribution is a package of <I>tiger scripts</I>, which
form the basis of the distribution's digital signature authentication. As the above-mentioned
summary explains:

<DL>
	<DD>The checking performed covers a wide range of items, including items identified
	in CERT announcements, and items observed in the recent intrusions. The scripts use
	Xerox's cryptographic checksum programs to check for both modified system binaries
	(possible trap doors/trojans), as well as for the presence of required security related
	patches.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>Xerox hash.2.5a can be
	found on the PARC ftp site (<A HREF="ftp://parcftp.xerox.com/pub/hash/hash2.5a/"><TT>ftp://parcftp.xerox.com/pub/hash/hash2.5a/</TT></A>).
	This package is generally referred to as the <I>Xerox Secure Hash Function</I>, and
	the distribution is named after Snefru, a pharaoh of ancient Egypt. The distribution
	at the aforementioned site was released in 1990, and source is included. For those
	interested in hacking the Snefru distribution, the material here is invaluable. (Also,
	refer to a sister document about the distribution and a more comprehensive explanation:
	<I>A Fast Software One Way Hash Function </I>by Ralph C. Merkle (there is a full
	citation at the end of this chapter in the Resources section). 
<HR>


</BLOCKQUOTE>

<P>The TAMU distribution is comprehensive and can be used to solve several security
problems, over and above searching for trojans. It includes a network monitor and
packet filter.


<BLOCKQUOTE>
	<P>