Checkpoint Fire Wall-1 White Paper
`
`Version 2.0
`September 1995
`
`Table of Contents
`
`• Executive Summary
`• Internet Firewall Technologies
`o Qyeryiev
`o Application-Layer and Circuit Gateways
`o Packet-Filtering G a t e w a ys
`o Checkpoint Fire Wall-1
`• Configuring Fire Wall-1
`o A Simple Configuration
`o A More Detailed Configuration
`o Authentication
`o AntiSpoofing
`o Logging and Alerting
`o Installing a Rule Base
`o Security Policy
`• Principles of Operation
`o Introduction
`o FireWall-1 Architecture
`o Control Module
`o Firewall Module
`o Authentication
`o Encryption
`o Address Translation
`o Outbound FTP Connections
`o UDP-based Applications
`o Performance
`• Conclusion
`• Specifications
`• Notices
`
`Executive Summary
`When you connect your local network to the Internet, the single most important measure you can take to
`prevent break-ins is to define a network security policy and establish a firewall to implement that policy. This
`document describes how to accurately and simply express such a security policy in FireWall-1 by presenting a
`number of typical example configurations. These examples and their design rationale will serve as a guide for
`your own implementation.
`
`In addition, this document describes the architecture and unique characteristics of Checkpoint's FireWall-1
`Internet Gateway, and outlines the major characteristics that enable Checkpoint FireWall-1 to establish full,
`transparent, and true Internet connectivity using the entire range of Internet protocols, while ensuring network
`security. Encryption, User and Client Authentication and other FireWall-1 features and techniques are
`described. Finally, performance data are presented.
`
`The powerful combination of Checkpoint FireWall-1's sophisticated Stateful Multi-Layer Inspection (SMLI)
`technology and its intuitive GUI deliver unmatched security, connectivity and performance.
`
`Juniper Ex. 1036-p. 1
`Juniper v Implicit
`
`

`

`Internet Firewall Technologies
`Overviev
`When you connect your network to the Internet or to another network, securing your network against intrusion
`is of critical importance. The most effective way to secure the Internet link is to put a firewall system between
`the local network and the Internet. The firewall'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 privacy enhancements, may follow and complement firewalls, but
`stopping the fire from spreading into the private network is the first step.
`
`Two methods, usually implemented together, are commonly employed to establish Internet firewalls, the major
`difference between them being in the flow of communication:
`
`Application
`
`gateways
`
`With application 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 gateway implementations,
`additional packet filter machines are required to control and screen the traffic between the gateway and the
`networks. A typical configuration includes two routers, with a bastion host in the middle, to serve as the
`application gateway.
`
`Application gateways are secure but inefficient. They are nontransparent to users and applications and more
`important, to the gateway host on which they run, and they are difficult to configure and manage. Only a
`limited number of applications is supported and special tailoring is required for each one.
`
`P a c k et Filtering
`
`A packet-filter gateway acts as a router between two networks. As packets flow from source 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 filters are stateless, have only a low-level protocol understanding, and are difficult to configure and
`verify. Lack of auditing mechanisms is another major drawback.
`
`Checkpoint FireWall-1 combines the advantages of both methods - with none of their disadvantages - to create
`an efficient, protocol independent and secure firewall engine. FireWall-1 is capable of application-layer
`security, user authentication, unified support and handling of all protocols, and auditing and alerting.
`Checkpoint FireWall-1 's operation is also transparent to users and to system setup.
`
`In addition to the inspection technology, Checkpoint FireWall-1 includes an object-oriented graphical user
`interface that enables simple and flexible system management and configuration.
`
`Application-Layer and Circuit Gateways
`
`For each application relayed, application-layer gateways use specific, special-purpose code. Application
`gateways can provide a high level of security, though 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
`application gateways, users must first connect to the gatevay machine or install a specific client application for
`each application they expect to use. Each gatewayed application is a separate, proprietary piece of software and
`requires its own set of management tools and permissions.
`
`Circuit gateways provide a more general way to implement application gateways. They support some TCP
`applications, but not all. Circuit gateways do not support other protocols. Users are often forced to install and
`use different client applications or to change their work habits. Installing client applications on each internal
`
`Juniper Ex. 1036-p. 2
`Juniper v Implicit
`
`

`

`computer is likely to be a cumbersome task since the internal network is typically heterogeneous with respect to
`platforms, operating systems, versions, etc.
`
`Network performance is also affected by both application and circuit gateways; each packet must be copied and
`processed at least twice by all the communication layers, and user-layer processing and context switching is
`required. Moreover, a new process must be started for each connection.
`
`The application gateway computer itself (bastion-host or dual-homed gateway) remains exposed to the
`network, and additional means, such as packet-filtering, must be implemented to protect it. Applications and
`daemons must be carefully managed, since even with router packet filters, they are still vulnerable at the
`non-privileged ports. These protective measures typically entail acquiring additional hardware, limiting
`available services, as well as tedious and error-prone administrative overhead.
`
`Packet-Filtering Gatevays
`
`Packet-filtering technologies provide an efficient and general way to control any type of network traffic and
`applications. They require no changes in client applications, no specific application management or installation,
`and no additional hardware. Using a single, unified packet-filtering engine, all network traffic is processed and
`then either forwarded or blocked from a single point of control.
`
`However, packet filtering technologies do not address all security requirements. The information available for
`filtering (for example, source and destination addresses and port numbers) is rarely sufficient. The number of
`rules is limited, and there is a high performance penalty when many rule instances are used. Lack of context or
`state information makes it impossible to use packet filters for datagram-based protocols like UDP (User
`Datagram Protocol), RPC (Remote Procedure Call), or even FTP (File Transfer Protocol - a commonly used
`and surprisingly complex TCP based service). In most cases, packet-filtering technologies provide no auditing
`or alerting mechanisms.
`
`Previous packet-filtering technologies also suffer from poor management interfaces. Implementing them
`requires a high level of understanding of communication internals and writing low-level bit and byte code, so
`that these technologies are difficult to change and adapt. Some packet filters are implemented inside routers,
`thus limiting computing power and filtering capabilities and providing no auditing or reporting capabilities.
`Others are implemented as software packages that filter the packets in application-layer processes, an inefficient
`approach that requires multiple data copies, expensive delays and context switches, and delivers lower
`throughput.
`
`Checkpoint FireWall-1
`
`Most existing Internet firewalls use a combination of a packet-filter screening computer or a hardware-router
`for controlling the lower layers of communication, and application gateways for the enabled applications. This
`configuration provides only limited, non-transparent and nonflexible connectivity, and entails high costs in
`setup, management, and expertise.
`
`In contrast, FireWall-1 combines the advantages of both concepts:
`
`Packet F i l i t e r i ng
`
`An efficient inspection module - applicable to all protocols - with Stateful Multi-Layer Inspection (SMLI)
`technology, understands data in the packet intended for all other layers, from the network layer (IP headers) up
`to the application layer, and provides stateful context.
`
`In this way, FireWall-1 secures complex applications more effectively than technologies that have only data in
`some of the layers available to them. For example, while application gateways have access only to the
`application layer and routers have access only to to the lower layers. FireWall-1 integrates the information
`gathered from all layers into a single comprehensive inspection point.
`
`Juniper Ex. 1036-p. 3
`Juniper v Implicit
`
`

`

`At the same time, FireWall-l's SMLI technology provides transparent and efficient security to all protocols and
`applications.
`
`Application
`
`Gateways
`
`FireWall-1 provides secure application gateways (proxies) that add real value, for example, encryption and
`user authentication. There is no need for hardware routers or cumbersome system administration on the
`gateway.
`
`FireWall-1 provides logging and alerting mechanisms, as well as simple installation and setup procedures.
`
`Fire Wall-1 's single integrated security solution provides enterprise-wide security - though the security policy
`can be enforced by any number of firewalls and any number of authenticated users can be controlled, there is
`still only one security policy, one Rule Base, and one centralized log. In addition to a single integrated security
`policy, the system administrator can, if required, maintain different Rule Bases to be implemented, for
`example, at different times of day.
`
`An intuitive, objectoriented user interface enables easy, flexible, and uniform implementation of an
`organization's global security policy.
`
`The following sections of this document demonstrate how to implement a security policy in FireWall-1, and
`explain the principles of FireWall-l's operation.
`
`Configuring FireWall-1
`
`This section demonstrates how to build a FireWall-1 Rule Base to implement a security policy for a simple
`network configuration using a "diode" policy, and then for a larger network using a more detailed
`configuration.
`
`A Simple Configuration
`
`The following example illustrates how to deploy Fire Wall-1 in the network configuration shown in the diagram
`below. Note that this is not a recommended configuration, but simply an example for the purposes of this
`document.
`
`In this example, FireWall-1 will be installed on the gateway computer (named "monk" in the rules that follow).
`
`A Typical Security Policy
`
`For the configuration shown above, a typical security policy might be this:
`
`external networks may only send mail to local computers
`
`local computers may access the entire network: localnet and Internet
`
`This policy protects the private network from non-local networks, but puts no restrictions on local computers.
`
`You will begin by considering how this security policy can be implemented in Firewall-1, Next, you will see
`how this security policy can be "tightened up" so that the potential loopholes are blocked.
`
`Implementing a Security Policy
`
`In order to implement a security policy, you must perform the following actions:
`
`Juniper Ex. 1036-p. 4
`Juniper v Implicit
`
`

`

`Define the network objects used in the Rule Base.
`
`You do not have to define the entire network to FireWall-1 - only those objects that are used in the Rule Base.
`For the configuration described here, you must define the gateway (monk), the mail server (mailsrvr) and the
`local network (localnet).
`
`Define services used in your security policy (optional).
`
`You, do not have to define the commonly used services. These are already defined for you in Fire Wall-1. You
`should define only those special services that are pert of your security policy.
`
`Defining network objects and services is very straightforward. In most cases, you need only specify a name,
`because FireWall-1 can obtain the object's properties from the appropriate /etc, NIS (yp), and DNS
`databases.
`
`Define the Rule Base - the rules for accepting, rejecting and logging packets.
`
`Install the Rule Base - install the Inspection Code on the gateways.
`
`The next step in implementing a security policy is to define the Rule Base, using the Rule Base editor. In the
`Rule Base editor, rules are expressed in terms of the following elements:
`
`The first three elements describe the communication attempt.
`
`Source - where the packet is coming from
`
`Destination - where the packet is going
`
`Services-
`
`the type of application
`
`Note: If you specify "Any" under services, all TCP, UDP and RPC based applications, even those not
`defined in the Service Manager, are included. Even if you use an undefined database application, FireWall-1
`will secure the outbound connection and ensure that replies are passed through but nothing else.
`
`The next two elements indicate what is to be done.
`
`Action - what is to be done with the given communication attempt
`
`Track - whether to tog the packet or to generate an alert
`
`The last element indicates which firewall module will enforce the rule defined by the first five elements.
`
`Install On - the firewall module that will enforce this rule
`
`In this simple example, there are only two rules, corresponding to the policy given above.
`
`The first rule (non-local networks may only send mail to the mail server) can be expressed in the Rule Base
`editor as follows:
`
`Source
`
`Destination Services Action
`
`Track
`
`Install On
`
`Any
`
`mailsrvr
`
`smtp
`
`Accept
`
`Short Log Gateways
`
`Juniper Ex. 1036-p. 5
`Juniper v Implicit
`
`

`

`The second rule (local computers may access the entire network: localnet and Internet) can be expressed in the
`Rule Base editor as follows:
`
`Source
`
`Destination Services Action
`
`Track
`
`Install
`On
`
`localnet Any
`
`Any
`
`Accept
`
`Short Log Gateways
`
`You will first have to define the network objects used in the Rule Base. These objects are those shown in the
`network diagram above: localnet and a mail server (named mailsrvr). In addition, a gateway (named monk)
`must be defined, though it does not yet explicitly appear in the Rule Base. These names are of course arbitrary.
`
`Next, define the two rules, using the Rule Base Editor. When you are done, you should have a Rule Base
`similar to the one shown below:
`
`Implicit Drop
`
`FireWall-1 follows the principle "That Which Is Not Expressly Permitted is Prohibited." To enforce this
`principle, FireWall-1 implicitly adds a rule at the end of the Rule Base that drops all communication attempts
`not described by the other rules.
`
`Since the rules are examined sequentially for each packet, only packets not described by the first two rules are
`examined by the implicit rule. However, if you rely on the implicit rule to drop these packets, they will not be
`logged, because only packets which are described by a rule can be logged. In order to log these packets, you
`must explicitly define a "none of the above" rule, as follows:
`
`Source Destination Services Action
`
`Track
`
`Install On
`
`Any
`
`Any
`
`Any
`
`Reject
`
`Long Log Gateways
`
`If you do not explicitly define such a rule, FireWall-1 will implicitly define one for you, and the packets will be
`dropped. In no case will FireWall-1 allow these packets to pass. The advantages of defining such a rule
`explicitly are these:
`
`• You can then specify togging for rejected packets.
`• You can tune your security policy.
`* You can better understand your network behavior.
`
`"Stealthing" the Gateway
`
`The Rule Base described above has a shortcoming - it enables localnet computers to get on the gateway
`(assuming that they have Unix accounts and passwords). In the given configuration, this is usually not
`desirable. To prevent any computers (not just local computers) from getting on the gateway, you must add a
`rule (before the other rules) as follows:
`
`Juniper Ex. 1036-p. 6
`Juniper v Implicit
`
`

`

`Source
`
`Destination Services Action
`
`Track
`
`Install On
`
`Any
`
`monk
`
`Any
`
`Reject
`
`Long Log Sateways
`
`Protecting the gateway in this manner makes it inaccessible to other users and applications (except for
`FireWall-1 management purposes). The gateway becomes an invisible network object that, from the point of
`view of the network, does not even exist.
`
`You may wish to confirm that the gateway is indeed inaccessible by performing the following experiment (after
`you have installed the Rule Base). Telnet out through the gateway and then try to TELNET back to the
`gateway. The second TELNET will fail.
`
`Note: The icons representing network objects convey information about the objects. Gateways look like
`gates, and a brick wall inside a host or gateway icon indicates that the object is FireWalled.
`
`To further protect the gateway, you may wish to add a rule that rejects any packet which originates on the
`gateway, as follows:
`
`Source
`
`Destination Services Action
`
`Track
`
`Install On
`
`monk
`
`Any
`
`Any
`
`Reject
`
`Long Log
`
`Src
`
`The reason that Install On is specified as Src in this rule is that by default, gateways enforce rules on inbound
`traffic only. The rule is enforced on monk, but because monk is specified as Src, the rule is enforced only in
`the outbound direction (that is, it applies only to packets leaving monk which also originate on monk). If
`Install On were specified as Gateways, then the rule would apply only to packets entering monk which also
`originate on monk, in other words, to no packets at all.
`
`A More Detailed Configuration
`
`Consider the following configuration:
`
`This configuration is similar to the first one, except that a public server (DMZ - Demilitarized Zone) has been
`added. DMZ provides HTTP, FTP and other services to non-local networks, but does not initiate any traffic.
`DMZ is actually a third interface attached to the gateway, and might be a network, a sub-network or a host.
`
`The security policy for this configuration is the same as the security policy for the previous configuration, with
`the following additional rule:
`
`Source
`
`Destination Services Action
`
`Track
`
`Install On
`
`Any
`
`DMZ
`
`HTTP, FTP Accept
`
`Short Log Gateways
`
`Juniper Ex. 1036-p. 7
`Juniper v Implicit
`
`

`

`Note that under Install On, you can specify a network object either by name or by function.
`
`Install
`
`ON MENU Meaning
`
`enforce OTL all network objects defined
`as gateways in the direction specified
`in the "Apply Gateway Rules to
`Interface Direction" property in the
`Control Properties/Security Policy
`window
`
`enforce in the outbound direction on
`the FireWalled network objects defined
`as Source (typically clients
`-initiators of traffic) in this rule
`
`enforce in the inbound direction on
`the FireRalled network objects defined
`as Destination (typically servers) in
`this rule
`
`enforce on all routers
`
`If you specify Src, the rule is enforced on the FireWalled network objects specified under Source in that rule.
`The icon for Src shows arrows pointing away from the object, to indicate that the rule is enforced for outgoing
`packets only.
`
`If you specify Dst, the rule is enforced on the FireWalled network objects specified under Destination in that
`rule. The icon for Dst shows arrows pointing to the object, to indicate that the rule is enforced for incoming
`packets only.
`
`If you specify Gateways, the rule is enforced on all the hosts that are defined as gateways (in the Host
`Properties window). The rule is enforced in the direction specified in "Apply Gateway Rules to Interface
`Direction" property in Control Properties/Security Policy window (see User Authentication and Security
`Policy).
`
`If you specify routers, the rule is enforced on the appropriate interfaces on all routers, using FireWall-l's
`auto-scoping feature. FireWall-1 generates an Access List for the router. It should be noted that with Access
`Lists only a subset of FireWall-1's FireWall Module functionality can be implemented. For example, it is not
`possible to secure FTP connections as described in Outbound FTP Connections.
`
`If you specify an object by name, then the rule is enforced for both incoming and outgoing packets
`(eitherbound).
`
`Authentication
`
`User Authentication
`
`Juniper Ex. 1036-p. 8
`Juniper v Implicit
`
`

`

`User Authentication enables an administrator to grant specific users special TELNET, FTP and HTTP access
`privileges. For example, if a localnet user is temporarily away from the office and logging in from a different
`host, the administrator may wish to allow that user to continue to use TELNET and FTP on the localnet
`without extending the same privilege to all users on that host.
`
`FireWall-1 recognizes the following authentication schemes:
`
`• SecurlD
`• S/Key
`• Unix password
`• Internal FireWall-1 password
`
`HTTP Authenticating Proxy
`
`The FireWall-1 HTTP Authenticating Proxy provides a mechanism for authenticating users of HTTP services.
`The FireWall-1 HTTP Authenticating Proxy runs on a gateway, and can protect any number of HTTP servers
`behind the gateway.
`
`Client Authentication
`
`In addition to User Authentication, FireWall-1's Client Authentication feature provides a mechanism for
`authenticating users of any application, standard or custom.
`
`Note: After successsful authentication, access privileges are determined by the user's individual properties, as
`defined in the User Properties window. These properties include allowed sources, destinations and time of
`day.
`
`Antispoofing
`
`Spoofing is a technique where an intruder attempts to gain unauthorized access by altering a packet's IP
`address to make it appear as though the packet originated in a part of the network with higher access privileges.
`For example, a packet originating on the Internet may be disguised as a localnet packet. If undetected, this
`packet might then have unrestricted access to the localnet.
`
`FireWall-1 has a sophisticated antispoofing feature which detects such packets by requiring that the interface
`on which a packet enters the gateway correspond to its IP address. For example, FireWall-1 would identify a
`packet entering the gateway from the Internet which carried a localnet IP address, and would reject that packet
`and issue an alert. This type of effective anti-spoofing can only be achieved by an integrated system such as
`FireWall-1 that has access to both the interface through which the packet arrived and the IP address it claims to
`have, and that is capable of logging and alerting these events.
`
`Antispoofing is defined in the property window of the network object which enforces it. For example, if a
`gateway is to enforce antispoofing, the spoof tracking parameters are defined in the gateway's Host Properties
`window. Similarly, a router's spoof tracking parameters are defined in its Router Properties window,
`
`In the above window, spoof tracking is defined for the interfaces as follows:
`
`Ie0
`
`Ie1
`
`- allow only localnet IP addresses (that is, packets whose source IP addresses are part
`interface
`(internal)
`of the localnet network), thus preventing spoofed packets from leaving the localnet through the gateway
`
`- allow only "Others" (that is, all packets except those whose source IP addresses
`interface
`(external)
`belong to the networks listed under Valid Addresses for this object's other interfaces, in this case localnet),
`thus preventing spoofed packets from entering the gateway from the outside
`
`Juniper Ex. 1036-p. 9
`Juniper v Implicit
`
`

`

`Logging and Alerting
`
`You can record events, including acceptance and rejection of packets, in a log. The FireWall-1 Log Viewer
`enables you to examine the log, filtering and searching the log in a variety of different ways, so that you can
`quickly and efficiently extract the information you need.
`
`You can issue an alert when FireWall-1 rejects or accepts a packet. The alert can take several forms. You can
`display a message on the master console, or you can send a mail message to some pre-determined address, or
`you can issue an SNMP trap. In fact, you can specify, in the Control Properties/Logging and Alerting
`window, any Unix command to be executed. All alerts are also logged.
`
`Installing a Rule Base
`Once a Rule Base has been defined, it must be installed on the FireWall Modules which are to enforce it. When
`you install a Rule Base, FireWall-1 verifies that the Rule Base is logical and consistent, generates Inspection
`Code from the Rule Base for each of the Install On objects, and downloads the Inspection Code to the
`specified FireWall Modules.
`
`If the specified network object is a router, FireWall-1 generates and installs the appropriate access list ratter
`than Inspection Code.
`
`Security Policy
`
`A security policy is defined not only by the Rule Base, but also by parameters specified in the Control
`Properties/Security Policy window. These parameters enable the user to control all aspects of a packet's
`inspection, while at the same time freeing the user of the need to specify repetitive detail in the Rule Base
`Editor.
`
`For example, instead of explicitly defining rules in the Rule Base for the details of identifying each TCP packet
`and its responses, you can specify in this window that packets of identified and established TCP connections
`should be automatically enabled. Note that the initial connection is established under one of the rules in the
`Rule Base.
`
`Principles of Operation
`Introduction
`
`This section describes the architecture and unique characteristics of the Checkpoint FireWall-1 Internet
`gateway, and outlines the major characteristics that enable Checkpoint Fire Wall-1 to establish full, transparent,
`and true Internet connectivity using the entire range of Internet protocols, while ensuring network security. In
`addition, User Authentication and other FireWall-1 features and techniques are described. Finally, performance
`data, are presented.
`
`N o t e: In FireWall-1 terminology, the term "gateway" is used to describe a computer used primarily to route
`traffic coming into and leaving a network. In some literature, the term "router" is used to describe a gateway.
`In FireWall-1 terminology, "router" means a Cisco or Wellfleet router.
`
`FireWall-1 Architecture
`
`FireWall-1 is comprised of two primary modules:
`
`Control Module
`
`Juniper Ex. 1036-p. 10
`Juniper v Implicit
`
`

`

`The Control Module includes the GUI and the Management Module.
`
`The GUI is the front end to the Management Module, which manages the FireWall-1 database: the Rule Base,
`network objects, services, users etc.
`
`FireWall Module
`
`The FireWall Module includes the Inspection Module and two daemons (snmpd and fwd).
`
`The FireWall Module implements the security policy, logs events, and communicates with the Control Module
`using the daemons.
`
`A FireWall-1 security policy is defined in terms of network objects, services, users, and the rules that govern
`the interactions between them. Once these have been specified with the Control Module, Inspection Code is
`generated and then installed on the firewalls that will enforce the security policy. (For more information about
`defining a security policy, see Configuring FireWall-1).
`
`Control Module
`
`Rule Base
`
`Once the network administrator has defined a security policy - a Rule Base and the properties of the objects
`(networks, services, hosls, and users) used in the Rule Base - it is converted into an Inspection Script.
`Inspection Code, compiled from the Inspection Script, is then transmitted on a secured control channel from
`the FireWall-1 Management Station - the computer on which the FireWall-1 database is maintained - to the
`FireWall-1 daemons on the firewalls that will enforce the policy. The FireWall-1 daemon loads the Inspection
`Code into the FireWall-1 Inspection Module. A network object on which the FireWall-1 Inspection Module is
`installed is known as a "FireWalled system."
`
`A Fire Walled system enforces those parts of the Inspection Code that are relevant to itself, but all logging and
`alerts are sent to the network object designated as the Master. The Master also maintains the most recent
`Inspection Code for each of the FireWalled systems it controls. If a FireWalled system loses its Inspection
`Code for any reason, it can retrieve an uptodate copy from the Master. In practice, the Master and Management
`Station are always on the same system. Failover Masters can be defined, which will take over if the primary
`Master goes down.
`
`Communication between the Inspection Module hosts and the Management Station is secured. The Inspection
`Module host reports its status to the Management Station using an SNMP Version 2 agent.
`
`The FireWall-1 deployment is completely integrated. In other words, though the security policy may be
`enforced by more than one network object and, as explained below, implemented at more than one layer (see
`Inspection Module Architecture). there is still only one security policy, one Rule Base, and one centralized log.
`
`Router Extension Module
`
`In the case of routers, the Access Lists derived from the security policy are installed by FireWall-1 on the
`routers. For Cisco routers, FireWall-1 downloads the access list using an Expect session that emulates a
`TELNET session into the router. For Wellfleet routers, FireWall-1 uses SNMP.
`
`jNetvork Object Manager
`
`The Network Object Manager defines the entities which are part of the security policy. Only those objects that
`are part of the security policy must be defined by the user. These may include:
`
`Networks and sub-networks
`
`Juniper Ex. 1036-p. 11
`Juniper v Implicit
`
`

`

`Servers and workstations (FireWalled or not)
`
`Routers
`
`Internet domains
`
`Every object has a set of attributes, such as network address, subnetmask, etc. Some of these attributes are
`specified by the user, while others are extracted by FireWall-1 from the network databases, like the hosts and
`networks files, Network Information Services (NIS/Yellow Pages), network databases and the Internet
`domain service. SNMP agents are used for extracting additional information, including the interface and
`network configuration of hosts, routers and gateways. Objects can be combined in groups and hierarchies.
`
`User Manager
`
`FireWall-1 enables access privileges to be defined for users on an individual or group basis. User groups can
`be created, and access privileges, including allowed sources and destinations as well as user authentication
`schemes, can be defined (see User Authentication).
`
`Service Manager
`
`The Service Manager defines the services known to the system and used in the security policy. All network
`services are screened and controlled, even those that are not defined. A comprehensive set of TCP/IP and
`Internet services is predefined, including the following:
`
`Standard arpa-services: Telnet, FTP , SMTP, etc.
`
`Berkeley r-services: rlogin, rsh, etc.
`
`SunRPC services: NIS/yellow pages, NFS, etc.
`
`Advanced Internet protocols such as HTTP, Gopher, Archie and many others
`
`IP services: Internet Control Message Protocol (ICMP), Routing Internet Protocol (RIP), SNMP, etc.
`
`New services can be defined by selecting the service type and setting the service's attributes. Service types
`include:
`
`Transmission Control Protocol (TCP)
`
`User Datagram Protocol (UDP)
`
`Remote Procedure Call (RFC)
`
`Internet Control Message Protocol (ICMP)
`
`Others - enables definition of services and protocols that do not conform to the standard set of attributes.
`Services are defined using simple expressions and macros.
`
`Services can be grouped in families and hierarchies. Examples: NFS (the mount program, NFS-server, lock
`manager), NIS/Yellow Pages (ypserv/ypbind), and WWW (HTTP, FTP, Archie, Gopher, etc.).
`
`System