Securing ~~
`Information
`Superhighway
`
`ONG
`
`CS-1008
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 47
`
`2~
`
`Ww
`
`~
`ak
`a> >
`Ue
`aw) LUE,
`ae WoYu a
`
`CS-1008
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 47
`
`

`

`KazemSohraby, AT&T Bell Labs
`
`Securing the Information Superhighway
`
`33 Kerberos: An Authentication Service for
`Computer Networks
`Whenusing authentication based on cryptography, an attack-
`erlistening to the network gains no information that would
`enable it to falsely claim another’s identity. Kerberosis the
`most commonly used example ofthis type of authentication
`technology.
`B. Clifford Neuman and Theodore Ts’o
`
`4() Access Control: Principles and Practice
`Access control constrains what a usercan dodirectly, as
`well as what programs executing on behalf of the users are
`allowed to do. In this way access control seeks to prevent
`activity that could lead to breachofsecurity.
`Ravi S. Sandhu and Pierangela Samarati
`
`50 Network Firewalls
`Computersecurity is a hard problem. Security on networked
`computers is much harder. Firewalls (barriers between two
`networks), whenused properly, can provideasignificant
`increase in computersecurity.
`Steven M.Bellovin and William R. Cheswick
`
`5S
`
`Key Escrowing Today
`The objective of the U.S. Government's Escrowed Encryption
`Standard and associated Key Escrow Systemis to provide
`strong security for communications while simultaneously
`allowing authorized government accessto particular commu-
`nications for law enforcement andnational security purposes.
`Dorothy E. Denning and Miles Smid
`
`Toward a National Public Key Infrastructure
`Reliance onelectronic communications makes information
`more vulnerable. Public key cryptographywill play an important
`role in providing confidentiality, messageintegrity, sender
`authentication, and sender non-repudiation.
`Santosh Chokhani
`
`
`70
`
`IEEE
`
`ommunications
`
`SE
`
`PT 1994 Vol. 32 No. 9
`
`MTHIS ISSUE
`
`provid
`
`es a sampling of security functions and
`
`technologies designed to protect the
`
`information superhighway.
`
`Cover illustration by Marsha Saldanha.
`
`MAGAZINE
`
`
`
`
`Director of Publications
`Editor-in-Chief Emeritus
`ThomasJ. Plevyak, Bell Atlantic
`Editor-in-Chief
`Curtis A.Siller, Jr., AT&T Bell Labs
`Executive Director
`Carol M, Lof, IEEE
`Senior Technical Editors
`Haruo Akimaru, Toyahashi U. (Japan)
`Adam Lender, Lockheed Research Laboratory
`Bahman Mobasser,Alcatel
`Harry Rudin, IBM Zurich Research Laboratory
`RaymondSteele, U. Southampton (UK)
`Technical Editors
`Ranavir Bose, AT&T Bell Labs.
`Michel Diaz, LAAS-CNRS,France
`Christos Douligeris, U, of Miami
`M.Robert Dresp, MITRE Corp.
`Boris Elenkrig, Russian Academyof Sciences
`‘Sol Greenspan, GTE Labs
`Roch Guerin, IBM Corp.
`Bruce Kieburtz, KEC
`Anton Kuchar, Czechoslovak Academy of Sciences
`Howard Lemberg, Bellcore
`John Lemp,Jr., U. Colorado
`Torlciv Maseng, Trondheim Tech. U. (Norway)
`Tetsuya Miki, NTT (Japan)
`Hussein Mouftah, Queens U. (Canada)
`John O'Reilly, U. of N. Wales
`RaymondPyle, Bell Atlantic
`Ram Rathore, Bellcore
`Tarek N. Saadawi, City College NY.
`Hady Salloum, Bellcore
`Rajeev Sinha, Bellcore
`Tetsuji Tanaka, OKI Electric Industry Co., Ltd.
`A.W.D. Watson, Motorola (UK)
`Patrick E, White, Bellcore
`Feature Editors
`Chung-ShengLi, IBM Corp., Book Reviews
`Tetsuya Miki, NTT, Chapters Comer
`David B. Newman,Jr., Law Offices of D.B. Newman
`Communications and the Law
`Paul Green, IBM Corp., CommuniCrostics Puzzle
`Vikram Punj, AT&TBell Labs, Conference Calendar
`S. Pasupathy, U. Toronto, Light Traffic
`Ahmad Aman, AT&T, News and Events
`Sue McDonald, Bellcore, News From JSAC
`AmaneNakajima, IBM Corp., Japan
`Kuriacose Joseph, David Sarnoff Res. Ctr.
`G.Soder, Technische U. Munchen
`S. Chia, British Telecom Labs
`Scanning the Literature
`Koichi Asatani, NTT
`Mostafa HashemSherif, AT&T Bell Labs
`Standards
`Regional Correspondents
`Victor Perez, Motorola (Mexico)
`Latin American Correspondents
`Janusz Filipiak, U. Mining & Metallurgy (Poland)
`Central & Eastern European Correspondent
`Angelo Luvison, CSELT(Italy)
`European Correspondent
`N. Sokolov, LONIIS (Russia)
`Russian Correspondent
`Botaro Hirosaki NEC Corp. (Japan)
`Asian Correspondent
`IEEE Production Staff
`Joseph Milizzo, Managing Editor
`Elizabeth Wilber, Production Editor
`Alan E,Oirich, Layout Editor
`Eric Levine, Advertising Sales Manager
`Joanne O'Rourke,Staff Assistant
`Susan Lange, Publications Assistant
`Erin E. Foote, Publications Assistant
`Operations Editor
`
`
`
`Sty—afeee
`
`48
`
`

`

`
`
`
`
`1994 Communications Society Officers
`Maurizio Decina, President
`Stephen B. Weinstein, VP-TechnicalAffairs
`Roberto B. de Marea, VP-International Affairs
`Celia L. Desmond, VP-Member Affairs
`Carol M.,Lof, Secretary
`G, Allan Ledbetter, Treasurer
`Paul Green, Past President
`Board of Governors
`Theofficers above plus Members-at-Large:
`Class of 1994
`Allen H. Cherin
`Richard Gitlin
`82. Securing a GlobalVillage and Its Resources
`Ray R. Laane
`Richard P, Skillen
`In aninternational economy andsocial infrastructure that
`
`Classof1995
`is growing more dependent everyday onits communications
`Anne Aldridge
`Laurence B, Milstein
`networks, more attention must be placed onthe security
`Birendra Prasada
`andintegrity of the components andinterfaces of those
`Harry Rudin
`Class of 1996
`critical structures.
`Harvey A. Freeman
`Lin-shan Lee
`Henry M.Kluepfel
`Joseph L. LoCicero
`Richard K.Snelling
`
`76 Digital Signatures: Are They Legal for Electronic
`Commerce?
`Digital signature technology promises assuranceat least
`equal to written signatures, Fromalegal standpoint, this
`assurance remains tobe tested in the evidentiary process.
`Patrick W. Brown
`
`Topics in Lightwave
`QQ) The Hidden Benefits Of Optical Transparency
`The optical fiber amplifier will bring about network trans-
`parency and reductions in manninglevels, interface prob-
`lems, software and operating costs, while improving
`reliability and performance,
`Peter Cochrane, Roger Heckingbottom, and David Heatley
`
`QS All-Optical Signal Processing in Ultrahigh-Speed
`Optical Transmission
`The coming broadbandera will require very high-speed
`technologies that can handle more than 100-Gb/s for both
`transmissionlines andtransmission nodes. Novel all-optical
`signal processing technologies that offer unsurpassed
`performanceare urgently required.
`Masatoshi Saruwatori
`
`Communicrostic Puzzle No. 142
`
`D EP A RT M EN T
`
`S
`
`Message from the President and
`the Director of Publications
`News from JSAC
`Reader Service Card
`Chapters Corner
`Communications and the Law
`Solution to Communicrostic No. 141
`Book Reviews
`Society News
`Guest Editorial
`Conference Calendar
`Advertisers Index
`New Products
`Scanning the Literature
`
`
`
`WPA.
`
`1994 IEEE Officers
`H. Troy Nagle, President
`J. Thomas Cain, President-Elect
`Luis T, Gandia, Secretary
`V. Thomas Rhyne, Treasurer
`Martha Sloan, Past President
`John H. Powers, General Manager
`John S$. Ryan, Director, Division IIT
`IEEE COMMUNICATIONS MAGAZINE
`(ISSN 0163-6804) is published monthly by The
`Institute of Electrical and Electronics Engineers,
`Inc. Headquarters address IEEE, 345 East 47th
`Street, NewYork, NY 10017-2394;telephone 212-705-
`7018; e-mail: j.milizzo@icee.org, Responsibility
`for the contents rests upon authors ofsigned articles
`and not the IEEE orits members, Unless otherwise
`specified, the IEEE neither endorses nor sanctions
`any positions or actions espoused in JEEE
`Communications Magazine,
`ANNUAL SUBSCRIPTION:
`$23 per memberperyearincludedin Societyfee.
`Non-membersubscription: $135. Single copy $10 for
`members and $20 for nonmembers.
`EDITORIAL CORRESPONDENCE:
`Address to: Editor, Curtis A. Siller, Jr., AT&TBell
`Laboratories, Rm 21-3F19, 1600 OsgoodStreet,
`North Andover, MA 01845; e-mail: csiller@mvuas
`.att.com. For departments, please see columns,
`COPYRIGHT AND REPRINT PERMISSIONS:
`Abstracting is permitted with credit to the source.
`Libraries are permitted to photocopybeyond the lim-
`itsof U.S, Copyrightlawforprivate use ofpatrons:
`those post-1977articles that carry a code on the bottom
`ofthe first page provided the per copy fee indicated
`in the codeis paid through the Copyright Clearance
`Center, 222 Rosewood Drive, Danvers, MA01923. For
`other copying, reprint, or republication permission,
`write to Director, Publishing Services, at [EEE Head-
`quarters, All rights reserved. Copyright © 1994 byThe
`Institute ofElectrical and Electronics Engineers,Inc.
`POSTMASTER:
`Send address changes to /EEE Communications
`Magazine, VEEE, 445 Hoes Lane, Piscataway, NJ
`08855-1331. GSTRegistration No, 125634188, Printed
`in USA. Second-class postage paid at New York,
`NYand atadditional mailing offices. Canadian Post
`International Publications Mail (Canadian
`Distribution) Sales Agreement No. 264075.
`SUBSCRIPTIONS,
`orders, address changes — IEEE Service Center,
`445 HoesLane,Piscataway, NJ 08855-1331; tele-
`phone: 908-981-0060,
`ADVERTISING:
`Advertising is accepted at the discretion of the pub-
`lisher. Address correspondence to:
`[EEE
`Communications Magazine, 345 East 47th Street,
`NewYork, NY 10017-2394,
`
`
`
`
`
`
`
`
`
`
`
`er 1994 ee Nsbs
`
`49
`
`

`

`Network Firewalls
`miFi
`Computer security is a hard problem. Security on networked
`computers is muchharder. Firewalls (barriers between two
`networks), when used properly, can provide a significant increase
`in computer security.
`
`
`R
`form
`else is
`thing
`able i
`not n
`the d
`
`|
`
`Inst
`
`
`
`Steven M. Bellovin and William R. Cheswick
`
` omputersecurity is a hard problem.
`
`Hosi
`Toso
`ema.)
`at risk
`ened.
`vice |
`tool t
`with 1
`attac!
`notbe
`Tl
`blyca
`will b
`admii
`puter
`does
`lofty}
`ness-
`
`—yol
`falls,
`
`yp
`
`Wh
`
`ave|
`° All
`ver
`e On
`sec
`° The
`Wi
`ure in
`is not
`Th
`oureé
`
`aeaNGeeeenersineee=nepeereneeoe
`
`methatit’s broken.” People at the other end say, “show
`Security on networked computers
`methat it’s both safe and necessary; otherwise, we
`is much harder. The administra-
`won’ trunit.” Those who are completely off the scale
`prefer to pull the plug on the network,rather than
`tor ofa single host can—witha great
`deal of care and attentionto details,
`take anyrisksat all. Such a moveis too extreme, but
`luck in the choice of vendor soft-
`understandable. Why would a companyrisk losing
`its secrets for the benefits of network connection?
`ware, and a careful and educated user community
`We do not advocate disconnection for mostsites,
`— probably do an adequate job of keeping the
`machinesecure. But if the machine is connected
`Ourphilosophyis simple: there are no absolutes. One
`to a network, the situation is muchdifficult.
`cannot have completesafety; 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 networkedfile system, and the database
`anetworkis to deny oneself those advantages. When
`serversare all potential sources of danger. Fur-
`all is said and done, disconnection may be the
`thermore, the authentication used by some proto-
`right choice, but itis a decision that can only be made
`by weighing the risks against the benefits.
`cols may be inadequate. Nevertheless, they must
`be run, to provide adequate serviceto localusers.
`Weadvocate caution, not hysteria. For reasons
`Second, there are now many morepoints from
`that are spelled out below, wefeel that firewalls are
`an importanttool that can minimize the danger, while
`which an attack can be launched. If a computer’s
`providing most— butnot necessarily all—ofthe ben-
`users are confined to a single building, it is dif-
`efits of a network connection. However, a paranoid
`flcult for an outsider to try to penetrate system
`stance is necessary for many sites whensetting 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 systemsare 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 anysort
`of networkservice at all — one runsthe risk that
`lem oftransitive trust. Your computers maybe secure,
`the bugs will manifest themselvesassecurity holes.
`but you may have users who connect from other
`machinesthat areless secure. This connection—even
`The mostpractical solution is to run as few programs
`as possible, and to makesure that these are as small
`ifduly authorized and immunetodirect attack —may
`and simpleas possible. A firewall can dothis.It is
`nevertheless be the vehicle for a successful penetra-
`not constrainedto offer general computingservices
`tion ofyour machines,if the source of the connection
`ly, me
`toageneraluserpopulation. Itneed not runnetworked
`a det
`has been compromised.
`file systems,distributed user namedatabases,etc. The
`tinct¢
`The usualsolutionto all of these problemsisa fire-
`wall: a barrierthat restricts the free flow ofdata between
`very act of eliminating such programs automatical-
`Fi
`thanj
`lymakesa firewall more securethan the averagehost.
`the inside and the outside. Used properly, a firewall
`for th
`Wealso feel that any program, no matter how
`can provideasignificant increase in computersecurity.
`Muchofthis article was
`innocuousit seems, can harborsecurity holes. (Who
`mach
`takenfrom “Firewalls and
`would have guessed that on some machines,integer
`Internet Security: Repelling
`rity bi
`divide exceptions couldleadto system penetrations?)
`work
`Akeydecision when developing a security policy is the
`the Wiley Hacker”by
`William R. Cheswick and
`not n¢
`Wethushaveafirm belief that everything is guilty
`stance ofthe firewall design. The stanceis the attitude
`unkn«
`until proven innocent. Consequently, we configure
`Steven M. Bellovin,
`of the designers. It is determined by the costof fail-
`vantt
`ourfirewalls to reject everything, unlesswe have explic-
`ureofthe firewall and the designers’ estimate of that
`AddisonWesley Publishing
`AS
`itly made the choice — andaccepted the risk — to
`likelihood. It is also based onthe designers’ opinions
`Company, ISBN 0-201-
`permitit. Taking the opposite tack,of blocking only
`admit
`63357-4, © 1994 AT&T
`of their own abilities. At one endofthe scaleis a phi-
`Bell Laboratories.
`notcl
`knownoffenders,strikes us as extremely dangerous.
`losophy that says, “we’ll run it unless you can show
`
`
`STEVEN M. BELLOVIN
`works at AT&T Bell Labora-
`tories, where he does research
`in networks andsecurity
`
`WILLIAM R. CHESWICK
`serves as anassistant pro-
`grammertrainee and member
`of the technicalstaffat Bell
`Laboratories.
`
`Stance
`
`50
`
`IEEE Communications Magazine * September 1994
`
`
`IEEE
`
`

`

`
`|1
`
`Filter
`
`Filter
`
`
`
`rite(stew)Outside
`
`|
`
`|
`
`
`
`™@ Figure 1. Schematic of a firewall.
`
`Furthermore, whether or not asecurity policy is
`formally spelled out, one alwaysexists. If nothing
`else is said or implemented, the defaultpolicy is “any-
`thing goes.” Needlesstosay,this stanceis rarely accept-
`able ina security-conscious environment. Ifone does
`not make explicit decisions, one will have made
`the default decision to allow almost anything.
`
`Host Security
`Tosomepeople,the very notion ofa firewall is anath-
`ema. In most situations, the networkis not the resource
`atrisk; rather, the endpoints of the networkare threat-
`ened. By analogy, con artists rarely steal phoneser-
`vice per se; instead, they use the phonesystemas a
`tool to reach their real victims. Soit is, in a sense,
`with networksecurity. Given that the target of the
`attackers is the hosts on the network, should they
`notbe suitably configured and armoredto 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 programsorin the
`administration of the system. It is this way with com-
`putersecurity: the attacker only has to winonce. It
`does not matter howthick are your walls, nor how
`lofty your battlements; ifan attackerfinds one weak-
`ness — say, a postern gate, to extend our metaphor
`—yoursystem will be penetrated. Andifone machine
`falls, its neighborsare 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.
`
`that most —
`
`systemis |
`
`more competent than your average system admin-
`istrator, but they may be moresecurity conscious.
`However, they are almost certainly better than
`nonadministrators who must nevertheless tend to
`their own machines. This category wouldinclude
`physical scientists, professors, etc., who (rightly)
`prefer to worry about their ownareas of responsi-
`bility. It may or may not be reasonable to demand
`more security consciousness from them; never-
`theless,it is obviously nottheir top priority.
`Fewernormal usersis a help as well. Poorly
`chosen passwordsare aseriousrisk; if users and their
`attendant passwords do not exist, this is not a
`problem. Similarly, one can make moreor less
`arbitrary changes to various program interfacesif
`that would help security, without annoying a pop-
`ulation accustomedto a different way ofdoing things.
`One example would bethe use of hand-held authen-
`ticators for logging in. Many people resent them,
`or they may be too expensiveto be furnished to
`an entire organization; a gateway machine, how-
`ever, Should have a user community thatis restrict-
`ed enoughso that these concernsare negligible.
`Moresubtly, gateway machines need not, and should
`say, “show
`not, be trusted by any other machines. Thus, even if
`erwise, we
`the gateway machine has been compromised, no oth-
`ffthescale
`ers will fall automatically. On the other hand, the
`ather than —
`gateway machinecan,if the user wishes (and decides
`treme, but
`against using hand-held authenticators), trust other
`risk losing
`machines, thereby eliminating the need for most
`nnection?
`passwordson the few accountsit should have. Again,
`mostsites,
`something that is not there cannot be compromised.
`lutes.One
`Gateway machineshave other, nonsecurity advan-
`itchimera
`tages as well. They are a central point for mail and
`vorks and
`FTP administration, for example. Only one machine
`nect from
`need be monitored for delayed mail, proper header
`yes. When
`syntax, return-address rewriting (i.e., to firstname
`ay be the
`. lastname@org . domain format), etc. Outsiders have
`y be made
`a Single point of contact for mail problems and a
`33
`single location to search forfiles being exported.
`yrreasons
`permitit.
`Our main focus, though, is security. And forall
`Types ofFirewalls
`ewalls are
`that we have stated aboutthe benefits of a firewall,
`ger, while
`Wedefineafirewallasacollectionofcomponents
`it should be stressed that we neither advocate nor
`oftheben-
`placed between two networksthatcollectively
`condonesloppyattitudes toward hostsecurity. Even
`paranoid ©
`have the following properties:
`ifa firewallwere impermeable, and evenif the admin-
`setting up
`° All traffic from inside to outside, and vice-
`istrators and operators never madeany mistakes, the
`versa, must pass throughthe firewall.
`Internetis not the only source ofdanger. Apart from
`° Only authorized traffic, as defined by the local
`the risk of insider attacks and in some environments,
`security policy, will be allowed to pass.
`that is a serious risk — an outsider can gain access
`° The firewall itself is immuneto penetration.
`by other means. In at least one case, a hacker
`Weshould note that these are design goals;a fail-
`camein through a modem pool, and attacked the
`ure in one aspect does not meanthatthe collection
`firewall from the inside [7]. Strong host security poli-
`is nota firewall, simply thatit is not a very good one.
`cies are a necessity, not a luxury. Forthat matter,
`That firewalls are desirable followsdirectly from
`internalfirewalls are a good idea,to protect very sen-
`ourearlier statements. Many hosts— and morelike-
`sitive portions of organizational networks.
`ly, most hosts — cannotprotect themselves against
`A firewall, in general, consists of several different
`a determined attack. Firewalls have several dis-
`components(Fig. 1). The “filters” (sometimescalled
`tinct advantages.
`“screens”) block transmissionofcertainclassesoftraf-
`First, ofcourse,a firewall is likely to be more secure
`fic. A gateway is a machineora set of machinesthat
`than an average host. The biggest single reason
`providesrelay services to compensateforthe effects
`for that is simply that it is not a general-purpose
`ofthe filter. The network inhabited by the gateway
`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 DMZis sometimesassisted by an internal
`work Information Service (NIS), rlogin, etc. — are
`gateway. Typically, the two gateways will have more
`not necessary. For that matter, many features of
`open communication throughthe inside filter than
`unknownsecurity can be omittedif they are irrele-
`the outside gatewayhasto otherinternal hosts. Either
`vantto the firewall’s functionality.
`.
`filter, or for that matter the gatewayitself, may be omit-
`A secondbenefit comesfrom havingprofessional
`ted; the details will vary from firewall to firewall. In
`administrationof the firewall machines. We do
`general, the outsidefilter can be used to protect the
`not claimthatfirewall administrators are necessarily
`gateway from attack, while the insidefilter is used
`
`
`eI
`4g
`
`S any sort
`risk that
`rity holes.
`programs
`e as small
`
`|
`this. It is
`g services
`etworked
`sete. The
`omatical- —
`rage host.
`itter how
`les.(Who
`s,integer
`rations?)
`zis guilty
`configure
`veexplic- ;
`risk —to
`king only :
`ngerous.
`
`aber 1994
`
`IEEE Communications Magazine ° September 1,994
`
`
`
`
`

`

`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.
`
`
`
`\)
`
`eeoeOUee
`
`
`to guardagainst the consequences of acompromised
`gateway. Eitherorbothfilters can protect the
`internal network fromassaults. An exposedgateway
`machineis often called a bastion host.
`Weclassify firewalls into three main categories:
`packetfiltering, circuit gateways, andapplication gate-
`ways. Commonly, more thanoneof these is usedatthe
`sametime. Asnotedearlier, mail is often routed through
`a gateway even whennosecurity firewall is used.
`Our examples and discussion unabashedlyrelate
`to UNIXsystems and programs. The majority of mul-
`tiuser machines onthe Internet run some version of
`the UNIX operating system. Most application-level
`gateways are implemented in UNIX.Thisis not to
`say that other operating systems are more secure; how-
`ever,there are fewerof them onthe 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 systemsas well.
`Ourfocusis on the TCP/IP protocolsuite, espe-
`ciallyas used onthe Internet. Again,this is not because
`TCP/IP has moresecurity problems thanotherpro-
`tocol stacks (we doubtthat very much),rather,it is a
`commentary on the success of TCP/IP.Byfar,it is the
`heterogeneous networkingprotocol ofchoice —not
`only onworkstations,for whichit is the native tongue
`— butonvirtually all machines, ranging from desktop
`personal computersto the largest supercomputers.
`Manyinternalcorporate networks are based on TCP/IP;
`some — butnot all — ofthese are connectedto the
`Internet. And the Internet links most major uni-
`versities in the United States (and many others around
`the world), research labs, many governmentagencies,
`and even a fair number of businesses. Webelieve,
`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 woulddiffer in detail.
`Traditionally, firewalls are placed between an
`organization and the outside world. Buta large orga-
`nization may needinternalfirewalls as well to iso-
`late security domains(also knownas administrative
`domains). A security domainis a set of machines
`under common administrative control, with a
`commonsecurity policy and security level.
`There are many good reasonsto erectinternalfire-
`walls. In many large companies, most employees are
`not (or should notbe)privy to all information. In
`other companies,the cash business(like the factory, or
`a phone company’s telephone switches) needs to be
`accessible to developers or support personnel,but
`not to the generalcorporate population. Even autho-
`rized users shouldpass throughasecurity gate-
`way when crossingthe firewall; otherwise, if their
`home machines, whichlive outside ofthe firewall,
`are compromised,the sensitive equipment onthe
`inside could be next. Thefirewall controls the access
`and the trust in a carefully predictable way.
`
`
`
`file
`
`by<
`file
`sav
`bas
`
`Packet filters work by dropping packets based on
`their source ordestination addresses orservice (i.e.,
`port number). In general, no contextis kept; decisions
`are madeonlyfromthe contentsofthe current pack-
`et. Dependingon the type ofrouter,filtering may be
`doneat inputtime,at output time, or both. The admin-
`istrator makes alist of the acceptable machines and
`services anda stoplist of unacceptable machines or
`services. It is easy to permit or denyaccess at the host
`or networklevel with a packet filter. For example,
`one can permit any IP access betweenhost A and B,
`or deny any access to B from any machinebut A,
`Mostsecurity 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 wantto allow any host to connect
`tomachineA, but only to sendor receive mail. Other
`services may or may not be permitted. Packetfil-
`tering allows some controlatthis level, but itis a dan-
`gerous and error-prone process. To doit right, one
`needs intimate knowledge ofTCP and UDPportuti-
`lization on a number of operating systems. Thisis
`oneofthe disadvantagesofpacketfilters: if you get
`these tables wrong you may inadvertently let in
`the Bad Guys[5]. But even witha perfectly imple-
`mentedfilter, some compromisescanbe dangerous.
`Wediscussthesein a sectionto follow.
`Configuring a packetfilteris 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
`mustbe specified formally, in termsoflogical expres-
`sions on packetfields. Finally — and this can be
`remarkablydifflcult— the expressions mustbe rewrit-
`ten in whatever syntax your vendorsupports.
`Anexampleis helpful. Suppose that onepart of
`yoursecurity policy wasto allow inbound mail (SMTP,
`port 25), but only to your gateway machine. How-
`ever, mail from someparticular site SPIGOTis
`to be blocked, because of their penchant fortry-
`ing to mail several gigabytes of data at a time. A
`filter that implemented such a ruleset mightlooklike
`ruleset A in the text box on the following page.
`Therules are appliedin order from top to bottom.
`The “*” in a field matches anything. Packets not
`explicitly allowed bya filter rule are rejected, i.e.,
`every rulesetis followed by an implicit rule reading
`like ruleset B in the textbox above. Thisfits with
`our general philosophy:all that is not expressly
`permitted is prohibited.
`Note carefully the distinction betweenruleset A
`and ruleset C, which is intended to implementthe
`policy “any inside host can send mailto the outside.”
`Thecall may come fromanyport on an inside
`machine,butwill be directed to port 25 on the outside.
`This rulesetseems simple and obvious.It is also wrong.
`The problemisthatthe restriction we have defined
`is based solely on the outside host’s port number.
`While port25 is indeed the normal mail port, there
`is no way we can controlthat on a foreign host. An
`enemycanaccessanyinternal machine andportbyorig-
`Packet-Filtering Gateways
`inating his call fromport 25 on the outside machine.
`A better rule would be to permit outgoing calls
`Pr filters can provide a cheap andusefullevel
`to port 25, i.e., we want to permit our hosts to
`ofgateway security. Used by themselves, they are
`makecalls to someoneelse’s port25, so that we know
`cheap:thefiltering abilities come with the routersoft-
`what’s going on: mail delivery. Anincoming call from
`ware. Since you probably need a router to connect
`port 25 implements someserviceofthe caller's choos-
`to the Internetin thefirst place, there is no extra charge.
`ing. Fortunately, the distinction between incom-
`Evenif the router belongs to yournetworkservice
`ingand outgoing calls can be made ina simple packet
`provider, you will probably find that theywill install
`filter if we expand ournotationa bit.
`anyfilters you wish.
`
`
`52
`
`IEEE Communications Magazine ° September 1994
`
`
`

`

`
`
`
`C
`
`D
`
`port
`_sre
`action
`allow {our hosts} *
`allow
`Os
`25
`
`_dest___—sport
`es
`25
`ahs
`-
`
`flags
`
`ACK
`
`comment
`our packets to their SMTP port
`their replies
`
`:
`
`|
`
`|
`
`E
`
`action _src___port _dest_port
`allow {ourhosts} *
`=,
`*
`allow
`=
`3
`*
`allow
`E
`a
`>1024
`
`B
`
`flags comment
`our outgoing calls
`replies to ourcalls
`traffic to nonservers
`
`ACK _
`
`A TCP conversationconsists of packets flow-
`ing in twodirections [19]. Evenif 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 ofthe control fields. In particular, an initial
`openrequest packet in TCP doesnot havethe set
`in the header; all other TCP packets do. Thus,
`packets with ACKsetare part of an ongoing con-
`versation; packets without it represent connec-
`tion establishment messages, which wewill 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 beeninitiated. 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 destinationfields, rather than the more neb-
`ulous “OURHOST” and “THEIRHOST”:
`The notation “{our hosts}” describes a set of
`machines,any one ofwhichiseligible. Ina real pack-
`etfilter, you could eitherlist the machinesexplicitly,
`or you could specify a group of machines, proba-
`bly by the network numberportion ofthe IP address.
`
`Filtering FTP Sessions
`Someservices are not handled well by packetfilters.
`Weuse 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 secondary con-
`nection. If the control channel to a server on
`THEIRHOSTuses the connection
`
`(ourhost,
`
`ourport,
`
`theirhost,
`
`21),
`
`filtering decisions. Mostservers, and hence most attack
`targets, live on low-numbered ports; most outgoing
`calls tend to use higher numberedports,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 connectioninitiated
`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 bythefirst rule,
`and would not be examined bythe later rules.
`Unfortunately, this ruleset does not accom-
`plish what wereally want, whichis 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 bypassis avail-
`able if you have the source code to the FTPclient
`programs. You can modify the programsto 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 variantis not without its problems. The data
`channel, though an outgoing call, is toa 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 furtherin [3].
`
`Evenif all
`the data
`
`is flowing
`
`one way,
`acknowledg-
`ment packets
`and control
`
`packets must
`flow the
`other way.
`
`
`
`
`
`file transfers will occur on
`
`(ourhost, ourport,
`
`theirhost, 20)
`
`Protocols Without Fixed Addresses
`Some services are problematic for packet filters
`because they can involve random port numbers. On
`oc