ch01.htm

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

probable) that users might be unaware of obscure network utilities at work with their
operating systems.</P>
<P>This is especially so with UNIX-based operating systems, but for a slightly different
reason. UNIX is a large and inherently complex system. Comparing it to other operating
systems can be instructive. DOS contains perhaps 30 commonly used commands. In contrast,
a stock distribution of UNIX (without considering windowed systems) supports several
hundred commands. Further, each command has one or more command-line options, increasing
the complexity of each utility or program.</P>
<P>In any case, in the active state of insecurity in shipped software, utilities
are enabled and this fact is unknown to the user. These utilities, while enabled,
can foster security holes of varying magnitude. When a machine configured in this
manner is connected to the Net, it is a hack waiting to happen.</P>
<P>Active state problems are easily remedied. The solution is to turn off (or properly
configure) the offending utility or service. Typical examples of active state problems
include

<UL>
	<LI>Network printing utilities<BR>
	<BR>
	
	<LI>File-sharing utilities<BR>
	<BR>
	
	<LI>Default passwords<BR>
	<BR>
	
	<LI>Sample networking programs
</UL>

<P>Of the examples listed, default passwords is the most common. Most multiuser operating
systems on the market have at least one default password (or an account requiring
no password at all).
<H3><FONT COLOR="#000077"><B>The Passive State</B></FONT></H3>
<P>The passive state involves operating systems with built-in security utilities.
These utilities can be quite effective when enabled, but remain worthless until the
system administrator activates them. In the passive state, these utilities are never
activated, usually because the user is unaware that they exist. Again, the source
of the problem is the same: The user or system administrator lacks adequate knowledge
of the system.</P>
<P>To understand the passive state, consider logging utilities. Many networked operating
systems provide good logging utilities. These comprise the cornerstone of any investigation.
Often, these utilities are not set to active in a fresh installation. (Vendors might
leave this choice to the system administrator for a variety of reasons. For example,
certain logging utilities consume space on local drives by generating large text
or database files. Machines with limited storage are poor candidates for conducting
heavy logging.) Because vendors cannot guess the hardware configuration of the consumer's
machine, logging choices are almost always left to the end-user.</P>
<P>Other situations that result in passive-state insecurity can arise: Situations
where user knowledge (or lack thereof) is not the problem. For instance, certain
security utilities are simply impractical. Consider security programs that administer
file-access privileges (such as those that restrict user access depending on security
level, time of day, and so forth). Perhaps your small network cannot operate with
fluidity and efficiency if advanced access restrictions are enabled. If so, you must
take that chance, perhaps implementing other security procedures to compensate. In
essence, these issues are the basis of security theory: You must balance the risks
against practical security measures, based on the sensitivity of your network data.</P>
<P>You will notice that both active and passive states of insecurity in software
result from the consumer's lack of knowledge (not from any vendor's act or omission).
This is an education issue, and education is a theme that will recur throughout this
book.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>Education issues are matters entirely
	within your control. That is, you can eliminate these problems by providing yourself
	or your associates with adequate education. (Put another way, crackers can gain most
	effectively by attacking networks where such knowledge is lacking.) That settled,
	I want to examine matters that might not be within the end-user's control. 
<HR>


</BLOCKQUOTE>

<H4><FONT COLOR="#000077"><B>System Flaws or Deficiency of Vendor Response</B></FONT></H4>
<P>System flaws or deficiency of vendor response are matters beyond the end-user's
control. Although vendors might argue this point furiously, here's a fact: These
factors are the second most common source of security problems. Anyone who subscribes
to a bug mailing list knows this. Each day, bugs or programming weaknesses are found
in network software. Each day, these are posted to the Internet in advisories or
warnings. Unfortunately, not all users read such advisories.</P>
<P>System flaws needn't be classified into many subcategories here. It's sufficient
to say that a system flaw is any element of a program that causes the program to

<UL>
	<LI>Work improperly (under either normal or extreme conditions)<BR>
	<BR>
	
	<LI>Allow crackers to exploit that weakness (or improper operation) to damage or
	gain control of a system
</UL>

<P>I am concerned with two types of system flaws. The first, which I call a pure
flaw, is a security flaw nested within the security structure itself. It is a flaw
inherent within a security-related program. By exploiting it, a cracker obtains one-step,
unauthorized access to the system or its data.</P>


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>The Netscape secure sockets layer flaw:</B></FONT><B> </B>In
	January, 1996, two students in the Computer Science department at the University
	of California, Berkeley highlighted a serious flaw in the Netscape Navigator encryption
	scheme. Their findings were published in Dr. Dobb's Journal. The article was titled
	<I>Randomness and the Netscape Browser</I> by Ian Goldberg and David Wagner. In it,
	Goldberg and Wagner explain that Netscape's implementation of a cryptographic protocol
	called Secure Sockets Layer (SSL) was inherently flawed. This flaw would allow secure
	communications intercepted on the WWW to be cracked. This is an excellent example
	of a pure flaw. (It should be noted here that the flaw in Netscape's SSL implementation
	was originally discovered by an individual in France. However, Goldberg and Wagner
	were the first individuals in the United States to provide a detailed analysis of
	it.) 
<HR>
</P>

</BLOCKQUOTE>

<P>Conversely, there are secondary flaws. A secondary flaw is any flaw arising in
a program that, while totally unrelated to security, opens a security hole elsewhere
on the system. In other words, the programmers were charged with making the program
functional, not secure. No one (at the time the program was designed) imagined cause
for concern, nor did they imagine that such a flaw could arise.</P>
<P>Secondary flaws are far more common than pure flaws, particularly on platforms
that have not traditionally been security oriented. An example of a secondary security
flaw is any flaw within a program that requires special access privileges in order
to complete its tasks (in other words, a program that must run with root or superuser
privileges). If that program can be attacked, the cracker can work through that program
to gain special, privileged access to files. Historically, printer utilities have
been problems in this area. (For example, in late 1996, SGI determined that root
privileges could be obtained through the <TT>Netprint</TT> utility in its IRIX operating
system.)</P>
<P>Whether pure or secondary, system flaws are especially dangerous to the Internet
community because they often emerge in programs that are used on a daily basis, such
as FTP or Telnet. These mission-critical applications form the very heart of the
Internet and cannot be suddenly taken away, even if a security flaw exists within
them.</P>
<P>To understand this concept, imagine if Microsoft Word were discovered to be totally
insecure. Would people stop using it? Of course not. Millions of offices throughout
the world rely on Word. However, there is a vast difference between a serious security
flaw in Microsoft Word and a serious security flaw in NCSA HTTPD, which is a popular
Web-server package. The serious flaw in HTTPD would place hundreds of thousands of
servers (and therefore, millions of accounts) at risk. Because of the Internet's
size and the services it now offers, flaws inherent within its security structure
are of international concern.</P>
<P>So, whenever a flaw is discovered within sendmail, FTP, Gopher, HTTP, or other
indispensable elements of the Internet, programmers develop patches (small programs
or source code) to temporarily solve the problem. These patches are distributed to
the world at large, along with detailed advisories. This brings us to vendor response.
<H4><FONT COLOR="#000077"><B>Vendor Response</B></FONT></H4>
<P>Vendor response has traditionally been good, but this shouldn't give you a false
sense of security. Vendors are in the business of selling software. To them, there
is nothing fascinating about someone discovering a hole in the system. At best, a
security hole represents a loss of revenue or prestige. Accordingly, vendors quickly
issue assurances to allay users' fears, but actual corrective action can sometimes
be long in coming.</P>
<P>The reasons for this can be complex, and often the vendor is not to blame. Sometimes,
immediate corrective action just isn't feasible, such as the following:

<UL>
	<LI>When the affected application is comprehensively tied to the operating-system
	source<BR>
	<BR>
	
	<LI>When the application is very widely in use or is a standard<BR>
	<BR>
	
	<LI>When the application is third-party software and that third party has poor support,
	has gone out of business, or is otherwise unavailable
</UL>

<P>In these instances, a patch (or other solution) can provide temporary relief.
However, for this system to work effectively, all users must know that the patch
is available. Notifying the public would seem to be the vendor's responsibility and,
to be fair, vendors post such patches to security groups and mailing lists. However,
vendors might not always take the extra step of informing the general public. In
many cases, it just isn't cost effective.</P>
<P>Once again, this issue breaks down to knowledge. Users who have good knowledge
of their network utilities, of holes, and of patches are well prepared. Users without
such knowledge tend to be victims. That, more than any other reason, is why I wrote
this book. In a nutshell, security education is the best policy.
<H2><FONT COLOR="#000077"><B>Why Education in Security Is Important</B></FONT></H2>
<P>Traditionally, security folks have attempted to obscure security information from
the average user. As such, security specialists occupy positions of prestige in the
computing world. They are regarded as high priests of arcane and recondite knowledge
that is unavailable to normal folks. There was a time when this approach had merit.
After all, users should be afforded such information only on a need-to-know basis.
However, the average American has now achieved need-to-know status.</P>
<P>So, I pose the question again: Who needs to be educated about Internet security?
The answer is: We all do. I hope that this book, which is both a cracker's manual
and an Internet security reference, will force into the foreground issues that need
to be discussed. Moreover, I wrote this book to increase awareness of security among
the general public. As such, this book starts with basic information and progresses
with increasing complexity. For the absolute novice, this book is best read cover
to cover. Equally, those readers familiar with security will want to quickly venture
into later chapters.</P>