ch27.htm

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

issues regarding this stringent security environment remain. One is that security
with a firewall can be configured so stringently that it can actually impair the
process of networking. For example, some studies suggest that the use of a firewall
is impractical in environments where users critically depend on distributed applications.
Because firewalls implement such a strict security policy, these environments become
bogged down. What they gain in security, they lose in functionality. Universities
are a perfect example of this type of environment. Research in universities is often
conducted where two or more departments (often on network segments located far from
each other) are involved in the compilation of data (and corroboration of research
efforts). In these environments, it is very difficult to work under such tight security
restraints.</P>
<P>A second issue regarding firewalls is that they lead to placing most of your eggs
in one basket. Because a firewall is your face to the void, a breach can cause your
internal network to be easily destroyed. That is, firewalls can foster a climate
in which they are the only real access control and security you have. Firewalls are
almost always described as the bottleneck of a network, where all authentication
is to be done. This seems suitable as long as firewalls are infallible. But what
if they aren't? What if a technique is discovered to crack any firewall? Networks
that rely on firewalls would be completely exposed, and odds of survival would be
slim.</P>
<P>Before you construct a firewall, you should undertake some serious research. When
you construct a firewall, you must know your network intimately. This requires true
organization. Various network segments (either on the same network or different ones)
will need to communicate with each other. These networks can communicate through
automated processes or human interaction. Automated processes might prove easy to
accommodate. Human-initiated processes, however, can differ dramatically.</P>
<P>For some organizations, a firewall is just plain impractical. ISPs are within
this class. One could quickly lose customers by instituting harsh security policies.
Indeed, some contend that firewalls are not needed. These people argue that solid
system administration practices will render the same benefit as a firewall, without
slowing the network or making connections difficult.</P>
<P>There are other problems with establishing a firewall as well. If FTP, Telnet,
Gopher, HTTP, RPC, rlogin, and NFS were the only protocols that the Internet would
ever use, a firewall would pose only limited problems with access. After all, proxies
have been written for all of these applications. The problem is, these are not the
only services; new services crop up each month. Thus, to provide your internal users
with effective Internet access, you must keep up with the applications now emerging.
Proxies for such services will generally be obtainable, but after the new service
or protocol has already been on the market for some time. Of course, <I>some time</I>
is generally only a few months, but during those months, your internal users will
fuss.
<H2><FONT COLOR="#000077"><B>Building a Firewall: What You Need to Know</B></FONT></H2>
<P>The construction of a firewall is not for the faint of heart. It is for a system
administrator (or other individual) who <I>intimately</I> knows the network to be
firewalled. The process is not simple; the steps include

<DL>
	<DD><B>1. </B>Identifying topology and protocol needs<BR>
	<BR>
	<B>2.</B> Developing policies<BR>
	<BR>
	<B>3. </B>Having adequate tools<BR>
	<BR>
	<B>4.</B> Using those tools effectively<BR>
	<BR>
	<B>5. </B>Testing the configuration
</DL>

<H3><FONT COLOR="#000077"><B>Identifying Topology and Protocol Needs</B></FONT></H3>
<P>The first step is to understand the network in its entirety. This task might involve
more than simply looking over the machines, the logs, and so forth. It might involve
discussing these matters with individual departments. For example, in larger networks,
there might be many interactions between a specific department in one building and
a specific department in another. These buildings might be located hundreds or even
thousands of miles away from each other. You need to know what type of outgoing traffic
users require.</P>
<P>It is important to maintain your tact during this process. You will often run
into users who insist, &quot;We've been doing it this way for 10 years now.&quot;
Even though you have great authority (because security is such a serious concern),
you should work with these people as much as possible. It is not necessary that they
understand the process in full. Nevertheless, if you intend to restrict or otherwise
hamper their ability to reach out into the void, you should explain why to them.
The last thing you need is to anger (or otherwise foster resentment within) local
users. Rather, you need their support because after you finish building your firewall,
you will distribute a policy. How closely local users follow that policy will dramatically
affect the security of your network. For example, if insecure modems are located
in this or that department, this is a potential hole. If you have dealt tactfully
with local users, you will probably have nothing to fear. However, if you have issued
Draconian decrees, you can be pretty sure that local users will trip you up.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>I hear folks dispute this all the
	time. They insist that no one can simply install a modem on a machine. Why not? I
	have seen it happen in many companies. There is nothing in a policy alone that will
	prevent an employee from doing so. Furthermore, on networks with PC-based workstations,
	many machines or workstations have internal modems to begin with. I dealt with one
	client who had a Novell NetWare network from the old days. Even the client was unaware
	that some machines had modems (1200 baud, of course). 
<HR>


</BLOCKQUOTE>

<P>So, your first job is to determine what can and cannot be restricted. A list should
be made of all nonstandard protocols that are essential between this network and
any other. That done, you can begin to get a picture of how the firewall will be
built (at least, the local access policies). Determining whom (or what) not to let
in is a little less perplexing. More than likely, you will want to restrict connections
from any network known to forward unsolicited e-mail, sexual content, or other materials
not related to your business. You might also want to restrict addresses that are
known hacking or cracking havens.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>I would restrict all known hacking
	and cracking addresses. For example, a well- known hacking group recently conducted
	a wide scan of U.S. domains, purportedly under the guise of security research. This
	caused a stir in security-related mailing lists and newsgrouqa and rightly so. 
<HR>


</BLOCKQUOTE>

<H3><FONT COLOR="#000077"><B>Are Firewalls Foolproof?</B></FONT></H3>
<P>Are firewalls foolproof? Are humans foolproof? The answer to both questions is
no. Firewall products have not been proven to be flawed, but human implementation
has. Crackers have conducted various studies on breaking firewalls. The majority
of those studies point to two phases of an attack. The first is to discover what
type of firewall exists on a particular network and what type of services are running
behind it. That first task has already been encapsulated in an automated package;
the Jakal scanner can accomplish this for you.</P>
<P>The second task, finding a hole in the firewall, is a bit more difficult. Cracker
studies indicate that if there is such a hole, it exists as a result of human error
(or rather, misconfiguration on the part of the system administrator). This is not
a rare occurrence. One must recognize that no matter what platform is in use, this
is a problem. In UNIX networks, it can be at least partially attributed to the fact
that UNIX is so complex. There are hundreds of native applications, protocols, and
commands. This is before you begin to construct a firewall. Failed firewall implementation
on Microsoft platforms might occur for other reasons (for instance, because administrators
might be unfamiliar with TCP/IP). In either case, human error is a likely possibility.
For this reason, companies should be extremely selective when choosing the personnel
responsible for implementing the firewall. Some common cracker agendas include

<UL>
	<LI>Sorting out the real components from the fake ones--Many firewalls use <I>sacrificial
	hosts</I>, machines designed either as Web servers (that the owners are willing to
	part with) or decoys. <I>Decoys</I> are nothing more than traps, places where an
	inexperienced cracker's activities are captured and logged. These can employ complex
	means of veiling their bogus character. For example, they might issue responses to
	emulate a real file system or real applications. These generally are deeply entrenched
	in a chroot'd environment. The cracker's first task is to identify what viable targets
	might actually exist.
</UL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference: </B></FONT>Decoys bear at least a fleeting
	resemblance to the box (reportedly built by Steven Bellovin) described in the article
	by B. Cheswick titled &quot;An Evening With Berferd In Which a Cracker is Lured,
	Endured and Studied.&quot; This article can be found online at <A HREF="ftp://research.att.com/dist/internet_security/berferd.ps"><TT>ftp://research.att.com/dist/internet_security/berferd.ps</TT></A>.
	
<HR>


</BLOCKQUOTE>


<UL>
	<LI>Trying to get some definitive information about the internal system--This applies
	especially to machines that serve mail and other services. At a minimum, you should
	attempt to get an insider to send you a mail message so that the paths can be examined.
	This might give you a clue as to how some portions of the network are constructed.<BR>
	<BR>
	
	<LI>Keeping up with the current advisories--In certain situations, new bugs arise
	in commonly used programs that can run on or behind the firewall. These holes might
	be able to get you at least the minimum access necessary to gain a better look.
</UL>

<P>Also, no firewall can effectively prevent attacks from the inside. If a cracker
can place someone (perhaps himself or herself) in your employ, it won't be long before
your network is cracked. I know someone who managed to gain employment with a well-known
oil company. That hacker collected extensive information not only about the internal
network there, but also about the firewall hosts.</P>
<P>Finally, firewalls have been bypassed or broken in the past. The Quake site at
Crack dot Com is one such example. Although relatively little information has been
distributed about how the crack was accomplished, it was reported in <I>Wired</I>
that:

<DL>
	<DD>Hackers broke into the Web server and file server of Crack dot Com, a Texas gaming
	company, on Wednesday, stealing the source code for id's Quake 1.01, as well as Crack's
	newest project, Golgotha, and older games Abuse and Mac Abuse...The hackers, who
	were able to get through the Crack's firewall, left intact a bash-history file that
	recorded all their movements.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>The preceding paragraph
	is excerpted from &quot;Hackers Hack Crack, Steal Quake,&quot; an article, by Annaliza
	Savage, that appeared in <I>Wired</I>. Find the article online at <A HREF="http://www.wired.com/news/culture/story/1418.html"><TT>http://www.wired.com/news/culture/story/1418.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>It is possible to identify the type of firewall being run on a given server. However,
printing that is beyond the level of irresponsibility to which I am prepared to stoop
just to sell a book. I will say this: You can do it with a combination of the Jakal
scanner and a script written to jackhammer a site. Which addresses are blocked matters
less than <I>how</I> they are blocked (that is, you need to elicit responses from
the firewall).
<H2><FONT COLOR="#000077"><B>Commercial Firewalls</B></FONT></H2>
<P><B>The Eagle Family of Firewalls by Raptor</B></P>
<P>Company: Raptor Systems</P>
<P>Specs: <A HREF="http://www.raptor.com/products/brochure/40broch.html"><TT>http://www.raptor.com/products/brochure/40broch.html</TT></A></P>
<P>Home: <A HREF="http://www.raptor.com"><TT>http://www.raptor.com</TT></A><TT></TT></P>
<P>Raptor has been around a long time. It introduced its line of firewall products
in 1991. The company has a solid reputation. As stated in its online company description:

<DL>
	<DD>...Raptor Systems' award-winning Eagle family of firewalls provides security
	across a range of industries, including telecommunications, entertainment, aerospace,
	defense, education, health care, and financial services. Raptor has numerous strategic
	relationships with world-class companies like Compaq Computer Corporation, Siemens-Nixdorf,
	Hewlett-Packard, Sprint, and Shiva Corporation.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>Check out Raptor's online
	company description at <A HREF="http://www.raptor.com/products/brochure/40broch.html#aboutraptor"><TT>http://www.raptor.com/products/brochure/40broch.html#aboutraptor</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>Its products combine a wide range of firewall techniques, including heavy logging;
specialized, event-triggered treatment of suspicious activity; and extremely granular
access controls. This family of firewall products integrates application proxies.</P>
<P><B>Check Point Firewall and Firewall-1</B></P>
<P>Company: Check Point Software Technologies Ltd.</P>
<P>Specs: <A HREF="http://www.checkpoint.com/products/firewall/intro.html"><TT>http://www.checkpoint.com/products/firewall/intro.html</TT></A></P>
<P>Home: <A HREF="http://www.checkpoint.com/"><TT>http://www.checkpoint.com/</TT></A><TT></TT></P>
<P>Check Point is based in Israel and was founded in 1993. It also has outposts in
eight U.S. cities, including Redwood City, Los Angeles, New York, and others. The
product line offers cross-platform support.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>Articles and press releases
	about Check Point are located online at <A HREF="http://www.checkpoint.com/press/index.html"><TT>http://www.checkpoint.com/press/index.html</TT></A>.
	More important information about Check Point's flagship product is located at <A
	HREF="http://www.checkpoint.com/products/white/index.html"><TT>http://www.checkpoint.com/products/white/index.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>One of the more interesting elements of Check Point Firewall-1 is that it includes
time object control. That is, one can assign certain times of the day to perform
certain access restrictions. Firewall-1 also has provisions to distribute process
loads among a series of workstations.</P>
<P><B>SunScreen</B></P>
<P>Company: Sun Microsystems</P>
<P>Specs: <A HREF="http://www.sun.com/security/overview.html"><TT>http://www.sun.com/security/overview.html</TT></A></P>
<P>Home: <A HREF="http://www.sun.com"><TT>http://www.sun.com</TT></A><TT></TT></P>
<P>Sun's SunScreen is comprised of a series of products. In the SunScreen product
line, Sun has addressed one of the primary problems I mentioned previously: If your
bottleneck is broken, your network is completely exposed. Sun's new line of products
will likely revolutionize the firewall industry (certainly on the Sun platform).
The chief products include

<UL>
	<LI>SunScreen SPF 100/100G--Turnkey solution that provides non-IP-address capability.
	That is, crackers from the outside cannot reliably identify the nodes behind the
	wall. Moreover, heavy packet-filtering technology has been added.<BR>
	<BR>
	
	<LI>SunScreen<FONT SIZE="1"><SUP>TM</SUP></FONT> EFS--Implements heavy-duty packet
	filtering and more importantly, encryption. Special amenities include provisions
	for remote administration and administration through an HTML interface.
</UL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>Some specs for SunScreen
	EFS are located online at <A HREF="http://www.sun.com/security/prod_spec.html"><TT>http://www.sun.com/security/prod_spec.html</TT></A>.
	
<HR>


</BLOCKQUOTE>


<UL>
	<LI>SunScreen<FONT SIZE="1"><SUP>TM</SUP></FONT> SKIP--This is an interesting product