United States Patent
`Wesinger, Jr. et al.
`
`[19]
`
`[54] FIREWALL PROVIDING ENHANCED
`NETWORK SECURITY AND USER
`TRANSPARENCY
`
`[75] Inventors: Ralph E. Wesinger, Jr., San Jose;
`Christopher D. Coley, Morgan Hill,
`both of Calif.
`
`[73] Assignee: Network Engineering Software, San
`Jose, Calif.
`
`[21] Appl. No.: 08/733,361
`[22]
`Filed:
`Oct. 17, 1996
`
`[51] Int. Cl.6 ...................................................... .. G06F 1/00
`[52] US. Cl. .............................. .. 395/187.01; 395/200.55;
`395/200.57
`[58] Field of Search ............................. .. 395/186, 187.01,
`395/188.01, 200.3, 200.55, 200.68, 200.57;
`380/3, 4, 21, 23, 25; 340/8253
`
`[56]
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`4,713,753 12/1987 Boebert et al. ....................... .. 364/200
`
`4,799,153
`4,799,156
`
`1/1989 Hann et al. . . . . . . .
`1/1989 Shavit 61 al. ..
`
`. . . .. 380/25
`364/401
`
`5,191,611
`
`3/1993 Lang . . . . . . . . .
`
`. . . . .. 380/25
`
`5,241,594
`5,416,842
`
`380/4
`8/1993 Kung ..
`5/1995 AZIZ ........................................ .. 380/30
`
`(List continued on next page.)
`
`OTHER PUBLICATIONS
`
`Kiuchi et al., “C—HTTP The Development of a Secure,
`Closed HTTP Based Network on the Internet”, PRoceedings
`of SNDSS, IEEE, pp. 64—75, Jun. 1996.
`Neuman, “Proxy Based Authorization and Accounting for
`Distributed Systems”, IEEE, pp. 283—291, 1993.
`Network Firewalls; IEEE Communications Magazine; (Ball
`ovin et al.) pp. 50—57; Sep., 1994.
`The MITRE Security Perimeter; IEEE Communications
`Magazine; (Goldberg); pp. 212—218; 1994.
`
`US005898830A
`Patent Number:
`Date of Patent:
`
`[11]
`[45]
`
`5,898,830
`Apr. 27, 1999
`
`IpAccess—An Internet Service Access System for Firewall
`Installations; IEEE Communications Magazine; (Stempel);
`pp. 31—41; 1995.
`Remote Control of Diverse Network Elements Using
`SNMP; IEEE Communications Magazine; (Aicklen et al.);
`pp. 673—667; 1995.
`Firewall’s Information is Money!, Scienti?c Management
`Corporation.
`Primary Examiner—Joseph Palys
`Attorney, Agent, or Firm—McDonnell Boehnen Hulbert &
`Berghoff
`[57]
`
`ABSTRACT
`
`The present invention, generally speaking, provides a ?re
`wall that achieves maximum network security and maxi
`mum user convenience. The ?rewall employs “envoys” that
`exhibit the security robustness of prior-art proxies and the
`transparency and ease-of-use of prior-art packet ?lters, com
`bining the best of both worlds. No traffic can pass through
`the ?rewall unless the ?rewall has established an envoy for
`that traffic. Both connection-oriented (e.g., TCP) and con
`nectionless (e.g., UDP-based) services may be handled
`using envoys. Establishment of an envoy may be subjected
`to a myriad of tests to “qualify” the user, the requested
`communication, or both. Therefore, a high level of security
`may be achieved. The usual added burden of prior-art proxy
`systems is avoided in such a way as to achieve fall
`transparency-the user can use standard applications and need
`not even know of the existence of the ?rewall. To achieve
`full transparency, the ?rewall is con?gured as two or more
`sets of virtual hosts. The ?rewall is, therefore, “multi
`horned,” each home being independently con?gurable. One
`set of hosts responds to addresses on a ?rst network interface
`of the ?rewall. Another set of hosts responds to addresses on
`a second network interface of the ?rewall. In one aspect,
`programmable transparency is achieved by establishing
`DNS mappings between remote hosts to be accessed through
`one of the network interfaces and respective virtual hosts on
`that interface. In another aspect, automatic transparency may
`be achieved using code for dynamically mapping remote
`hosts to virtual hosts in accordance with a technique referred
`to herein as dynamic DNS, or DDNS.
`
`21 Claims, 9 Drawing Sheets
`
`, FIREWALL I
`
`'151
`
`54
`
`107"
`
`FIREWALL
`DNS/DUNS
`
`118
`
`5.4
`
`109
`
`no
`
`7 l6
`
`FIREIVAIJ/
`
`ADDRESS SUBSET:
`
`EU. 192,168.3(X
`
`:
`
`9
`
`166
`
`\"IRIUA l , HOS'I
`MACHINE
`
`/ .
`
`ADDRESSES
`
`@LI
`7‘
`III.
`
`115
`
`4G ' SUBSET
`
`153
`
`151
`
`Petitioner Apple Inc. - Ex. 1044, p. 1
`
`

`
`5,898,830
`Page 2
`
`US. PATENT DOCUMENTS
`
`1/1996 Yoshida etal- ------------------ -- 395/187-01
`5,483,661
`2/1996 Kaufnman etal- --------------------- -- 380/30
`5,491,752
`2/1996 Linehan et a1.
`380/21
`5,495,533
`8/1996 Denslow
`395/187.01
`5,548,721
`8/1996 Gelb ......... ..
`395/187.01
`5,550,984
`5,577,209 11/1996 Boyle et a1. ........ ..
`395/200.06
`5,590,199 12/1996 Krajewski, Jr. et a1.
`380/25
`
`2/1997 Chen et a1. ............................. .. 380/21
`5,602,918
`2/1997 Shwed .... ..
`395/200.11
`5,606,668
`4/1997 Vu .................................... .. 395/187.01
`5,623,601
`5/1997 Land?eld et a1. .................... .. 395/326
`5,632,011
`6/1997 Yu .......... ..
`. 395/500
`5,636,371
`6/1997 Nguyen
`380/29
`5,638,448
`8/1997 Kralowetz
`95/20057
`5,657,452
`9/1997 Falk et a1.
`.... .. 380/25
`5,668,876
`5,687,235 11/1997 Periman et a1.
`.. 380/25
`
`Petitioner Apple Inc. - Ex. 1044, p. 2
`
`

`
`U.S. Patent
`
`Apr. 27, 1999
`
`Sheet 1 0f 9
`
`5,898,830
`
`CORP.
`
`INTERNET
`
`/
`
`g 3-2 _’ FIREWALL
`
`- w 192.168.X.X§
`
`._ ............................
`
`DNS/DDNS
`
`// //
`
`168
`
`167
`FIREWALL
`DNS/DDNS \\107 "
`
`160
`
`-
`
`-
`
`’
`/
`/ 5.4
`118
`
`109
`
`.
`
`-
`
`\117
`
`155 ’
`\ ’
`;-.__165\ FIREWALL
`/110
`DNS/DDNS
`ADDRESS SUBSET,§ "-._
`I
`
`E.G.192.168.X.X "
`
`101
`/ i
`
`\166
`1_
`i
`'1 152/
`=
`4G-SUBSET ;
`ADDRESSES?
`
`i
`; VIRTUAL HOST
`MACHINE
`
`FIREWALL
`
`1 l6
`\ DNSHDDNS
`\\
`
`105B
`/
`
`105
`/
`
`\115
`
`_
`
`/
`
`'
`
`'
`
`'
`
`<—105A g
`
`4G-SUBSET
`
`102
`
`./1O3
`119
`
`ACCT.
`
`'
`
`;
`5
`
`153
`
`151
`
`Petitioner Apple Inc. - Ex. 1044, p. 3
`
`

`
`U.S. Patent
`
`Apr. 27, 1999
`
`Sheet 2 0f 9
`
`5,898,830
`
`INTERNET
`
`FIREWALL
`
`DNS/DDNS
`
`220
`
`/207
`/217
`
`209
`
`FIG. 2
`
`Petitioner Apple Inc. - Ex. 1044, p. 4
`
`

`
`U.S. Patent
`
`Apr. 27, 1999
`
`Sheet 3 0f 9
`
`5,898,830
`
`mom l
`
`<mom
`
`ZOEW<Q AA
`ZOCLEDUEZOU
`
`mwim
`
`am
`
`Em
`
`ZQ
`
`m .UE
`
`rllltm
`
`2m
`
`\
`
`D
`
`
`
`
`
`mmOmMDm - Q<~Ummm
`
`Petitioner Apple Inc. - Ex. 1044, p. 5
`
`

`
`U.S. Patent
`
`Apr. 27, 1999
`
`Sheet 4 0f 9
`
`5,898,830
`
`INTERNET
`
`420
`
`FIREWALL
`
`FIREWALL
`
`DNS/DDNS — 407
`
`DNS/DDNS _ 408
`
`FIG. 4
`
`Petitioner Apple Inc. - Ex. 1044, p. 6
`
`

`
`U.S. Patent
`
`Apr. 27, 1999
`
`Sheet 5 of 9
`
`5,898,830
`
`mmemfiz
`
`OEZOO
`
`u5<>>mME
`
`
`
` 04 EHEEmZHEO<§A<UHm>En,_
`
`u_<Dr§:>
`
`~50:
`
`q<DHyd>
`
`N50:
`
`A<DHM:>
`
`ZHmOE
`
`Petitioner Apple Inc. - Ex. 1044, p. 7
`
`Petitioner Apple Inc. - Ex. 1044, p. 7
`
`

`
`U.S. Patent
`
`Apr. 27, 1999
`
`Sheet 6 0f 9
`
`5,898,830
`
`REQUEST
`
`l / VH1
`
`DAEMON
`
`610
`
`MASTER
`CONFIG
`
`"1111;, EXECUTION THREADS
`
`.. .
`
`/VHN
`PROCESS
`——> OUTPUT
`THIS
`CONNECTION
`
`FIG. 6
`
`Petitioner Apple Inc. - Ex. 1044, p. 8
`
`

`
`U.S. Patent
`
`Apr. 27, 1999
`
`Sheet 7 0f 9
`
`5,898,830
`
`PORT
`RULEl
`
`:80
`={
`TIME
`
`}
`WWWsRMOcOM
`.CGI
`ROOT
`
`}
`WWW.HONOLULU.NET ={
`:“’7
`
`: “1AM-12PM”
`
`={
`: “PROCESSCGI”
`= “/HOME/SRMC/HTML”
`
`ROOT
`
`}
`WWW.SANJOSE.NET
`.CGI
`ALLOW
`
`}
`DENY
`
`= “fHOME/HONOLULU/HTML”
`
`=
`= “PROCESSCGI”
`:{
`*.sRMc.cOM
`205.138.192.*
`205.138.192.0/23
`
`={
`MISTERPAINCOM
`
`}
`}
`WWPROXYSRMCCOM :{
`MODE
`= RT_SERVERPROXY
`
`}
`NS.SRMC.COM
`ALLOW
`
`}
`}
`MJLIsRMOcOM
`ALLOW
`
`}
`DENY
`
`={
`={
`192.168.0.*
`192.168.1.* =RULE1
`192.168.2.* ={
`TIME
`
`}
`192.168.3.*
`
`=192.168.2.*
`
`: “1AM-12PM”
`
`192.168.0.0/23
`
`= RULEl
`
`= {
`192.168.0.* = {
`TIME
`
`= “12PM-1AM”
`
`FIG. 7
`
`Petitioner Apple Inc. - Ex. 1044, p. 9
`
`

`
`U.S. Patent
`
`Apr. 27, 1999
`
`Sheet 8 0f 9
`
`5,898,830
`
`MAIN DAEMON / 801
`COMMANDLINE
`PROCESSING
`READ CONFIG 4
`
`61 (k
`MASTER
`CONFIG
`
`WAIT FOR CONNECTION
`REQUEST
`
`VIRTUAL HOST
`810
`/
`
`V
`GET LOCAL
`HOST INFO
`
`v / 803
`MULTI-HOMING
`(WHICH HOST?)
`
`v / s05
`
`
`
`INET “WRAPPER”
`
`GET REMOTE
`HOST INFO
`
`li /818
`CONTENT
`(PROTOCOL BASED)
`PROCESSING
`A
`+___|
`(CLOSE)
`FIG. 8
`
`/820
`CHANNEL
`PROCESSING
`
`v
`
`Petitioner Apple Inc. - Ex. 1044, p. 10
`
`

`
`U.S. Patent
`
`Apr. 27, 1999
`
`Sheet 9 0f 9
`
`5,898,830
`
`QAAQK/EE
`
`HmZMmCLZH
`
`HWZEHZH
`
`@ .UE
`
`Petitioner Apple Inc. - Ex. 1044, p. 11
`
`

`
`1
`FIREWALL PROVIDING ENHANCED
`NETWORK SECURITY AND USER
`TRANSPARENCY
`
`BACKGROUND OF THE INVENTION
`
`1. Field of the Invention
`The present invention relates to computer network secu
`rity and more particularly to ?rewalls, i.e., a combination of
`computer hardware and software that selectively allows
`“acceptable” computer transmissions to pass through it and
`disallows other non-acceptable computer transmissions.
`2. State of the Art
`In the space of just a few years, the Internet—because it
`provides access to information, and the ability to publish
`information, in revolutionary ways—has emerged from rela
`tive obscurity to international prominence. Whereas in gen
`eral an internet is a network of networks, the Internet is a
`global collection of interconnected local, mid-level, and
`wide-area networks that use the Internet Protocol (IP) as the
`network layer protocol. Whereas the Internet embraces
`many local- and wide-area networks, a given local- or
`wide-area network may or may not form part of the Internet.
`For purposes of the present speci?cation, a “wide-area
`network”
`is a network that links at least two LANs
`over a wide geographical area via one or more dedicated
`connections. The public switched telephone network is an
`example of a wide-area network. A “local-area network”
`(LAN) is a network that takes advantage of the proximity of
`computers to typically offer relatively ef?cient, higher speed
`communications than wide-area networks.
`In addition, a network may use the same underlying
`technologies as the Internet. Such a network is referred to
`herein as an “Intranet,” an internal network based on Internet
`standards. Because the Internet has become the most per
`vasive and successful open networking standard, basing
`internal networks on the same standard is very attractive
`economically. Corporate Intranets have become a strong
`driving force in the marketplace of network products and
`services.
`The present invention is directed primarily toward the
`connection of an Intranet to the Internet and the connection
`of intranets to other intranets, and any network connection
`where security is an issue.
`As the Internet and its underlying technologies have
`become increasingly familiar, attention has become focused
`on Internet security and computer network security in gen
`eral. With unprecedented access to information has also
`come unprecedented opportunities to gain unauthoriZed
`access to data, change data, destroy data, make unauthoriZed
`use of computer resources, interfere with the intended use of
`computer resources, etc. As experience has shown, the
`frontier of cyberspace has its share of scof?aws, resulting in
`increased efforts to protect the data, resources, and reputa
`tions of those embracing intranets and the Internet.
`Firewalls are intended to shield data and resources from
`the potential ravages of computer network intruders. In
`essence, a ?rewall functions as a mechanism which monitors
`and controls the How of data between two networks. All
`communications, e.g., data packets, which ?ow between the
`networks in either direction must pass through the ?rewall;
`otherwise, security is circumvented. The ?rewall selectively
`permits the communications to pass from one network to the
`other, to provide bidirectional security.
`Ideally, a ?rewall would be able to prevent any and all
`security breaches and attacks. Although absolute security is
`
`10
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`5,898,830
`
`2
`indeed a goal to be sought after, due to many variables (e.g.,
`physical intrusion into the physical plant) it may be difficult
`to achieve. However, in many instances, it is of equal if not
`greater importance to be alerted to an attack so that measures
`may be taken to thwart the attack or render it harmless, and
`to avoid future attacks of the same kind. Hence a ?rewall, in
`addition to security, should provide timely information that
`enables attacks to be detected.
`Firewalls have typically relied on some combination of
`two techniques affording network protection: packet ?lter
`ing and proxy services.
`Packet ?ltering is the action a ?rewall takes to selectively
`control the How of data to and from a network. Packet ?lters
`allow or block packets, usually while routing them from one
`network to another (often from the Internet to an internal
`network, and vice versa). To accomplish packet ?ltering, a
`network administrator establishes a set of rules that specify
`what types of packets (e.g., those to or from a particular IP
`address or port) are to be allowed to pass and what types are
`to be blocked. Packet ?ltering may occur in a router, in a
`bridge, or on an individual host computer.
`Packet ?lters are typically con?gured in a “default permit
`stance”; i.e., that which is not expressly prohibited is per
`mitted. In order for a packet ?lter to prohibit potentially
`harmful traf?c, it must know what the constituent packets of
`that traffic look like. However, it is virtually impossible to
`catalogue all the various types of potentially harmful packets
`and to distinguish them from benign packet traffic. The
`?ltering function required to do so is too complex. Hence,
`while most packet ?lters may be effective in dealing with the
`most common types of network security threats, this meth
`odology presents many chinks that an experienced hacker
`may exploit. The level of security afforded by packet
`?ltering, therefore, leaves much to be desired.
`Recently, a further network security technique termed
`“stateful inspection” has emerged. Stateful inspection per
`forms packet ?ltering not on the basis of a single packet, but
`on the basis of some historical window of packets on the
`same port. Although stateful inspection may enhance the
`level of security achievable using packet ?ltering, it is as yet
`relatively unproven. Furthermore, although an historical
`window of packets may enable the ?lter to more accurately
`identify harmful packets, the ?lter must still know what it is
`looking for. Building a ?lter with suf?cient intelligence to
`deal with the almost in?nite variety of possible packets and
`packet sequences is liable to prove an exceedingly difficult
`task.
`The other principal methodology used in present-day
`?rewalls is proxies. In order to describe prior-art proxy
`based ?rewalls, some further de?nitions are required. A
`“node” is an entity that participates in network communi
`cations. A subnetwork is a portion of a network, or a
`physically independent network, that may share network
`addresses with other portions of the network. An interme
`diate system is a node that is connected to more than one
`subnetwork and that has the role of forwarding data from
`one subnetwork to the other (i.e., a “router”).
`Aproxy is a program, running on an intermediate system,
`that deals with servers (e.g., Web servers, FTP servers, etc.)
`on behalf of clients. Clients, e.g. computer applications
`which are attempting to communicate with a network that is
`protected by a ?rewall, send requests for connections to
`proxy-based intermediate systems. Proxy-based intermedi
`ate systems relay approved client requests to target servers
`and relay answers back to clients.
`Proxies require either custom software (i.e., proxy-aware
`applications) or custom user procedures in order to establish
`
`Petitioner Apple Inc. - Ex. 1044, p. 12
`
`

`
`3
`a connection. Using custom software for proxying presents
`several problems. Appropriate custom client software is
`often available only for certain platforms, and the softWare
`available for a particular platform may not be the softWare
`that users prefer. Furthermore, using custom client softWare,
`users must perform extra manual con?guration to direct the
`softWare to contact the proxy on the intermediate system.
`With the custom procedure approach, the user tells the client
`to connect to the proxy and then tells the proxy Which host
`to connect to. Typically, the user Will ?rst enter the name of
`a ?reWall that the user Wishes to connect through. The
`?reWall Will then prompt the user for the name of the remote
`host the user Wishes to connect to. Although this procedure
`is relatively simple in the case of a connection that traverses
`only a single ?reWall, as netWork systems groW in
`complexity, a connection may traverse several ?reWalls.
`Establishing a proxied connection in such a situation starts
`to become a confusing maZe, and a signi?cant burden to the
`user, since the user must knoW the route the connection is to
`take.
`Furthermore, since proxies must typically prompt the user
`or the client softWare for a destination using a speci?c
`protocol, they are protocol-speci?c. Separate proxies are
`therefore required for each protocol that is to be used.
`Another problematic aspect of conventional ?reWall
`arrangements, from a security perspective, is the common
`practice of combining a ?reWall With other packages on the
`same computing system. The ?reWall package itself may be
`a combination of applications. For example, one Well-knoWn
`?reWall is a combination Web server and ?reWall. In other
`cases, unrelated services may be hosted on the same com
`puting platform used for the ?reWall. Such services may
`include e-mail, Web servers, databases, etc. The provision of
`applications in addition to the ?reWall on a computing
`system provides a path through Which a hacker can poten
`tially get around the security provided by the ?reWall.
`Combining other applications on the same machine as a
`?reWall also has the result of alloWing a greater number of
`users access to the machine. The likelihood then increases
`that a user Will, deliberately or inadvertently, cause a secu
`rity breach.
`There remains a need for a ?reWall that achieves both
`maximum security and maximum user convenience, such
`that the steps required to establish a connection are trans
`parent to the user. The present invention addresses this need.
`
`SUMMARY OF THE INVENTION
`The present invention, generally speaking, provides a
`?reWall that achieves maximum netWork security and maxi
`mum user convenience. The ?reWall employs “envoys” that
`exhibit the security robustness of prior-art proxies and the
`transparency and ease-of-use of prior-art packet ?lters, com
`bining the best of both Worlds. No traf?c can pass through
`the ?reWall unless the ?reWall has established an envoy for
`that traf?c. Both connection-oriented (e.g., TCP) and con
`nectionless (e.g., UDP-based) services may be handled
`using envoys. Establishment of an envoy may be subjected
`to a myriad of tests to “qualify” the user, the requested
`communication, or both. Therefore, a high level of security
`may be achieved.
`Security may be further enhanced using out-of-band
`authentication. In this approach, a communication channel,
`or medium, other than the one over Which the netWork
`communication is to take place, is used to transmit or convey
`an access key. The key may be transmitted from a remote
`location (e.g, using a pager or other transmission device) or
`
`10
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`5,898,830
`
`4
`may be conveyed locally using a hardWare token, for
`example. To gain access, a hacker must have access to a
`device (e.g., a pager, a token etc.) used to receive the
`out-of-band information. Pager beep-back or similar authen
`tication techniques may be especially advantageous in that,
`if a hacker attempts unauthoriZed access to a machine While
`the authoriZed user is n possession of the device, the user
`Will be alerted by the device unexpectedly receiving the
`access key. The key is unique to each transmission, such that
`even if a hacker is able to obtain it, it cannot be used at other
`times or places or With respect to any other connection.
`Using envoys, the added burden associated With prior-art
`proxy systems is avoided so as to achieve full transparency
`the user can use standard applications and need not even
`knoW of the existence of the ?reWall. To achieve full
`transparency, the ?reWall is con?gured as tWo sets of virtual
`hosts. The ?reWall is, therefore, “multi-homed,” each home
`being independently con?gurable. One set of hosts responds
`to addresses on a ?rst netWork interface of the ?reWall.
`Another set of hosts responds to addresses on a second
`netWork interface of the ?reWall. In accordance With one
`aspect of the invention, programmable transparency is
`achieved by establishing DNS mappings betWeen remote
`hosts to be accessed through one of the netWork interfaces
`and respective virtual hosts on that interface. In accordance
`With another aspect of the invention, automatic transparency
`may be achieved using code for dynamically mapping
`remote hosts to virtual hosts in accordance With a technique
`referred to herein as dynamic DNS, or DDNS.
`The ?reWall may have more than tWo netWork interfaces,
`each With its oWn set of virtual hosts. Multiple ?reWalls may
`be used to isolate multiple netWork layers. The full trans
`parency attribute of a single ?reWall system remains
`unchanged in a multi-layered system: a user may, if
`authoriZed, access a remote host multiple netWork layers
`removed, Without knoWing of the existence of any of the
`multiple ?reWalls in the system.
`Furthermore, the ?reWalls may be con?gured to also
`transparently perform any of various kinds of channel
`processing, including various types of encryption and
`decryption, compression and decompression, etc. In this
`Way, virtual private netWorks may be established Whereby
`tWo remote machines communicate securely, regardless of
`the degree of proximity or separation, in the same manner as
`if the machines Were on the same local area netWork.
`The problem of Internet address scarcity may also be
`addressed using multi-layer netWork systems of the type
`described. Whereas addresses on both sides of a single
`?reWall must be unique in order to avoid routing errors,
`netWork segments separated by multiple ?reWalls may reuse
`the same addresses.
`
`BRIEF DESCRIPTION OF THE DRAWING
`
`The present invention may be further understood from the
`folloWing description in conjunction With the appended
`draWing. In the draWing:
`FIG. 1 is a block diagram of a multi-layered computer
`enterprise netWork in Which the present invention may be
`used;
`FIG. 2 is a block diagram of a netWork similar to the
`netWork of FIG. 1 but in Which a tWo-sided ?reWall has been
`replaced by a three-sided ?reWall;
`FIG. 3 is a block diagram shoWing in greater detail a
`special-purpose virtual host used for con?guration of a
`?reWall;
`
`Petitioner Apple Inc. - Ex. 1044, p. 13
`
`

`
`5,898,830
`
`5
`FIG. 4 is a block diagram of a load-sharing ?rewall;
`
`FIG. 5 is a block diagram of one embodiment of the
`?rewall of the present invention;
`
`6
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENTS
`
`FIG. 6 is a block diagram illustrating the manner in which
`the present ?rewall handles connection requests;
`
`The following terms are used in the present speci?cation
`in accordance with the following de?nitions:
`
`Concept/Feature
`
`Multi-homing
`
`Programmable transparency
`
`Envoy
`
`Multi-layering
`
`Con?gurator
`
`N-dimensional ?rewall
`
`Out-of-band authentication
`
`Channel processing
`
`virtual private network
`
`DDNS
`
`Load sharing
`
`Address reuse
`
`Programmable
`transparency—connectionless protocols
`
`De?nition
`
`Multiple virtual hosts running on a
`single physical machine, using multiple
`network addresses on a single network
`interface. A virtual host assumes the
`identity of one of multipe,
`independently-con?gurable “homes” to
`handle a particular connection at a
`particular time.
`The ability to establish a connection
`through a ?rewall without requiring
`that the user be aware of the ?rewall.
`An intervening program that functions
`as a transparent applications gateway.
`The use of programmable transparency
`to achieve end-to-end connection
`across an arbitrary number of networks
`that are connected by multiple multi
`homing ?rewalls.
`Code that provides a Web-like
`interface, accessible remotely through
`a secure port, for con?guring a
`?rewall.
`A ?rewall having N network interfaces
`and con?gured to provide multiple
`virtual hosts for each interface.
`In deciding whether to allow or
`disallow a connection by a user, the
`use of information communicated to
`the user through means other than the
`desired connection.
`Processing performed on data flowing
`through a communications channel to
`enhance some attribute of the data,
`such as security, reproduction quality,
`content, etc.
`An internet in which envoys
`(intervening programs) are used to
`perform encrypted communications
`from one secure network to another
`through a none-secure network.
`The dynamic assignment of network
`addresses to virtual hosts on a time
`limited basis.
`The use of DDNS to assign a network
`address for a particular connection to a
`virtual host on one of multiple
`machines based on the load of the
`machines.
`The use of the same network address
`within different networks separated by
`?rewalls.
`The use of envoys for connectionless
`(e.g., UDP) communications in which a
`time-out value is used to achieve the
`equivalent of a connection.
`
`FIG. 7 is an eXample of a portion of the master con?gu
`ration ?le of FIG. 5;
`
`FIG. 8 is a block diagram illustrating in greater detail the
`structure of the present ?rewall; and
`
`FIG. 9 is a block diagram of a combination ?rewall that
`allows the bulk of the entire Internet address space to be
`used on both sides of the ?rewall.
`
`65
`
`The present ?rewall provides a choke point used to
`control the How of data between two networks. One of the
`two networks may be the Internet, or both of the two
`networks may be intranets-the nature and identity of the two
`networks is immaterial. The important point is that all traf?c
`between the two networks must pass through a single,
`narrow point of controlled access. A?rewall therefore brings
`a great deal of leverage to bear on the problem of network
`security, allowing security measures to be concentrated on
`
`Petitioner Apple Inc. - Ex. 1044, p. 14
`
`

`
`7
`this controlled access point. To avoid possible security
`compromises, the ?rewall should ideally run on a dedicated
`computer, i.e. one Which does not have any other user
`accessible programs running on it that could provide a path
`via Which communications could circumvent the ?reWall.
`One environment in Which ?reWalls are particularly desir
`able is in enterprise netWork systems, in Which a number of
`individual netWorks that may be respectively associated With
`different departments or divisions of a company, for
`example, are connected With one another. In such an
`environment, ?reWalls can be employed to restrict access to
`the individual netWorks. While not limited to this particular
`situation, the present invention Will be, described hereinafter
`in such a context, to facilitate an understanding of its
`underlying principles.
`Referring noW to FIG. 1, assume that the accounting
`departments of tWo remote corporate sites are networked,
`and that these tWo different accounting netWorks are to be
`connected via the Internet or a similar non-secure, Wide-area
`netWork. For purposes of illustration, a ?rst site 101 having
`a ?rst accounting netWork 103 might be located in
`California, and a second site 151 having a second accounting
`netWork 153 might be located in Japan. Within each site,
`each accounting netWork may be part of a larger corporate
`netWork (109, 159). Precautions are required to safeguard
`sensitive accounting data such that it cannot be accessed
`over the general corporate netWork. A ?rst ?reWall (105,
`155) is used for this purpose. The ?rst ?reWall is interposed
`betWeen the accounting netWork and the general corporate
`netWork.
`A convenient Way to place the tWo accounting netWorks
`in communication With each other is through the Internet
`120, Which comprises another layer of a multi-layer net
`Work. As compared to other forms of connection, the Inter
`net may be more economical, more easily accessible, and
`more robust. Connecting to the Internet, hoWever, requires
`that access betWeen the Internet and the respective sites be
`strictly controlled. A second ?reWall (107, 157) is used at
`each site for this purpose.
`In the folloWing description, the present ?reWall is illus
`trated most often as a rectangle having along each of tWo
`edges thereof a netWork connection and a roW of boxes
`representing multiple “homes,” corresponding to respective
`virtual hosts. A virtal host along one edge may be used to
`initiate a connection only in response to a request from the
`netWork connection that enters the ?reWall at that edge. The
`connection, once established, is fully bi-directional, With the
`same virtual host passing data betWeen the originating
`netWork connection and the netWork connection at the
`opposite edge of the ?reWall.
`More generally, the ?reWall may be N-sided, having N
`netWork connections and being illustrated as an N-sided
`polygon. Any virtual host may establish a connection
`betWeen any pair of netWork connections so long as the
`connection originated from the netWork connection adjoin
`ing that virtual host. Again, the connection, once established,
`is fully bidirectional.
`The ?reWalls 105, 107, 155 and 157 are each of a
`construction to be more particularly described hereinafter.
`Each ?reWall is multi-homing. This means that each ?reWall
`is con?gured as multiple virtual hosts running on a physical
`computer. In the example of FIG. 1, a ?reWall is depicted as
`a single computer having multiple virtual hosts on each of its
`tWo interfaces. In practice, the multiple virtual hosts can be
`con?gured in this manner or, alternatively, implemented in
`any number of computers, as explained in detail hereinafter.
`
`55
`
`65
`
`15
`
`35
`
`45
`
`5,898,830
`
`8
`Each virtual host corresponds to a “home”, i.e. a site via
`Which a connection is made betWeen the tWo netWorks on
`either side of the ?reWall. At different times, the same virtual
`host might correspond to different homes associated With
`different connections. At any given time, hoWever, a virtual
`host represents one home. In the folloWing description of the
`particular example illustrated in FIG. 1, therefore, homes
`and virtual hosts are described as being synonymous With
`one another. Each virtual host is fully independently con
`?gurable and unique from each of the other virtual hosts.
`Considering the ?reWall 105 as being exemplary of each of
`the ?reWalls 105, 107, 155 and 157, one set of hosts 105a
`responds to addresses on a ?rst netWork interface of the
`?reWall. Another set of hosts 105b responds to addresses on
`a second netWork interface of the ?reWall.
`Normally, in accordance With the prior art, connecting
`from one computer to another remote computer along a
`route traversing one or more ?reWalls Would require the user
`to con?gure a prior-art proxy for each ?reWall to be tra
`versed. In accordance With one aspect of the invention,
`hoWever, programmable transparency is achieved by estab
`lishing DNS mappings betWeen remote hosts to be accessed
`through one of the netWork interfaces and respective virtual
`hosts on that interface.
`DNS is a distributed database system that translates host
`names to IP addresses and IP addresses to host names (e.g,
`it might translate host name omer.odyssey.com to
`129.186.424.43). The information required to perform such
`translations is stored in DNS tables. Any program that uses
`host names can be a DNS client. DNS is designed to
`translate and forWard queries and responses betWeen clients
`and servers.
`When a client needs a particular piece of information
`(e.g., the IP address of homer.odyssey.com), it asks its local
`DNS server for that information. The local DNS server ?rst
`examines its oWn local memory, such as a cache, to see if it
`already knoWs the ansWer to the client’s query. If not, the
`local DNS server asks other DNS servers, in turn, to
`discover the ansWer to the client’s query. When the local
`DNS server gets the ansWer (or decides that for some reason
`it cannot), it stores any information it received and ansWers
`the client. For example, to ?nd the IP address for
`homer.odyssey.com, the local DNS server ?rst asks a public
`root name server Which machines are name servers for the
`corn domain. It then asks one of those “com” name servers
`Which machines are name servers for the odyssey.com
`domain, and then it asks one of those name servers for the
`IP address of homer.odyssey.com.
`This asking and ansWering is all transparent to the client.
`As far as the client is concerned, it has communicated only
`With the local s