FAQ TOC |
Previous Section |
Next Section
Before being able to understand a complete discussion of firewalls,
it's important to understand the basic principles that make firewalls
work.
A firewall is a system or group of systems that enforces an access
control policy between two networks. The actual means by which this is
accomplished varies widely, but in principle, the firewall can be
thought of as a pair of mechanisms: one which exists to block traffic,
and the other which exists to permit traffic. Some firewalls place a
greater emphasis on blocking traffic, while others emphasize
permitting traffic. Probably the most important thing to recognize
about a firewall is that it implements an access control policy. If
you don't have a good idea of what kind of access you want to allow or
to deny, a firewall really won't help you. It's also important to
recognize that the firewall's configuration, because it is a mechanism
for enforcing policy, imposes its policy on everything behind it.
Administrators for firewalls managing the connectivity for a large
number of hosts therefore have a heavy responsibility.
The Internet, like any other society, is plagued with the kind of
jerks who enjoy the electronic equivalent of writing on other people's
walls with spraypaint, tearing their mailboxes off, or just sitting in
the street blowing their car horns. Some people try to get real work
done over the Internet, and others have sensitive or proprietary data
they must protect. Usually, a firewall's purpose is to keep the jerks
out of your network while still letting you get your job done.
Many traditional-style corporations and data centers have computing
security policies and practices that must be adhered to. In a case
where a company's policies dictate how data must be protected, a
firewall is very important, since it is the embodiment of the
corporate policy. Frequently, the hardest part of hooking to the
Internet, if you're a large company, is not justifying the expense or
effort, but convincing management that it's safe to do so. A firewall
provides not only real security--it often plays an important role as
a security blanket for management.
Lastly, a firewall can act as your corporate ``ambassador'' to the
Internet. Many corporations use their firewall systems as a place to
store public information about corporate products and services, files
to download, bug-fixes, and so forth. Several of these systems have
become important parts of the Internet service structure (e.g.:
UUnet.uu.net, whitehouse.gov, gatekeeper.dec.com) and
have reflected well on their organizational sponsors.
Some firewalls permit only email traffic through them, thereby
protecting the network against any attacks other than attacks against
the email service. Other firewalls provide less strict protections,
and block services that are known to be problems.
Generally, firewalls are configured to protect against unauthenticated
interactive logins from the ``outside'' world. This, more than anything,
helps prevent vandals from logging into machines on your network. More
elaborate firewalls block traffic from the outside to the inside, but
permit users on the inside to communicate freely with the outside. The
firewall can protect you against any type of network-borne attack if
you unplug it.
Firewalls are also important since they can provide a single ``choke
point'' where security and audit can be imposed. Unlike in a situation
where a computer system is being attacked by someone dialing in with a
modem, the firewall can act as an effective ``phone tap'' and tracing
tool. Firewalls provide an important logging and auditing function;
often they provide summaries to the administrator about what kinds and
amount of traffic passed through it, how many attempts there were to
break into it, etc.
This is an important point: providing this ``choke point'' can serve
the same purpose on your network as a guarded gate can for your site's
physical premises. That means anytime you have a change in ``zones''
or levels of sensitivity, such a checkpoint is appropriate. A company
rarely has only an outside gate and no receptionist or security staff
to check badges on the way in. If there are layers of security on
your site, it's reasonable to expect layers of security on your
network.
Firewalls can't protect against attacks that don't go through the
firewall. Many corporations that connect to the Internet are very
concerned about proprietary data leaking out of the company through
that route. Unfortunately for those concerned, a magnetic tape can
just as effectively be used to export data. Many organizations that
are terrified (at a management level) of Internet connections have no
coherent policy about how dial-in access via modems should be
protected. It's silly to build a 6-foot thick steel door when you live
in a wooden house, but there are a lot of organizations out there
buying expensive firewalls and neglecting the numerous other
back-doors into their network. For a firewall to work, it must
be a part of a consistent overall organizational security
architecture. Firewall policies must be realistic and reflect the
level of security in the entire network. For example, a site with top
secret or classified data doesn't need a firewall at all: they
shouldn't be hooking up to the Internet in the first place, or the
systems with the really secret data should be isolated from the rest
of the corporate network.
Another thing a firewall can't really protect you against is traitors
or idiots inside your network. While an industrial spy might export
information through your firewall, he's just as likely to export it
through a telephone, FAX machine, or floppy disk. Floppy disks are a
far more likely means for information to leak from your organization
than a firewall! Firewalls also cannot protect you against stupidity.
Users who reveal sensitive information over the telephone are good
targets for social engineering; an attacker may be able to break into
your network by completely bypassing your firewall, if he can find a
``helpful'' employee inside who can be fooled into giving access to a
modem pool. Before deciding this isn't a problem in your
organization, ask yourself how much trouble a contractor has getting
logged into the network or how much difficulty a user who forgot his
password has getting it reset. If the people on the help desk believe
that every call is internal, you have a problem.
Lastly, firewalls can't protect against tunneling over most
application protocols to trojaned or poorly written clients. There
are no magic bullets and a firewall is not an excuse to not implement
software controls on internal networks or ignore host security on
servers. Tunneling ``bad'' things over HTTP, SMTP, and other
protocols is quite simple and trivially demonstrated. Security isn't
``fire and forget''.
Firewalls can't protect very well against things like viruses. There
are too many ways of encoding binary files for transfer over networks,
and too many different architectures and viruses to try to search for
them all. In other words, a firewall cannot replace
security-consciousness on the part of your users. In general, a
firewall cannot protect against a data-driven attack--attacks in
which something is mailed or copied to an internal host where it is
then executed. This form of attack has occurred in the past against
various versions of sendmail, ghostscript, and
scripting mail user agents like OutLook.
Organizations that are deeply concerned about viruses should implement
organization-wide virus control measures. Rather than trying to screen
viruses out at the firewall, make sure that every vulnerable desktop
has virus scanning software that is run when the machine is rebooted.
Blanketing your network with virus scanning software will protect
against viruses that come in via floppy disks, modems, and Internet.
Trying to block viruses at the firewall will only protect against
viruses from the Internet--and the vast majority of viruses are
caught via floppy disks.
Nevertheless, an increasing number of firewall vendors are offering
``virus detecting'' firewalls. They're probably only useful for naive
users exchanging Windows-on-Intel executable programs and
malicious-macro-capable application documents. There are many
firewall-based approaches for dealing with problems like the
``ILOVEYOU'' worm and related attacks, but these are really
oversimplified approaches that try to limit the damage of something
that is so stupid it never should have occurred in the first place.
Do not count on any protection from attackers with this feature.
A strong firewall is never a substitute for sensible software that
recognizes the nature of what it's handling--untrusted data from an
unauthenticated party--and behaves appropriately. Do not think that
because ``everyone'' is using that mailer or because the vendor is a
gargantuan multinational company, you're safe. In fact, it isn't true
that ``everyone'' is using any mailer, and companies that specialize
in turning technology invented elsewhere into something that's ``easy
to use'' without any expertise are more likely to produce software
that can be fooled.
Some have argued that this is the case. Before pronouncing such a
sweeping prediction, however, it's worthwhile to consider what IPSEC
is and what it does. Once we know this, we can consider whether IPSEC
will solve the problems that we're trying to solve with firewalls.
IPSEC (IP SECurity) refers to a set of standards developed by the
Internet Engineering Task Force (IETF). There are many documents that
collectively define what is known as ``IPSEC'' [4]. IPSEC
solves two problems which have plagued the IP protocol suite for
years: host-to-host authentication (which will let hosts know that
they're talking to the hosts they think they are) and encryption
(which will prevent attackers from being able to watch the traffic
going between machines).
Note that neither of these problems is what firewalls were created to
solve. Although firewalls can help to mitigate some of the risks
present on an Internet without authentication or encryption, there are
really two classes of problems here: integrity and privacy of the
information flowing between hosts and the limits placed on what kinds
of connectivity is allowed between different networks. IPSEC
addresses the former class and firewalls the latter.
What this means is that one will not eliminate the need for the other,
but it does create some interesting possibilities when we look at
combining firewalls with IPSEC-enabled hosts. Namely, such things as
vendor-independent virtual private networks (VPNs), better packet
filtering (by filtering on whether packets have the IPSEC
authentication header), and application-layer firewalls will be able
to have better means of host verification by actually using the IPSEC
authentication header instead of ``just trusting'' the IP address
presented.
There are several books that touch on firewalls. The best known are:
Related references are:
- Internetworking with TCP/IP Vols I
, II
, and III
- Authors
- Douglas Comer and David Stevens
- Publisher
- Prentice-Hall
- Edition
- 1991
- ISBN
- 0-13-468505-9 (I), 0-13-472242-6 (II), 0-13-474222-2
(III)
- Comment
- A detailed discussion on the architecture and
implementation of the Internet and its protocols. Volume I (on
principles, protocols and architecture) is readable by everyone.
Volume 2 (on design, implementation and internals) is more
technical. Volume 3 covers client-server computing.
- Unix System Security--A Guide for Users and
System Administrators
- Author
- David Curry
- Publisher
- Addison Wesley
- Edition
- 1992
- ISBN
- 0-201-56327-4
- Firewalls Mailing List
- http://lists.gnac.net/firewalls/
The internet firewalls mailing list is a forum for firewall
administrators and implementors. To subscribe to Firewalls, send
subscribe firewalls in the body of a message (not in
the ``Subject:'' line) to
majordomo@lists.gnac.net
- Firewall-Wizards Mailing List
- http://www.nfr.net/forum/firewall-wizards.html
The Firewall Wizards Mailing List is a moderated firewall and
security related list that is more like a journal than a public
soapbox.
- Firewall HOWTO
- http://sunsite.unc.edu/LDP/HOWTO/Firewall-HOWTO.html
Describes exactly what is needed to build a firewall, particularly
using Linux.
- Firewall Toolkit (FWTK) and Firewall Papers
- ftp://ftp.tis.com/pub/firewalls/
- Marcus Ranum's firewall related publications
- http://www.ranum.com/pubs/
- Papers on firewalls and breakins
- ftp://ftp.research.att.com/dist/internet_security/
- Texas A&M University security tools
- http://www.net.tamu.edu/ftp/security/TAMU/
- COAST Project Internet Firewalls page
- http://www.cs.purdue.edu/coast/firewalls/
FAQ TOC |
Previous Section |
Next Section
