`
`Network Firewalls
`
`Computer security is a hard problem. Security on networked
`computers is much harder. Firewalls (barriers between two
`networks), when used properly, can provide a significant increase
`in computer security.
`
`Steven M. Bellovin and William R. Cheswick
`
` omputer security is a hard problem.
`
`me that it’s broken. ” People at the other end say, “show
`me that it’s both safe and necessary; otherwise, we
`Security on networked computers
`is much harder. The administra-
`won’t run it.” Those who are completely off the scale
`prefer to pull the plug on the network, rather than
`tor of a single host can #with a great
`deal of care and attention to details,
`take any risks at all. Such a move is too extreme, but
`luck in the choice of vendor soft-
`-
`.
`.
`.
`understandable. Why would a company risk losing
`its secrets for the benefits of network connection?
`ware, and a careful and educated user community
`We do not advocate disconnection for most sites.
`— probably do an adequate job of keeping the
`machine secure. But if the machine is connected
`Ourphilosophy issimple: there are no absolutes. One
`to a network, the situation is much difficult.
`cannot have complete safety; to pursue that chimera
`is to ignore the costs of the pursuit. Networks and
`First, many more entry points to the host than
`internetworks have advantages; to disconnect from
`a simple login prompt must be secured. The
`mailer, the networked file system, and the database
`a network is to deny oneself those advantages. When
`all is said and done, disconnection may be the
`servers are all potential sources of danger. Fur-
`thermore, the authentication used by some proto—
`right choice, but it is a decision that can only be made
`by weighing the risks against the benefits.
`cols may be inadequate. Nevertheless, they must
`We advocate caution, not hysteria. For reasons
`be run, to provide adequate service to local users.
`that are spelled out below, we feel that firewalls are
`Second, there are now many more points from
`which an attack can be launched. If a computer’s
`an important tool that can minimize the danger,while
`users are confined to a single building, it is dif-
`providing most —but not necessarily all—of the ben-
`flcult for an outsider to try to penetrate system
`efits of a network connection. However, a paranoid
`stance is necessary for many sites when setting up
`security. A network-connected computer, on the
`a firewall.
`other hand, can be reached from any point on the
`network — and the Internet reaches tens of mil-
`Most computing professionals realize that most
`large software systems are buggy. If the system is
`lions of users in every part of the globe.
`Finally, networks expose computers to the prob—
`security-sensitive — that is, if it provides any sort
`of network service at all — one runs the risk that
`lem of transitive trust. Your computers may be secure,
`but you may have users who connect from other
`the bugs will manifest themselves as security holes.
`machines that are less secure. This connection —— even
`The most practical solution is to run as few programs
`as possible, and to make sure that these are as small
`ifduly authorized and immune to direct attack— may
`and simple as possible. A firewall can do this. It is
`nevertheless be the vehicle for a successful penetra-
`tion ofyour machines, if the source of the connection
`not constrained to offer general computing services
`has been compromised.
`to a general user population. It need not run networked
`file systems, distributed user name databases, ctc. The
`The usual solution to all ofthese problems is a fire-
`wall: a barrier that restrictsthe free flow ofdata between
`very act of eliminating such programs automatical-
`the inside and the outside. Used properly. a firewall
`lymakes a firewall more secure than the average host.
`Much ofthis article was
`We also feel that any program, no matter how
`can provide asignificant increase in computersecurity.
`taken from "Firewalls and
`innocuous it seems, can harbor security holes. (Who
`Stance
`Internet Security: Repelling
`would have guessed that on some machines, integer
`the Wiley Hacker" by
`Akey decisionwhen developing a security policy is the
`divide exceptions cool d lead to system penetrations?)
`William R. Chemick and
`stance ofthe firewall design. The stance is the attitude
`We thus have a firm belief that everything is guilty
`Steven M. Bellovz'n,
`of the designers. It is determined by the cost of fail-
`until proven innocent. Consequently, we configure
`Addison Wesley Publishing
`ure of the firewall and the designers’ estimate of that
`our firewalls to reject everything, unlesswe have explic-
`Company, ISBN 0-201-
`likelihood. It is also based on the designers’ opinions
`itly made the choice — and accepted the risk — to
`6335 7-4. © 1994 .4 T&T
`of their own abilities. At one end of the scale is a phi-
`permit it. Taking the opposite tack, of blocking only
`Bell Laboratories.
`losophy that says, “we’ll run it unless you can show
`known offenders. strikes us as extremely dangerous.
`
`
`STEVEN M. BELLOVIN
`works at A TdiT Bell Labora—
`tories, where he does research
`in networks and security
`
`WILLIAM R. CHESWICK
`server or an assistant pm—
`gmmmer trainee and member
`OfIhe technical staffal Bell
`Laboratories.
`
`50
`
`IEEE Communications Magazine ' September 1994
`
`SAMSUNG 1002
`
`1
`
`SAMSUNG 1002
`
`

`

`
`
`
`
`
`“£23
`
`V
`
`I Figure 1. Schematic ofa firewall.
`
`Furthermore, Whether or not a security policy is
`formally spelled out. one always exists. If nothing
`else is said or implemented, the default policy is “any-
`thing goes.” Needless to say, this stance is rarely accept—
`able in a security—conscious environment. if one does
`not make explicit decisions, one will have made
`the default decision to allow almost anything.
`
`Host Security
`To some people, the very notion of afirewall is anath-
`ema. In most situations. the network is not the resource
`at risk; rather, the endpoints ofthe network are threat-
`ened. By analogy, con artists rarely steal phone ser—
`vice per se; instead, they use the phone system as a
`tool to reach their real victims. So it is, in a sense,
`with network security. Given that the target of the
`attackers is the hosts on the network, should they
`notbe suitably configured and armored to resist attack?
`The answer is that they should be, but proba—
`bly cannot. Such attempts are probably futile. There
`will be bugs, either in the network programs or in the
`administration of the system. It is this way with com—
`puter security: the attacker only has to win once. It
`does not matter how thick are your walls, nor how
`lofty yourbattlements; ifan attacker findsone weak-
`ness — say, a postern gate, to extend our metaphor
`# your system will be penetrated. And ifone machine
`falls, its neighbors are likely to follow.
`
`Everything is
`
`guilty until
`
`proven
`
`innocent.
`
`Thus, we
`
`configure our
`
`firewalls
`
`to reject
`
`everything,
`
`unless
`
`we have
`
`explicitly
`
`made the
`
`choice ——
`
`and accepted
`
`the risk — to
`
`permit it.
`
`more competent than your average System admin-
`istrator, but they may be more security conscious.
`However. they are almost certainly better than
`nonadministrators who must nevertheless tend to
`their own machines. This category would include
`physical scientists, professors, etc, who (rightly)
`prefer to worry about their own areas of responsi-
`bility. It may or may not be reasonable to demand
`more security consciousness from them; never-
`theless, it is obviously not their top priority.
`Fewer normal users is a help as well. Poorly
`chosen passwords are a serious risk; ifusers and their
`attendant passwords do not exist, this is not a
`problem. Similarly, one can make more or less
`arbitrary changes to various program interfaces if
`that would help security, without annoying a pop-
`ulation accustomed to a differentway ofdoing things.
`One examplcwou id be the use ofhand-held authen-
`ticators for logging in. Many people resent them,
`or they may be too expensive to be furnished to
`an entire organization; a gateway machine, how-
`ever, should have a user community that is restrict-
`ed enough so that these concerns are negligible.
`More subtly, gatewaymachines need not, and should
`not, be trusted by any other machines. Thus, even if
`the gateway machine has been compromised, no oth-
`ers will fall automatically. On the other hand, the
`gateway machine can, if the userwishes (and decides
`against using hand-held authenticators), trust other
`machines, thereby eliminating the need for most
`passwords on the few accounts it should have. Again,
`something that is not there cannot be compromised.
`Gatewaymachineshave other,nonseeurityadvan—
`tages as well. They are a central point for mail and
`FTP administration. for example. Only one machine
`need be monitored for delayed mail, proper header
`syntax, return—address rewriting (i.e., to firstname
`. lastname@org . domain format), etc. Outsiders have
`a single point of contact for mail problems and a
`single location to search for files being exported.
`Our main focus, though, is security. And for all
`Iypes of Firewalls
`that we have stated about the benefits of a firewall,
`it should be stressed that we neither advocate nor
`e define a firewall as aoollection ofcomponents
`W placed between two networks that collectively
`condone sloppy attitudes toward host security. Even
`have the following properties:
`if a firewall were impermeable, and even if the admin-
`0 All traffic from inside to outside, and vice—
`istrators and operators never made any mistakes. the
`Internet is not the only source ofdanger. Apart from
`versa, must pass through the firewall.
`the risk of insider attacks and in some environments,
`' Only authorized traffic. as defined by the local
`that is a serious risk — an outsider can gain access
`security policy, will be allowed to pass.
`by other means. In at least one case, a hacker
`- The firewall itself is immune to penetration.
`came in through a modem pool, and attacked the
`We should note that these are design goals; a fail-
`ure in one aspect does not mean that the collection
`firewall from the inside [7]. Strong host securitypoli—
`cies are a necessity, not a luxury. For that matter,
`is not a firewall, simply that it is not a very good one.
`internal firewalls are agood idea, to protect verysen-
`That firewalls are desirable follows directly from
`sitive portions of organizational networks.
`ourearlierstatements. Many hosts— and more like-
`A firewall, in general, consistsofseveral different
`ly. most hosts A cannot protect themselves against
`a determined attack. Firewalls have several dis-
`components (Fig. l). The “filters” (sometimescalled
`“screens”) block transmission ofcertain classes oftraf-
`tinct advantages.
`fic. A gateway is a machine or a set of machines that
`First, ofcourse, a firewall is likely to be more secure
`than an average host. The biggest single reason
`provides relay services to compensate for the effects
`of the filter. The network inhabited by the gateway
`for that is simply that it is not a general-purpose
`machine. Thus, features that are of doubtful secu—
`is often called the demilitarized zone (DMZ). A gate-
`rity but add greatly to user convenience ,. Net—
`way in the DMZ is sometimes assisted by an internal
`work lnformation Service (NIS), 1 login. etc. 7 are
`gateway. Typically. the two gateways will have more
`not necessary. For that matter, many features of
`open communication through the inside filter than
`the outside gateway has to other internal hosts. Either
`unknown security can be omitted if they are irrele—
`vant to the firewall’s functionality.
`filter, or for that matter the gatewayitself, maybe omit-
`ted; the details will vary from firewall to firewall. In
`A second benefitcomes from havingprofessional
`administration of the firewall machines. We do
`general, the outside filter can be used to protect the
`not Claim that firewall administrators are necessarily
`gateway from attack, while the inside filter is used
`
`
`IEEE Communications Magazine 0 September 1994
`
`51
`
`2
`
`

`

`
`
`to guard against the consequences of a compromised
`gateway. Either or both filters can protect the
`internal network from assaults. An exposed gateway
`machine is often called a bastion host.
`We classify firewalls into three main categories:
`packet filtering, circuit gateways. and application gate-
`ways. Commonly, more than one ofthese is used at the
`same time. As noted earlier, mail isoftenrouted through
`a gateway even when no security firewall is used.
`Our examples and discussion un abashedly relate
`to UNIX systems and programs. 'Ihe majority of mul—
`tiuser machines on the Internet run some version of
`the UNIXoperatingsystem. Most application-level
`gateways are implemented in UNIX. This is not to
`say that other operating systems are more secure; how-
`ever, there are fewer of them on the Internet. and they
`are less popular as targets for that reason. But
`the principles and philosophy apply to network gate-
`ways built on other operating systems as well.
`Our focus is on the TCP/IP protocol suite, espe—
`cially as used on the Internet. Again, this is not because
`TCP/IP has more security problems than other pro-
`tocol stacks (we doubt that very much), rather, it is a
`commentary on the success of TCP/IP. By far, it is the
`heterogeneous networking protocol ofchoice—not
`only on workstations,for which it is the native tongue
`— but on virtually all machines, ranging from desktop
`personal computers to the largest supercomputers.
`Manyintemalcorporate networks are based onTCP/I P;
`some — but not all —— of these are connected to the
`Internet. And the Internet links most major uni-
`versities in the United States (and many others around
`the world), research labs, many government agencies,
`and even a fair number of businesses. We believe,
`though, that our advice is applicable to any net-
`work with similar characteristics. We have read of
`serious attacks on computers attached to public X25
`data networks. Firewalls are useful there, too,
`although naturally they would differ in detail.
`Traditionally, firewalls are placed between an
`organization and the outside world. But a large orga-
`nization may need internal firewalls as well to iso-
`late securily domains (also known as administrative
`domains). A security domain is a set of machines
`under common administrative control, with a
`common security policy and security level.
`There are many good reasons to erect internal fire-
`walls. In many large companies, most employees are
`not (or should not be) privy to all information. In
`other companies, the cash business (likethe factory, or
`a phone company’s telephone switches) needs to be
`accessible to developers or support personnel, but
`not to the general corporate population. Even autho-
`rized users should pass through a security gate-
`way when crossing the firewall; otherwise, if their
`home machines, which live outside of the firewall,
`are compromised, the sensitive equipment on the
`inside couldbe next. The firewall controls the access
`and the trust in a carefully predictable way.
`
`Packet-Filtering Gateways
`
`Even autho-
`
`rized users
`
`should pass
`
`through a
`
`security
`
`gateway
`
`when crossing
`
`the firewall;
`
`otherwise, if
`
`their home
`
`machines are
`
`compromised,
`
`the equip-
`
`ment on the
`
`inside could
`
`be next.
`
`Packet filters work by dropping packets based on
`theirsource or destination addresses or service (i.c.,
`port number). In general, no context is kept; decisions
`are made only from the contents of the current pack-
`et. Depending on the type of router, filtering may be
`done at input time, at output time, or both. The admin-
`istrator makes a list of the acceptable machines and
`services and a stoplist of unacceptable machines or
`services. It is easy to permit or deny access at the host
`or network level with a packet filter. For example7
`one can permit any 1P access between host A and B,
`or deny any access to B from any machine but A.
`Most security policies require finer control than
`this; they need to define access to specific ser—
`vices for hosts that are otherwise untrusted. For exam—
`ple, one might want to allow any host to Connect
`to machine A, but only to send or receive mail. Other
`services may or may not be permitted. Packet fil-
`teringallows some control at this level, but it is a dan-
`gerous and error—prone process. To do it right, one
`needs intimate knowledge ofTCP and UDP port uti-
`lization on a number of operating systems. This is
`one of the disadvantages of packet filters: if you get
`these tables wrong you may inadvertently let in
`the Bad Guys [5]. But even with a perfectly imple-
`mented filter, some compromisescan be dangerous.
`We discuss these in a section to follow.
`Configuring a packet filter is a three-step process.
`First, ofcourse, one must knowwhat should and should
`not be permitted. That is, one must have a securi-
`ty policy. Next, the allowable types of packets
`must be specified formally, in terms of logical expres—
`sions on packet fields. Finally — and this can be
`remarkably difficult —the expressions must be rewrit-
`ten in whatever syntax your vendor supports.
`An example is helpful. Suppose that one part of
`your security policywas to allow inbound mail (SMTP.
`port 25), but only to your gateway machine. How—
`ever, mail from some particular site SPIGOT is
`to be blocked, because of their penchant for try-
`ing to mail several gigabytes of data at a time. A
`filter that implemented such a ruleset might look like
`ruleset A in the text box on the following page.
`The rules are applied in order from top to bottom.
`The “*"’ in a field matches anything. Packets not
`explicitly allowed by a filter rule are rejected, i.c.,
`every ruleset is followed by an implicit rule reading
`like ruleset B in the textbox above. This fits with
`our general philosophy: all that is not expressly
`permitted is prohibited.
`Note carefully the distinction between ruleset A
`and ruleset C, which is intended to implement the
`policy“anyinside hostcan send mail to the outside."
`The call may come from any port on an inside
`machine, butwill be directed to port 25 on the outside.
`This ruleset seems simple and obvious. It is also wrong.
`The problem is that the restriction we have defined
`is based solely on the outside host’s port number.
`While port 25 is indeed the normal mail port. there
`is no way we can control that on a foreign host. An
`eneinycan aoeessany internal machineandportbyorig—
`inating his call from port 25 on the outside machine.
`A better rule would be to permit outgoing calls
`Packet filters can provide a cheap and useful level
`to port 25, i.c., we want to permit our hosts to
`ofgateway security. Used by themselves, they are
`make calls to someone else’s port 25, so that we know
`cheap: the filtering abilities come with the router soft-
`ware. Since you probably need a router to connect
`what’s going on: mail delivery. An incoming call from
`port 25 implements some service of the caller’s choos—
`to the Internet in the first place, there is no extra charge.
`Even if the router belongs to your network service
`ing. Fortunately, the distinction between incom-
`provider, you will probably find that they will install
`ing and outgoingcalls can be made in a simple packet
`any filters you wish.
`filter if we expand our notation a bit.
`
`52
`
`IEEE Communications Magazine ' September 1994
`
`3
`
`

`

`
`
`A
`
`8
`
`
`action purhost
`pgrt
`theirhost port
`comment
`biock '
`*
`_
`*
`sneer '
`‘*
`we' denser-mime people
`allow 'OURéGW ‘ «25‘
`*
`‘
`'_
`tobur SMTPpart
`
`i
`
`'
`
`
`
`
`
`
`. rt ‘
`theirhost
`'
`ourhoa’cgw
`action
`biock_r
`it, _*~
`*
`
`,
`‘C I action earnest
`jag-arenas: part” commentTi
`atlow
`5‘6,
`*
`'
`i
`*
`25
`connection tethe‘ir SM‘i'P port
`
`Di; action "
`'sr'c‘
`-1ponv_;_raest
`_
`i
`’
`25 ,
`altow {burhosts}
`’5
`1 our packetstotheir SMTP port
`new ,
`3*7
`,
`25,
`p
`*_
`_
`_ n _*
`ACK ’
`‘ theirreplies
`_
`
`and“, .,{W¢m}_ '*
`3
`f,
`-
`, r
`v f- abut outgoingcoils
`allow - *4 .
`,*L
`*7
`*.
`ACK
`repligstooureaiis
`railow'
`‘*;
`,-
`"
`,* ‘ £8924
`_ traffic to nonservers
`
`.
`
`7
`
`.
`
`_,
`
`,
`
`A TCP
`
`conversation
`
`consists of
`
`packets
`
`flowing in
`
`two directions.
`
`Even if all
`
`the data
`
`is flowing
`
`one way,
`
`acknowledg-
`
`ment packets
`
`and control
`
`packets must
`
`flow the
`
`other way.
`
`A TCP conversation consists of packets flow-
`ing in two directions [19]. Even if all of the data is
`flowing one way, acknowledgment packets and
`control packets must flow the other way. We can
`accomplish what we want by paying attention to
`the direction of the packet, and by looking at
`some of the control fields. In particular, an initial
`open request packet in TCP does not have the set
`in the header; all other TCP packets do. Thus,
`packets with ACK set are part of an ongoing con-
`versation; packets without it represent connec-
`tion establishment messages, which we will permit
`only from internal hosts. The idea is that an out-
`sider cannot initiate a connection, but can contin—
`ue one. One must believe that an inside kernel
`will reject a continuation packet for a TCP ses-
`sion that has not been initiated. To date, this is a
`fair assumption. Thus, we can write our ruleset as
`seen in ruleset D, keying our rules by the source
`and destination fields, rather than the more neb—
`ulous “OURHOST” and “THEIRHOST”:
`The notation “ {our hosts}” describes a set of
`machines, any one ofwhich is eligible. In a real pack-
`et filter, you could either list the machines explicitly,
`or you could specify a group of machines. proba-
`blyby the network number portion ofthe [P address.
`
`Filtering FTP Sessions
`Some services are not handled well by packet filters.
`We use the File Transfer Protocol (FTP) [20] as an
`example here; other problematic protocols include
`x11 and the Domain Name System (DNS) [12, 16,
`17. 23].
`For FTP, files are transferred via a secondarycon-
`nection. If the control channel to a server on
`THEIRHOST uses the connection
`
`(ourhost, ourport,
`
`theirhost, 21).
`
`file transfers will occur on
`
`filtering decisions. Most servers, and hence most attack
`targets, live on low-numbered ports; most outgoing
`calls tend to use higher numbered ports, typicallyabove
`1023. Thus, a sample ruleset might be ruleset E in
`the text box, where packets are passed under one
`of three circumstances:
`' They originated from one of our machines.
`0 They are reply packets to a connection initiated
`by one of our machines.
`- They are destined for a high—numbered port on
`our machines.
`Actually, the last two rules apply to all packets, not
`just packets originating from outside. But any pack-
`ets from the inside would be accepted bythe first rule,
`and would not be examined by the later rules.
`Unfortunately, this ruleset does not accom-
`plish what we really want, which is to block incom-
`ing calls to our servers. We said “most servers”
`live on low-numbered ports, not “all.” A number
`of tempting targets, especially x11, inhabit high-
`numbered ports. Presumably, one could filter out
`known dangerous ports; unfortunately, new ones
`could be added without notice. Thus, a cautious
`stance dictates that this heuristic not be adopted.
`Under certain circumstances, a bypass is avail-
`able if you have the source code to the FTP client
`programs. You can modify the programs to issue
`a PASV command to the server, directing it to do
`a passive open, and thus permitting an outgoing
`call through the firewall for the data channel.
`This variant is not without its problems. The data
`Channel, though an outgoing call, is to a random port,
`Such calls are generally barred by sites that wish
`to restrict outbound data How. You also have the
`obvious problem of distributing modified clients
`to all inside machines. Also, not all servers under
`stand the PASV command, even though they
`should. The issues are discussed further in [3].
`
`Protocols Without Fixed Addresses
`
`theirhost, 20)
`
`(ourhost, ourport,
`
`Some services are problematic for packet filters
`because they can involve random port numbers. On
`occasion the situation is even worse: a number ofser-
`vices always use random port numbers, and rely on
`by default. Furthermore, the server must initiate the
`a separate server to supply the Cu rrent contact infor-
`file transfer call. We thus have the problem we
`mation.
`saw earlier, but without the ability to screen
`based on the direction of the call.
`Two examples ofthis are the tcpmux protocol [13]
`and the portmapper [261 used by SunOS for RPC
`One idea is to use the range of ourport to make
`
`
`IEEE Communications Magazine ' September 1994
`
`53
`
`4
`
`

`

`
`
`Filtering TCP
`
`circuits is
`
`difi‘icalt.
`
`Filtering
`
`UDPpackets
`
`while still
`
`retaining
`
`desired
`
`functionality
`
`is all but
`
`impossible.
`
`[‘25]. In both cases, client programs contact the map-
`ping program rather than the application.Thc portmap-
`per also processes registration requests from
`applications, informing it of their currentport num-
`bers. On the other hand, tcpmux will invoke the appli-
`cation directly, passing it the open connection.
`This difference gives rise to different filler-based
`protection mechanisms. With tcprnux, one can block
`access to either all such services, or none, simply
`by controlling access to the tcpmux port. With
`the portmapper. each service has its own port
`number. While one can deny easy access to them
`by filtering out portmapper requests, an intruder can
`bypass the portmapper and simply sweep the port
`number space looking for interesting applica»
`tions. We have seen evidence of this happening. The
`only cure is to block access to all possible port
`numbers used by RFC-based sewers — and there
`is no easy way to know what that range is.
`
`Packet Filters and UDP
`Filtering TCP circuits is difficult. Filtering UDP
`paCkEts [18] while still retaining desired function—
`ality is all but impossible.The reason lies in the essen—
`tial difference between TCP and UDP: the former is
`avirtual circuit protocol, and as such has retained con-
`text; the latter is a datagram protocol, where each
`message is independent. As we saw earlier, filter»
`ing TCP requires reliance on the ACK bit, in order
`to distinguish between incoming calls and return
`packets from an outgoing call. But UDP has no
`such indicator: we are forced to rely on the source
`port number, which is subject to forgery.
`An example illustrates the problem. Suppose
`an internal host wishes to query the UDP echo
`server on some outside machine. The originating
`packet would carry the address
`
`(localhost,
`
`localport, remotehost, 7) ,
`
`ting the clock when rebooting — will not work,
`because the client program will not use port 123. (Of
`course, at booting computer probably should not
`ask an outsider for the time.)
`
`Typical Configurations
`We cannot provide readerswith the exact packet fil-
`ter for a particular site, because we do not knowwhal
`its policies are. Butwe can give some reasonable sam —
`ples that may serve as a starting point.
`Universities tend to have an open policy about
`Internet connections. Still, they should block
`some common services, such as NFS and TFTP.
`There is no need to export these services to the world.
`Also, there might be a PC lab in a dorm that hasbcen
`the source of some trouble, so they do not allow
`that lab access the Internet. (The users have to go
`through one of the main systems that require an
`account, which gives some accountability.) Final—
`ly, there is to be no access to the administrative
`computers except for access to a transcript man—
`ager. That service should use strong authentica-
`lion and encryption.
`On the other hand, a small company with an
`Internet connection might wish to shut out most
`incoming Internet access, while preserving most
`outgoing connectivity. A gateway machine receives
`incoming mail and provides name service for the
`company’s machines. Only access to that machine.
`and to the necessary services, should be permitted.
`
`Application-Level Gateways
`
`where localport: is in the high-numbered range.
`But the reply would be
`
`(remotehost, 7,
`
`localhost,
`
`localport) ,
`
`and the firewallwould have no idea that localport
`was really a safe destination. An incoming packet
`
`(remotehost, 7,
`
`localhos:, 2049) .
`
`A n application-levelgateway representstheoppo-
`site extreme in firewall design. Rather than using
`a general-purpose mechanism to allow many dif—
`ferent kinds of traffic to flow, special-purpose
`code earl be used for each desired application.
`Although this seems wasteful, it is likely to be far
`more secure than any of the alternatives. One
`need not worry about interactions among differ-
`ent sets of filter rules, nor about holes in thou—
`sands of hosts offering nominally secure services
`to the outside. Only a chosen few programs need
`to be scrutinized.
`Application gateways have another advantage
`that in some environments is quite critical: it is
`easy to log and control all incoming and outgoing
`traffic. The SEAL package [21] from Digital
`Equipment Corporation takes advantage of this.
`Outbound FTP traffic is restricted to authorized
`is probably an attempt to subvert our NFS server;
`individuals. and the effective bandwidth is limit-
`and, while we could list the known dangerous
`destinations. we do not know what new targets
`ed. The intent is to prevent theft of valuable com—
`will be added next week by a system administra—
`pany programs and data. While of limited utility
`tor in the remote corners ofournetwork Worse yet,
`against insiders, who could easily dump the
`the RPCibased services use dynamic port num-
`desired files to tapes or floppies, it is a powerful
`bers, sometimes in the high-numbered range. Aswith
`weapon against electronic intruders who lack
`physical access.
`TCP, indirectly named services are not amenable
`to protection by packet filters.
`Electronic mail is often passed through an appli-
`A conservative stance therefore dictates that
`cation-level gateway, regardless of what technolo-
`gy is chosen for the rest of the firewall. Indeed,
`we ban Virtually all outgoing UDP calls. [t is not
`that the requests themselves are dangerous;
`mail gateways are valuable for their other proper-
`rather, it is that we cannot trust the responses.
`ties. even without a firewall. Users can keep the same
`The only exceptions are those protocols where there
`address, regardless of which machine they are
`is apcer-to-peerrelationship. Agood example is the
`using at the time. The gateway machines also
`Network Time Protocol (NTP) [15]. In normal oper-
`worry about mail header formats and logging
`ation, messages are both from and to port 123. It
`(mail logging is a postmaster’s friend) and pro-
`is thus easy to admit replies, because they are to a
`vide a centralized point for monitoring the behav-
`fixed port number, rather than to an anonymous
`ior of the electronic mail system.
`high-numbered port. But one use of NTP —~ set—
`It is equally valuable to route incoming mail
`
`54
`
`IEEE Communications Magazine 0 September 1994
`
`5
`
`

`

`
`
`The principal
`
`disadvantage
`
`of applica-
`
`tion-level
`
`gateways is
`
`the need for
`
`a specialized
`
`user program
`
`or variant
`
`user interface
`
`for most
`
`services
`
`provided.
`
`through a gateway. One person can be aware of
`all internal connectivity problems, rather than
`leaving it to hundreds of random system adminis—
`trators around the net. Reasonably constant mail
`addresses can be accepted and processed. Different
`technologies, such as uucp, can be used to deliver
`mail internally. Indeed, the need for incoming
`mail gateways is so obvious that the DNS has a
`special feature — MX records — defined to support
`them. No other application has a defined mecha-
`nism for indirect access.
`These features are even more valuable from a
`security perspective. Internal machine names can
`be stripped off, hiding possibly valuable data.
`Trafflc analysis and even content analysis and
`recording can be performed to look for informa—
`tion leaks. But these abilities should be used with
`the utmost reluctance, for both legal and ethical rea-
`sons.
`
`Application gateways are often used in con-
`junction with the other gateway designs, packet
`filters and circuit—level relays. An application
`gateway can be used to pass X11 through a fire-
`wall with reasonable security [27]. The semantic
`knowledge inherent in the design of an applica-
`tion gateway can be used in more sophisticated fash-
`ions. Gopher servers [1] can specify that a file is
`in the format used by the uuencode program.
`But that format includes a file name and mode. A
`clever gateway could examine or even rewrite this
`line, thus blocking attempts to force the installa—
`tion of bogus .rhosts files or shells with the
`setuid bit turned on.
`The type offiltering used depends on local needs
`and customs. A location with many PC users
`might wish to scan incoming files for viruses.
`We note that the mechanisms described here-
`in are intended to guard against attackfrom the out-
`side. A clever insider who wanted to retrieve such
`files certainly would not be stopped by them. But
`it is not a firewall’s job to worry about that class
`of problem.
`The principal disadvantage of application-
`level