ch26.htm

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

nearly as common as mail bombings.</P>
<P>As for mail bombings, the perpetrators are usually easily tracked. Furthermore,
bozo files (kill files) and exclusionary schemes basically render these attacks utterly
harmless (they ultimately bring more sorrow to the perpetrator than anyone). The
only real exception to this is where the bombing is so consistent and in such volume
that it cripples a mail server.</P>
<P>Other level-one intrusions consist of knuckleheads initiating Telnet sessions
to your mail or news server, trying to ascertain shared out directories and whatnot.
As long as you have properly secured your network, these activities are harmless.
If you haven't properly configured shares, or if you are running the r services (or
other things you shouldn't), some of these garden- variety level-one techniques can
expand into real trouble.
<H4><FONT COLOR="#000077"><B>Levels Two and Three</B></FONT></H4>
<P>Levels two and three involve things like local users gaining read or write access
to files (or directories) they shouldn't. This can be a problem, depending largely
on the character of the file(s). Certainly, any instance of a local user being able
to access the <TT>/tmp</TT> directory can be critical. This could potentially pave
a pathway to level-three issues (the next stage) where a user could conceivably gain
write access as well (and thus progress to a level-four environment). This is an
issue primarily for UNIX administrators or NT administrators.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>Microsoft Windows 95 does not have
	granular access control and therefore, barring installation of some third-party,
	access-control device, Windows 95 networks are completely insecure. Because of this,
	level-two attacks are critical and can easily progress to levels three, four, five,
	and six in seconds. If you run such a network, immediately get an access-control
	device of some sort. If you do not, anyone (at any time) can delete one or more critical
	files. Many programs in the Windows 95 environment rely on file dependencies. As
	long as you run a Windows 95 network connected to the Internet (without access control
	or closing the holes in Internet Explorer), it is only a question of how long before
	someone mangles your network. By deleting just a few files on a Windows 95 network,
	a cracker can incapacitate it permanently. If you have the ability to do so, monitor
	all traffic to ports 137-139, where the sharing process occurs. Furthermore, I would
	<I>strictly</I> prohibit users within that network from installing Web or FTP servers.
	If you are running the Microsoft platform and want to provide servers open to the
	outside world (an idea that I would furiously argue against), get NT. 
<HR>


</BLOCKQUOTE>

<P>Local attacks are a bit different. The term <I>local user</I> is, I realize, a
relative one. In networks, <I>local user</I> refers to literally anyone currently
logged to any machine within the network. Perhaps a better way to define this is
to say that a local user is anyone who has a password to a machine within your local
network and therefore has a directory on one of your drives (regardless of what purpose
that directory serves: a Web site, a local hard disk drive on one of the workstations,
and so forth).</P>
<P>The threat from local users correlates directly to what type of network you are
maintaining. If you are an ISP, your local users could be anyone; you have probably
never met or spoken to 90 percent of your local users. As long as their credit card
charges ring true each month, you probably have little contact with these folks even
by e-mail (barring the distribution of monthly access or maintenance reports; this
interaction doesn't really count as contact, though). There is no reason to assume
that these faceless persons are not crackers. Everyone but your immediate staff should
be suspect.</P>
<P>An attack initiated by a local user can be either pathetic or extremely sophisticated.
Nevertheless, no matter what level of expertise is behind these attacks, will almost
invariably originate over Telnet. I have indicated before that if you are an ISP,
it is an excellent idea to isolate all shell accounts to a single machine. That is,
logins should only be accepted on the one or more machines that you have allocated
for shell access. This makes it much easier to manage logs, access controls, loose
protocols, and other potential security issues.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>TIP:</B></FONT><B> </B>In general, you should also segregate
	any system boxes that are going to house user-created CGI. 
<HR>


</BLOCKQUOTE>

<P>These machines should be blocked into their own networked segment. That is, they
should be surrounded by either routers or hubs, depending on how your network is
configured. The topology should ensure that bizarre forms of hardware address spoofing
cannot leak beyond that particular segment. This brings up some issues of trust,
a matter I address later in this book.</P>
<P>There are only two kinds of attack you will encounter. The less serious one is
the <I>roving user</I>, a cracker who is new to the subject and therefore looks around
for things (oh, they might print the <TT>passwd</TT> file to <TT>SDTOUT</TT>, see
if they can read any privileged files, and whatnot). Conversely, you may encounter
an organized and well-thought-out attack. This is where the attacker already knows
your system configuration well. Perhaps he previously assessed it from an account
with another provider (if your system gives away information from the outside, this
is a definite possibility).</P>
<P>For those using access-control-enabled environments, there are two key issues
regarding permissions. Each can affect whether a level-two problem escalates into
levels three, four, or five. Those factors are

<UL>
	<LI>Misconfiguration on your part<BR>
	<BR>
	
	<LI>Holes inherent within software
</UL>

<P>The first contingency arises when you don't properly understand the permission
scheme. This is not a crime. I recognize (though few will admit it) that not every
UNIX or NT system administrator is a guru. It takes time to acquire in-depth knowledge
of the system. Just because you have earned a B.S. in CS doesn't mean you will know
for certain that your system is secure. There are tools to check for common misconfigurations,
and I offer quite a few throughout this book. If you have even the slightest suspicion
that permissions may be set inaccurately, get these tools and double-check.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>TIP:</B></FONT><B> </B>Many security tools come with tutorials
	about vulnerabilities. SATAN is a great example. The tutorials included with SATAN
	are of significant value and can be used to understand many weaknesses within the
	system, even if you do not run UNIX. For example, suppose you are a journalist and
	want to gain a better understanding of UNIX security. You don't need UNIX to read
	the HTML tutorials included with SATAN. 
<HR>


</BLOCKQUOTE>

<P>The second contingency is more common than you think. In fact, it crops up all
the time. For example, according to the CERT advisory titled &quot;Vulnerability
in IRIX csetup&quot; (issued in January, 1997):

<DL>
	<DD>The CERT Coordination Center has received information about a vulnerability in
	the csetup program under IRIX versions 5.x, 6.0, 6.0.1, 6.1, and 6.2. csetup is not
	available under IRIX 6.3 and 6.4. By exploiting this vulnerability, local users can
	create or overwrite arbitrary files on the system. With this leverage, they can ultimately
	gain root privileges.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>Find this advisory online
	at <A HREF="http://www.fokus.gmd.de/vst/Security/cert/0073.html"><TT>http://www.fokus.gmd.de/vst/Security/cert/0073.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>Take a good look at this advisory. Note the date. This is not some ancient advisory
from the 1980s. This appeared very recently. These types of problems are not exclusive
to any one company. Holes are routinely found in programs on every manner of operating
system, as noted in the CERT advisory titled &quot;Vulnerability in Solaris admintool&quot;
(August, 1996):

<DL>
	<DD>AUSCERT has received a report of a vulnerability in the Sun Microsystems Solaris
	2.x distribution involving the program admintool. This program is used to provide
	a graphical user interface to numerous system administration tasks. This vulnerability
	may allow a local user to gain root privileges...In Solaris 2.5, admintool is set-user-id
	root by default. That is, all file accesses are performed with the effective uid
	of root. An effect of this is that the vulnerability will allow access to any file
	on the system. If the vulnerability is exploited to try and create a file that already
	exists, the contents of that file will be deleted. If the file does not exist, it
	will be created with root ownership and be world writable.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>Find this advisory online
	at <A HREF="http://www.fokus.gmd.de/vst/Security/cert/0050.html"><TT>http://www.fokus.gmd.de/vst/Security/cert/0050.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>It makes no difference what flavor you are running. Bugs are posted for almost
all operating systems. Most networked systems see at least one advisory a month of
this nature (by <I>this nature</I>, I mean one that can lead to leveraged or even
root access). There is no immediate solution to this problem because most of these
holes are not apparent at the time the software is shipped. The only solution is
that you subscribe to every mailing list germane to bugs, holes, and your system.
In this respect, security is a never-ending, learning process.</P>
<P>There are some techniques that you can employ to keep up with the times. First,
if you subscribe to several mailing lists, you will be hammered with e-mail. Some
lists generate as many as 50 messages a day. On UNIX platforms, this is not much
of a problem, because you can control how these messages are written to the disk
at their time of arrival (by trapping the incoming address and redirecting the mail
to a particular directory and so forth). In a Microsoft Windows environment, however,
that volume of mail can be overwhelming for someone busy with other tasks. If you
are the system administrator of a network running NT, there are several actions you
can take. One is to direct different lists to different accounts. This makes management
of incoming mail a bit easier (there are also products on the market for this sort
of thing). Nonetheless, no matter what platform you use, you should fashion scripts
to analyze those mail messages before you read them. I would install Perl (which
is also available for NT) and use it to scan the messages for strings that would
likely appear in a post relevant to your specific configuration. With a little effort,
you can even create a script that rates these hits by priority.
<H4><FONT COLOR="#000077"><B>Level Four</B></FONT></H4>
<P>Level-four issues are usually related to outsiders being able to access internal
files. This access may vary. They may be able to do no more than verify the existence
of certain files, or they may be able to read them. Level-four problems also include
those vulnerabilities whereby remote users--without valid accounts--can execute a
limited number of commands on your server.</P>
<P>The highest percentage of these holes arise through misconfiguration of your server,
bad CGI, and overflow problems.
<H4><FONT COLOR="#000077"><B>Levels Five and Six</B></FONT></H4>
<P>Levels five and six consist of conditions whereby things are allowed to occur
that <I>never</I> should. Any level five or six hole is fatal. At these stages, remote
users can read, write, and execute files (usually, they have used a combination of
techniques to get to this stage). Fortunately, if you have closed levels two, three,
and four, it is almost impossible that you will ever see a level five or six crisis.
If you close lesser avenues of entry, a level-six vulnerability is most likely to
originate with a vendor's faulty software.
<H3><FONT COLOR="#000077"><B>Response Levels</B></FONT></H3>
<P>What do you do if you discover an attack in progress? It depends on the situation.
<H4><FONT COLOR="#000077"><B>Responding to Level-One Attacks</B></FONT></H4>
<P>Level-one attacks can be treated as described previously. Filter the incoming
address and contact the attacker's service provider. These are minor inconveniences.
Only when the denial-of-service attack appears to be related to some other form of
attack (perhaps more sophisticated) or where it continues for some time (as in the
Panix.com case) should you bother to do more than exclude the incoming traffic. However,
if you are in a situation identical to Panix, you may want to contact CERT or other
authorities.
<H4><FONT COLOR="#000077"><B>Responding to Level-Two Attacks</B></FONT></H4>
<P>Level-two attacks can be dealt with internally. There is no reason to leak information
that local users can access things they shouldn't. Basically, freeze or eliminate
the user's account. If there are complaints, let your lawyers sort it out. If you
&quot;counsel&quot; the individual, you will see poor results. Within a month, he
or she will be at it again. You are not engaged in a game. There is no guarantee
that this internal user is just an innocent, curious individual. One last thing:
give no warning about freezing the account. This way, you can preserve any evidence
that might otherwise be deleted.


<BLOCKQUOTE>
	<P>
<HR>