‘r
`
`V"
`
`3- '
`
`I
`
`:43):- L:
`
`Securing the
`Information
`Superhighway
`
`Page47
`
`September 1994 Vol. 32 No. 9
`
`ELr}.
`JUJL‘Lp-
`.IIJILM
`‘C
`ELM)
`“LUIJ.
`JU'J)
`('1 <
`(lb-49m
`4&9;
`Huh-I at
`ZJtmnz-r.
`
`084008
`Cisco Systems, Inc. v. Finjan, Inc.
`
`CS-1008
`Cisco Systems, Inc. v. Finjan, Inc.
`Page 47
`
`

`

`IEEE
`
`ammunicatians
`
`SEPT 1994 \[OL 32 No.9
`
`MAGAZINE
`
`Fl THIS lSSUE
`
`provides a sampling of security functions and
`
`technologies designed to protect the
`
`information superhighway.
`
`Cover illustration by Marsha Saldanha.
`
`
`
`
`
`Director of Publications
`Editor-invchlef Emeritus
`Thomas J. Plcvyak. Bell Atlantic
`Editor-in-Chief
`Curtis A. Siller, Jr., AT&T Bell Labs
`Executive Director
`Carol M. Lot, iEEE
`Senior Technical Editors
`Haruo Akimaru, Toyahashi U. (Japan)
`Adam Lender, Lockheed Research Laboratory
`Bahman Mobasser, Alcatel
`Harry Rudin, IBM Zurich Research Laboratory
`Raymond Steele, U. Southampton (UK)
`Technical Editors
`Ranavir Bose. AT&T Bell Labs.
`Michel Diaz, MAS-CNRS, France
`Christos Douligeris. U. of Miami
`M. Robert Dresp. MITRE Corp.
`Boris Elcnkrig, Russian Academy of Sciences
`'Sol Greenspan. GTE Labs
`Roch Guerin. lBM Corp.
`Bruce Kiebunz, KEC
`Anton Kuchar, Czechoslovak Academy of Sciences
`Howard Lemberg. Bellcore
`John Lemp. Jr., U. Colorado
`Torleiv Mascng, Trondheim Tech. U. (Norway)
`Tetsuya Miki, N'IT (Japan)
`Hussein Mouftah, Queens U. (Canada)
`John O'Reiily, U. of N. Wales
`Raymond Pyle, Bell Atlantic
`Ram Rathore, Beiicore
`Tarek N. Saadawi, City College N.Y.
`Hady Salloum, Beilcore
`Rajeev Sinha, Bellcore
`Tetsuji Tanaka. OK] Electric Industry Co.. Ltd.
`A.W.D. Watson. Motorola (UK)
`Patrick E. While. Bellcore
`Feature Editors
`Chung-Shcng Li, IBM Corp.. Book Review:
`Tetsuya Miki, N'IT, Chapters Corner
`David B. Newman, Jr., Law Offices of DB. Newman
`Conttnttnt'catiom and the Law
`Paul Green, IBM Corp, ComntttniCrostt'cs Puzzle
`Vikram Punj, AT&T Bell Labs, Conference Calendar
`8. Pasupathy. U. Toronto, Light Traflic
`Ahmad Aman, AT&T, New: and Events
`Sue McDonald, Belieore. News Front ISAC
`Amane Nakajima. IBM Corp., Japan
`Kuriacose Joseph, David Samoif Res, Ctr.
`G. Sorter, Teclmische U. Munclten
`S. Chia, British Telecom Labs
`Scanning the Literature
`Koichi Asatani, NTI‘
`Moslafa Hashem Sher-if, AT&T Bell Labs
`Standards
`Regional Correspondents
`Victor Perez, Motorola (Mexico)
`Latin American Correspondents
`Janusz Filipiak, U. Mining & Metallurgy (Poland)
`Central & Eartcnt European Correspondent
`Angelo Luvison. CSELT (ituly)
`European Cam'sltttttrlt'nt
`N. Sokoiov, LONIIS (Russia)
`Russian COITcSpUIitlt'ltl
`Botaro Hirosaki NEC Corp. (Japan)
`Asian Commandant
`IEEE Production Staff
`Joseph Milizzo. Managing Editor
`Elizabeth \Vilbcr, Production Editor
`Alan E. Oirich, Layout Editor
`Eric Levine, Advertising Sales Manager
`Joanne O'Rourke, Staff Assistant
`Susan Langc, Publications Assistant
`Erin E. Poole, Publications Assistant
`Operations Editor
`
`Kazem Sohraby, AT&T Bell Labs
`
`33
`
`40
`
`50
`
`58
`
`Securing the Information Superhighway
`
`Kerberos: An Authentication Service for
`
`Computer Networks
`When using authentication based on cryptography, an attack-
`er listening to the network gains no information that would
`enable it to falsely claim another’s identity. Ker‘bcros is the
`most commonly used example of this type of authentication
`technology.
`B. Clifford Neuman and Theodore Ts’o
`
`Access Control: Principles and Practice
`Access control constrains what a user can do directly, 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 breach of security.
`Ravi S. Sandhu and Pierangela Samarati
`
`Network Firewalls
`Computer security is it 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
`
`Key Escrowing Today
`The objective of the US. Government‘s Escrowcd Encryption
`Standard and associated Key Escrow System is to provide
`strong security for communications while simultaneously
`allowing authorized government access to particular commu—
`nications for law enforcement and national security purposes.
`Dorothy E. Denning and Miles Smid
`
`.«.-
`
`
`
`.‘.J».c...’..v4.4..__.’
`
`
`
`ll
`
`70
`
`Toward a National Public Key Infrastructure
`Reliance on electronic communications makes information
`
`more vulnerable. Public key cryptography will play an important
`role in providing confidentiality, message integrity, sender
`authentication, and sender non—repudiation.
`Santosh Chokhani
`
`
`
`48
`
`

`

`
`
`
`
`76
`
`82
`
`90
`
`98
`
`Digital Signatures: Are They Legal for Electronic
`Commerce?
`Digital signature technology promises assurance at least
`equal to written signatures. From a legal standpoint, this
`assurance remains to be tested in the evidentiary process.
`Pa trick W. Brown
`
`Securing’a Global Village and Its Resources
`In an international economy and social infrastructure that
`is growing more dependent everyday on its communications
`networks, more attention must be placed on the security
`and integrity of the components and interfaces of those
`critical structures.
`Henry M. Kluepfel
`
`Topics in Lightwave
`
`,
`
`The Hidden Benefits Of Optical Transparency
`The optical fiber amplifier will bring about network trans-
`parency and reductions in manning levels, interface prob-
`lems. software and operating costs. while improving
`reliability and performance.
`Peter Cochrane, Roger Heckingbottom, and David Heatley
`
`All—Optical Signal Processing in U/trahigh-Speed
`Optical Transmission
`The coming broadband era will require very high-speed
`technologies that can handle more than IOO-Gb/s for both
`transmission lines and transmission nodes. Novel all—optical
`signal processing technologies that offer unsurpassed
`performance are urgently required.
`Masatoshi Saruwatori
`
`D
`
`EPARTMENTS
`
`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. 147
`Book Reviews
`
`Communicrostic Puzzle No. 142
`
`Society News
`Guest Editorial
`Conference Calendar
`Advertisers Index
`New Products
`
`Scanning the Literature
`
`
`
`1994 Communicatlons Society Officers
`Maurizio Decina. l’n'sirlr-nl
`Stephen B. Weinstein, I"P-‘I'rt‘lmit'al.Iflnirs
`Roberto 13. de Marco. Vl’JIllt'ntfllt'nItfll.‘Iflttirj
`(‘elia L. Desmond. Vl’-lllrmber Affairs
`Carol M. Lot. .fi‘ern'lmy
`0. Allan Ledbeltcr. Treasurer
`Paul Green. Purl Preside"!
`Board of Governors
`The officers above plus Members-at-Large:
`Class of 1991
`Allen H. Cherin
`Richard Gitlin
`Ray R. Luane
`Richard P. Skillen
`mom
`Anne Aldridge
`[xturenee I3. Milstein
`Birendra Prasada
`Harry Rudin
`Class of 1996
`Harvey A. Freeman
`Lin-shan Lee
`Joseph L. LoC‘iecro
`Richard K. Snelling
`
`
`
`1994 IEEE Officers
`H. Troy Nagle. Preside"!
`J. Thomas Cain. President—Elect
`Luis T. Gandia, Sacra/my
`V. Thomas Rhyne. Treasurer
`Martha Sloan. Past President
`John H. Powers. General Manager
`John S. Ryan. Director; Division III
`IEEE COMMUNICATIONS MAGAZINE
`(ISSN ”toil—68M) is published monthly by The
`Institute of Electrical and Electronics Engineers,
`Inc. Headquarters address IEEE. 345 East 47th
`Street. Nchork.NY ItXJI 7-394: telephone 212-705-
`7018; e-mail: j.mitizzo(¢;vieee.org. Responsibility
`for the contents rests upon authors ofsigned articles
`and not the IEEE or its members. Unless otherwise
`specified. the IEEE neither endorses nor sanctions
`any positions or actions espoused in IEEE
`Cannmmicalians Magazine.
`ANNUAL SUBSCRIPTION:
`$23 per member per year included in Society fee.
`Non—member subscription: $I35. Single copy $10 [or
`members and $20 for nonmembers.
`EDITORIAL CORRESPONDENCE:
`Address to: Editor. Curtis A. Sillcr. Jr.. AT&T Bell
`Laboratories, Rm 21-31719. 1600 Osgood Street.
`North Andover. MA 01845: e-mail: esiller@mvaas
`.att.com. For departments. please see columns.
`COPYRIGHT AND REPRINT PERMISSIONS:
`Abstracting is permitted with credit to the source.
`Librariesare permitted tophotocopyheyond tlrelim-
`itsot Us. Copyright law for private use ofpatrons:
`those postdWT articles that carry a code on the bottom
`of the first page provided the percopy Ice indicated
`in the code is paid through the Copyright Clearance
`Center. 222 Rosewood Drive. Danvcrs. MAUWD. For
`othercopying. reprint. or republication permission.
`write toDirector. Publishing Services. at IEEE Head-
`quarters. All rights reserved. Copyright 0 1994 byThe
`Institute otElectricaI and Electronics Engineers. Inc.
`POSTMASTER:
`Send address changes to IEEE Communications
`I‘lflgflzfllu' IEEE. 445 Hoes Lane. Piscataway. N]
`“3855433 LUSTRegistrationNo. 125634188. Printed
`in USA, Second-class postage paid at New York.
`NY and at additional mailingotfices. Canadian Post
`International Publications Mail (Canadian
`Distribution) Sales Agreement No. 264075.
`SUBSCRIPTIONS.
`orders. address changes — IEEE. Service Center.
`445 Hoes Lane. Piscataway. NJ 08855-1331; tele—
`phone: 903-981-0060.
`ADVERTISING:
`Advertising is accepted at the discretion of the pub-
`lisher, Address correspondence to:
`IEEE
`Crminnmiculiunr rIItrgazine. 345 East 47th Street.
`New York. NY 10017-2394.
`
`
`
`
`VERA.
`
`
`
`
`
`
`
`49
`
`

`

`
`
`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
`
`
`
`STEVEN M. BELLOVIN
`works at A T&T Bell Labora-
`tories, where he does research
`in networks and security
`
`WILLIAM R. CHESWICK
`serves as an assistant pro-
`grammer trainee and membEr
`of the technical staffat Bell
`Laboratories.
`
`.
`
`lnsi
`
`ITis
`
`Fl
`form
`else is
`
`thing
`ablei
`not H
`the d
`
`Host
`To so
`emal
`at l‘iSlt
`ened.
`
`vice IF
`tool I
`with 1
`attacl
`not be
`Tl
`
`bly ca
`will bt
`admit
`puter
`does
`
`ver
`° On
`sec
`0 The
`Wt
`ure in
`is not
`Th
`ouree
`
`ly, me
`a dett
`tinct z
`Fir
`than t
`for th
`mach
`
`rity bi
`work
`not at
`unknt
`vant t(
`A:
`admit
`notcl:
`
`
`
`
`
`
`..__...4_._.-a.-—._._._-—_____.__._--_..—._.__.a-__.__.._.
`
`IEEE
`
`me that it’s broken.” People at the other end say, “show
`me that it’s both safe and necessary; otherwise, we
`won’t run it.” Those who are completely offthe 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 is simple: there are no 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
`a network is 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
`providing most —but not necessarily all— ofthe 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
`
` omputer security is a hard problem.
`
`tor of a single host can—with a great
`deal ofcare and attention to details,
`luck in the choice of vendor soft-
`
`Security on networked computers
`is much harder. The administra-
`
`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 login 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. Yourcomputers may be secure,
`but you may have users who connect from other
`machines that are less secure. This connection — even
`
`ifduly authorized and immune to direct 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 a fire-
`wall: a barrier that restricts the free flow ofdata between
`
`the inside and the outside. Used properly, a firewall
`can provide a significant increase in computer security.
`
`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 general computing services
`to a general user population. It need not run networked
`file systems, distributed user name databases, etc. The
`very act of eliminating such programs automatical-
`ly makes a firewall more secure than the average host.
`Much of this article was
`We also feel that any program, no matter how
`taken from “Firewalls and
`innocuous it seems, can harbor security holes. (Who
`Internet Security: Repelling
`would have guessed that on some machines, integer
`the Wiley Hacker" by
`divide exceptions could lead to system penetrations?)
`Akey decision when developing a security policy is the
`William R. Cheswick and
`stance of the firewall design. The stance is the attitude
`We thus have a firm belief that everything is guilty
`Steven M. Bellovin,
`of the designers. It is determined by the cost of fail-
`until proven innocent. Consequently, we configui‘e
`Addison Wesley Publishing
`our firewalls to reject everything, unless we have expllC‘
`ure of the firewall and the designers’ estimate of that
`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, © 1 994 A T& T
`permit it. Taking the opposite tack, of blocking only
`of their own abilities. At one end of the scale is a phi-
`Bell Laboratories.
`known offenders, strikes us as extremely dangerous-
`losophy that says, “we’ll run it unless you can show
`
`Stance
`
`50
`
`IEEE Communications Magazine ° September 1994
`
`
`

`

`
`
`Filter
`
`Filter
`
`Inside'—.¥Outside
`
`
`
`I Figure 1. Schematic ofa firewall. ,
`
`Furthermore, whether or not a security policy is
`formally SpellCd out, one always exists. If nothing
`else is said or implemented, the default policy is “any-
`thing goes.” Needless tosay, 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 vely 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-
`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 your battlements; ifan attacker finds one weak—
`ness — say, a postern gate, to extend our metaphor
`—your system will be penetrated. And if one machine
`falls, its neighbors are likely to follow.
`
`types of Firewalls
`
`i
`
`lsay,“show
`erwise, we
`ffthescale
`ather than '
`treme, but T.)
`risk losing
`.
`nnection?
`mostsites.
`tlutes. One
`atchimera
`avorks and
`meet from
`ges.When
`ay be the
`iybe made
`;.
`)r reasons
`
`.
`
`-
`
`I
`
`‘
`
`.
`
`I
`
`ewalls are
`1ger,while
`)ftheben-
`tparanoid .,
`setting up , I
`
`.
`
`that most
`
`i.
`
`system is I
`
`I
`
`_
`"1
`
`.
`sany sort
`:risk that l
`rity holes.
`:5
`programs
`eas small
`this. It is
`gservices
`tetworked
`s,etc.The
`omatical— .
`ragehost.
`.-
`itter how
`3?
`les. (Who ,
`:s,integeru :‘
`:rations?)
`j
`sis guilty
`I
`:onfigurc
`‘
`tveexplic- ,‘ i
`risk—t0 v
`'
`king only i
`tngerous. If
`
`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 example would 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, 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 machine can, ifthe user wishes (and decides
`against usinghand-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.
`Gateway machines have other, nonsecurity advan—
`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 . domainfomiat), 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
`
`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.
`
`W e define a firewall as a collection ofcomponents
`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-
`‘ All traffic from inside to outside, and vice-
`istrators and operators never made any mistakes, the
`versa, must pass through the firewall.
`Internet is not the only source of danger. Apart from
`the risk ofinsider attacks and in some environments,
`° Only authorized traffic, as defined by the local
`security policy, will be allowed to pass.
`that is a serious risk —— an outsider can gain access
`by other means. In at least one case, a hacker
`° The firewall itself is immune to penetration.
`We should note that these are design goals; a fail-
`came in through a modem pool, and attacked the
`ure in one aspect does not mean that the collection
`firewall from the inside [7]. Strong host security poli—
`is not a firewall, simply that it is not a very good one.
`cies are a necessity, not a luxury. For that matter,
`That firewalls are desirable follows directly from
`internal firewalls are a good idea, to protectveiy sen—
`our earlier statements. Many hosts — and more like-
`sitive portions of organizational networks.
`A firewall, in general, consists of several different
`ly, most hosts — cannot protect themselves against
`a determined attack. Firewalls have several dis—
`components (Fig. l). The “filters” (sometimes called
`tinct advantages.
`“screens”) block transmission ofcertain classes of traf-
`First, ofcourse, a firewall is likely to be more secure
`fic. A gateway is a machine or a set of machines that
`than an average host. The biggest single reason
`provides relay services to compensate for the effects
`for that is simply that it is not a general-purpose
`of the 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 DMZ is sometimes assisted 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 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 gateway itself, may be omit-
`ted; the details will vary from firewall to firewall. In
`A second benefit comes from having professional
`administration of the firewall machines. We do
`general, the outside filter can be used to protect the
`gateway from attack, while the inside filter is used
`not claim that firewall administrators are necessarily
`
`
`nber 1994'
`
`IEEE Communications Magazine ' September 1994
`
`51
`
`
`
`
`
`

`

`ff
`
`
`
`
`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 the consequences ofa 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 of these is used at the
`same time. As noted earlier, mail is often routed through
`a gateway even when no security firewall is used.
`Otirexaniples and discussion unabashedly relate
`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 fewerof them on thelnternet, 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 of choice — not
`only on workstations, forwhich it is the native tongue
`— but on virtually all machines, ranging from desktop
`personal computers to the largest supercomputers.
`Many internal corporate networks are based on TCP/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
`theworld),researchlabs,manygovernmentagencies,
`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 large companies, most employees are
`not (or should not be) privy to all information. In
`other companies, the cash business (like the fact01y, 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.
`
`
`
`.5,
`
`file
`
`Packet filters work by dropping packets based on
`theirsource or destination addresses or selvice (i.e.,
`port number). In general, no context is kept; decisions
`are made only from the contents'ofthe current pack~
`et. Depending on the type of router, filtering may be
`done at input time, at output time, or both.’lhe admin—
`istrator makes a list of the acceptable machines and
`selvices and a stoplist of unacceptable machines 0r
`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 I? 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-
`tering allows 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 compromises can be dangerous.
`We discuss these in a section to follow.
`Configuring a packet filter is a three-step process.
`First, ofcourse, one must know what 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
`yoursecurity policy was 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.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
`policy“any inside host can 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
`enemy can access any internal machine and port byorig-
`Packet-Filtering Gateways
`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.e., 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-
`what’s going on: mail delivery. An incoming call from
`ware. Since you probably need a router to connect
`port 25 implements some service ofthe caller’s choos-
`to the Internet in the first place, there is no extra charge.
`ing. Fortunately, the distinction between incom-
`Even if the router belongs to your network service
`ing and outgoing calls can be made in a simple packet
`provider, you will probably find that they will install
`filter if we expand our notation a bit.
`any filters you wish.
`
`
`52
`
`IEEE Communications Magazine ' September 1994 >
`
`
`IE1
`
`

`

`A TCP
`
`conversation
`
`consists of
`
`packets
`
`flowing in
`
`two directions.
`
`Even ifall
`
`the data
`
`is flowing
`
`one way,
`
`acknowledg-
`
`ment packets
`
`and control
`
`packets mast
`
`flow the
`
`other way.
`
`
`
`
`
`
`action
`ourhost
`port
`theirhost
`port
`comment
`
`A
`
`*
`block
`allow OUR-GW
`
`*
`25
`
`SPIGOT
`*
`
`*
`*
`
`we don't trust these people
`connection to our SMTP port
`
`
`action
`ourhost
`port
`theirhost
`port
`comment
`block
`* I
`*
`*
`*
`default
`
`;
`[
`
` w
`
`port
`:-
`
`themhost 1” port
`.*_.
`-,25
`I
`
`comment ,
`connection to their SMTP port
`
`ourhost
`
`action
`allow
`
`port ,
`'src
`action
`allow '{our hosts} “*
`allow
`*'
`'
`25
`
`dest
`*.
`i
`. *
`
`'port
`' 25
`*
`
`flags
`
`ACK
`
`Comment
`our packets to their SMTP port
`their replies
`
`.
`
`B
`
`C
`
`D
`
`;
`
`
`
`E
`
`
`
`
`
`.
`
`ACK ,
`
`as s
`'V o‘ri:
`asst:
`'7 Jon
`’
`sic-
`,
`action
` iLCém'mertt ‘ 7 ,
`
`
`
`*
`. *_ _ ._.*
`allow {cirrhosis}
`our outgoing calls
`*
`.*
`*
`allow
`*
`replies to our calls
`traffic to nonservers
`* <
`*
`>1024
`allow
`*
`
`
`3
`
`
`
`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—
`bly bythe network numberportion ofthe IP 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 secondary con-
`nection. If the control channel to a server on
`THEIRHOST uses the connection
`
`(ourhost, ourport,
`
`theirhost, 21),
`
`file transfers will occur on
`
`(ourhost, ourport,
`
`theirhost, 20)
`
`filtering decisions Most servers, and hence most attack
`targets, live on low-numbered ports; most outgoing
`calls tend to use highernumbered 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.
`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 by the first rule,
`and would not be examined by the later rules.
`Unfortu