Maximum Security:
A Hacker's Guide to Protecting Your Internet Site and Network
  
27
Firewalls
More than 50 percent of all users have heard of firewalls, but only a handful
know what a firewall really is. This is because firewalls are only used by those
actively engaged in protecting networks connected to the Internet.
What Is a Firewall?
A firewall is any device used to prevent outsiders from gaining access
to your network. This device is usually a combination of software and hardware. Firewalls
commonly implement exclusionary schemes or rules that sort out wanted and unwanted
addresses.
To understand how firewalls work, consider some of the subjects discussed earlier
in this book. First, most simple authentication procedures use the IP address as
an index. The IP address is the most universal identification index on the Internet.
This address can be either a static or dynamic address:
- A static IP address is permanent; it is the address of a machine that is always
connected to the Internet. There are many classes of static IP addresses. One class
can be discovered by issuing a whois query; this class consists primarily of top-level
machines in a network, such as domain name servers, Web servers, and root-level machines.
These actually have registered hostnames within the whois database at InterNIC. Other
classes of static IP addresses are addresses assigned to second- and third-level
machines within networks dominated by domain name servers, root servers, Web servers,
and so on. These also have permanent physical addresses. However, these machines
might or might not possess a registered hostname. In any event, their addresses are
registered as well.
- A dynamic IP address is one that is arbitrarily assigned to a different node
each time it connects to a network. Dynamic IP is often used by ISPs for dial-up
access--each time a node dials up, it is assigned a different IP address.
Whether your address is static or dynamic, it is used in all network traffic that
you conduct. For example, as discussed in Chapter 13, "Techniques to Hide One's
Identity," a Web server records your IP address when you request a Web page.
This is not to intrude on your privacy; it is done so that the server knows how to
send you the requested data. In a similar fashion, all network services capture your
IP (either temporarily or permanently) so they can return data to your address. In
essence, it works much like the postal service: Imagine if every letter mailed had
a return address. On the Internet, things are just so. The IP is the return address.
When a connection is made between your machine and a remote machine, various dialogs
may ensue. I discussed some of those dialogs in Chapter 6, "A Brief Primer on
TCP/IP." A common one--which you are apt to remember--is the TCP/IP three-way
handshake. At any rate, such dialogs occur, during which time your IP is known by
the target machine.
Under normal circumstances, where no firewall or other superseding utility (such
as TCP_Wrapper) has been installed, the dialog between your machine and the remote
machine occurs directly (see Figure 27.1).
FIGURE 27.1.
The route of information.
When I say that information travels directly, that is a very qualified term. As
you can see, the process (even without security measures) is complex:
- 1. The data originates somewhere within Your Network (which,
by the way, could refer to a machine in your home). In this case, you are connected
to your provider's network. For our purposes, your provider's network is Your
Network.
2. Information travels from your machine to a machine on the provider's network.
From there, the information travels through an Ethernet cable (or other means of
transport) to the main server of Your Network.
3. The server of Your Network passes this information to Router 1,
which promptly pours the information through the telephone line (or other high-speed
connection) to the Internet at large.
4. The information travels across the Internet (passing through many routers
and gateways along the way), ultimately reaching Router 2. Router 2 pipes the information
into Their Server; the information is then served via Ethernet (or other
transport) to Their Network.
NOTE: I have greatly simplified the network
outlay design by providing only relevant details. In practice, there might be all
sorts of devices located between Your Network and Their Network.
If neither side has installed security measures, the path is deemed (for all purposes)
direct. Router 2, for example, allows packets from any source (IP) address
to travel directly to Their Server and ultimately, to Their Network.
At no point during that travel do the packets meet an obstacle. This is a completely
insecure situation. However, for many years, this was the standard. Today, the type
of situation illustrated in Figure 27.1 is too dangerous. Over the years, network
engineers considered a wide range of solutions, including the firewall.
What Are the Components of a Firewall?
The most fundamental components of a firewall exist neither in software nor hardware,
but inside the mind of the person constructing it. A firewall, at its inception,
is a concept rather than a product; it is an idea in the architect's mind of who
and what will be allowed to access the network. Who and what dramatically
influence how network traffic (both incoming and outgoing) is routed. For this reason,
constructing a firewall is part art, part common sense, part ingenuity, and part
logic.
Suppose the architect knows a Web server must exist on the host network. This
Web server will obviously accept connections from almost any IP address. A restricted
area, therefore, must be created for that server. In other words, in providing Web
services from the host network, the architect must ensure that the Web server does
not endanger the remaining portions of the network. Likewise, incoming mail is also
an issue.
Specific Components and Characteristics
Firewalls can be composed of software, hardware, or, most commonly, both. The
software components can be either proprietary, shareware, or freeware. The hardware
can be any hardware that supports the software being used.
If hardware, a firewall can (and often does) consist of no more than a router.
As you will learn in Chapter 28, "Spoofing Attacks," routers have advanced
security features, including the capability to screen IP addresses. This screening
process allows you to define which IP addresses are allowed to connect and which
are not.
Other implementations consist of both hardware and software. (These can get pretty
eclectic. I have seen people using 386 boxes with shareware firewall/bridge products
on them.)
In any event, all firewalls share a common attribute: the capability to discriminate
or the capability to deny access generally based on source address.
Types of Firewalls
There are different kinds of firewalls, and each type has its advantages and disadvantages.
The most common type is referred to as a network-level firewall. Network-level
firewalls are usually router based. That is, the rules of who and what can access
your network is applied at the router level. This scheme is applied through a technique
called packet filtering, which is the process of examining the packets that
come to the router from the outside world.
In a router-based firewall implementation, the source address of each incoming
connection (that is, the address from which the packets originated) is examined.
After each IP source address has been identified, whatever rules the architect has
instituted will be enforced. For example, perhaps the architect decides that no network
traffic will be accepted from any address within Microsoft Corporation. Thus, the
router rejects any packets forwarded from microsoft.com. These packets never
reach the internal server or the network beneath it.
NOTE: Routers are about the size of a
small printer. Generally, at the back of the router are connection points for Ethernet
and digital telephone lines. Use these connection points to connect the telephone
line (T1, T3, and so on) and Ethernet to your server. Routers are configured using
special software. In most instances, the software is quite easy to use. Most newer
implementations are controlled through a windowed interface (such as the X Window
system, OpenWindows, and so on). Routers range in price (from used to new) from $600
to $1800.
Router-based firewalls are fast. Because they only perform cursory checks on the
source address, there is no real demand on the router. It takes no time at all to
identify a bad or restricted address. Nevertheless, the speed comes with a price:
Router-based firewalls use the source address as an index. That means (barring controls
against such access) packets sent from forged source addresses can gain at least
some level of access to your server.
In fairness, many packet-filtering techniques can be employed with router-based
firewalls that shore up this weakness. The IP address header is not the only field
of a packet that can be trapped by a router. As packet-filtering technology becomes
more sophisticated, so do the schemes or rules employed by an administrator. One
can now even apply rules related to state information within packets, using indexes
such as time, protocol, ports, and so forth.
Cross Reference: For an excellent discussion
of the fields that can be filtered, as well as a comprehensive look at packet filtering,
"Network (In)Security Through IP Packet Filtering" by D. Brent Chapman
is a must. Find it online at http://www.unix.geek.org.uk/~arny/pktfilt.ps.
However, these are not the only deficiencies of packet-filtering, router-based
firewalls. For example:
- Another problem is that a number of RPC (Remote Procedure Call) services are
very difficult to filter effectively because the associated servers listen at ports
that are assigned randomly at system startup. A service known as portmapper maps
initial calls to RPC services to the assigned service numbers, but there is no such
equivalent for a packet filtering router. Since the router cannot be told which ports
the services reside at, it isn't possible to block completely these services unless
one blocks all UDP packets (RPC services mostly use UDP). Blocking all UDP would
block potentially necessary services such as DNS. Thus, blocking RPC results in a
dilemma.
Cross Reference: The preceding paragraph
is excerpted from "Problems with Packet Filtering Routers" by John Wack.
It can be found online at http://www.telstra.com.au/pub/docs/security/800-10/node51.html.
Wack discusses RPC as a potential problem because the ports can be assigned dynamically
at startup. However, in most cases, this type of filtering (appropriately called
protocol filtering) is not a problem. Very sophisticated schemes can be implemented
in protocol filtering, and these rely primarily on the port called by the remote
host.
Cross Reference: For an excellent discussion
of protocol filtering and packet filtering in general, check out "Packet Filtering
in an IP Router" by Bruce Corbridge, Robert Hening, and Charles Slater. This
paper offers an inside look at exactly how packet filtering is accomplished in Telebit
routers. More importantly, the document takes you through the design and implementation
of the router. You can find it online at http://www.alw.nih.gov/Security/FIRST/papers/firewall/cslater.ps.
Packet Filtering Tools
Packet filtering can be implemented without instituting a complete firewall. There
are many free and commercial packet-filtering tools on the Internet. Following is
a list of several such utilities.
TCP_Wrappers
TCP_Wrappers is a program written by Wietse Venema (also the co-author of the
famous scanning utility, SATAN). Arguably, no other tool more easily or efficiently
facilitates monitoring connections to your machine. The program works by replacing
system daemons and recording all connection requests, their time, and most importantly,
their origin. For these reasons, TCP_Wrappers is one of the most critical evidence-gathering
tools available. TCP_Wrappers also has the capability to screen out unwanted networks
and IP addresses, preventing users from such addresses from connecting.
Cross Reference: TCP_Wrappers is available
online at ftp://ftp.win.tue.nl/pub/security/tcp_wrappers_7.4.tar.gz.
NetGate
NetGate (developed by SmallWorks) is a rule-based packet filtering system. It
was designed for use on SPARC systems running SunOS 4.1.x. Like most packet
filters, NetGate can examine each and every packet it encounters and can apply various
rules, based upon the source address revealed in that examination. (NetGate also
sports some pretty strong logging capabilities.) Reportedly, the distribution can
be obtained either as a binary installation ($1500) or source ($2500). If your company
needs a product with support (as opposed to freeware), I would recommend NetGate
as a reasonable and economical alternative to other, more high-profile products.
Cross Reference: You can find information
about NetGate at http://hosaka.smallworks.com/netgate/packetfiltering.html.
Internet Packet Filter
This interesting package is freely available. Written by Darren Reed, the Internet
Packet Filter has all the amenities of a finely coded, commercial application. (Reed
took particular pride in developing a package that could defeat the type of IP spoofing
attack that Kevin Mitnik purportedly launched against machines at the San Diego Supercomputer
Center.) Some interesting tidbits: Reed provided functionality not only to discard
TCP packets that were incomplete or malformed, but to do so silently (your host returns
no ICMP error). Internet Packet Filter also offers a comprehensive testing utility,
so you can ensure your rules are sound before you implement them. (The program actually
can take previous logs as input, and you can watch as the rules are applied. Very
cool.) It is available for SunOS.
Cross Reference: The Internet Packet Filter
can be found at ftp://coombs.anu.edu.au:/pub/net/kernel/ip_fil3.0.4.tar.gz.
Audit and Logging Tools
Packet filters, when used in conjunction with powerful auditing tools, can greatly
assist in protecting your network and identifying intruders. The right combination
of these types of tools can be every bit as effective as a commercial firewall (and
generally, a whole lot less expensive). Following are some good auditing tools.
Argus
Argus was developed at Carnegie Mellon University's Software Engineering Institute.
Argus is known to compile without errors, at least on the following platforms:
- SunOS 4.x
- Solaris 2.3
- SGI IRIX5.2
In the document announcing Argus's availability, authors report that Argus is
suitable for network monitoring, identifying potential network problems, and perhaps
most importantly, verifying access control policies.
Cross Reference: The document announcing
Argus's availability can be found online at ftp://ftp.sei.cmu.edu/pub/argus-1.5/argus-1.5.announce.
The tool can be obtained online at ftp://ftp.sei.cmu.edu/pub/argus-1.5/.
Netlog
Netlog, developed at Texas A&M University, can log all TCP and UDP traffic.
To use this product, you must have a C compiler that will take ANSI C conventions.
This tool also supports logging of ICMP messages (though the developers report that
performing this logging activity soaks up a great deal of storage).
Cross Reference: Netlog is available online
at ftp://coast.cs.purdue.edu/pub/tools/unix/TAMU/.
Netman
This tool is covered extensively in Chapter 12, "Sniffers." However,
I will reiterate that this is a suite of applications that is well crafted; it is
arguably the most complete package of its kind ever made.
Cross Reference: Netman is available online
at ftp://ftp.cs.curtin.edu.au/pub/netman/.
NOCOL/NetConsole v4.0
NOCOL/NetConsole v4.0 is a suite of standalone applications that perform a wide
variety of monitoring tasks. This suite offers a Curses interface, which is great
for running on a wide range of terminals (it does not require the X Window system
in order to work). It is extensible, has support for a Perl interface, and is quite
complex. It also operates on networks running AppleTalk and Novell NetWare.
Cross Reference: NOCOL/NetConsole v.4.0
is available online at ftp://ftp.navya.com/pub/vikas/nocol.tar.gz.
There are other platform-specific packet filters. One well-known one is packetfilter,
which runs on Ultrix 4.3. It is kernel resident.
Cross Reference: The man page for packetfilter
is available online at http://198.233.42.11/
cgi-bin/man2html/packetfilter(4).
Nonetheless, many of these tools, although capable of examining and monitoring
packet traffic, cannot institute access-control policies. And that is the whole purpose
of a firewall. It gives the administrator the ability to finely control who can (and
cannot) access the network.
Application-Proxy Firewalls/Application Gateways
Other types of firewalls exist. A common type is application-proxy firewalls
(sometimes referred to as application gateways). These work a bit differently
from packet-filtering, router-based firewalls. Application gateways are software-based.
When a remote user from the void contacts a network running an application gateway,
the gateway blocks the remote connection. Instead of passing the connection along,
the gateway examines various fields in the request. If these meet a set of predefined
rules, the gateway creates a bridge between the remote host and the internal host.
Bridge refers to a patch between two protocols. For example, in a typical
application gateway scheme, IP packets are not forwarded to the internal network.
Instead, a type of translation occurs, with the gateway as the conduit and interpreter.
This is sometimes referred to as the man-in-the-middle configuration.
The advantage of the application-gateway proxy model is the lack of IP forwarding.
More importantly, more controls can be placed on the patched connection. Finally,
such tools often offer very sophisticated logging facilities. Again, there is no
such thing as a free lunch. As you might expect, this gateway scheme has a cost in
terms of speed. Because each connection and all packet traffic are accepted, negotiated,
translated, and reforwarded, this implementation can be slower than router-based
packet filtering.
IP forwarding occurs when a server that receives an external request from
the outside world forwards that information in IP format to the internal network.
Leaving IP forwarding enabled is a fatal error. If you allow IP forwarding to occur,
a cracker can get in from the outside and reach workstations on your internal network.
Another disadvantage of this scheme is that a proxy application must be created
for each networked service. Thus, one is used for FTP, another for Telnet, another
for HTTP, and so forth. As John Wack explains in his article titled "Application
Gateways":
- A disadvantage of application gateways is that, in the case of client-server
protocols such as Telnet, two steps are required to connect inbound or outbound.
Some application gateways require modified clients, which can be viewed as a disadvantage
or an advantage, depending on whether the modified clients make it easier to use
the firewall. A Telnet application gateway would not necessarily require a modified
Telnet client, however it would require a modification in user behavior: the user
has to connect (but not log in) to the firewall as opposed to connecting directly
to the host. But a modified Telnet client could make the firewall transparent by
permitting a user to specify the destination system (as opposed to the firewall)
in the Telnet command. The firewall would serve as the route to the destination system
and thereby intercept the connection, and then perform additional steps as necessary
such as querying for a one-time password. User behavior stays the same, however at
the price of requiring a modified client on each system.
Cross Reference: "Application Gateways"
by John Wack can be found online at http://www.telstra.com.au/pub/docs/security/800-10/node52.html.
TIS FWTK
A typical example of an application-gateway firewall package is the Trusted Information
Systems (TIS) Firewall Tool Kit (hereinafter referred to as the FWTK). This
software package, early versions of which are free for noncommercial use, contains
many separate components. The majority of these components are proxy applications.
It includes proxies for the following services:
- Telnet
- FTP
- rlogin
- sendmail
- HTTP
- The X Window system
The FWTK is a comprehensive system. Nonetheless, it does not protect your network
immediately upon installation. This is not a product that you simply install and
abandon. The TIS FWTK is a tool kit. After you unpack the software, you must
make certain decisions. You must also understand what you are doing. This is not
a simple configuration problem. If you make erroneous rules or decisions along the
way, your network might be unreachable from the void, even from friendly networks.
Reading the documentation is paramount.
The beautiful thing about the FWTK is that it has excellent access control built
into its design. For example, you can allow or deny access (connection) from a network,
a part of a network, or even a single address. In this respect, it has granular access
control.
Cross Reference: Before you get the TIS
FWTK, you should probably examine a posting of a message from Marcus Ranum, one of
the developers of TIS FWTK. This is a short, entertaining document that gives some
insight into how the FWTK started. That document is located online at http://www.micrognosis.com/~nreadwin/fwtk/history.txt.
Cross Reference: Obtain a copy of the
TIS Firewall Tool Kit at ftp://ftp.tis.com/pub/firewalls/toolkit/dist/.
Cross Reference: The FWTK requires a UNIX
system and a C compiler. Moreover, although the FWTK is known to compile on SunOS
and BSD without problems, configuration issues exist for Linux. To sort out these
problems quickly, there is no better document than "Creating a Linux Firewall
using the TIS Toolkit" by Benjamin Ewy. That document is located online at http://www.ssc.com/lj/issue25/1204.html.
Patches for use with the FWTK on Linux are located online at ftp://ftp.tisl.ukans.edu/pub/security/firewalls/fwtkpatches.tgz.
The reason I mention the TIS FWTK is because it was the first, full-fledged firewall
of this class. It was a ground breaker in the firewall field.
Cross Reference: "Thinking About
Firewalls," also by Marcus Ranum, is a very good document about firewalls in
general. This document details the types of firewalls that can be implemented and
their advantages and disadvantages. It can be found online at http://hp735c.csc.cuhk.hk/ThinkingFirewalls.html.
NOTE: Another extremely popular firewall
in this class is SOCKS, which is based on the application-proxy model. The connect
request is intercepted by SOCKS and translated. Thus, a direct connection never occurs
between your network and the outside world. SOCKS is of great significance because
it is so well established that support for it is already included in many browser
packages, most notably Netscape Navigator.
Cross Reference: There is a very comprehensive
coverage of SOCKS technology on the Internet. The document is so well designed and
written that anyone can get a solid grasp of how SOCKS works in just a few moments.
That document is at http://www.socks.nec.com/introduction.html.
It is my opinion that application-gateway systems (proxy-based firewalls) are
more secure. This is because there is no IP forwarding scheme. That means IP packets
from the void cannot reach any machine on your internal network.
Firewalls Generally
One of the main ideas behind a firewall is that your network will remain theoretically
invisible (or at least unreachable) to anyone not authorized to connect. This process
works through the exclusionary schemes that one can apply using a firewall.
CAUTION: Your firewalled network will
not be entirely invisible. At least one scanner, called Jakal, can scan for
services running behind a firewall. Jakal, a stealth scanner, will scan a domain
(behind a firewall) without leaving any trace of the scan. According to the authors,
all alpha test sites were unable to log any activity (though it is reported that
"some firewalls did allow SYN | FIN to pass through"). Refer to Chapter
9, "Scanners," for the scoop on that utility.
Theoretically, a firewall is the most stringent security measure you can implement
(barring, of course, disconnecting your system from the Internet). Nevertheless,
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.
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.
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.
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.
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, some time
is generally only a few months, but during those months, your internal users will
fuss.
Building a Firewall: What You Need to Know
The construction of a firewall is not for the faint of heart. It is for a system
administrator (or other individual) who intimately knows the network to be
firewalled. The process is not simple; the steps include
- 1. Identifying topology and protocol needs
2. Developing policies
3. Having adequate tools
4. Using those tools effectively
5. Testing the configuration
Identifying Topology and Protocol Needs
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.
It is important to maintain your tact during this process. You will often run
into users who insist, "We've been doing it this way for 10 years now."
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.
NOTE: 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).
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.
NOTE: 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.
Are Firewalls Foolproof?
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.
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
- Sorting out the real components from the fake ones--Many firewalls use sacrificial
hosts, machines designed either as Web servers (that the owners are willing to
part with) or decoys. Decoys 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.
Cross Reference: Decoys bear at least a fleeting
resemblance to the box (reportedly built by Steven Bellovin) described in the article
by B. Cheswick titled "An Evening With Berferd In Which a Cracker is Lured,
Endured and Studied." This article can be found online at ftp://research.att.com/dist/internet_security/berferd.ps.
- 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.
- 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.
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.
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 Wired
that:
- 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.
Cross Reference: The preceding paragraph
is excerpted from "Hackers Hack Crack, Steal Quake," an article, by Annaliza
Savage, that appeared in Wired. Find the article online at http://www.wired.com/news/culture/story/1418.html.
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 how they are blocked (that is, you need to elicit responses from
the firewall).
Commercial Firewalls
The Eagle Family of Firewalls by Raptor
Company: Raptor Systems
Specs: http://www.raptor.com/products/brochure/40broch.html
Home: http://www.raptor.com
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:
- ...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.
Cross Reference: Check out Raptor's online
company description at http://www.raptor.com/products/brochure/40broch.html#aboutraptor.
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.
Check Point Firewall and Firewall-1
Company: Check Point Software Technologies Ltd.
Specs: http://www.checkpoint.com/products/firewall/intro.html
Home: http://www.checkpoint.com/
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.
Cross Reference: Articles and press releases
about Check Point are located online at http://www.checkpoint.com/press/index.html.
More important information about Check Point's flagship product is located at http://www.checkpoint.com/products/white/index.html.
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.
SunScreen
Company: Sun Microsystems
Specs: http://www.sun.com/security/overview.html
Home: http://www.sun.com
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
- 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.
- SunScreenTM EFS--Implements heavy-duty packet
filtering and more importantly, encryption. Special amenities include provisions
for remote administration and administration through an HTML interface.
Cross Reference: Some specs for SunScreen
EFS are located online at http://www.sun.com/security/prod_spec.html.
- SunScreenTM SKIP--This is an interesting product
that provides PCs and workstations with secure authentication.
Cross Reference: Check out SunScreen SKIP
online at http://www.sun.com/security/skip.html.
IBM Internet Connection Secured Network Gateway
Company: Internal Business Machines (IBM)
Specs: http://www.ics.raleigh.ibm.com/firewall/info.htm
Home: http://www.ics.raleigh.ibm.com/firewall/overview.htm
This product is designed for AIX. Like Sun's SunScreen product line, it is capable
of hiding the IPs of your internal network. It supports application proxies and has
exceptional logging and reporting capabilities, as well as isolated Web services.
Cross Reference: For an extremely comprehensive
study of IBM's Internet Connection Secured Network Gateway, visit http://www.ncsa.com/fpfs/ibm.html
at NCSA.
Cisco PIX Firewall
Company: Cisco Systems
Specs: http://www.cisco.com/univercd/data/doc/cintrnet/prod_cat/pcpix.htm
Home: http://www.cisco.com
This firewall relies not on application proxies (which can consume additional
network resources and CPU time) but instead on a secure operating system within the
hardware component itself. Special features include an HTML configuration and administration
control tool, IP concealment and non-translation, easy configuration, and support
for 16,000 instant connections.
Summary
Firewalls now comprise the most commonly accepted method of protecting a network
and, for the most part, seem to be impenetrable when attacked by 95 percent of the
cracking community. Moreover, firewall technology is yet in its infancy. Nevertheless,
firewalls have been cracked in the past. It is also worth noting that some firewalls
can raise security issues themselves. For example, it was recently found that the
Gopher proxy in a Raptor product can, under certain circumstances, leave a Windows
NT server vulnerable to a denial-of-service attack. (The CPU climbs to near 100 percent
utilization.)
The future of firewall technology is a very interesting field indeed. However,
if you have truly sensitive data to protect (and it must be connected to the Internet),
I advise against using a firewall (commercial or otherwise) as your only means of
defense.
Resources
Internet Firewalls and Network Security (Second Edition). Chris Hare and
Karanjit Siyan. New Riders. ISBN: 1-56205-632-8. 1996.
Internet Firewalls. Scott Fuller and Kevin Pagan. Ventana Communications
Group Inc. ISBN: 1-56604-506-1. 1997.
Building Internet Firewalls. D. Brent Chapman and Elizabeth D. Zwicky.
O'Reilly & Associates. ISBN: 1-56592-124-0. 1995.
Firewalls and Internet Security : Repelling the Wily Hacker. William R.
Cheswick and Steven M. Bellovin. Addison-Wesley Professional Computing. ISBN: 0-201-63357-4.
1994.
Actually Useful Internet Security Techniques. Larry J. Hughes, Jr. New
Riders. ISBN: 1-56205-508-9. 1995.
Internet Security Resource Library: Internet Firewalls and Network Security,
Internet Security Techniques, Implementing Internet Security. New Riders. ISBN:
1-56205-506- 2. 1995.
Firewalls FAQ. Marcus J. Ranum.
NCSA Firewall Policy Guide. Compiled by Stephen Cobb, Director of Special
Projects. National Computer Security Association.
Comparison: Firewalls. Comprehensive comparison of a wide variety of firewall
products. LANTimes. June 17, 1996.
There Be Dragons. Steven M. Bellovin. Proceedings of the Third Usenix UNIX
Security Symposium, Baltimore, September 1992. AT&T Bell Laboratories, Murray
Hill, NJ. August 15, 1992.
Rating of Application Layer Proxies. Michael Richardson.
Keeping Your Site Comfortably Secure: An Introduction to Internet Firewalls.
John P. Wack and Lisa J. Carnahan. National Institute of Standards and Technology.
SQL*Net and Firewalls. David Sidwell and Oracle Corporation.
Covert Channels in the TCP/IP Protocol Suite. Craig Rowland. Rotherwick
& Psionics Software Systems Inc.
If You Can Reach Them, They Can Reach You. William Dutcher. A PC Week Online
Special Report, June 19, 1995.
Packet Filtering for Firewall Systems. February 1995. CERT (and Carnegie
Mellon University).
Network Firewalls. Steven M. Bellovin and William R. Cheswick. IEEECM,
32(9), pp. 50-57, September 1994.
Session-Layer Encryption. Matt Blaze and Steve Bellovin. Proceedings of
the Usenix Security Workshop, June 1995.
A Network Perimeter With Secure External Access. Frederick M. Avolio and
Marcus J. Ranum. An extraordinary paper that details the implementation of a firewall
purportedly at the White House.
Packets Found on an Internet. Steven M. Bellovin. Lambda. Interesting analysis
of packets appearing at the application gateway of AT&T.
Using Screend to Implement TCP/IP Security Policies. Jeff Mogul. Rotherwick
and Digital.
Firewall Application Notes. Livingston Enterprises, Inc. Good document
that starts by describing how to build a firewall. It also addresses application
proxies, Sendmail in relation to firewalls, and the characteristics of a bastion
host.
X Through the Firewall, and Other Application Relays. Treese/Wolman. Digital
Equipment Corp. Cambridge Research Lab.
Intrusion Protection for Networks 171. BYTE Magazine. April, 1995.
Benchmarking Methodology for Network Interconnect Devices (RFC 1944). S.
Bradner and J. McQuaid.
Firewall Performance Measurement Techniques: A Scientific Approach. Marcus
Ranum.
Warding Off the Cyberspace Invaders. Amy Cortese. Business Week.
03/13/95.
Vulnerability in Cisco Routers Used as Firewalls. Computer Incident Advisory
Capability Advisory: Number D-15.
WAN-Hacking with AutoHack--Auditing Security behind the Firewall. Alec
D.E. Muffett. Written by the author of Crack, the famous password-cracking program.
Extraordinary document that deals with methods of auditing security from behind a
firewall (and auditing of a network so large that it contained tens of thousands
of hosts).
Windows NT Firewalls Are Born. PC Magazine. February 4, 1997.
IP v6 Release and Firewalls. Uwe Ellermann. 14th Worldwide Congress on
Computer and Communications Security. Protection, pp. 341-354, June 1996.
The SunScreen Product Line Overview. Sun Microsystems.
Product Overview for IBM Internet Connection Secured Network Gateway for AIX,
Version 2.2. IBM firewall information.
The Eagle Firewall Family. Raptor firewall information.
Secure Computing Firewall&tm; for NT. Overview. Secure Computing.
Check Point FireWall-1 Introduction. Check Point Technologies firewall
information.
Cisco PIX Firewall. Cisco Systems firewall information.
Protecting the Fortress From Within and Without. R. Scott Raynovich. LAN
Times. April 1996.
Internet Firewalls: An Introduction. Firewall white paper. NMI Internet
Expert Services.
Features of the CentriTM Firewall.
Centri firewall information.
Five Reasons Why an Application Gateway Is the Most Secure Firewall. Global
Internet.
© Copyright, Macmillan Computer Publishing. All
rights reserved.
| 
