ch06.htm

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

	Moreover, as you might guess, sniffers can pose a tremendous security threat. You
	will examine sniffers in Chapter 12, "Sniffers." 
<HR>


</BLOCKQUOTE>

<P>Important network-level protocols include</P>

<UL>
	<LI>The Address Resolution Protocol (ARP)
	<LI>The Internet Control Message Protocol (ICMP)
	<LI>The Internet Protocol (IP)
	<LI>The Transmission Control Protocol (TCP)
</UL>

<P>I will briefly examine each, offering only an overview.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>For more comprehensive
	information about protocols (or the stack in general), I highly recommend <I>Teach
	Yourself TCP/IP in 14 Days </I>by Timothy Parker, Ph.D (Sams Publishing). 
<HR>


</BLOCKQUOTE>

<H4><FONT COLOR="#000077"><B>The Address Resolution Protocol</B></FONT></H4>
<P>The Address Resolution Protocol (ARP) serves the critical purpose of mapping Internet
addresses into physical addresses. This is vital in routing information across the
Internet. Before a message (or other data) is sent, it is packaged into IP packets,
or blocks of information suitably formatted for Internet transport. These contain
the numeric Internet (IP) address of both the originating and destination machines.
Before this package can leave the originating computer, however, the hardware address
of the recipient (destination) must be discovered. (Hardware addresses differ from
Internet addresses.) This is where ARP makes its debut.</P>
<P>An ARP request message is broadcast on the subnet. This request is received by
a router that replies with the requested hardware address. This reply is caught by
the originating machine and the transfer process can begin.</P>
<P>ARP's design includes a cache. To understand the ARP cache concept, consider this:
Most modern HTML browsers (such as Netscape Navigator or Microsoft's Internet Explorer)
utilize a cache. This cache is a portion of the disk (or memory) in which elements
from often-visited Web pages are stored (such as buttons, headers, and common graphics).
This is logical because when you return to those pages, these tidbits don't have
to be reloaded from the remote machine. They will load much more quickly if they
are in your local cache.</P>
<P>Similarly, ARP implementations include a cache. In this manner, hardware addresses
of remote machines or networks are remembered, and this memory obviates the need
to conduct subsequent ARP queries on them. This saves time and network resources.</P>
<P>Can you guess what type of security risks might be involved in maintaining such
an ARP cache? At this stage, it is not particularly important. However, address caching
(not only in ARP but in all instances) does indeed pose a unique security risk. If
such address-location entries are stored, it makes it easier for a cracker to forge
a connection from a remote machine, <I>claiming</I> to hail from one of the cached
addresses.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>Readers seeking in-depth
	information on ARP should see RFC 826 (<A HREF="http://www.freesoft.org/Connected/RFC/826"><TT>http://www.freesoft.org/Connected/RFC/826</TT></A>).<BR>
	
<HR>

<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>Another good reference
	for information on ARP is Margaret K. Johnson's piece about details of TCP/IP (excerpts
	from <I>Microsoft LAN Manager TCP/IP Protocol</I>) (<A HREF="http://www.alexia.net.au/~www/yendor/internetinfo/index.html"><TT>http://www.alexia.net.au/~www/yendor/internetinfo/index.html</TT></A>).
	
<HR>


</BLOCKQUOTE>

<H3><FONT COLOR="#000077"><B>The Internet Control Message Protocol</B></FONT></H3>
<P>The Internet Control Message Protocol handles error and control messages that
are passed between two (or more) computers or hosts during the transfer process.
It allows those hosts to share that information. In this respect, ICMP is critical
for diagnosis of network problems. Examples of diagnostic information gathered through
ICMP include</P>

<UL>
	<LI>When a host is down
	<LI>When a gateway is congested or inoperable
	<LI>Other failures on a network
</UL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>TIP:</B></FONT><B> </B>Perhaps the most widely known ICMP
	implementation involves a network utility called <I>ping</I>. Ping is often used
	to determine whether a remote machine is alive. Ping's method of operation is simple:
	When the user pings a remote machine, packets are forwarded from the user's machine
	to the remote host. These packets are then echoed back to the user's machine. If
	no echoed packets are received at the user's end, the ping program usually generates
	an error message indicating that the remote host is down. 
<HR>
</P>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>I urge those readers
	seeking in-depth information about ICMP to examine RFC 792 (<A HREF="http://sunsite.auc.dk/RFC/rfc/rfc792.html"><TT>http://sunsite.auc.dk/RFC/rfc/rfc792.html</TT></A>).
	
<HR>


</BLOCKQUOTE>

<H3><FONT COLOR="#000077"><B>The Internet Protocol</B></FONT></H3>
<P>IP belongs to the network layer. The Internet Protocol provides packet delivery
for all protocols within the TCP/IP suite. Thus, IP is the heart of the incredible
process by which data traverses the Internet. To explore this process, I have drafted
a small model of an IP datagram (see Figure 6.2).</P>
<P><A NAME="02"></A><A HREF="02.htm"><B>Figure 6.2.</B></A><B><BR>
</B><I>The IP datagram.</I></P>
<P>As illustrated, an IP datagram is composed of several parts. The first part, the
<I>header</I>, is composed of miscellaneous information, including originating and
destination IP address. Together, these elements form a complete header. The remaining
portion of a datagram contains whatever data is then being sent.</P>
<P>The amazing thing about IP is this: If IP datagrams encounter networks that require
smaller packages, the datagrams bust apart to accommodate the recipient network.
Thus, these datagrams can fragment during a journey and later be reassembled properly
(even if they do not arrive in the same sequence in which they were sent) at their
destination.</P>
<P>Even further information is contained within an IP datagram. Some of that information
may include identification of the protocol being used, a header checksum, and a time-to-live
specification. This specification is a numeric value. While the datagram is traveling
the void, this numeric value is constantly being decremented. When that value finally
reaches a zero state, the datagram dies. Many types of packets have time-to-live
limitations. Some network utilities (such as Traceroute) utilize the time-to-live
field as a marker in diagnostic routines.</P>
<P>In closing, IP's function can be reduced to this: providing packet delivery over
the Internet. As you can see, that packet delivery is complex in its implementation.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>I refer readers seeking
	in-depth information on Internet protocol to RFC 760 (<A HREF="http://sunsite.auc.dk/RFC/rfc/rfc760.html"><TT>http://sunsite.auc.dk/RFC/rfc/rfc760.html</TT></A>).
	
<HR>


</BLOCKQUOTE>

<H3><FONT COLOR="#000077"><B>The Transmission Control Protocol</B></FONT></H3>
<P>The Transmission Control Protocol is the chief protocol employed on the Internet.
It facilitates such mission-critical tasks as file transfers and remote sessions.
TCP accomplishes these tasks through a method called <I>reliable</I> data transfer.
In this respect, TCP differs from other protocols within the suite. In <I>unreliable</I>
delivery, you have no guarantee that the data will arrive in a perfect state. In
contrast, TCP provides what is sometimes referred to as <I>reliable stream delivery</I>.
This reliable stream delivery ensures that the data arrives in the same sequence
and state in which it was sent.</P>
<P>The TCP system relies on a virtual circuit that is established between the requesting
machine and its target. This circuit is opened via a three-part process, often referred
to as the <I>three-part handshake</I>. The process typically follows the pattern
illustrated in Figure 6.3.</P>
<P><A NAME="03"></A><A HREF="03.htm"><B>Figure 6.3.</B></A><B><BR>
</B><I>The TCP/IP three-way handshake.</I></P>
<P>After the circuit is open, data can simultaneously travel in both directions.
This results in what is sometimes called a <I>full-duplex transmission path</I>.
Full-duplex transmission allows data to travel to both machines at the same time.
In this way, while a file transfer (or other remote session) is underway, any errors
that arise can be forwarded to the requesting machine.</P>
<P>TCP also provides extensive error-checking capabilities. For each block of data
sent, a numeric value is generated. The two machines identify each transferred block
using this numeric value. For each block successfully transferred, the receiving
host sends a message to the sender that the transfer was clean. Conversely, if the
transfer is unsuccessful, two things may occur:</P>

<UL>
	<LI>The requesting machine receives error information
	<LI>The requesting machine receives nothing
</UL>

<P>When an error is received, the data is retransmitted unless the error is fatal,
in which case the transmission is usually halted. A typical example of a fatal error
would be if the connection is dropped. Thus, the transfer is halted for no packets.</P>
<P>Similarly, if no confirmation is received within a specified time period, the
information is also retransmitted. This process is repeated as many times as necessary
to complete the transfer or remote session.</P>
<P>You have examined how the data is transported when a connect request is made.
It is now time to examine what happens when that request reaches its destination.
Each time one machine requests a connection to another, it specifies a particular
destination. In the general sense, this destination is expressed as the Internet
(IP) address and the hardware address of the target machine. However, even more detailed
than this, the requesting machine specifies the application it is trying to reach
at the destination. This involves two elements:</P>

<UL>
	<LI>A program called inetd
	<LI>A system based on ports
</UL>

<H3><FONT COLOR="#000077"><B>inetd: The Mother of All Daemons</B></FONT></H3>
<P>Before you explore the inetd program, I want to briefly define daemons. This will
help you more easily understand the inetd program.</P>
<P><I>Daemons</I> are programs that continuously listen for other processes (in this
case, the process listened for is a connection request). Daemons loosely resemble
<I>terminate and stay resident</I> (TSR) programs in the Microsoft platform. These
programs remain alive at all times, constantly listening for a particular event.
When that event finally occurs, the TSR undertakes some action.</P>
<P>inetd is a very special daemon. It has been called many things, including the
<I>super-server</I> or <I>granddaddy of all processes</I>. This is because inetd
is the main daemon running on a UNIX machine. It is also an ingenious tool.</P>
<P>Common sense tells you that running a dozen or more daemon processes could eat
up machine resources. So rather than do that, why not create one daemon that could
listen for all the others? That is what inetd does. It listens for connection requests
from the void. When it receives such a request, it evaluates it. This evaluation
seeks to determine one thing only: What service does the requesting machine want?
For example, does it want FTP? If so, inetd starts the FTP server process. The FTP
server can then process the request from the void. At that point, a file transfer
can begin. This all happens within the space of a second or so.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>TIP:</B></FONT><B> </B>inetd isn't just for UNIX anymore.
	For example, Hummingbird Communications has developed (as part of its Exceed 5 product
	line) a version of inetd for use on any platform that runs Microsoft Windows or OS/2.
	There are also non- commercial versions of inetd, written by students and other software
	enthusiasts. One such distribution is available from TFS software and can be found
	at <A HREF="http://www.trumpton.demon.co.uk/software/inetd.html"><TT>http://www.trumpton.demon.co.uk/software/inetd.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>In general, inetd is started at boot time and remains resident (in a listening
state) until the machine is turned off or until the root operator expressly terminates
that process.</P>
<P>The behavior of inetd is generally controlled from a file called <TT>inetd.conf</TT>,
located in the <TT>/etc</TT> directory on most UNIX platforms. The <TT>inetd.conf</TT>
file is used to specify what services will be called by inetd. Such services might
include FTP, Telnet, SMTP, TFTP, Finger, Systat, Netstat, or any other processes
that you specify.
<H3><FONT COLOR="#000077"><B>The Ports</B></FONT></H3>
<P>Many TCP/IP programs can be initiated over the Internet. Most of these are client/server
oriented. As each connection request is received, inetd starts a server program,
which then communicates with the requesting client machine.</P>
<P>To facilitate this process, each application (FTP or Telnet, for example) is assigned
a unique address. This address is called a <I>port</I>. The application in question
is bound to that particular port and, when any connection request is made to that
port, the corresponding application is launched (inetd is the program that launches
it).</P>
<P>There are thousands of ports on the average Internet server. For purposes of convenience
and efficiency, a standard framework has been developed for port assignment. (In
other words, although a system administrator can bind services to the ports of his
or her choice, services are generally bound to recognized ports. These are commonly
referred to as <I>well-known ports</I>.)</P>
<P>Please peruse Table 6.2 for some commonly recognized ports and the applications
typically bound to them.
<H4><FONT COLOR="#000077"><B>Table 6.2. Common ports and their corresponding services
or applications.</B></FONT></H4>
<P>
<TABLE BORDER="1">
	<TR ALIGN="LEFT" rowspan="1">
		<TD ALIGN="LEFT" VALIGN="TOP"><I>Service or Application</I></TD>
		<TD ALIGN="LEFT" VALIGN="TOP"><I>Port</I></TD>
	</TR>
	<TR ALIGN="LEFT" rowspan="1">
		<TD ALIGN="LEFT" VALIGN="TOP">File Transfer Protocol (FTP)</TD>
		<TD ALIGN="LEFT" VALIGN="TOP">21</TD>