MINDPRIDE Computer Services Home | About Us | Our Services | Contact Information | Tutorials, Articles & Dictionaries | Site Map

Firewall FAQ I

From: C Matthew Curtin <cmcurtin@interhack.net>
Subject: Firewalls FAQ
Followup-To: poster
Date: 2 Jul 2001 05:39:01 GMT
Organization: The Ohio State University Dept. of Computer and Info. Science
Message-ID: <9hp1dl$3r2$1@news.cis.ohio-state.edu>
X-PostedBy: pfaq
X-Face: L"IcL.b%SDN]0Kql2be.}+i05V9fi\yX#H1+Xl)3!+n/3?5%-SA-HDg<IT

NNR0S;8"vcNN"O;O}YpB{&^1xazqDMg^v!6LS7S"5|}2uTl$NKV5}Bkca{M|Y^cZD@{1 URL: http://www.interhack.net/pubs/fwfaq/ Version: 10.0 Archive-name: firewalls-faq Posting-Frequency: monthly Internet Firewalls: Frequently Asked Questions Matt Curtin Marcus J. Ranum cmcurtin@interhack.net mjr@nfr.com Date: 2000/12/01 19:48:21 Revision: 10.0 Contents * Contents * 1 Administrativia o 1.1 About the FAQ o 1.2 For Whom Is the FAQ Written? o 1.3 Before Sending Mail o 1.4 Where Can I find the Current Version of the FAQ? o 1.5 Where Can I Find Non-English Versions of the FAQ? o 1.6 Contributors o 1.7 Copyright and Usage * 2 Background and Firewall Basics o 2.1 What is a network firewall? o 2.2 Why would I want a firewall? o 2.3 What can a firewall protect against? o 2.4 What can't a firewall protect against? o 2.5 What about viruses? o 2.6 Will IPSEC make firewalls obsolete? o 2.7 What are good sources of print information on firewalls? o 2.8 Where can I get more information on firewalls on the Internet? * 3 Design and Implementation Issues o 3.1 What are some of the basic design decisions in a firewall? o 3.2 What are the basic types of firewalls? + 3.2.1 Network layer firewalls + 3.2.2 Application layer firewalls o 3.3 What are proxy servers and how do they work? o 3.4 What are some cheap packet screening tools? o 3.5 What are some reasonable filtering rules for a kernel-based packet screen? + 3.5.1 Implementation + 3.5.2 Explanation o 3.6 What are some reasonable filtering rules for a Cisco? + 3.6.1 Implementation + 3.6.2 Explanations + 3.6.3 Shortcomings o 3.7 What are the critical resources in a firewall? o 3.8 What is a DMZ, and why do I want one? o 3.9 How might I increase the security and scalability of my DMZ? o 3.10 What is a single point of failure', and how do I avoid having one? o 3.11 How can I block all of the bad stuff? o 3.12 How can I restrict web access so users can't view sites unrelated to work? * 4 Various Attacks o 4.1 What is source routed traffic and why is it a threat? o 4.2 What are ICMP redirects and redirect bombs? o 4.3 What about denial of service? o 4.4 What are some common attacks, and how can I protect my system against them? + 4.4.1 SMTP Server Hijacking (Unauthorized Relaying) + 4.4.2 Exploiting Bugs in Applications + 4.4.3 Bugs in Operating Systems * 5 How Do I... o 5.1 Do I really want to allow everything that my users ask for? o 5.2 How do I make Web/HTTP work through my firewall? o 5.3 How do I make SSL work through the firewall? o 5.4 How do I make DNS work with a firewall? o 5.5 How do I make FTP work through my firewall? o 5.6 How do I make Telnet work through my firewall? o 5.7 How do I make Finger and whois work through my firewall? o 5.8 How do I make gopher, archie, and other services work through my firewall? o 5.9 What are the issues about X11 through a firewall? o 5.10 How do I make RealAudio work through my firewall? o 5.11 How do I make my web server act as a front-end for a database that lives on my private network? o 5.12 But my database has an integrated web server, and I want to use that. Can't I just poke a hole in the firewall and tunnel that port? o 5.13 How Do I Make IP Multicast Work With My Firewall? * A Some Commercial Products and Vendors * B Glossary of Firewall-Related Terms * C TCP and UDP Ports o C.1 What is a port? o C.2 How do I know which application uses what port? o C.3 What are LISTENING ports? o C.4 How do I determine what service the port is for? o C.5 What ports are safe to pass through a firewall? o C.6 The behavior of FTP o C.7 What software uses what FTP mode? o C.8 Is my firewall trying to connect outside? o C.9 The anatomy of a TCP connection * References 1 Administrativia 1.1 About the FAQ The Firewalls FAQ is currently undergoing revision. The maintainers welcome input and comments on the contents of this FAQ. Comments related to the FAQ should be addressed to firewalls-faq@interhack.net. Before you send us mail, please be sure to see sections 1.2 and 1.3 to make sure this is the right document for you to be reading. 1.2 For Whom Is the FAQ Written? Firewalls have come a long way from the days when this FAQ started. They've gone from being highly customized systems administered by their implementors to a mainstream commodity. Firewalls are no longer solely in the hands of those who design and implement security systems; even security-conscious end-users have them at home. We wrote this FAQ for computer systems developers and administrators. We have tried to be fairly inclusive, making room for the newcomers, but we still assume some basic technical background. If you find that you don't understand this document, but think that you need to know more about firewalls, it might well be that you actually need to get more background in computer networking first. We provide references that have helped us; perhaps they'll also help you. 1.3 Before Sending Mail Note that this collection of frequently-asked questions is a result of interacting with many people of different backgrounds in a wide variety of public fora. The firewalls-faq address is not a help desk. If you're trying to use an application that says that it's not working because of a firewall and you think that you need to remove your firewall, please do not send us mail asking how. If you want to know how to get rid of your firewall'' because you cannot use some application, do not send us mail asking for help. We cannot help you. Really. Who can help you? Good question. That will depend on what exactly the problem is, but here are several pointers. If none of these works, please don't ask us for any more. We don't know. * The provider of the software you're using. * The provider of the network service you're using. That is, if you're on AOL, ask them. If you're trying to use something on a corporate network, talk to your system administrator. 1.4 Where Can I find the Current Version of the FAQ? The FAQ can be found on the Web at * http://www.interhack.net/pubs/fwfaq/. * http://www.ranum.com/pubs/fwfaq/ It's also posted monthly to * comp.security.firewalls, * comp.security.unix, * comp.security.misc, * comp.answers, and * news.answers. Posted versions are archived in all the usual places. Unfortunately, the version posted to Usenet and archived from that version lack the pretty pictures and useful hyperlinks found in the web version. 1.5 Where Can I Find Non-English Versions of the FAQ? Several translations are available. (If you've done a translation and it's not listed here, please write us so we can update the master document.) Norwegian Translation by Jon Haugsand http://helmersol.nr.no/haandbok/doc/brannmur/brannmur-faq.html 1.6 Contributors Many people have written helpful suggestions and thoughtful commentary. We're grateful to all contributors. We'd like to thank a few by name: Keinanen Vesa, Allen Leibowitz, Brent Chapman, Brian Boyle, D. Clyde Williamson, Paul D. Robertson, Richard Reiner, Humberto Ortiz Zuazaga, and Theodore Hope. 1.7 Copyright and Usage Copyright ©1995-1996, 1998 Marcus J. Ranum. Copyright ©1998-2000 Matt Curtin. All rights reserved. This document may be used, reprinted, and redistributed as is providing this copyright notice and all attributions remain intact. Translations of the complete text from the original English to other languages are also explicitly allowed. Translators may add their names to the Contributors'' section. 2 Background and Firewall Basics Before being able to understand a complete discussion of firewalls, it's important to understand the basic principles that make firewalls work. 2.1 What is a network firewall? 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. 2.2 Why would I want a firewall? 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. 2.3 What can a firewall protect against? 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. 2.4 What can't a firewall protect against? 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''. 2.5 What about viruses? 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 gargaMindPridean 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. 2.6 Will IPSEC make firewalls obsolete? 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. 2.7 What are good sources of print information on firewalls? There are several books that touch on firewalls. The best known are: * Building Internet Firewalls, 2d ed. Authors Elizabeth D. Zwicky, Simon Cooper, and D. Brent Chapman Publisher O'Reilly Edition 2000 ISBN 1-56592-871-7 * Firewalls and Internet Security: Repelling the Wily Hacker Authors Bill Cheswick and Steve Bellovin Publisher Addison Wesley Edition 1994 ISBN 0-201-63357-4 * Practical Internet & Unix Security Authors Simson Garfinkel and Gene Spafford Publisher O'Reilly Edition 1996 ISBN 1-56592-148-8 Note Discusses primarily host security. 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 2.8 Where can I get more information on firewalls on the Internet? 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/ 3 Design and Implementation Issues 3.1 What are some of the basic design decisions in a firewall? There are a number of basic design issues that should be addressed by the lucky person who has been tasked with the responsibility of designing, specifying, and implementing or overseeing the installation of a firewall. The first and most important decision reflects the policy of how your company or organization wants to operate the system: is the firewall in place explicitly to deny all services except those critical to the mission of connecting to the Net, or is the firewall in place to provide a metered and audited method of queuing'' access in a non-threatening manner? There are degrees of paranoia between these positions; the final stance of your firewall might be more the result of a political than an engineering decision. The second is: what level of monitoring, redundancy, and control do you want? Having established the acceptable risk level (e.g., how paranoid you are) by resolving the first issue, you can form a checklist of what should be monitored, permitted, and denied. In other words, you start by figuring out your overall objectives, and then combine a needs analysis with a risk assessment, and sort the almost always conflicting requirements out into a laundry list that specifies what you plan to implement. The third issue is financial. We can't address this one here in anything but vague terms, but it's important to try to quantify any proposed solutions in terms of how much it will cost either to buy or to implement. For example, a complete firewall product may cost between$100,000 at the high end, and
free at the low end. The free option, of doing some fancy configuring on a
Cisco or similar router will cost nothing but staff time and a few cups of
coffee. Implementing a high end firewall from scratch might cost several
man-months, which may equate to \$30,000 worth of staff salary and benefits.
The systems management overhead is also a consideration. Building a
home-brew is fine, but it's important to build it so that it doesn't require
constant (and expensive) attention. It's important, in other words, to
evaluate firewalls not only in terms of what they cost now, but continuing
costs such as support.

On the technical side, there are a couple of decisions to make, based on the
fact that for all practical purposes what we are talking about is a static
traffic routing service placed between the network service provider's router
and your internal network. The traffic routing service may be implemented at
an IP level via something like screening rules in a router, or at an
application level via proxy gateways and services.

The decision to make is whether to place an exposed stripped-down machine on
the outside network to run proxy services for telnet, FTP, news, etc., or
whether to set up a screening router as a filter, permitting communication
with one or more internal machines. There are pluses and minuses to both
approaches, with the proxy machine providing a greater level of audit and
potentially security in return for increased cost in configuration and a
decrease in the level of service that may be provided (since a proxy needs
to be developed for each desired service). The old trade-off between
ease-of-use and security comes back to haunt us with a vengeance.

3.2 What are the basic types of firewalls?

Conceptually, there are two types of firewalls:

1.   Network layer
2.   Application layer

They are not as different as you might think, and latest technologies are
blurring the distinction to the point where it's no longer clear if either
one is better'' or worse.'' As always, you need to be careful to pick
the type that meets your needs.

Which is which depends on what mechanisms the firewall uses to pass traffic
from one security zone to another. The International Standards Organization
(ISO) Open Systems Interconnect (OSI) model for networking defines seven
layers, where each layer provides services that higher-level'' layers
depend on. In order from the bottom, these layers are physical, data link,
network, transport, session, presentation, application.

The important thing to recognize is that the lower-level the forwarding
mechanism, the less examination the firewall can perform. Generally
speaking, lower-level firewalls are faster, but are easier to fool into
doing the wrong thing.

3.2.1 Network layer firewalls

These generally make their decisions based on the source, destination
addresses and ports (see Appendix C for a more detailed discussion of ports)
in individual IP packets. A simple router is the traditional'' network
layer firewall, since it is not able to make particularly sophisticated
decisions about what a packet is actually talking to or where it actually
came from. Modern network layer firewalls have become increasingly
sophisticated, and now maintain internal information about the state of
connections passing through them, the contents of some of the data streams,
and so on. One thing that's an important distinction about many network
layer firewalls is that they route traffic directly though them, so to use
one you either need to have a validly assigned IP address block or to use a
private internet'' address block [3]. Network layer firewalls tend to be
very fast and tend to be very transparent to users.

Figure 1: Screened Host Firewall

[\begin{figure} \begin{center} \includegraphics {firewalls-faq1} \end{center}\end{figure}]

In Figure 1, a network layer firewall called a screened host firewall'' is
represented. In a screened host firewall, access to and from a single host
is controlled by means of a router operating at a network layer. The single
host is a bastion host; a highly-defended and secured strong-point that
(hopefully) can resist attack.

Figure 2: Screened Subnet Firewall

[\begin{figure} \begin{center} \includegraphics {firewalls-faq2} \end{center}\end{figure}]

Example Network layer firewall : In figure 2, a network layer firewall
called a screened subnet firewall'' is represented. In a screened subnet
firewall, access to and from a whole network is controlled by means of a
router operating at a network layer. It is similar to a screened host,
except that it is, effectively, a network of screened hosts.

3.2.2 Application layer firewalls

These generally are hosts running proxy servers, which permit no traffic
directly between networks, and which perform elaborate logging and auditing
of traffic passing through them. Since the proxy applications are software
components running on the firewall, it is a good place to do lots of logging
and access control. Application layer firewalls can be used as network
address translators, since traffic goes in one side'' and out the other,
after having passed through an application that effectively masks the origin
of the initiating connection. Having an application in the way in some cases
may impact performance and may make the firewall less transparent. Early
application layer firewalls such as those built using the TIS firewall
toolkit, are not particularly transparent to end users and may require some
training. Modern application layer firewalls are often fully transparent.
Application layer firewalls tend to provide more detailed audit reports and
tend to enforce more conservative security models than network layer
firewalls.

Figure 3: Dual Homed Gateway

[\begin{figure} \begin{center} \includegraphics {firewalls-faq3} \end{center}\end{figure}]

Example Application layer firewall : In figure 3, an application layer
firewall called a dual homed gateway'' is represented. A dual homed
gateway is a highly secured host that runs proxy software. It has two
network interfaces, one on each network, and blocks all traffic passing
through it.

The Future of firewalls lies someplace between network layer firewalls and
application layer firewalls. It is likely that network layer firewalls will
become increasingly aware'' of the information going through them, and
application layer firewalls will become increasingly low level'' and
transparent. The end result will be a fast packet-screening system that logs
and audits data as it passes through. Increasingly, firewalls (network and
application layer) incorporate encryption so that they may protect traffic
passing between them over the Internet. Firewalls with end-to-end encryption
can be used by organizations with multiple points of Internet connectivity
to use the Internet as a private backbone'' without worrying about their

3.3 What are proxy servers and how do they work?

A proxy server (sometimes referred to as an application gateway or
forwarder) is an application that mediates traffic between a protected
network and the Internet. Proxies are often used instead of router-based
traffic controls, to prevent traffic from passing directly between networks.
Many proxies contain extra logging or support for user authentication. Since
proxies must understand'' the application protocol being used, they can
also implement protocol specific security (e.g., an FTP proxy might be
configurable to permit incoming FTP and block outgoing FTP).

Proxy servers are application specific. In order to support a new protocol
via a proxy, a proxy must be developed for it. One popular set of proxy
servers is the TIS Internet Firewall Toolkit (FWTK'') which includes
proxies for Telnet, rlogin, FTP, X-Window, HTTP/Web, and NNTP/Usenet news.
SOCKS is a generic proxy system that can be compiled into a client-side
application to make it work through a firewall. Its advantage is that it's
easy to use, but it doesn't support the addition of authentication hooks or
http://www.socks.nec.com/.

3.4 What are some cheap packet screening tools?

The Texas AMU security tools include software for implementing screening
routers. Karlbridge is a PC-based screening router kit available from
ftp://ftp.net.ohio-state.edu/pub/kbridge/. A version of the Digital
Equipment Corporation screend'' kernel screening software is available for
BSD-derived operating systems. There are numerous kernel-level packet
screens, including ipf, ipfw, and ipfwadm. Typically, these are included in
various free Unix implementations, such as FreeBSD, OpenBSD, NetBSD, and
Linux. You might also find these tools available in your commercial Unix
implementation. If you're willing to get your hands a little dirty, it's
completely possible to build a secure and fully functional firewall for the
price of hardware and some of your time.

3.5 What are some reasonable filtering rules for a kernel-based packet
screen?

This example is written specifically for ipfwadm on Linux, but the
principles (and even much of the syntax) applies for other kernel interfaces
for packet screening on open source'' Unix systems.

There are four basic categories covered by the ipfwadm rules:

-A
Packet Accounting
-I
Input firewall
-O
Output firewall
-F
Forwarding firewall

switches and options, see the ipfwadm man page.

3.5.1 Implementation

Here, our organization is using a private (RFC 1918) Class C network
192.168.1.0. Our ISP has assigned us the address 201.123.102.32 for our
gateway's external interface and 201.123.102.33 for our external mail
server. Organizational policy says:

* Allow all outgoing TCP connections
* Allow incoming SMTP and DNS to external mail server
* Block all other traffic

The following block of commands can be placed in a system boot file (perhaps
rc.local on Unix systems).

ipfwadm -F -i m -b -P tcp -S 0.0.0.0/0 1024:65535 -D 201.123.102.33 25
ipfwadm -F -i m -b -P tcp -S 0.0.0.0/0 1024:65535 -D 201.123.102.33 53
ipfwadm -F -i m -b -P udp -S 0.0.0.0/0 1024:65535 -D 201.123.102.33 53
ipfwadm -F -a m -S 192.168.1.0/24 -D 0.0.0.0/0 -W eth0

/sbin/route add -host 201.123.102.33 gw 192.168.1.2

3.5.2 Explanation

* Line one flushes (-f) all forwarding (-F) rules.
* Line two sets the default policy (-p) to deny.
* Lines three through five are input rules (-i) in the following format:

ipfwadm -F (forward) -i (input) m (masq.) -b (bi-directional) -P
* Line six appends (-a) a rule that permits all internal IP addresses out
to all external addresses on all protocols, all ports.
* Line eight adds a route so that traffic going to 201.123.102.33 will be
directed to the internal address 192.168.1.2.

3.6 What are some reasonable filtering rules for a Cisco?

The example in figure 4 shows one possible configuration for using the
Cisco as filtering router. It is a sample that shows the implementation of
as specific policy. Your policy will undoubtedly vary.

Figure 4: Packet Filtering Router

[\begin{figure} \begin{center} \includegraphics {firewalls-faq4} \end{center}\end{figure}]

In this example, a company has Class C network address 195.55.55.0. Company
network is connected to Internet via IP Service Provider. Company policy is
are accepted. All incoming connections go through mailhost''. Mail and DNS
are only incoming services.

3.6.1 Implementation

* Allow all outgoing TCP-connections
* Allow incoming SMTP and DNS to mailhost
* Allow incoming FTP data connections to high TCP port (>1024)
* Try to protect services that live on high port numbers

Only incoming packets from Internet are checked in this configuration. Rules
are tested in order and stop when the first match is found. There is an
implicit deny rule at the end of an access list that denies everything. This
IP access list assumes that you are running Cisco IOS v. 10.3 or later.

no ip source-route
!
interface ethernet 0
!
interface serial 0
ip access-group 101 in
!
access-list 101 deny ip 127.0.0.0 0.255.255.255 any
access-list 101 deny ip 10.0.0.0 0.255.255.255 any
access-list 101 deny ip 172.16.0.0 0.15.255.255 any
access-list 101 deny ip 192.168.0.0 0.0.255.255 any
access-list 101 deny ip any 0.0.0.255 255.255.255.0
access-list 101 deny ip any 0.0.0.0 255.255.255.0
!
access-list 101 deny ip 195.55.55.0 0.0.0.255
access-list 101 permit tcp any any established
!
access-list 101 permit tcp any host 195.55.55.10 eq smtp
access-list 101 permit tcp any host 195.55.55.10 eq dns
access-list 101 permit udp any host 192.55.55.10 eq dns
!
access-list 101 deny tcp any any range 6000 6003
access-list 101 deny tcp any any range 2000 2003
access-list 101 deny tcp any any eq 2049
access-list 101 deny udp any any eq 2049
!
access-list 101 permit tcp any 20 any gt 1024
!
access-list 101 permit icmp any any
!
snmp-server community FOOBAR RO 2
line vty 0 4
access-class 2 in
access-list 2 permit 195.55.55.0 0.0.0.255

3.6.2 Explanations

* Drop all source-routed packets. Source routing can be used for address
spoofing.
* Drop directed broadcasts, which are used in smurf attacks.
* If an incoming packet claims to be from a local net, loopback network,
or private network, drop it.
* All packets which are part of already established TCP-connections can
pass through without further checking.
* All connections to low port numbers are blocked except SMTP and DNS.
* Block all services that listen for TCP connections on high port
numbers. X-windows (port 6000+), OpenWindows (port 2000+) are a few
candidates. NFS (port 2049) runs usually over UDP, but it can be run
over TCP, so you should block it.
* Incoming connections from port 20 into high port numbers are supposed
to be FTP data connections.
* All UDP traffic is blocked to protect RPC services

3.6.3 Shortcomings

* You cannot enforce strong access policies with router access lists.
Users can easily install backdoors to their systems to get over no
incoming telnet'' or no X'' rules. Also crackers install telnet
backdoors on systems where they break in.
* You can never be sure what services you have listening for connections
on high port numbers.
* Checking the source port on incoming FTP data connections is a weak
security method. It also breaks access to some FTP sites. It makes use
of the service more difficult for users without preventing bad guys

Use at least Cisco version 9.21 so you can filter incoming packets and check
for address spoofing. It's still better to use 10.3, where you get some
extra features (like filtering on source port) and some improvements on
filter syntax.

You have still a few ways to make your setup stronger. Block all incoming
TCP-connections and tell users to use passive-FTP clients. You can also
block outgoing ICMP echo-reply and destination-unreachable messages to hide
your network and to prevent use of network scanners. Cisco.com use to have
an archive of examples for building firewalls using Cisco routers, but it
doesn't seem to be online anymore. There are some notes on Cisco access
control lists, at least, at
ftp://ftp.cisco.com/pub/mibs/app_notes/access-lists.

3.7 What are the critical resources in a firewall?

It's important to understand the critical resources of your firewall
architecture, so when you do capacity planning, performance optimizations,
etc., you know exactly what you need to do, and how much you need to do it
in order to get the desired result.

What exactly the firewall's critical resources are tends to vary from site
to site, depending on the sort of traffic that loads the system. Some people
think they'll automatically be able to increase the data throughput of their
firewall by putting in a box with a faster CPU, or another CPU, when this
isn't necessarily the case. Potentially, this could be a large waste of
money that doesn't do anything to solve the problem at hand or provide the
expected scalability.

On busy systems, memory is extremely important. You have to have enough RAM
to support every instance of every program necessary to service the load
placed on that machine. Otherwise, the swapping will start and the
productivity will stop. Light swapping isn't usually much of a problem, but
if a system's swap space begins to get busy, then it's usually time for more
RAM. A system that's heavily swapping is often relatively easy to push over
the edge in a denial-of-service attack, or simply fall behind in processing
the load placed on it. This is where long email delays start.

Beyond the system's requirement for memory, it's useful to understand that
different services use different system resources. So the configuration that
you have for your system should be indicative of the kind of load you plan
to service. A 700 MHz processor isn't going to do you much good if all
you're doing is netnews and mail, and are trying to do it on an IDE disk
with an ISA controller.

Table 1: Critical Resources for Firewall
Services

Service     Critical Resource

Email       Disk I/O

Netnews     Disk I/O

Web         Host OS Socket Performance

IP Routing  Host OS Socket Performance

Web Cache   Host OS Socket Performance, Disk I/O

3.8 What is a DMZ, and why do I want one?

DMZ'' is an abbreviation for demilitarized zone''. In the context of
firewalls, this refers to a part of the network that is neither part of the
internal network nor directly part of the Internet. Typically, this is the
area between your Internet access router and your bastion host, though it
can be between any two policy-enforcing components of your architecture.

A DMZ can be created by putting access control lists on your access router.
This minimizes the exposure of hosts on your external LAN by allowing only
recognized and managed services on those hosts to be accessible by hosts on
the Internet. Many commercial firewalls simply make a third interface off of
the bastion host and label it the DMZ. The point is that the network is
neither inside'' nor outside''.

For example, a web server running on NT might be vulnerable to a number of
denial-of-service attacks against such services as RPC, NetBIOS and SMB.
These services are not required for the operation of a web server, so
blocking TCP connections to ports 135, 137, 138, and 139 on that host will
reduce the exposure to a denial-of-service attack. In fact, if you block
everything but HTTP traffic to that host, an attacker will only have one
service to attack.

This illustrates an important principle: never offer attackers more to work
with than is absolutely necessary to support the services you want to offer
the public.

3.9 How might I increase the security and scalability of my DMZ?

A common approach for an attacker is to break into a host that's
vulnerable to attack, and exploit trust relationships between the vulnerable
host and more interesting targets.

If you are running a number of services that have different levels of
security, you might want to consider breaking your DMZ into several
security zones''. This can be done by having a number of different
networks within the DMZ. For example, the access router could feed two
ethernets, both protected by ACLs, and therefore in the DMZ.

On one of the ethernets, you might have hosts whose purpose is to service
your organization's need for Internet connectivity. These will likely relay
mail, news, and host DNS. On the other ethernet could be your web server(s)
and other hosts that provide services for the benefit of Internet users.

In many organizations, services for Internet users tend to be less carefully
guarded and are more likely to be doing insecure things. (For example, in
the case of a web server, unauthenticated and untrusted users might be
running CGI or other executable programs. This might be reasonable for your
web server, but brings with it a certain set of risks that need to be
managed. It is likely these services are too risky for an organization to
run them on a bastion host, where a slip-up can result in the complete
failure of the security mechanisms.)

By putting hosts with similar levels of risk on networks together in the
DMZ, you can help minimize the effect of a breakin at your site. If someone
breaks into your web server by exploiting some bug in your web server,
they'll not be able to use it as a launching point to break into your
private network if the web servers are on a separate LAN from the bastion
hosts, and you don't have any trust relationships between the web server and
bastion host.

Now, keep in mind that we're running ethernet here. If someone breaks into
your web server, and your bastion host is on the same ethernet, an attacker
can install a sniffer on your web server, and watch the traffic to and from
your bastion host. This might reveal things that can be used to break into

Splitting services up not only by host, but by network, and limiting the
level of trust between hosts on those networks, you can greatly reduce the
likelihood of a breakin on one host being used to break into the other.
Succinctly stated: breaking into the web server in this case won't make it
any easier to break into the bastion host.

You can also increase the scalability of your architecture by placing hosts
on different networks. The fewer machines that there are to share the
available bandwidth, the more bandwidth that each will get.

3.10 What is a single point of failure', and how do I avoid having one?

An architecture whose security hinges upon one mechanism has a single
point of failure. Software that runs bastion hosts has bugs. Applications
have bugs. Software that controls routers has bugs. It makes sense to use
all of these components to build a securely designed network, and to use
them in redundant ways.

If your firewall architecture is a screened subnet, you have two packet
filtering routers and a bastion host. (See question 3.2 from this section.)
Your Internet access router will not permit traffic from the Internet to get
all the way into your private network. However, if you don't enforce that
rule with any other mechanisms on the bastion host and/or choke router, only
one component of your architecture needs to fail or be compromised in order
to get inside. On the other hand, if you have a redundant rule on the
bastion host, and again on the choke router, an attacker will need to defeat
three mechanisms.

Further, if the bastion host or the choke router needs to invoke its rule to
block outside access to the internal network, you might want to have it
trigger an alarm of some sort, since you know that someone has gotten

3.11 How can I block all of the bad stuff?

For firewalls where the emphasis is on security instead of connectivity,
you should consider blocking everything by default, and only specifically
allowing what services you need on a case-by-case basis.

If you block everything, except a specific set of services, then you've
security problem with everything product and service around, you only need
to worry about every security problem with a specific set of services and
products. :-)

Before turning on a service, you should consider a couple of questions:

* Is the protocol for this product a well-known, published protocol?
* Is the application to service this protocol available for public
inspection of its implementation?
* How well known is the service and product?
* How does allowing this service change the firewall architecture? Will
an attacker see things differently? Could it be exploited to get at my
internal network, or to change things on hosts in my DMZ?

When considering the above questions, keep the following in mind:

* Security through obscurity'' is no security at all. Unpublished
protocols have been examined by bad guys and defeated.
* Despite what the marketing representatives say, not every protocol or
service is designed with security in mind. In fact, the number that are
is very few.
* Even in cases where security is a consideration, not all organizations
have competent security staff. Among those who don't, not all are
willing to bring a competent consultant into the project. The end
result is that otherwise-competent, well-intended developers can design
insecure systems.
* The less that a vendor is willing to tell you about how their system
really works, the more likely it is that security (or other) problems
exist. Only vendors with something to hide have a reason to hide their
designs and implementations.

3.12 How can I restrict web access so users can't view sites unrelated to
work?

A few years ago, someone got the idea that it's a good idea to block
bad'' web sites, i.e., those that contain material that The Company views
inappropriate''. The idea has been increasing in popularity, but there are
several things to consider when thinking about implementing such controls in

* It is not possible to practically block everything that an employer
deems inappropriate''. The Internet is full of every sort of
material. Blocking one source will only redirect traffic to another
source of such material, or cause someone to figure a way around the
block.
* Most organizations do not have a standard for judging the
appropriateness of material that their employees bring to work, i.e.,
books, magazines, etc. Do you inspect everyone's briefcase for
inappropriate material'' every day? If you do not, then why would you
inspect every packet for inappropriate material''? Any decisions
along those lines in such an organization will be arbitrary. Attempting
to take disciplinary action against an employee where the only standard
is arbitrary typically isn't wise, for reasons well beyond the scope of
this document.
* Products that perform site-blocking, commercial and otherwise, are
typically easy to circumvent. Hostnames can be rewritten as IP
addresses. IP addresses can be written as a 32-bit integer value, or as
four 8-bit integers (the most common form). Other possibilities exist,
as well. Connections can be proxied. Web pages can be fetched via
email. You can't block them all. The effort that you'll spend trying to
implement and manage such controls will almost certainly far exceed any
level of damage control that you're hoping to have.

The rule-of-thumb to remember here is that you cannot solve social problems
with technical solutions. If there is a problem with someone going to an
inappropriate'' web site, that is because someone else saw it and was
offended by what he saw, or because that person's productivity is below
expectations. In either case, those are matters for the personnel