ch25.htm

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

	<P>
<HR>
<FONT COLOR="#000077"><B>TIP:</B></FONT><B> </B>There are some measures you can take
	to avoid that announcement, but they are drastic: You can actually institute the
	same security procedures that other networks do, including installing software (sometimes
	a firewall and sometimes not) that will refuse to report your machine's particulars
	to the target. There are serious problems with this type of technique, however, as
	they require a high level of skill. (Also, many tools will be rendered useless by
	instituting such techniques. Some tools are designed so that one or more functions
	require the ability to go out of your network, through the router, and back inside
	again.) 
<HR>


</BLOCKQUOTE>

<P>Again, however, we are assuming here that the target is not armored; it's just
an average site, which means that we needn't stress too much about the scan. Furthermore,
as Dan Farmer's recent survey suggests, scanning may not be a significant issue anyway.
According to Farmer (and I have implicit faith in his representations, knowing from
personal experience that he is a man of honor), the majority of networks don't even
notice the traffic:

<DL>
	<DD>...no attempt was made to hide the survey, but only three sites out of more than
	two thousand contacted me to inquire what was going on when I performed the unauthorized
	survey (that's a bit over one in one thousand questioning my activity). Two were
	from the normal survey list, and one was from my random group.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>The preceding paragraph
	is excerpted from the introduction of <I>Shall We Dust Moscow? </I>by Dan Farmer.
	This document can be found online at <A HREF="http://www.trouble.org/survey/introduction.html"><TT>http://www.trouble.org/survey/introduction.html</TT></A>
	
<HR>


</BLOCKQUOTE>

<P>That scan involved over 2,000 hosts, the majority of which were fairly sensitive
sites (for example, banks). You would expect that these sites would be ultra-paranoid,
filtering every packet and immediately jumping on even the slightest hint of a scan.
<H2><FONT COLOR="#000077"><B>Developing an Attack Strategy</B></FONT></H2>
<P>The days of roaming around the Internet, cracking this and that server are basically
over. Years ago, compromising the security of a system was viewed as a minor transgression
as long as no damage was done. Today, the situation is different. Today, the value
of data is becoming an increasingly talked-about issue. Therefore, the modern cracker
would be wise not to crack without a reason. Similarly, he would be wise to set forth
cracking a server only with a particular plan.</P>
<P>The only instance in which this does not apply is where the cracker is either
located in a foreign state that has no specific law against computer intrusion (Berferd
again) or one that provides no extradition procedure for that particular offense
(for example, the NASA case involving a student in Argentina). All other crackers
would be wise to tread very cautiously.</P>
<P>Your attack strategy may depend on what you are wanting to accomplish. We will
assume, however, that the task at hand is basically nothing more than compromise
of system security. If this is your plan, you need to lay out how the attack will
be accomplished. The longer the scan takes (and the more machines that are included
within it), the more likely it is that it will be immediately discovered. Also, the
more scan data that you have to sift through, the longer it will take to implement
an attack based upon that data. The time that elapses between the scan and the actual
attack, as I've mentioned, should be short.</P>
<P>Some things are therefore obvious (or should be). If you determine from all of
your data collection that certain portions of the network are segmented by routers,
switches, bridges, or other devices, you should probably exclude those from your
scan. After all, compromising those systems will likely produce little benefit. Suppose
you gained root on one such box in a segment. How far do you think you could get?
Do you think that you could easily cross a bridge, router, or switch? Probably not.
Therefore, sniffing will only render relevant information about the other machines
in the segment, and spoofing will likewise work (reliably) only against those machines
within the segment. Because what you are looking for is root on the main box (or
at least, within the largest network segment available), it is unlikely that a scan
on smaller, more secure segments would prove to be of great benefit.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>Of course, if these machines (for
	whatever reason) happen to be the only ones exposed, by all means, attack them (unless
	they are completely worthless). For example, it is a common procedure to place a
	Web server outside the network firewall or make that machine the only one accessible
	from the void. Unless the purpose of the exercise is to crack the Web server (and
	cause some limited, public embarrassment to the owners of the Web box), why bother?
	These machines are typically &quot;sacrificial&quot; hosts--that is, the system administrator
	has anticipated losing the entire machine to a remote attack, so the machine has
	nothing of import upon its drives. Nothing except Web pages, that is. 
<HR>


</BLOCKQUOTE>

<P>In any event, once you have determined the parameters of your scan, implement
it.
<H2><FONT COLOR="#000077"><B>A Word About Timing Scans</B></FONT></H2>
<P>When should you implement a scan? The answer to this is really &quot;never.&quot;
However, if you are going to do it, I would do it late at night relative to the target.
Because it is going to create a run of connection requests anyway (and because it
would take much longer if implemented during high-traffic periods), I think you might
as well take advantage of the graveyard shift. The shorter the time period, the better
off you are.
<H3><FONT COLOR="#000077"><B>After the Scan</B></FONT></H3>
<P>After you have completed the scan, you will be subjecting the data to analysis.
The first issue you want to get out of the way is whether the information is even
authentic. (This, to some degree, is established from your sample scans on a like
machine with the like operating system distribution.)</P>
<P>Analysis is the next step. This will vary depending upon what you have found.
Certainly, the documents included in the SATAN distribution can help tremendously
in this regard. Those documents (tutorials about vulnerabilities) are brief, but
direct and informative. They address the following vulnerabilities:

<UL>
	<LI>FTP vulnerabilities
	<LI>NFS export to unprivileged programs
	<LI>NFS export via portmapper
	<LI>NIS password file access
	<LI>REXD access
	<LI>SATAN password disclosure
	<LI>Sendmail vulnerabilities
	<LI>TFTP file access
	<LI>Remote shell access
	<LI>Unrestricted NFS export
	<LI>Unrestricted X server access
	<LI>Unrestricted modem
	<LI>Writeable FTP home directory
</UL>

<P>In addition to these pieces of information, you should apply any knowledge that
you have gained through the process of gathering information on the specific platform
and operating system. In other words, if a scanner reports a certain vulnerability
(especially a newer one), you should refer back to the database of information that
you have already built from raking BUGTRAQ and other searchable sources.</P>
<P>This is a major point: There is no way to become either a master system administrator
or a master cracker overnight. The hard truth is this: You may spend weeks studying
source code, vulnerabilities, a particular operating system, or other information
before you truly understand the nature of an attack and what can be culled from it.
Those are the breaks. There is no substitute for experience, nor is there a substitute
for perseverance or patience. If you lack any of these attributes, forget it.</P>
<P>That is an important point to be made here. Whether we are talking about individuals
like Kevin Mitnik (cracker) or people like Weitse Venema (hacker), it makes little
difference. Their work and their accomplishments have been discussed in various news
magazines and online forums. They are celebrities within the Internet security (and
in some cases, beyond). However, their accomplishments (good or bad) resulted from
hard work, study, ingenuity, thought, imagination, and self-application. Thus, no
firewall will save a security administrator who isn't on top of it, nor will SATAN
help a newbie cracker to unlawfully breach the security of a remote target. That's
the bottom line.
<H2><FONT COLOR="#000077"><B>Summary</B></FONT></H2>
<P>Remote attacks are becoming increasingly common. As discussed in several earlier
chapters, the ability to run a scan has become more within the grasp of the average
user. Similarly, the proliferation of searchable vulnerability indexes have greatly
enhanced one's ability to identify possible security issues.</P>
<P>Some individuals suggest that the free sharing of such information is itself contributing
to the poor state of security on the Internet. That is incorrect. Rather, system
administrators must make use of such publicly available information. They should,
technically, perform the procedures described here on their own networks. It is not
so much a matter of cost as it is time.</P>
<P>One interesting phenomenon is the increase in tools to attack Windows NT boxes.
Not just scanning tools, either, but sniffers, password grabbers, and password crackers.
In reference to remote attack tools, though, the best tool available for NT is SAFEsuite
by Internet Security Systems (ISS). It contains a wide variety of tools, although
the majority were designed for internal security analysis.</P>
<P>For example, consider the Intranet Scanner, which assesses the internal security
of a network tied to a Microsoft Windows NT server. Note here that I write only that
the network is <I>tied</I> to the NT server. This does not mean that all machines
on the network must run NT in order for the Intranet Scanner to work. Rather, it
is designed to assess a network that contains nodes of disparate architecture and
operating systems. So, you could have boxes running Windows 95, UNIX, or potentially
other operating systems running TCP/IP. The title of the document is &quot;Security
Assessment in the Windows NT Environment: A White Paper for Network Security Professionals.&quot;
It discusses the many features of the product line and a bit about Windows NT security
in general.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>To get a better idea
	of what Intranet Scanner offers, check out <A HREF="http://eng.iss.net/prod/winnt.html"><TT>http://eng.iss.net/prod/winnt.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>Specific ways to target specific operating systems (as in &quot;How To&quot; sections)
are beyond the scope of this book, not because I lack the knowledge but because it
could take volumes to relate. To give you a frame of reference, consider this: The
Australian CERT (AUSCERT) UNIX Security Checklist consists of at least six pages
of printed information. The information is extremely abbreviated and is difficult
to interpret by anyone who is not well versed in UNIX. Taking each point that AUSCERT
raises and expanding it into a detailed description and tutorial would likely create
a 400-page book, even if the format contained simple headings such as <TT>Daemon</TT>,
<TT>Holes</TT>, <TT>Source</TT>, <TT>Impact</TT>, <TT>Platform</TT>, <TT>Examples</TT>,
<TT>Fix</TT>, and so on. (That document, by the way, discussed elsewhere in this
book, is the definitive list of UNIX security vulnerabilities. It is described in
detail in Chapter 17, &quot;UNIX: The Big Kahuna.&quot;)</P>
<P>In closing, a well-orchestrated and formidable remote attack is not the work of
some half-cocked cracker. It is the work of someone with a deep understanding of
the system--someone who is cool, collected, and quite well educated in TCP/IP. (Although
that education may not have come in a formal fashion.) For this reason, it is a shame
that crackers usually come to such a terrible end. One wonders why these talented
folks turn to the dark side.</P>
<P>I know this, though: It has nothing to do with money. There are money-oriented
crackers, and they are professionals. But the hobbyist cracker is a social curiosity--so
much talent and so little common sense. It is extraordinary, really, for one incredible
reason: It was crackers who spawned most of the tools in this book. Their activities
gave rise to the more conventional (and more talented) computing communities that
are coding special security applications. Therefore, the existence of specialized
tools is really a monument to the cracking community. They have had a significant
impact, and one such impact was the development of the remote attack. The technique
not only exists because of these curious people, but also grows in complexity because
of them.</P>
<CENTER>
<P>
<HR>
<A HREF="../ch24/ch24.htm"><IMG SRC="../button/previous.gif" WIDTH="128" HEIGHT="28"
ALIGN="BOTTOM" ALT="Previous chapter" BORDER="0"></A><A HREF="../ch26/ch26.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>