ch13.htm

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

systems. (The exceptions are reportedly Ultrix and the NeXT platform.) One nice amenity
for Linux users is that a pre-compiled binary comes with the distribution. The standard
distribution of MasterPlan is available at

<UL>
	<LI><A HREF="ftp://ftp.netspace.org/pub/Software/Unix/masterplan.tar.Z"><TT>ftp://ftp.netspace.org/pub/Software/Unix/masterplan.tar.Z</TT></A>
</UL>

<P>The Linux compiled version is available at

<UL>
	<LI><A HREF="ftp://ftp.netspace.org/pub/Software/Unix/masterplan-linux.tar.Z"><TT>ftp://ftp.netspace.org/pub/Software/Unix/masterplan-linux.tar.Z</TT></A>
</UL>

<P>As you've now seen, the finger utility is dangerous and revealing. More and more
sites are now disabling finger services, at least with respect to external queries.
For various reasons, however, many providers simply do not bother to shut it down.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>TIP:</B></FONT><B> </B>If you want to see an example of
	mapping an IP address to a username dynamically, trying fingering <TT>[e-mail]</TT>.
	This host has apparently aliased out the PPP connections so that the entire list
	of users connected via PPP can be examined using the <TT>finger</TT> command. Thus,
	if you receive a message from a user in that domain, but the user obscured his e-mail
	address, it could still be culled using the <TT>finger</TT> command. By fingering
	the entire block of current PPP addresses, you can map the IP to a username and from
	there, finger the username. By going through this process, you can easily obtain
	the e-mail address of a user in that domain, even if he is trying to hide. 
<HR>


</BLOCKQUOTE>

<P>Note that MasterPlan will not prevent someone from fingering you; it will simply
identify that party and how many times the finger request has been issued.</P>
<P>But all this assumes that your provider allows finger requests from the void.
Suppose for a moment that it doesn't. Does this mean that you are safe and that you
shouldn't worry about your name being revealed? Hardly. It simply means that a standard
finger query will fail to render any information about you.</P>
<P>Suppose that someone is attempting to finger you and discovers that finger requests
from the void are prohibited. Suppose further that this person is determined to find
your real name and is willing to risk an angry message from your provider to his
own. In such a case, the nosy party will initiate a Telnet session to your provider's
mail server. (This is done by initiating a Telnet request to port 25.)</P>
<P>In most cases (except those where the provider is paranoid or running a firewall),
a server will accept a Telnet connection to port 25 (the port that sendmail runs
on). Such a connection looks like this:</P>
<PRE><FONT COLOR="#0066FF">220 shell. Sendmail SMI-8.6/SMI-SVR4 ready at Wed, 19 Feb 1997 07:17:18 -0800
</FONT></PRE>


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>TIP:</B></FONT><B> </B>The preceding piece of a started
	Telnet session was initiated on a Solaris 2.5 SPARC station 20. Different flavors
	of UNIX will provide different strings at the beginning of the session. However,
	almost all reveal the operating system and version number. 
<HR>


</BLOCKQUOTE>

<P>If the nosy party can get to such a prompt, there is better than an 80 percent
chance that he will have your name momentarily. The information is collected by issuing
the following command:</P>
<PRE><FONT COLOR="#0066FF">expn username
</FONT></PRE>
<P>This command requests that the mail package expand a username into an e-mail address
and real name. This is a feature (not a bug) of the sendmail package. The response
will typically expand into something similar to</P>
<PRE><FONT COLOR="#0066FF">username &lt;username@target_of_probe.com&gt; Real Name
</FONT></PRE>
<P>The first field will report back the username or user ID that you request to be
expanded. This will be followed by the person's e-mail address and finally, his &quot;real&quot;
name.</P>
<P>Note that the <TT>expn</TT> function can be disabled by the system administrator,
although few actually do it. There are reasons for this, and the most probable is
that administrators simply fear fiddling with the sendmail configuration. Sendmail
is a notoriously complex and powerful program that has evolved into a huge package.
There are so many options for it that an entire book could be written just on its
configuration. It is for this reason, no doubt, that sendmail has consistently been
the source of holes in Internet security. So you might wonder why the program is
even used at all. That is easy to explain. Sendmail is the most successful program
for transport of electronic mail ever created. Millions of users all over the world
send mail each day using this program.</P>
<P>In any event, if the <TT>expn</TT> function is operable, the nosy individual will
still get your real name, if it is available. Unfortunately, even if the <TT>expn</TT>
function has been disabled, the snooping party can still verify the existence of
your account using the <TT>vrfy</TT> function. This is academic, however; if your
provider's sendmail system honors Telnet sessions, there is a greater than 70 percent
chance that one or both of these functions is available.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>TIP:</B></FONT><B> </B>You will find that many other versions
	of sendmail-- which has now been ported to almost every platform-- will also render
	this information. 
<HR>


</BLOCKQUOTE>

<P>Currently, other than rewriting your account so that your real name does not appear
in the <TT>/etc/passwd</TT> database, there is no way for you to exercise control
over these remote functions. sendmail issues must be resolved by root. Moreover,
it is highly unlikely that a system administrator will fiddle with his or her sendmail
configuration just to satisfy the needs of a paranoid user. Thus, the rule of thumb
is this: If you intend to remain untouchable on the Net, you must never, ever allow
your real name to fill that field within the <TT>/etc/passwd</TT> file.
<H3><FONT COLOR="#000077"><B>A Few Words About Cookies</B></FONT></H3>
<P>You have seen the message many times. You land on a WWW site and a dialog box
appears. The server at the other end says it wants to set a cookie. Most users have
no idea what this means, so they simply click the OK button and continue. Other users
actually read the dialog box's contents and get a little worried. (This is especially
true when the cookie is going to be set for sometime into the year 2000. The user
may not be sure what a cookie is, but almost all users balk when that cookie is going
to hang around for 3 or 4 years.)


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>TIP:</B></FONT><B> </B>If you have never seen such a dialog
	box, you need to set your options to warn you before cookies are being set. Personally,
	I prefer to at least be notified when anything is being written to my hard disk drive.
	You should watch all such activities closely, monitoring any code or other device
	that is arbitrarily forwarded to your machine. 
<HR>


</BLOCKQUOTE>

<P>What are cookies? The cookie concept is very much like getting your hand stamped
at a dance club. You can roam the club, have some drinks, dance, and even go outside
to your car for a few minutes. As long as the stamp is on your hand, you will not
have to pay again, nor will your access be restricted. But cookies go much further
than this. They record specific information about the user, so when that user returns
to the page, the information (known as <I>state information</I>) can be retrieved.
The issue concerning cookies, though, isn't that the information is retrieved. The
controversy is about where the information is retrieved from: your hard disk drive.</P>
<P>Cookies (which Netscape calls <I>persistent client state HTTP cookies</I>) are
now primarily used to store options about each user as he browses a page. The folks
at Netscape explain it this way:

<DL>
	<DD>This simple mechanism provides a powerful new tool which enables a host of new
	types of applications to be written for Web-based environments. Shopping applications
	can now store information about the currently selected items, for fee services can
	send back registration information and free the client from retyping a user-id on
	next connection, sites can store per-user preferences on the client, and have the
	client supply those preferences every time that site is connected to.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>The article from which
	the previous quote is excerpted, &quot;Persistent Client State HTTP Cookies,&quot;
	can be found at <A HREF="http://home.netscape.com/newsref/std/cookie_spec.html"><TT>http://home.netscape.com/newsref/std/cookie_spec.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>To understand the way cookies work, please examine Figure 13.4.</P>
<P><A NAME="04"></A><A HREF="04.htm"><B>Figure 13.4.</B></A><B><BR>
</B><I>Setting cookies.</I></P>
<P>As you can see, when the remote server is contacted, it requests permission to
set a cookie. (One wonders why some sites set a cookie on their opening page. Just
what state information are they recording? You haven't specified any preferences
yet, so there is essentially nothing to record.) Prior to the setting of the cookie,
however, the user is generally confronted with the advisory shown in Figure 13.5.</P>
<P><A NAME="05"></A><A HREF="05.htm"><B>Figure 13.5.</B></A><B><BR>
</B><I>Cookie warning!</I></P>


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>TIP:</B></FONT><B> </B>Note that this advisory will only
	be shown if you choose this option (Warn on Cookie) in your preferences. In Netscape
	Navigator, this option can be toggled in the Network Preferences menu under the Protocols
	tab. In Microsoft Internet Explorer, it can be set in the Options menu under the
	Advanced tab. 
<HR>


</BLOCKQUOTE>

<P>Advocates of cookies insist that they are harmless, cannot assist in identifying
the user, and are therefore benign. That is not true, as explained by D. Kristol
and L. Montulli in RFC 2109:

<DL>
	<DD>An origin server could create a Set-Cookie header to track the path of a user
	through the server. Users may object to this behavior as an intrusive accumulation
	of information, even if their identity is not evident.(Identity might become evident
	if a user subsequently fills out a form that contains identifying information.)
</DL>

<P>I know many programmers who are exploring techniques for using cookies for user
authentication. This is disturbing. There has not been enough scrutiny of the privacy
issues surrounding cookies, and there needs to be some method developed to manage
them. That is, perhaps some cookies are desirable to a particular user and some are
not. The user may visit certain sites regularly. If those sites use cookie conventions,
the user will unnecessarily be confronted with a cookie warning each time he visits,
unless that cookie remains on the drive. However, other cookies (from sites that
the user may never visit again) should be easily removed. This is also discussed
in RFC 2109:

<DL>
	<DD>User agents should allow the user to control cookie destruction. An infrequently
	used cookie may function as a &quot;preferences file&quot; for network applications,
	and a user may wish to keep it even if it is the least-recently-used cookie. One
	possible implementation would be an interface that allows the permanent storage of
	a cookie through a checkbox (or, conversely, its immediate destruction).
</DL>

<P>Briefly, to find the cookies on your hard disk drive, search for the file <TT>cookies.txt</TT>.
This file will contain a list of cookies and their values. It looks like this:</P>
<PRE><FONT COLOR="#0066FF">www.webspan.net    FALSE    /~frys    FALSE    859881600    worldohackf   2.netscape.com    TRUE    /    FALSE    946684799    NETSCAPE_ID    
1000e010,107ea15f.adobe.com    TRUE    /    FALSE    946684799    INTERSE    207.171.18.182 6852855142083822www.ictnet.com    FALSE    /    FALSE    946684799    Apache    pm3a-4326561855491810745.microsoft.com    TRUE    /    FALSE    937422000