|
|
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.
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:
Ø
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.
Ø
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.
Ø
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.
Ø
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.
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. 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.
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.
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.
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.
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 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.
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.
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.
Audit and Logging Tools
Argue
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
Ø
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.
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), we advise against using a firewall (commercial or otherwise) as your only means of defense.