ch25.htm

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

</BLOCKQUOTE>

<H2><FONT COLOR="#000077"><B>Doing a Test Run</B></FONT></H2>
<P>The test-run portion of the attack is practical only for those individuals who
are serious about cracking. Your average cracker will not undertake such activity,
because it involves spending a little money. However, if I were counseling a cracker,
I would recommend it.</P>
<P>This step involves establishing a single machine with the identical distribution
as the target. Thus, if the target is a SPARCstation 2 running Solaris 2.4, you would
erect an identical machine and string it to the Net via any suitable method (by modem,
ISDN, Frame Relay, T1, or whatever you have available). After you have established
the machine, run a series of attacks against it. There are two things you are looking
for:

<UL>
	<LI>What the attacks are going to look like from the attacking side<BR>
	<BR>
	
	<LI>What the attacks will look like from the victim's side
</UL>

<P>There are a number of reasons for this, and some are not so obvious. In examination
of the logs on the attacking side, the cracker can gain an idea of what the attack
should look like if his target is basically unprotected--in other words, if the target
is not running custom daemons. This provides the cracker a little road map to go
by; certainly, if his ultimate scan and attack of the target do not look nearly identical,
this is cause for concern. All things being equal, an identically configured machine
(or, I should say, an <I>apparently</I> identically configured machine) should respond
identically. If it does not, the folks at the target have something up their sleeve.
In this instance, the cracker would be wise to tread carefully.</P>
<P>By examining the victim-side logs, the cracker can get a look at what his footprint
will look like. This is also important to know. On diverse platforms, there are different
logging procedures. The cracker should know at a minimum exactly what these logging
procedures are; that is, he needs to know each and every file (on the identically
configured machine) that will show evidence of an intrusion. This information is
paramount, because it serves as a road map also: It shows him exactly what files
have to be altered to erase any evidence of his attack. The only way to identify
these files for certain is to conduct a test under a controlled environment and examine
the logs for themselves.</P>
<P>In actual attacks, there should be only a few seconds (or minutes at most) before
root (or some high level of privilege) is obtained. Similarly, it should be only
seconds thereafter (or minutes at worst) before evidence of that intrusion is erased.
For the cracker, any other option is a fatal one. They may not suffer from it in
the short run, but in the long run, they will end up in handcuffs.</P>
<P>This step is not as expensive as you would think. There are newsgroups (most notably,
<TT>misc.forsale.computers.workstation</TT>) where one can obtain the identical machine
(or a close facsimile) for a reasonable price. Generally, the seller of such a machine
will load a full version of the operating system &quot;for testing purposes only.&quot;
This is their way of saying &quot;I will give you the operating system, which comes
without a license and therefore violates the license agreement. If you keep it and
later come under fire from the vendor, you are on your own.&quot;</P>
<P>Even licensed resellers will do this, so you can end up with an identical machine
without going to too much expense. (You can also go to defense contracting firms,
many of which auction off their workstations for a fraction of their fair market
value. The only bar here is that you must have the cash ready; you generally only
get a single shot at a bid.)</P>
<P>Other possibilities include having friends set up such a box at their place of
work or even at a university. All you really need are the logs. I have always thought
that it would be a good study practice to maintain a database of such logs per operating
system per attack and per scanner--in other words, have a library of what such attacks
look like, given the aforementioned variables. This, I think, would be a good training
resource for new system administrators, something like &quot;This is what a SS4 looks
like when under attack by someone using ISS. These are the log files you need to
look for and this is how they will appear.&quot;</P>
<P>Surely, a script could be fashioned (perhaps an automated one) that would run
a comparative analysis against the files on your workstation. This process could
be done once a day as a cron job. It seems to me that at least minimal intrusion-detection
systems could be designed this way. Such tools do exist, but have been criticized
by many individuals because they can be &quot;fooled&quot; too easily. There is an
excellent paper that treats this subject, at least with respect to SunOS. It is titled
<I>USTAT: A Real Time Intrusion Detection System for UNIX</I>. (This paper was, in
fact, a thesis for the completion of a master's in computer science at the University
of Santa Barbara, California. It is very good.) In the abstract, the author writes:

<DL>
	<DD>In this document, the development of the first USTAT prototype, which is for
	SunOS 4.1.1, is described. USTAT makes use of the audit trails that are collected
	by the C2 Basic Security Module of SunOS, and it keeps track of only those critical
	actions that must occur for the successful completion of the penetration. This approach
	differs from other rule-based penetration identification tools that pattern match
	sequences of audit records.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>The preceding paragraph
	is excerpted from <I>USTAT: A Real Time Intrusion Detection System for UNIX</I> by
	Koral Ilgun. It can be found online at <A HREF="ftp://coast.cs.purdue.edu/pub/doc/intrusion_detection/ustat.ps.gz"><TT>ftp://coast.cs.purdue.edu/pub/doc/intrusion_detection/ustat.ps.gz</TT></A>
	
<HR>


</BLOCKQUOTE>

<P>Although we proceeded under the assumption that the target network was basically
an unprotected, out-of-the-box install, I thought I should mention tools like the
one described in the paper referenced previously. The majority of such tools have
been employed on extremely secure networks--networks often associated with classified
or even secret or top-secret work.</P>
<P>Another interesting paper lists a few of these tools and makes a brief analysis
of each. It discusses how

<DL>
	<DD>Computer security officials at the system level have always had a challenging
	task when it comes to day-to-day mainframe auditing. Typically the auditing options/features
	are limited by the mainframe operating system and other system software provided
	by the hardware vendor. Also, since security auditing is a logical subset of management
	auditing, some of the available auditing options/features may be of little value
	to computer security officials. Finally, the relevant auditing information is probably
	far too voluminous to process manually and the availability of automated data reduction/analysis
	tools is very limited. Typically, 95% of the audit data is of no security significance.
	The trick is determining which 95% to ignore.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>The previous paragraph
	is excerpted from <I>Summary of the Trusted Information Systems (TIS) Report on Intrusion
	Detection Systems</I>, prepared by Victor H. Marshall, Systems Assurance Team Leader,
	Booz, Allen &amp; Hamilton Inc. This document can be found online at <A HREF="ftp://coast.cs.purdue.edu/pub/doc/intrusion_detection/auditool.txt.Z"><TT>ftp://coast.cs.purdue.edu/pub/doc/intrusion_detection/auditool.txt.Z</TT></A>
	
<HR>


</BLOCKQUOTE>

<P>In any event, this &quot;live&quot; testing technique should be primarily employed
where there is a single attack point. Typical situations are where you suspect that
one of the workstations is the most viable target (where perhaps the others will
refuse all connections from outside the subnet and so forth). Obviously, I am not
suggesting that you erect an exact model of the target network; that could be cost
and time prohibitive. What I am suggesting is that in coordination of a remote attack,
you need to have (at a minimum) some idea of what is supposed to happen. Simulating
that attack on a host other than the target is a wise thing to do. Otherwise, there
is no guarantee that you can even marginally ensure that the data you receive back
has some integrity. Bellovin's paper on Berferd should be a warning to any cracker
that a simulation of a vulnerable network is not out of the question. In fact, I
have wondered many times why security technologies have not focused entirely on this
type of technique, especially since scanners have become so popular.</P>
<P>What is the difficulty in a system administrator creating his own such system
on the fly? How difficult would it be for an administrator to write custom daemons
(on a system where the targeted services aren't even actually running) that would
provide the cracker with bogus responses? Isn't this better than announcing that
you have a firewall (or <TT>TCP_WRAPPER</TT>), therefore alerting the attacker to
potential problems? Never mind passive port-scanning utilities, let's get down to
the nitty-gritty: This is how to catch a cracker--with a system designed exclusively
for the purpose of creating logs that demonstrate intent. This, in my opinion, is
where some new advances ought to be made. These types of systems offer automation
to the process of evidence gathering.</P>
<P>The agencies that typically utilize such tools are few. Mostly, they are military
organizations. An interesting document is available on the Internet in regard to
military evaluations and intrusion detection. What is truly interesting about the
document is the flair with which it is written. For instance, sample this little
excerpt:

<DL>
	<DD>For 20 days in early spring 1994, Air Force cybersleuths stalked a digital delinquent
	raiding unclassified computer systems at Griffiss AFB, NY. The investigators had
	staked out the crime scene--a small, 12-by-12-foot computer room in Rome Laboratory's
	Air Development Center--for weeks, surviving on Jolt cola, junk food and naps underneath
	desks. Traps were set by the Air Force Information Warfare Center to catch the bandit
	in the act, and `silent' alarms sounded each time their man slinked back to survey
	his handiwork. The suspect, who dubbed himself `Data Stream,' was blind to the surveillance,
	but despite this, led pursuers on several high-speed chases that don't get much faster--the
	speed of light. The outlaw was a computer hacker zipping along the ethereal lanes
	of the Internet, and tailing him was the information superhighway patrol--the Air
	Force Office of Special Investigations computer crime investigations unit.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>The previous paragraph
	is excerpted from &quot;Hacker Trackers: OSI Computer Cops Fight Crime On-Line&quot;
	by Pat McKenna. It can be found online at <A HREF="http://www.af.mil/pa/airman/0496/hacker.htm"><TT>http://www.af.mil/pa/airman/0496/hacker.htm</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>The document doesn't give as much technical information as one would want, but
it is quite interesting, all the same. Probably a more practical document for the
legal preservation of information in the investigation of intrusions is one titled
&quot;Investigating and Prosecuting Network Intrusions.&quot; It was authored by
John C. Smith, Senior Investigator in the Computer Crime Unit of the Santa Clara
County District Attorney's Office.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>&quot;Investigating and
	Prosecuting Network Intrusions&quot; can be found online at <A HREF="http://www.eff.org/pub/Legal/scda_cracking_investigation.paper"><TT>http://www.eff.org/pub/Legal/scda_cracking_investigation.paper</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>In any event, as I have said, at least some testing should be done beforehand.
That can only be done by establishing a like box with like software.
<H2><FONT COLOR="#000077"><B>Tools: About Holes and Other Important Features</B></FONT></H2>
<P>Next, you need to assemble the tools you will actually use. These tools will most
probably be scanners. You will be looking (at a minimum) to identify all services
now running on the target. Based on your analysis of the operating system (as well
as the other variables I've mentioned in this chapter), you will need to evaluate
your tools to determine what areas or holes they do not cover.</P>
<P>In instances where a particular service is covered by one tool but not another,
it is best to integrate the two tools together. The ease of integration of such tools
will depend largely on whether these tools can simply be attached as external modules
to a scanner like SATAN or SAFESuite. Again, here the use of a test run can be extremely
valuable; in most instances, you cannot simply attach an external program and have
it work flawlessly.</P>
<P>To determine the exact outcome of how all these tools will work in concert, it
is best to do this at least on some machine (even if it is not identical to the target).
That is because, here, we are concerned with whether the scan will be somehow interrupted
or corrupted as the result of running two or more modules of disparate design. Remember
that a real-time scanning attack should be done only once. If you screw it up, you
might not get a second chance.</P>
<P>So, you will be picking your tools (at least for the scan) based on what you can
reasonably expect to find at the other end. In some cases, this is an easy job. For
example, perhaps you already know that someone on the box is running X Window System
applications across the Net. (Not bloody likely, but not unheard of.) In that case,
you will also be scanning for xhost problems, and so it goes.</P>
<P>Remember that a scanner is a drastic solution. It is the equivalent of running
up to an occupied home with a crowbar in broad daylight, trying all the doors and
windows. If the system administrator is even moderately tuned into security issues,
you have just announced your entire plan.


<BLOCKQUOTE>