`
`Version 2.0
`September 1995
`
`Table of Contents
`
`• Executive Summfil
`• Internet FireV'8.ll Technologies
`o Overyiey
`o bP.P.licati.on-L8.)!1r arui Circuit GatevaY.§.
`o Packet-Filteoog Gatewa~
`o CheckPoint Fire Wall-1
`• Co1:illg,;mre: FireWall· 1
`C A SimP.le Configuration
`c A. More Detaped Configuration
`o A.utbentication
`c Anti.Spoofmg
`o Logging and Al.enmg
`o ~aRule:Base
`o Securiy...E2l:i&Y.
`• PrinciPMl5 of OP.erntion
`o Introduction
`o FireWe.11"1 Architecmre
`o Control Mod1Jle
`o Firevall Module
`. o Aulhenticaoon
`o Enc~
`o Address Translation
`:a Outbound. FTP Connec'lions
`o UDP·bMed Anplications
`o Pe:d'annance
`• Conclusion
`• .mieciiicati.om
`• Notices
`Executive Summary
`
`When you connect your local network tn the Internet, The sme:ie most important In283Uie you ca.n take TD
`prevent break.-irul iJl 1D define a network secun:ty policy and es1a.blish a firewall 1D implement that policy. This
`document describes hov 1D accurately and simply express-such a 5ecurity policy in FireWa.ll-1 by presenting a
`number of 'M)icel example co:nfigtm.tiowi. These exW1ple:, rnd 1h.eir de:;ign rationale mil 3erve Ma guide for
`your oVIL implement.a.ti.on.
`
`In addition, this docwnent describe:! th.e architecture and uruque chm.cteri!tics of CheckPo:int's FireWell-1
`Internet Gateway, and outJines the major characteristics that enable CheckPo:intFireWalH 1D establishflill,
`tra.nsparent, and true In-oornet connectivity wing the entire renge of Inteme, protocols, vhile erun.1:ring network
`security Encryption, User 8llJl. Client Authentic&tinn end other Fire Wall-1 features and "OOchnique~ are
`de:scribed. Firlfll.l.y, perfannance data are presented.
`
`The powerful combination of CheckPoil'lt FueWall-1 's sophisticated Sw.teful Multi-Le_yer lrupection (SMLI)
`technology and its :intuitive GUI deliver 'llllm.8.tched secun.y, connectivity and performence.
`
`INV0012089
`
`Page 1 of 23
`
`Implicit Exhibit 2009
`Juniper v. Implicit
`
`
`
`Internet Firewall Technologies
`
`Overviev
`
`When you connect your network to the Internet or to &n.other network, securing your network egairult intrusion
`is of ciiti.ce.l im:portance. Toe most effective way to secure the Internet link is to put a firewall system between
`the lcical network and the Internet. The firevall's role is to ensure that all communication between an
`organization's network and the Internet conforms to the organization's security policies. Additional security
`measures, such as authentication and pri'i'a.Cy enhancements, may follow and complement firevalls, but
`stoppillg the fire from spreadillg into the private network is the first step.
`
`Two methods, usually implemented together, are commonly employed to establish Internet firevalls, the major
`difference between th.em being in the flow of communication:
`
`A.ppfkatio.B lf8M Fll'.J'.:t'
`
`With appI:i,:;ation and circuit gateways, all packets are addressed to a "USer-layer application on the gateway that
`relays the packets between the two communication points. In most application gate-way implementations,
`additional packet filter machines are required to control and screen the uaffic between the gateway and the
`networks. A typical configuration includes two routers, with a bastion host in the middle, to serve as the
`appI:i,:;ation gateway.
`
`AppI:i,:;ation ga!Eways are secure but inefficient. They are nontransparent to "USers and appI:i,:;ations and more
`important, to the gateway host on which they run, and they are difficult to configure and manage. Only a
`limited number of appI:i,:;ations is supported and special tailoring is required for each one.
`
`A packet-filter gateway acts as a router between two networks. A$ packets flow from so1JICe to destination, the
`gateway either forwards or blocks them. A packet-filter gateway is less secure than an application gateway but
`more efficient. It is comprehensive and transparent to many protocols and applications. However, traditional
`packet fillers are stateless, have only a low-level protocol understanding, and are difficult to configure and
`verify. Lack of auditing mechanisms is &n.other major drawback.
`
`Ch.eckPoint Fire Wall-1 combines the advantages of both methods - with none of their dis ad vantages - to create
`an efficient, protocol independent and secure firevall engine. Fire Wall-1 is capable of application-layer
`security, user authentication, unified support and handling of all protocols, and auditing and alerting.
`CheckPoint PireWall-1 's operation is also transparent to users and to system setup.
`
`In addition to the inspection technology, CheckPoint PireWall-1 includes an object-oriented graphical user
`interface that enables simple and :flexible system management and configuration.
`
`Application-Layer and Circuit Gatevays
`
`For each appI:i,:;ation relayed, application-layer gateva.ys use specific, special-pUipose code. Application
`gateways can provill.e a high level of security, tho~h
`they suffer from a number of deficiencies, and only a
`limited number (usually only a small basic subset) of applications and services are supported. In order to use
`appI:i,:;ation gateways, users must first connect to the ga1eway machine or install a specific client application for
`each appI:i,:;ation they expect to use. Each gatewayed application is a separate, proprielmy piece of software and
`requires its own set of management tools and permissions.
`
`Circuit gateways provill.e a more general -way to implement application ga!Eways. They support some TCP
`applications, but not all. Circuit gateways do not support other protocols. Users are often forced to install and
`"\Ji!e different client applications or 'OC1 change their work habits. Insta1ling client applications on ea.ch in1ernal
`
`INV0012090
`
`Page 2 of 23
`
`Implicit Exhibit 2009
`Juniper v. Implicit
`
`
`
`compur.er is likely 10 be a cumbersome task. :since the internal network. is typically heterogeneous vi.th :respect to
`pl.a:tfoITll!!, oper&.ting system:,, ve:!3i0ns, etc.
`
`Network. pedoDD8IlCe is also affecr.ed by both application mi circuit gateways; each packet m1l3t be copied and
`processed at lea.st twice by all the communication layeo, and user-layer processillg and context svitcb:ing ii!
`required. Moreo..er, a nev process mwt be started for ee.ch collllt'ctiDn.
`
`The application ga1ewy computer itself (bastion· .host or dual-homed gatevay) remains exposed 10 the
`network., and additional. meSM, such a.s packet-filtering, mrut be implemented to protect it Applicatiore and
`dremons mmt be ca:refully managed, since even vith. muter packet fl11.ers, they are still v-oJMx:able e.t tbe
`non-privileged ports. These protective measures typically enllill e.cq uiring additioMl. h8Id vare, limiting
`alf&ile.ble services, es vell a.s tedious and er.ror-prone ad~~tiv-e
`overhead.
`
`Packet-Filtering Gatevays
`
`Pack.et-filtering technologie:1 provide an efficient em genel"81 "Ol&.ji' to control &ny type of network traffic and
`applications. They req_uire no change:1 in client applli:ations, no specific application management or installation,
`and no additkinalhalliva:re. Using asingle, unified pack.et-filtering engine, all network traffic is processed ,mi
`then either forvarded or blocked from a single point of control.
`
`However, packet filteiing 1echnologie:i do not address all security requirements. The infoIJJ111tion available for
`filtering (for exmi.ple, soJJICe md des1;1natbn addmsses e.vd pa:n numbers) i:J mely sufficient The number of
`rules is limited, and there is a high peifoilll8l1.Ce penalty vhf:n many rule il'.131iallCes e:re 113ed. Le.ck of context or
`state information. malres it impossible to use packet filters for da,agmm-bMed pro(Ocols like UDP (User
`Datagram. Protocol), RPC (Remote Proceduie Call), or e,ren FTP (File Tmlsfer Protocol - a commonly used
`and surpiisirlilY complex TCP based service). In most cases, pack.et-!iltertng tecbmlogies provide no auditing
`or elertillg mech.&wlll5.
`
`inu:rta.ces. Implementing th.em
`Preww packet-filteiillg 1echnologies also suffer from poor ~ement
`requires a high level of understanding of commUllication inlErnals and writing low-level bit and byte code, so
`that thes~ teclmologies are difficult to change and adapt Some packet filtera are implemented inside router.i,
`thus limiting computing power and filteling capabilities and prorning no auditing or reporting capabilities.
`Others are implemented &s: softvare packages that filter the packets in application-layer processes, &n inefficient
`approach lhat requires multiple data copies, expensive delays and context swi"IJ::h.es, and delivers lo-wer
`throughput.
`
`CheckPoint FireWall-1
`
`Most existing Internet tirevalls use a combination of e. packet-filter screening computer 01 e. hard "Wre-router
`for controlling the lover layers of comm1J.llication, and e.pplice.1ion gateways for the enabled applicatiore. 'Illlll
`configuration provides only limited, non-transparent 00\d nonflexible connectivity, 8Ild en18.ils rugh cost:, in
`setup, management, and expertise.
`
`In contra3t, FireWall-1 combines tbe advantages of "both concepts:
`
`Padt/r FfflWDlg
`
`An efficient :irulpection module - applicable 10 all pro10cols - with Sta:teful Mu11i.-Layer Inspection ( SMLI)
`1echnology, underate.nds de.w. in the peck.et intended for all other lllyers, from the network. layer (IP headers) up
`to the application layer, and provides stateful con-iext.
`
`In this vay, FireWall-1 secures complex applications more effectively than technologies tba.t have only data in
`some of the layers a'l8ila.ble to them. For example, while application ga12vay.i have access only to the
`application layer and routers have acces.s only 1D 10 the lo""Wer layers, FireWall-1 integrates the information
`gat.hered from all layers inlO a single comprehensive :il1Spection point
`
`INV0012091
`
`Page 3 of 23
`
`Implicit Exhibit 2009
`Juniper v. Implicit
`
`
`
`At the same time, Fire Wall-1 's SMLI technology provide:,,: irulllpe:rent and efficient securtty to all protocols and
`applicatiow.
`
`Ap_p,Uc8tiWJ <7aten,p
`
`Fire Wall-1 provides secure application gateways (proxies) tll.at add real value, for example, encryption and
`user authentication. lhere is no need for hardware routers or cumbersome system edminturation on. the
`gateway.
`
`FireWall-1 provides logging 8.lld alerting mechard:lms, 83 well 83 simple ir!3t8Jlation and setup procedures.
`
`FireWall-1 's single integrated security :.o:olution provides enterprise-wide security- though the security policy
`can be enforced by any number of firevalls and any number of authenticated user.J can be controlled, th.ere is
`still only one seclllity policy, olle Rule Base, e.ru1 one centrlJ.lized lag. In additioll to a single integrated security
`policy, the system a.dmilwltrator can, if required, main1ain different Rule Bases to be implemented,
`for
`example, at different times of day.
`
`An intuitive, o bjec1Diiented user interface enables easy, flexible, and unifomi implementation of an
`orgenization's global seclllity policy.
`
`Th.e followillg sectioil!I of thi3 document l1em.onstra1e hov to implement a secmi'Y 11olicy ln FireWall-1, and
`explain the principles of PireWall-1 's operation.
`
`Configuring Fire W all-1
`'This section demonstre.'es hovto build a FireWall-1 Rule Base to implement a seculity policy for a simple
`network confia:u:ra'tion using a "diode" policy, and then for a larger network U!l:ing a more det:ailed
`configuration.
`
`A Simple Configuration
`
`The follo'Wirtg example illustrates hov 1D deploy Fire Wall-1 in the network configuration shovn :in the diagram
`below. Note that this i;3 not a :recommended configuration, but simply en elr..miple for the plJillOSAS of this
`document.
`
`[n 1his example, FireWall-1 "Vi11 be irun.alled on the gatevay computer (named "monk" in the rules that follow)_
`
`A Typical Security Policy
`
`For the config1JI1J.tion shown a'bove, a typical security policy might be this:
`
`external networks may only send llWl. to local computers
`
`1Dc8l comput.eI3 may access the entire network: locamet and Internet
`
`'This policy protects the private Mtvork from non-local network!!, but puts no restrictions on local computer.J.
`
`You vill begin by considering hov this seclllity policy Ct1It be implemenmd in Fire Wall-I. Next, )UU will ~ee
`how this secllrity policy can be "tigh1ened up" so that the pot.enti.81 loophDles are blocked.
`
`Implementing a Security Policy
`
`In order to implement a security policy, :you m1J3t peifomi. the follDwing actions:
`
`INV0012092
`
`Page 4 of 23
`
`Implicit Exhibit 2009
`Juniper v. Implicit
`
`
`
`Define the network objects wed in the Rule B ese.
`
`You do not have to define the entire net"WOrk to FireWall-1 - only those objects that are used in the Rule Bese.
`For the configuration described here, )OU must define the gateway (monk), the mail server (m.ailsrvr) and the
`local netvork (localnet).
`
`Define services used in your security policy (optional).
`
`You do not have to defim the commonly used services. These are already defined for you inFireWall-1. You
`should define only those special services tha.t a.re part of your security policy.
`
`Definirig network o bjec~ e:nd services is. vezy straightforward. In most cases, you need only specify a nam.e,
`because Fire Wall-I ce:n obtain tM object's properties from the appropriate /etc, NrS (yp), e:nd DNS
`dat9.ba:1es.
`
`Define the Rule Ee:ie - the rules for accepting, rejecting 8Iui logging packel!I.
`lmtall the Rule Base - install me Inspection Code on the gatevay.,.
`
`The next step :in implementing a securtty policy is to define the Rule BIISe, using the Rule Base editJr. In the
`Rule Base edi"b:Jr, rules m expres:ied in te=
`of the follo'lli'ing elements:
`
`The first three elements describe the communication att!lmpt.
`
`,$l.ncn~ - vhere the packet i3 coming from
`
`.&stin,itli.w - where the packet i3 going
`
`- the type of application
`.. ~1'..JP.li:'l'~<r
`
`Note: If you SJlecify "Any" under services, all TCP, UDP and :RPC based applicatioru, even those not
`defined in the Service Manager, are included. Even if you we an Ulldefi.ned dat9.base application, FireWell-1
`will secure the outbound connection e:nd enaure that replies are passed through but nothing else.
`
`The next two elements indicate vhat is m be done.
`
`Ai~tii:w - what is to be done with. the given communication attempt
`
`TJ1:1t±-whether to Jog the packet or to generate an alen
`
`The l.rult element mdicates vhich f~mill
`
`rnodllle 'Will enfoICe Uie rule defired by tile first five elements .
`
`- the fire'W6ll module "that will enforce tJili! role
`./J1.1"t.tl/-011
`
`In this :iimpl.e ex6lllple, there are only two rules, corresponding to the pob,::y given above.
`
`The first rule (oon-local networks may only send mail to the mail server) can be expressed in the Rule Base
`editor as folloW':3:
`
`Source
`
`Destination
`
`Services
`
`Action
`
`Track
`
`Install
`
`On
`
`kn.y
`
`mailsrvr
`
`smtp
`
`A.ocept
`
`Sbort Log
`
`G-ateways
`
`INV0012093
`
`Page 5 of 23
`
`Implicit Exhibit 2009
`Juniper v. Implicit
`
`
`
`The second rule (local computers may access the entire network: localnet alld Internet) can be expressed in the
`Rule Base edi1DI e.lJ follows:
`
`Sourc!ii'
`
`Destination
`
`Services
`
`Action
`
`Track
`
`InstalJ.
`On
`
`localnet
`
`Any
`
`Short Log Gatemys
`
`You will f:ir.lt have to define the network objects used in the Rule Base. These objects are those sho"llrl in the
`retwrk diagl'8.lll above: IDcwnet end e. mail seiver (neroed mailsrvr). In addition, a gateway (named monk}
`must 'be defined, tho~h
`it doe:1 not yet explicitly appear in the Rule 88Se. The:1e nem.es ere of course erbitrazy.
`
`Next, define the two rules, using tile Rule Base Editor. When. you are done, you shou1d ha1re & Rule B@.Se
`similar to the one shown belov:
`
`Implicit Drop
`
`Fire Well-I follo-ws the principle "That Which Is Not Extiressly Pennitled is Prohibited." To enforce this
`principle, FireWall-1 implicitly e.dds a rule at the end of the Rule Base th.at drops all comJniJIU.Cation at!Empts
`rot desciihed lJy the other rules.
`
`Since ,be rules m exemmed sequentially for each J)e£ket, only packets not de3clibed by the first two rules are
`examined by the implicit rule. However, if you rely on the implicit rule to drop these pa.eke is, they will not be
`logged, because only packet, vhicheie described by a rule can be logged. In order ro log these l)ack.e~, you
`must explicitly define a "none of the e.bove• ruJe, as follo'W3:
`
`Souroe Destination
`
`Services Action
`
`Traok
`
`Install On
`
`Any
`
`Any
`
`Any
`
`~ject
`
`Long Log Gateways
`
`IC you do not explicitly define such a rule, PireW8.ll-1 will implicitly define one for you, and the I)ackets will be
`dropped. In no case vil1 Fire Wall-I allow tbese pai:keTS m pass. Th.e advantages of defining SU£h a :rule
`explicitly are these:
`
`• You can then :1peci!y logging for rejected pa.cMt3.
`• You can tuM yow secl.Jlity policy.
`• You can bet1E1 u:n.der.r111nd your network behaVior.
`
`·steal.thing· the Gatevay
`
`The Rule Base described above bas a shortt:ommg - it enables localnet computers to get on 1he gai:eway
`(ass1Jlllirig that Uley ha~ Unix accounts 8IUl passva.Ids). In the given configuration, th:i3 is 1.IBually not
`desirable. To prevent any computers (not jwt local computeD) from getting on the gateW'B.y, you must add a
`rule (before the other rules) as folloivs:
`
`INV0012094
`
`Page 6 of 23
`
`Implicit Exhibit 2009
`Juniper v. Implicit
`
`
`
`Destination. Services
`
`Action
`
`Track
`
`In.stall On
`
`monk
`
`Any
`
`Reject
`
`Long Log
`
`6ateways
`
`Prol:lctirig tJ-ie g&.tevay in tlili mbi\ner miJke::i it inacce:isible b of.her \JSeni 8Ild appl:icatioill! (except for
`FireWall-1 manegement pUIIJoses). The gateway becomes an invisible riework object that, from the point of
`view of the network, does not even exist
`
`tJJ con!inn t.hat t.he gatemy is indeed ine.ccmible bypexfonnirlg the following experiment (after
`You may wh
`you have installed the :Rule B~e). Telnet out throU:h the gateway and then try to TELNET back to 1he
`.
`gawway. The second TELNET will fail.
`
`Note: The icons representing network. o bjacts convey infonnation about the objects Ga1Eways look like
`gates, mi e. brick wall in!lide a host or gateway icon irulice.tes that the object is Fire Welled.
`
`To further protect the gateway, you may wh
`gateway, as follows:
`
`to add a rule 'that rejects any packet vhich originate:, on the
`
`Source
`
`Destinatio~
`
`Services
`
`.\ction
`
`Track
`
`In.sta11 On
`
`monk
`
`Any
`
`ilny
`
`Reject
`
`Lorig Log
`
`Src
`
`The reason t.hat lns1)ill On :is specified as SIC ill thls rule is that by default, gateways enforce rules on inbound
`traffic only. The rule ~ enforced on monk, but because monk is specified as Src, the rule is enforced only in
`the outbound direction (tha.t is. it applies only 10 packets leavmg monk vhich also originate on monk). 1f
`Inste.ll On were specified :as Gateways, thfn the rule "Wnld apply o:nly 1D pacxets ente~ monk vllich also
`originate on monk, in other words, to no packets at ell.
`
`A More Detailed Configuration
`
`Co~ider fue following configuration:
`
`This configuration i3 similar to the fir.It one, excep, that a pulilic seITer (DMZ - Demilim:ized Zone) ha:! been
`added. DMZ provides HITP, FTP and other services ,o non-locel rietworkS, but does not initiate any traffic.
`DMZ is a.ctually a third. interlace attached to the galb'V8.)', and might be a network, a sub-network or a host.
`
`The securtty policy for this configuration is the same es the security pol:Jcy for 1he previow configuration, with
`the followmg additional role:
`
`Source
`
`Destination
`
`Services
`
`Mtion
`
`Track
`
`Install On
`
`An.y
`
`Dl':IZ
`
`HTTP, FTP Accept
`
`Short Log Gateways
`
`INV0012095
`
`Page 7 of 23
`
`Implicit Exhibit 2009
`Juniper v. Implicit
`
`
`
`Note t.h.a.t under IruiWI On, you can specify a network object either bY nfilJl.e or by fUI1Ction.
`
`In.sta1l.
`
`On lfenu
`
`l!eao.i.ug
`
`deli:n.ed
`enforce on ~ll ~twor~ objects
`specified
`as gateways
`in the direction
`in
`to
`the "'Apply Gateway Rules
`Inter:face Direction"
`property
`the
`in
`Control Properties/Security
`Policy
`wirul.0111"
`
`in the outbounil. direction
`enforce
`on
`the ~ireWalled
`objects
`network
`deiinEd
`as Source (typically
`clients
`-initiators
`o:f traffic)
`in
`
`rw.e
`
`this
`
`inholUld direction
`in the
`enforce
`on
`the FireWalled network objects
`defined
`in
`as Destination
`(typically
`servers}
`rw.e
`this
`
`enforce on all
`
`routers
`
`If you :ipedfy Sn:, the rule JS enfon:ed on the Fire Walled netvork objects specified under Sourte in that rule.
`imov:; :pointing away from the object, to indicate t.hat tbe rule is enforced for ouigomg
`Th.e icon for Src :ibov:i
`pe.cke~ only
`
`If you specify Dst, the rule is entooced on the Fire Walled network object, specified under Des-tinati.on :in that
`rule. The icon for Dst shows arrom pointing 10 the object, to indicate f.he.t the rule is enforced for incommg
`J.,ackets only.
`
`If you specify Gatrrways, the rule is eI'l!orced on all the host! that are defined as gateways (in the Host
`Properties v.iru:low). The role iS enforced in the direction specified in "Apply Gate-way Rules to Interface
`Direction" property in Control ProJ)erties/8ecurity Policy windov (see User Authentication 8Illi fuiimr.l.tY.
`Polle:<,:).
`
`If you specify rou11!trn, the rule i3 enforced on the appropria.t.e i.n1erfaces on all routers, using Fire Wall-I's
`auto-scoping feature. F.ireWall-1 gene:ra.t.es an Access List for the router. It should be noted that with Access
`Liilts only a subset of PlreWlll.l-1 ', Fire Wall ModUle fum:tioruility Cllll tie implemented. For example, it is not
`possible 10 secure FTP connections as cl.escnt,ed in Outt,ound PTP Connec:ti.ons.
`
`If you ~pecify an object by Illmlf:, then the I'1J1e is enforced for both incoming aru1 ouigomg packet!
`( eitherbound).
`
`A uthentica.tion
`
`User Authentication
`
`INV0012096
`
`Page 8 of 23
`
`Implicit Exhibit 2009
`Juniper v. Implicit
`
`
`
`User Authentication enables m 8dministra:tor 10 grant 8pecific U8ers special TELNET, F1P &rui HTTP access
`prtvileges. For ex8Jllple, if a loi::alnet wer i:I temporerily avay from tlle office and logging in from a different
`Mst, 1he admirdstra10r may vJsh to allow that 1.13er ID conttnre ti we TELNET imd. F1P on t.he localnet
`vithnut exteruling the same privilege 10 &ll wers on that host
`
`Fire W8.ll-1 recogruzes the folloving authentication schemes:
`
`• SecurID
`• $/Key
`• Urux pass'l//'Old
`• Intern.al Fire Wall-1 password
`
`HTTP Anthenticam:ig Pm::r:,
`
`The Fire Wall-1 HTIP Authenticatillg Proxy provid.e3 a m.eclwrism for authenticating weI! of HTI'P servi::e11.
`The Fire Wall-1 H'ITP Authenticating Proxy rum on a gatevay. and can protect Wl.Y nmnber of HTI'P servers
`behind tll.e gatemy.
`
`Client Authsntication
`
`In addition 10 User Autbenti.cation, P:ireWall-1 's Client Authentication feature provides a mech.ani3m for
`auth.anticating user.; of any application, standard or custom.
`
`Note: After successsful authentication, access privileges are detennined by the user's :indim ual 11roperties, as
`defined in th.a User Properties vindov. These properties include allowed sources, destinations and time of
`day.
`
`AntiSpoofing
`
`Spoofing i8 a technique vhere an intruder attempt! 1o gain Vllauthndzed acce3, by altelillg a packet's IP
`address 10 make it appear os though the packet oiiginaied in a part of the netvark "With higher access privilege:,.
`For example, a pack.et originating on the Internet may be disguised as a local.net pack.ei. If undetBcted, thls
`pack.et nugM then have unre:itdcted acce::is to 'the localnet.
`Fire Wiill-1 w a ;soph.i:,ticat:ed cmti!lpoof~ feature vh.ich detect, :iucn packets by requiring tha.t the :interlace
`on which a packet eniers 'the gatevay correspond to its IP address. For examIJle, Fire Wall-I volll.d identify a
`pack.et enteiing tbe gate'l!l'a.y from the Internet vhich carried a localnet IP address, and vould reject t.hat packet
`and issue an alert. This lype of effective anti-spoofing can only be achieved by an in'!Bgraied system such as
`Fire Wall-I that h&I access 1D both the inieife.ce thro~h which the packet arrtved and the IP address it cla.Jms 1,0
`have, and that is capable of logging and alerting these event!.
`
`Anti5poof:ing is defined in the property Widow of the network object vluch enforces it. For example, if a
`ga:te'Wll.y ia to enforce antispoofing, the spoof trllekirig pamneter.i ere defined in the gatevay' s Host Propertie:i
`wind.ow. Similarly, a router's spoof tracldng pe.rameter.i are defined in its Router Properties window.
`
`Int.he allove window, spoof tracking :i3 defined for the inteifaces as follovs:
`
`M.7 (inft'JJAif} iJ11l-'Jmcp. - allow only localnet IP addresses (that :is, packets whose source IP addresses m part
`of the locelnet network), thus preventing spoofed packets from leaving the Iocmt thrOUgh the gateway
`
`iJJ#!'.Jf.ir.~ - allow only "Other:," (that is. all packets except those whose soun:e IP addresses
`~1 (i'.rn>.111o.-tl,I
`belong to the networks listed under Valid Addresses for tlllS object's other interfaces, :in thi:l case localnet),
`Oms prevenurig spoofed packets from entering the gateva.y from the ou1slde
`
`INV0012097
`
`Page 9 of 23
`
`Implicit Exhibit 2009
`Juniper v. Implicit
`
`
`
`Logging and Alerting
`
`You can record evenw, including acceptance and rejection of pac:kets, in a. log. The FileWall-1 Log Vie-wer
`enable! you 1n examine the log, filtering and searching the log in a lf8rtety of different mys, so that ~u ~an
`q uiL:kly and efficien'tly extract the information you nred.
`
`You can 1szue an e.lert vhen Fire. We.11· 1 rejecw or accept!. a packet The &Jert can take several forms. You can
`display a message on the masier console, or :you. can send a mail message to some pre-dei;emuned &idress, or
`you can issue arr. SNMP trai;,. !n fact, ~uca.n spectly, in the Control Properties/Logging and Alerting
`vindov, any Urrix command n be executed. All al.em ere lllso logged.
`
`Installing a Rule Base
`
`Once a Rule Base has been defined, it must be installed on the Fire Wall Modules vli:h are 1D enforce it. When
`you in.stall a J:i?ule Base, Pi.reWalM verifies tbat tlle Rule BMe :is logical and c:oruiistent, generates Iru:pecti.on
`Code from t.he Rllle Ba.,e for each of the In,tall On object!, and dovnl.oad:s the I~pection Code m the
`specified. Fire W8ll Mod ule:l.
`
`If the :ipeci!ied networkobjecti, o.rourer, FiieWe.11·1 genei:a.tes and in!ltalls the appropria1e ecces-.s listre.tMr
`tlJ.an Inspection Code.
`
`Security Policy
`
`A security policy is defined not only by the l.!ulfl Ba!e, but eJso by param::1ers specified in the Contral
`Properties/ Security Policy 'Window. These parameters enable the u.,er 10 control all &1pects of a paclre t' s
`in the Rule Base
`in3per;:tion, while at the seme ,time freeing the ~er of the need 10 speci!y repeti.ti.ve de~
`Editor.
`For example, in31ead of explicitly defining rules in me~ Ba:1e for the detrol., o! identif~
`each 'I':!P pa.cl'.2t
`and i'IS responses, you can specify in tlilil 'Windov tbat packets of identified and established TCP connectlons
`should be au10mati.cally enabled. Note that the initial connecuon is e,t.abll!lhed under one of tbe rules in tlle
`Rule Base.
`
`Principles of Operation
`
`Introduction
`
`This section describes the arcbit.ecture and unique cwa.c-eristics of fue CheckPoint FireWall-1 Internet
`gateway, am outlines the major characteristics that enable CheckPoint FmiWall-1 to establlilh full, traruparem,
`and true Internet connectivity 1J3:ing the entire xarige of Interne1 protocols, while ens'W1tlg network seculi.ty. In
`8.dditi.On, Us er Authentication and other Fire Wall-1 features and techniques are described. Finally, performance
`da1a -are presented.
`
`No11e: tn FireWall-1 termimlogy, the term "gatevay" i;:i used to describe a comp.uterused prim.ar:ily to rou1li
`traffic coming in'ID and I.eavtrig a network. rn some lhm1.ture, the term "romer" 13 wed. to describe a gatew-e.y.
`In FireWe.ll· 1 lerminOiogy, ''router" nle8IIS a Cisco or Wellfleet router
`
`FireWall-1 Architecture
`
`FireWall-1 ls comprised of two primary modules:
`
`~onttol Modu1!L __
`
`-
`
`-
`
`----------------
`
`INV0012098
`
`Page 10 of 23
`
`Implicit Exhibit 2009
`Juniper v. Implicit
`
`
`
`I
`
`I
`
`I
`
`I
`
`I
`
`I
`
`I
`
`The Controi Module includes the GUI and the M8l'Jai'.ementModule.
`
`The GUI i.9 1he front end to the M~e:ment Module, vhieh :m&tages th.e FireW&.ll· 1 da:tatla:ie: the Rule Base,
`network object3, se.vices, use:cs et.c.
`
`Pil'eWnll Module
`
`The FireWaJl Module includes the Inspection Module and two daemons (snmpd and fwd).
`
`The Fire Will ModlJle unplements the securtty poliey, Jogs eventi, and communicates With the Control Module
`using the daem.orui.
`
`A FireWall-1 security policy is: defined in teml3 of network objec1S, :mvices, users, and the rules that govern
`the interactions between them. Once these have been specliied with fu.e Control Module, Ins.pection Code i3
`generated and th.en installed on the firewalls tllat will enforce the security policy. {For more information about
`defirdng a security policy, see Confjgimm: FireWeJI-1).
`
`Control Module
`
`Rule Bue
`
`Oru:e the network. ed:m:inill1I8.tor h83 defmed a securtty polley • a RlJJ.e B&l!e and. the properties of the objects
`(nenror~, service~. ho~'-'. end 1.li!ets) used in the Rule B~e - itjs converted int:i an Inspection Script.
`Inspection Code, compiled from tm Impection Script, i3 then trfll'ISmitted on e. secured control chaririel from
`i:h.e File Wall-1 Management Station - the computer on vhieh the Fite W~ 1 databa.,e is maintained - 1D the
`that will enforce the policy. The FileWall.-1 daemon load3 the Inspecti.On
`.Fire.Wall-1 daemons on the fire~
`Code in.in the FireWell-1 Iruipection Module. A network object on vruch the Fire:Wall·l Ire:pection Module is
`installed is known all a "Fire Walled sy:nem."
`
`A PheWalled system enforces those pans of the Inspection Code that are rel.eV'ailt to itself, but all logging and
`ale:rt5 are sent to the nenrork object designated as the Master. The MM1:er also maintafu3 the most re~n.t
`Inspection Code !or eech of the Fire Walled systems it controls. If a Fire Walled system 1o,e:i it:, ln:,peclion
`Code for any reason, it cen retrieve llII uptode.te co:py from tile M~ter. In practice, the M~ter end Management
`Station ere alvays on w i:18.lne sysiem. Failove.r M83ters eel\ be defined, vhich 'Will take over if the primary
`I
`Master goes down.
`
`Commurucation between the Irepection Module host:, elld the Mmagement Station is secured. The Ins:pe ction
`Mod.ule h.Ost repo~ itti status to the MeDagem.(tnt St.a.lion wing en SNMP Version 2 agent.
`
`I
`
`The Fire W~-1 depJoyment is completely in1egre.ted, In other word:i, though the seculity policy may be
`enforced by more fuan one :netwo1k. object and, as exp!ained l)elow, implemen'led at more than one layer (see
`I
`ll."1$P.ection Module Architecture), there is still only one :,ecurity policy, one Rule Base, and one centrali2ed log.
`
`Router Extensron Modale
`
`•
`
`I
`
`1
`
`In the cooe of routeIS, the Access LiSIS deiived from t.ht :iectJiity poliey m irutalled oy P'ireW~JH on the
`:rout:ers. For ClSco rouiers, FireWall-1 do'fl'ltloe.ds ~ access liSt u,mg an Expec1 session that emulates a
`1 TELNET session into the rout.er. For Wellfleet rou.iers, P'ileW&ll-1 uses SNMP,
`
`jNetvor:k: Object Manager
`The Ne,tvork Object Manager de!lnes tile entities which are part of the security policy. Only those object3 that
`la.re part of the security policy must be defined by the user. These may itielurl.e:
`
`Networks and sub-networks
`
`1
`
`INV0012099
`
`Page 11 of 23
`
`Implicit Exhibit 2009
`Juniper v. Implicit
`
`
`
`Serve:rs and worksta.tinro (Fire W8lled or rot)
`
`Routers
`
`Internet dam.ams
`
`Every object has a set of am:ibut.es, such as network address, subnetmask, etc. Some of these attributes ere
`specified by the user, while others m exuaci»d byFtreWall-1 from 1he nei:,rork databases, file the hosts and
`files, Network Information SeIVices (NI S/Yellov Pe.ges), network databases mi me Internet
`networks
`domain service. SNMP &gents are used for extracting additio!l8l infoxmation, including the interface e.lll1
`network configuration of hos;s, roumrs and gatt:vays. Objects can be combined in groups and hierarchies.
`
`User Manager
`
`FireWall-1 enables access piivileges to be defined for 1JSeIS on enindividuru.or group basis. User groups can
`be created, and access privileges, including ellowed sources and des1ina.tions 83 veil as 1J3er a.uthentica.lion
`schemes, can be defmed (see User Authentication).
`
`Service Manager
`
`The SeIVic:e M8ll.8.ger defines the services kno'm! to the sys