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.
`Security on networked computers
`is much harder. The administra-
`torofasingle hostcan-withagreat
`deal of care and attention to details,
`luck in the choice of vendor soft-
`ware, and a careful and educated user community
`- probably do an adequate job of keeping the
`machine secure. But if the machine is connected
`to a network, the situation is much difficult.
`First, many more entry points to the host than
`a simple l o g i n prompt must be secured. The
`mailer, the networked file system, and the database
`servers are all potential sources of danger. Fur-
`thermore, the authentication used by some proto-
`cols may be inadequate. Nevertheless, they must
`be run, to provide adequate service to local users.
`Second, there are now many more points from
`which an attack can be launched. If a computer’s
`users are confined to a single building, it is dif-
`flcult for an outsider to try to penetrate system
`security. A network-connected computer, on the
`other hand, can be reached from any point on the
`network - and the Internet reaches tens of mil-
`lions of users in every part of the globe.
`Finally, networks expose computers to the prob-
`lem of transitive trust. Your computersmay be secure,
`but you may have users who connect from other
`machines that are lesssecure. Thisconnection-even
`ifdulyauthorizedandimmune todirect attack-may
`nevertheless be the vehicle for a successful penetra-
`tion ofyour machines, if the source of the connection
`has been compromised.
`The usual solution to all of these problems is afire-
`wall: abanier thatrestrictsthe freeflowofdatabetween
`the inside and the outside. Used properly, a firewall
`can provide asignificantincreaseincomputersecurity.
`Stance
`Akey decisionwhen developing a security policy is the
`stanceofthe firewalldesign. Thestance is the attitude
`of the designers. It is determined by the cost of fail-
`ure of the firewall and the designers’ estimate of that
`likelihood. It is also basedon the designers’ opinions
`of their own abilities. At one end of the scale is a phi-
`losophy that says, “we’ll run it unless you can show
`
`me that it’s broken.” People at the other end say, “show
`me that it’s both safe and necessary; otherwise, we
`won’trun it.”Thosewho arecompletelyoff the scale
`prefer to pull the plug on the network, rather than
`take any risks at all. Such a move is too extreme, but
`understandable. Why would a company risk losing
`its secrets for the benefits of network connection?
`We do not advocate disconnection for most sites.
`Our philosophy issimple: there areno absolutes. One
`cannot have complete safety; to pursue that chimera
`is to ignore the costs of the pursuit. Networks and
`internetworks have advantages; to disconnect from
`anetworkis to deny oneself those advantages. When
`all is said and done, disconnection may be the
`right choice, but it is a decision that can only be made
`by weighing the risks against the benefits.
`We advocate caution, not hysteria. For reasons
`that are spelled out below, we feel that firewalls are
`an important tool that can minimize the danger, while
`providingmost-butnot necessarily all-of
`the ben-
`efits of a network connection. However, a paranoid
`stance is necessary for many sites when setting up
`a firewall.
`Most computing professionals realize that most
`large software systems are buggy. If the system is
`security-sensitive - that is, if it provides any sort
`of network service at all - one runs the risk that
`the bugs will manifest themselves as security holes.
`The most practical solution is to run as few programs
`as possible, and to make sure that these are as small
`and simple as possible. A firewall can do this. It is
`not constrained to offer generalcomputing services
`to ageneral user population. It need not run networked
`file systems, distributedusernamedatabases,etc. The
`very act of eliminating such programs automatical-
`ly makes a firewall more secure than the average host.
`We also feel that any program, no matter how
`innocuous it seems, can harbor security holes. (Who
`would have guessed that on some machines, integer
`divide exceptions couldlead to system penetrations?)
`We thus have a firm belief that everything is guilty
`until proven innocent. Consequently, we configure
`our firewalls to reject everything, unlesswe have explic-
`itly made the choice - and accepted the risk - to
`permit it. Taking the opposite tack, of blocking only
`known offenders, strikes us as extremely dangerous.
`
`IEEE Communications Magazine September 1994
`
`STEVEN M. BELLOVIN
`works at AT&T Bell Labora-
`tones, where he does research
`in networks and securily
`
`WILLIAM R CHESWICK
`serves as an assirtantpro-
`gammer trainee and member
`of the technical staff at Bell
`Laboratories.
`
`Much of this article was
`taken ?om “Firewalls and
`Internet Security: Repelling
`the Wiky Hacker” by
`William R. Cheswick and
`Steven M. Bellovin,
`Addison Wesley Publishing
`Company, ISBN 0-201-
`63357-4, 0 1994 AT&T
`Bell Laboratories.
`
`50
`
`Authorized licensed use limited to: Stanford University. Downloaded on April 30, 2009 at 17:51 from IEEE Xplore. Restrictions apply.
`
`Juniper Ex. 1046-p. 1
`Juniper v Implicit
`
`

`

`-
`
`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; if usersand 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 toa differentway ofdoing things.
`One example would be the use of hand-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, gateway machines 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 machinecan, if theuserwishes(and decides
`against using hand-held authenticators), trust other
`machines, thereby eliminating the need for most
`passwordson the few accounts it should have. Again,
`something that is not there cannot be compromised.
`Gateway machines have other, nonsecurity advan-
`tages as well. They are a central point for mail and
`madministration, for example. Only one machine
`need be monitored for delayed mail, proper header
`syntax, return-address rewriting (i.e., to f irstname
`. lastname@org . dminformat), 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
`that we have stated about the benefits of a firewall,
`it should be stressed that we neither advocate nor
`condone sloppy attitudes toward host security. Even
`if a firewall were impermeable, and even if the admin-
`istrators and operators never made any mistakes, the
`Internet isnot theonlysource ofdanger. Apart from
`the risk of insider attacks and in some environments,
`that is a serious risk - an outsider can gain access
`by other means. In at least one case, a hacker
`came in through a modem pool, and attacked the
`firewall from the inside [7]. Strong host securitypoli-
`cies are a necessity, not a luxury. For that matter,
`internal firewallsare agood idea, toprotectverysen-
`sitive portions of organizational networks.
`Afirewall, ingeneral, consistsofseveral different
`components (Fig. 1). The “filters” (sometimes called
`“screens”) block transmission of certain classes of traf-
`fic. A gateway is a machine or a set of machines that
`provides relay services to compensate for the effects
`of the filter. The network inhabited by the gateway
`isoftencalled the demilitarizedzone (DMZ). Agate-
`way in the DMZ is sometimes assisted by an internal
`gateway. Typically, the two gateways will have more
`open communication through the inside filter than
`the outside gateway has to other internal hosts. Either
`filter,orforthatmatterthegatewayitself,maybeomit-
`ted; the details will vary from firewall to firewall. In
`general, the outside filter can be used to protect the
`gateway from attack, while the inside filter is used
`
`Figure I . Schematic of a 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 tosay, thisstance i5 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 a firewall is anath-
`ema. In most situations, the network is not the resource
`at risk rather, the endpoints of the 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
`not be suitably configured and armored to resist attack?
`The answer is that they should be, but proba-
`blycannot. Such attempts areprobablyfutile. There
`will be bugs, either in the network programsor 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
`loftyyourbattlements; ifan attacker findsone weak-
`ness - say, a postern gate, to extend our metaphor
`-your systemwill be penetrated. And if one machine
`falls. its neighbors are likely to follow.
`Types of Firewalls
`W placed between two networks that collectively
`e define afirewall as acollectionofcomponents
`
`have the following properties:
`All traffic from inside to outside, and vice-
`versa, must pass through the firewall.
`Only authorized trafflc, as defined by the local
`security policy, will be allowed to pass.
`The firewall itself is immune to penetration.
`We should note that these are design goals; a fail-
`ure in one aspect does not mean that the collection
`is not a firewall, simply that it is not a very good one.
`That firewalls are desirable follows directly from
`our earlier statements. Many hosts-and more like-
`ly, most hosts - cannot protect themselves against
`a determined attack. Firewalls have several dis-
`tinct advantages.
`First, ofcourse, afirewall is likely to be more secure
`than an average host. The biggest single reason
`for that is simply that it is not a general-purpose
`machine. Thus, features that are of doubtful secu-
`rity but add greatly to user convenience - Net-
`work Information Service (NIS), rlcgin, etc. - are
`not necessary. For that matter, many features of
`unknown security can be omitted if they are irrele-
`vant to the firewall’s functionality.
`A second benefit comes from having professional
`administration of the firewall machines. We do
`not claim that firewall administrators are necessarily
`
`IEEE Communications Magazine September 1994
`
`51
`
`Authorized licensed use limited to: Stanford University. Downloaded on April 30, 2009 at 17:51 from IEEE Xplore. Restrictions apply.
`
`Juniper Ex. 1046-p. 2
`Juniper v Implicit
`
`

`

`-
`
`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.
`
`to guard against theconsequencesof acompromised
`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 applicationgate-
`ways.Commonly,more thanoneoftheseisusedatthe
`same time. Asnotedearlier,mailisoftenrouted through
`a gateway even when no security firewall is used.
`Our examples and discussion unabashedlyrelate
`to UNIX systems and programs. The majority of mul-
`tiuser machines on the Internet run some version of
`the UNIX operating system. 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-
`ciallyasusedon the Internet.Again, thisisnot 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 TCPIIP. By far, it is the
`heterogeneous networking protocol of choice- not
`onlyonworkstations,forwhich it is thenative tongue
`-but on virtually all machines, ranging from desktop
`personal computers to the largest supercomputers.
`Many intemdcorporate networks are based onTCP/IP
`some - but not all -of
`these are connected to the
`Internet. And the Internet links most major uni-
`versitiesin theunited States (andmanyothersaround
`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 X.25
`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 security 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 largecompanies, most employees are
`not (or should not be) privy to all information. In
`othercompanies, thecash business(1ike thefactory,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 could be next. The firewall controls the access
`and the trust in a carefully predictable way.
`
`Packet-Filtering Gateways
`P of gateway security. Used by themselves, they are
`acket filters can provide a cheap and useful level
`
`cheap: the filtering abilities come with the router soft-
`ware. Since you probably need a router to connect
`to thelnternet inthe firstplace, there isnoextracharge.
`Even if the router belongs to your network service
`provider, you will probably find that they will install
`any filters you wish.
`
`Packet filterswork by dropping packets based on
`their source or destination addresses or service (i.e.,
`port number). In general, no context is kept; decisions
`are made only from the contentsof the current pack-
`et. Depending on the type of router, filtering may be
`doneat inputtime,atoutputtime,orboth.Theadmin-
`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 example,
`one can permit any IP 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-
`teringallowssomecontrolatthislevel, but itisadan-
`gerous and error-prone process. To do it right, one
`needs intimate knowledge of TCP 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 [SI. But even with a perfectly imple-
`mented filter, some compromises can be dangerous.
`We discuss these in a section to follow.
`Configuring a packet filter is a three-step process.
`First,ofwurse,onemust knowwhat shouldand 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
`remarkablydifflcult-the expressionsmust 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 (SMTF’,
`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 looklike
`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.e.,
`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
`po1icy“any inside host can send mail to the outside.”
`The call may come from any port on an inside
`machine, but will be directed to port 25 on the outside.
`This ruleset seems simple and obvious. It is also wrong.
`The problemis that therestriction 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
`enemy can access any intemal machine and port byorig-
`inating his call from port 25 on the outside machine.
`A better rule would be to permit outgoing calls
`to port 25, i.e., we want to permit our hosts to
`make calls to someone else’s port 25, so that we know
`what’sgoingon: mail delivery. An incoming call from
`port 25 implements some service of the caller’s choos-
`ing. Fortunately, the distinction between incom-
`ing and outgoing calls can be made in a simple packet
`filter if we expand our notation a bit.
`
`52
`
`IEEE Communications Magazine September 1994
`
`Authorized licensed use limited to: Stanford University. Downloaded on April 30, 2009 at 17:51 from IEEE Xplore. Restrictions apply.
`
`Juniper Ex. 1046-p. 3
`Juniper v Implicit
`
`

`

`-
`
`A TCP
`conversation
`consists of
`packets
`flowing in
`two directions.
`Even ifall
`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, anyone of which is eligible. In a real pack-
`et filter, youcouldeither list themachinesexplicitly,
`or you could specify a group of machines, proba-
`bly by the network number portion of the IP address.
`Filtering FTP Sessions
`Some services are not handled well by packet filters.
`We use the File Transfer Protocol (FTF’) [20] as an
`example here; other problematic protocols include
`x11 and the Domain Name System (DNS) [12,16,
`17. 231.
`For FIT, files are transferredviaasecondarycon-
`nection. If the control channel to a server on
`THEIRHOST uses the connection
`
`(ourhost, ourport, t h e i r h o s t , 2 1 ) ,
`
`file transfers will occur on
`
`(ourhost, ourport, t h e i r h o s t , 2 0 )
`
`by default. Furthermore, the server must initiate the
`file transfer call. We thus have the problem we
`saw earlier, but without the ability to screen
`based on the direction of the call.
`One idea is to use the range of ourport to make
`
`filtering decisions. Most servers, and hence most attack
`targets, live on low-numbered ports; most outgoing
`calls tend to use higher numbered ports, typically above
`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.
`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 by the 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 ~ 1 1 ,
`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 PA= 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 flow. 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
`Some services are problematic for packet filters
`because they can involve random port numbers. On
`occasion the situation is evenworse: a number of ser-
`vices always use random port numbers, and rely on
`a separate server to supply the current contact infor-
`mation.
`Twoexamplesofthisare the tcpmuxprotocol[13]
`and the portmapper [26] used by SunOS for RPC
`
`IEEE Communications Magazine September 1994
`
`53
`
`Authorized licensed use limited to: Stanford University. Downloaded on April 30, 2009 at 17:51 from IEEE Xplore. Restrictions apply.
`
`Juniper Ex. 1046-p. 4
`Juniper v Implicit
`
`

`

`-
`
`Filtering TCP
`circuits is
`dificult.
`Filtering
`UDP pa ckets
`while still
`retaining
`desired
`functionality
`is all but
`impossible.
`
`[25]. In both cases, client programs contact the map-
`ping program rather than the application.The 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 filter-based
`protection mechanisms. With tcpmux, 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 RPC-based servers - 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 isall but impossible. The reason liesin the essen-
`tial difference between TCP and UDP: the former is
`avirtualcircuit protocol, and assuch hasretainedcon-
`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
`
`where localport is in the high-numbered range.
`But the reply would be
`
`( remotehost, 7, localhost, localport) ,
`
`and the firewall would have no idea that localport
`was really a safe destination. An incoming packet
`
`(remotehost, 7, localhost, 2049),
`
`is probably an attempt to subvert our NFS server;
`and, while we could list the known dangerous
`destinations, we do not know what new targets
`will be added next week by a system administra-
`tor in the remote corners of our network. Worse yet,
`the RPC-based services use dynamic port num-
`bers, sometimes in the high-numbered range. As with
`TCP, indirectly named services are not amenable
`to protection by packet filters.
`A conservative stance therefore dictates that
`we ban virtually all outgoing UDP calls. It is not
`that the requests themselves are dangerous;
`rather, it is that we cannot trust the responses.
`The only exceptions are those protocols where there
`is apeer-to-peerrelationship. Agood example is the
`NetworkTime Protocol (NTP) [15]. Innormal oper-
`ation, messages are both from and to port 123. It
`is thus easy to admit replies, because they are to a
`fixed port number, rather than to an anonymous
`high-numbered port. But one use of NTP - set-
`
`ting the clock when rebooting - will not work,
`because the client program will not use port 123. (Of
`course, a 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 know what
`itspolicies are. Butwecangivesomereasonable 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 PClab in a dorm that has been
`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-
`tion 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
`A site extreme in firewall design. Rather than using
`n application-level gateway represents the oppo-
`
`a general-purpose mechanism to allow many dif-
`ferent kinds of traffic to flow, special-purpose
`code can 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
`individuals, and the effective bandwidth is limit-
`ed. The intent is to prevent theft of valuable com-
`pany programs and data. While of limited utility
`against insiders, who could easily dump the
`desired files to tapes or floppies, it is a powerful
`weapon against electronic intruders who lack
`physical access.
`Electronic mail is often passed through an appli-
`cation-level gateway, regardless of what technolo-
`gy is chosen for the rest of the firewall. Indeed,
`mail gateways are valuable for their other proper-
`ties, even without a firewall. Userscan keep the same
`address, regardless of which machine they are
`using at the time. The gateway machines also
`worry about mail header formats and logging
`(mail logging is a postmaster’s friend) and pro-
`vide a centralized point for monitoring the behav-
`ior of the electronic mail system.
`It is equally valuable to route incoming mail
`
`54
`
`IEEE Communications Magazine September 1994
`
`Authorized licensed use limited to: Stanford University. Downloaded on April 30, 2009 at 17:51 from IEEE Xplore. Restrictions apply.
`
`Juniper Ex. 1046-p. 5
`Juniper v Implicit
`
`

`

`-
`
`The principal
`disadvantage
`of applica-
`tion - level
`gateways is
`the need for
`a specialized
`user program
`or variant
`user in ter3ca ce
`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 - MXrecords - 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 utmostreluctance,forbothlegalandethicalrea-
`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 ~ 1 1
`through a fire-
`wall with reasonable security [27]. The semantic
`knowledge inherent in the design of an applica-
`tiongateway canbe usedinmoresophisticatedfash-
`ions. Gopher servers [l] 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 cou