ch12.htm

Maximum Security (First Edition) 网络安全 英文版

<H2><FONT COLOR="#000077"><B>How Do I Detect a Sniffer on My Network?</B></FONT></H2>
<P>The short answer to this question is: You don't. Here lies one of the reasons
sniffers are so threatening to security. They are largely passive applications and
generate nothing. In other words, they leave no trace on the system.</P>
<P>One way to detect a sniffer is to search all current processes being run. This
isn't entirely reliable, of course, but you can at least determine whether a process
is being run from your machine. Commands differ from platform to platform in performing
this operation. Those with DOS, Windows for Workgroups, or Windows 95 might have
a problem. However, those using UNIX or Windows NT can easily obtain a list of current
processes. In UNIX, issue the following command:</P>
<PRE><FONT COLOR="#0066FF">ps -aux
</FONT></PRE>
<P>or</P>
<PRE><FONT COLOR="#0066FF">ps -augx
</FONT></PRE>
<P>This command results in a listing of all processes, who initiated those processes,
what percentage of the CPU those processes are using, what percentage of memory,
and so on. The output comes in standard table form on <TT>STDOUT</TT>. If a process
is still running, it should be listed here (unless your <TT>ps</TT> or other binaries
have been trojaned).</P>
<P>Another method is to go searching for the sniffer. There are only so many sniffers
in existence. Chances are a cracker is using a freeware version. There is a possibility
that the cracker has written his or her own. In this case, you are in trouble and
will spend much time reconciling your directories. This is a complicated procedure,
and I am unaware of a utility that does expressly this. On the UNIX platform, you
likely will have to hack a program for yourself.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>Programs like <TT>ps</TT> (in fact,
	most programs) can be hidden from the <TT>ps</TT> query by changing their <TT>argv[0]</TT>
	(their first argument) to the name of a program one that is innocuous and not so
	suspicious. <BR>
	
<HR>
</P>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B><I>Directory reconciliation</I>
	is a fancy way of saying you need to perform frequent backups (ideally, once a day).
	The trick is to hack a program that takes the list of files on each backup and compares
	them to the backup on the following day. Include a type of file field, which contains
	the information you normally glean from the <TT>file</TT> command. This command reports
	the status of the file (whether it is binary, text, sound, and so on). If a file
	in a user's directory was a compiled binary one day and a shell script the next,
	it might not necessarily mean anything is wrong, but it is worth noting. A number
	of programs can help you per-form file reconciliation and are treated in Chapter
	11, &quot;Trojans.&quot; Some of these programs are Tripwire, ATP, and Hobgoblin.
	
<HR>


</BLOCKQUOTE>

<P>Some utilities, however, can identify whether your system has been thrown into
promiscuous mode. These can at least detect whether a running sniffer would even
work under your current configuration. Nitwit.c is one such utility.
<H2><FONT COLOR="#000077"><B>What Can I Do to Foil a Sniffer?</B></FONT></H2>
<P>Foiling a sniffer attack is not a difficult task. You have quite a few choices
and what you pick will probably depend on how paranoid you truly are. The rest will
depend on cost.</P>
<P>Your main concern is probably the transmission of truly sensitive data (namely,
user IDs and passwords). Some of these cross the network in plain (or <I>clear</I>)
text and, when captured with a sniffer, are easily read. Solutions to this problem
are straightforward and cost effective.
<H3><FONT COLOR="#000077"><B>Encryption</B></FONT></H3>
<P>At various points in this book, I mention a product called Secure Shell, or <I>SSH</I>.
SSH is a protocol that provides secure communications in an application environment
such as Telnet. It is built on the client/server model, as are most protocols out
there. The official port that the SSH server binds to is 22. Connections are negotiated
using an algorithm from RSA. After the authentication procedure is complete, all
subsequent traffic is encrypted using IDEA technology. This is typically strong encryption
and is suitable for just about any nonsecret, nonclassified communication.</P>
<P>For quite some time, the original SSH has been lauded (rightly so) for being the
chief communications protocol that provided security by encrypted session. However,
that all changed in mid-1996. SSH forged an alliance with Data Fellows, and F-SSH
currently provides high-level, military-grade encryption to communication sessions.
It provides the strongest encryption available to the general public for communications
across TCP/IP.</P>
<P>If you employ F-SSH on your site, usernames and passwords become less of an issue.
To my knowledge, there have been no instances of anyone cracking such an encryption
scheme. If you employ this product, even if a sniffer is present, the value of the
information gleaned would be negligible. The hard part is getting your staff to use
it.</P>
<P>People sometimes receive new policies and authentication procedures poorly. In
short, you might have to demonstrate to your local users exactly how easy it is to
use SSH.</P>
<P>Both free and commercial versions of SSH and F-SSH exist. The free version is
a UNIX utility; commercial versions for Windows 3.11, Windows 95, and Windows NT
are available.
<H2><FONT COLOR="#000077"><B>What Are Some Other Ways to Defeat Sniffer Attacks?</B></FONT></H2>
<P>The generally accepted way to defeat sniffer attacks is to employ safe topology.
That sounds easy enough, but involves some cost.</P>
<P>Are you familiar with that puzzle game that consists of a series of numbered tiles?
The object of the game is to arrange the numbers so they appear in sequential, ascending
order using the fewest possible moves. When working with network topology (under
cost constraints by management), you are playing a game much like the tile game.</P>
<P>Here are the rules:

<UL>
	<LI>Network blocks should only trust other network blocks if there is a reason.<BR>
	<BR>
	
	<LI>The network blocks should be designed around the trust relationships between
	your staff and not your hardware needs.
</UL>

<P>That established, let's have a look. The first point is this: a network block
should be composed of only those machines that need to trust one another. These typically
belong in the same room or, at worst, within the same office. Your accounting staff,
for example, should be bunched together in some portion of the building (see Figure
12.6).</P>
<P><A NAME="06"></A><A HREF="06.htm"><B>Figure 12.6.</B></A><B><BR>
</B><I>The accounting office.</I></P>
<P>From the diagram in Figure 12.6, you can immediately see one difference in this
configuration as compared to the others earlier in this chapter. Notice that each
of the stations is hardwired to the hub. (There is no closed-circuit wrap, like you
often see in small Novell networks. I see that kind of configuration all the time
in medical and legal offices.) Furthermore, the hub is wired to a switch. The major
difference is that because the segment is hardwired in this fashion, packets can
only be sniffed within that network segment. Thus, the remaining portion of the network
(beyond the switch) is protected from sniffing activity. This technique is commonly
referred to as <I>compartmentalization</I> or <I>segmentation</I>.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>TIP:</B></FONT><B> </B>You can also use bridges or routers
	to perform this segmentation. This may be more suitable, depending upon your configuration
	and finances. In fact, an older PC or workstation can be made to act as a bridge
	or a router.<I> </I>
<HR>


</BLOCKQUOTE>

<P>In segmentation, costs rise dramatically. Suppose you have 50 departments. Does
that mean you need 50 hubs, 50 switches, and a router to tie them together? Possibly.
It depends on how paranoid you really are. If you are doing sensitive work, then
yes, you will be spending money on hardware. But consider the advantages: If an evil
accounting employee wants to plant a sniffer, he can get no more than he could by
physically tampering with his coworker's workstation. Moreover, if a sniffer is found
on one of the three stations in accounting, there are only a limited number of individuals
who could have placed it there.</P>
<P>The problem is a matter of trust. Some machines must trust one another in order
to traffic information between themselves. Your job as a system administrator is
to determine ways in which to create the fewest trust relationships possible. In
this way, you build a framework that can tell you when a sniffer is placed, where
it is, and who could have placed it.</P>
<P>The problem is, in most offices, there is no real level of trust. The average
American business is in the business of making money. Tech support is expensive and
so is the downtime to restring a network. Additionally, there can be serious costs
involved in that restringing. What if all the wiring is embedded in the walls? These
are all issues that you must consider. In legacy networks, these are real problems.</P>
<P>Also, you must consider the level of risk. What are you protecting? What are you
planning to do regarding the Internet? These are the real issues. If you intend to
connect your LAN to the Net, a firewall is not going to be enough. Relying solely
on a firewall is a bad idea because new cracking techniques are always emerging.
Are firewalls impenetrable? Vendors say yes, as long as they are properly configured.
However, think about that statement for a moment. There was a time, not long ago,
when shadowed password schemes were touted as pretty close to infallible (in spite
of the fact that everyone deep in security knew that NIS would remain a weakness
that could render the best shadowing a wet noodle). Crackers can already scan behind
a firewall and determine the services running there. That is the first and most important
step.</P>
<P>It will not be long before firewalls get cracked, so be prepared. Your first concern
should be the worst case: If an intruder cuts through your armor, how far can he
or she get? Try to think of it in terms of a path or a trajectory. Starting at your
Web server and working your way back, how deep do the various levels of trust go?
For example, the Web server probably trusts one machine, which we'll call <TT>workstation1</TT>.
How many machines does <TT>workstation1</TT> trust? How many of those machines trust
others? In other words, worst case scenario, where will the cracker finally run out
of machines to compromise?</P>
<P>Your job is to prevent that worst-case scenario from becoming a disaster. You
do so by ensuring that if an intruder places a sniffer, that sniffing activity is
confined to a very small area.</P>
<P>If I ran a large LAN connected to the Net, I would be sniffing the traffic on
it. There are products that can reliably and conveniently present the results of
such sniffing in tabular form. A good storage device, such as a Jazz drive, makes
an excellent target to save those sniffer logs.
<H2><FONT COLOR="#000077"><B>Summary</B></FONT></H2>
<P>In this chapter, you learned a bit about sniffers:

<UL>
	<LI>Sniffers capture packet traffic across a network, usually an Ethernet.<BR>
	<BR>
	
	<LI>These can be placed surreptitiously on your drives.<BR>
	<BR>
	
	<LI>A sniffer can catch all packet traffic on a particular network block (or <I>segment</I>).<BR>
	<BR>
	
	<LI>Prevention of compromise is a two-fold process: encryption and compartmentalization.<BR>
	<BR>
	
	<LI>Encrypted communications can be used to prevent the capture of passwords if a
	sniffer attack is underway.<BR>
	<BR>
	
	<LI>Detection methods are scarce because sniffers leave little trace. However, you
	can run file-reconciliation utilities to determine new files on the system.<BR>
	<BR>
	
	<LI>You can monitor processes as they occur.
</UL>

<P>I assert that you can benefit greatly by running a sniffer on your network, even
if only for a day. This will familiarize you with what a cracker is facing to implement
such an attack. Also, after you are proficient with a sniffer, you can see for yourself
what type of information can actually be gleaned from your particular network configuration.</P>
<P>Lastly, sniffer or no sniffer, trace the levels and relationships of trust on
your network. You might be surprised to find that this path extends through the larger
portion of your network for one reason or another. This becomes more complicated,
depending on how many interfaces you are running and how many protocols run on them.
For example, if your firm is running Novell in one area, AppleTalk in another, TCP/IP
in another, DECnet in another, NFS in another, and so forth, you have your job cut
out for you. Starting at any given point, how far can you travel before you reach
a trust roadblock?


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>Levels of trust and relationships
	between network segments will be examined further in Chapter 28, &quot;Spoofing Attacks.&quot;
	<I>Spoofing</I> relies almost solely on trust relationships and has little to do
	with passwords. (After all, who needs a password if two machines already trust one
	another?) 
<HR>


</BLOCKQUOTE>

<P>These considerations are all relevant to the sniffer issue. In closing, sniffers
are very powerful tools for crackers, but only if you let them be. Moreover, if you
find one on your network, do not immediately remove it. Instead, install one of your
own and find out who is pulling the strings. Successful conclusions to network break-ins
almost never begin with confrontations. They begin with stealth. You cannot go to
the halls of justice without evidence.</P>
<CENTER>
<P>
<HR>
<A HREF="../ch11/ch11.htm"><IMG SRC="../button/previous.gif" WIDTH="128" HEIGHT="28"
ALIGN="BOTTOM" ALT="Previous chapter" BORDER="0"></A><A HREF="../ch13/ch13.htm"><IMG
SRC="../button/next.gif" WIDTH="128" HEIGHT="28" ALIGN="BOTTOM" ALT="Next chapter"
BORDER="0"></A><A HREF="../index.htm"><IMG SRC="../button/contents.gif" WIDTH="128"
HEIGHT="28" ALIGN="BOTTOM" ALT="Contents" BORDER="0"></A> <BR>
<BR>
<BR>
<IMG SRC="../button/corp.gif" WIDTH="284" HEIGHT="45" ALIGN="BOTTOM" ALT="Macmillan Computer Publishing USA"
BORDER="0"></P>

<P>&#169; <A HREF="../copy.htm">Copyright</A>, Macmillan Computer Publishing. All
rights reserved.
</CENTER>


</BODY>

</HTML>