Remote Management Architecture

A 3-tier architecture: there can be many different firewall modules running in different locations (security enforcement points) controlled by a central Management Console. Administrators can administer the security system either directly via the console, or by running GUI clients connected to the Management Console through the network from another desktop.

Firewall Modules

Responsible for:

Runs on:

  • Sun & HP
  • Windows NT
  • IBM RS/6000
  • Bay Networks, Cisco and 3Com Routers
  • Xylan and Ipsilon Switches

Inspection Engine uses Stateful Inspection Technology

  • Uses context to determine if a communication request should be allowed
  • Understands the intent of a given communication by learning from previous communication sessions, and allows it through for the duration of the session
  • Builds up a dynamic state table to store state information
  • Closes the needed port when the client session concludes

Management Console

Responsible for:

  • Managing object DBs, rule bases, log files
  • Concurrent administrative access with varying rights

Runs on:

  • SunOS4
  • Solaris2
  • Solaris x86
  • HP-UX
  • Windows NT
  • AIX

GUI Clients

Responsible for:

  • Building objects, rules
  • Views logs and FW status

Runs on:

  • Windows 95/NT
  • X/Motif (Sun, HP & AIX)

GUI is available only for Win95/98/NT and Motif. The exam focuses on the GUI, not the command line. The 3 different GUIs are: Security Policy Editor for setting up the security settings, Log Viewer for viewing the logs, and System Status tool for viewing the current statistics of different firewall components. Network Object Manager is a function within the Policy Editor. It is used to create objects so that we can place the objects in the rule base and set up corresponding security rules.

Licensing

For the Single Gateway Product, there is only one Firewall Module controlled by one Management Console, and they have to be installed on the same machine, meaning there is only one security enforcement point. However, you can still run the GUI client form another desktop. For multiple gateway products there could be multiple enforcement points. For example, Firewall Internet Gateway/25 means you can have up to 25 Firewall modules controlled by one Management Console.

Set up and configuration

To set up the Management Console, first run Configuration Manager on the remote NT management station and create the administrator account(s) via the Administrators tab. Then add the IP addresses of the GUI Clients that can log in to the local gateway via the GUI Clients tab. Finally, log into the Management Console via the GUI Client's Security Policy Login window.

On Unix, set up involves running the command “fwm–a” on the Management Console to add the necessary FireWall-1 administrator accounts. Edit the /etc/fw/conf/gui-clients file on the Management Console and add the IP addresses or hostnames of the GUI Client hosts that are allowed to remotely log in.

Administrator log in process

GUI client transmits the administrator's username and password to the Management Console. After validating the GUI client's IP address, the Management Console's FWM authenticates the administrator's username/ password and assigns the GUI client its access control rights and sends along the appropriate database information including security policy, object databases, log database, etc.

Administrator can have 4 different levels of access rights:

  • Monitor Only - access only to the log viewer and system status tool in read only manner
  • Read Only - in addition to the rights enjoyed by Monitor Only, administrator can access the Security Policy Editor in read only manner
  • User Access - administrator can modify user information but nothing else
  • Read/Write Access - administrator can do everything. Only one administrator can log in using this mode at a time

Communication between the Management Console and the Firewall Modules

The Firewall Module object must be defined as an Internal object in order for remote management to work.

fwd on the Management Console initiates a connection to fwd on the firewall and sends the encrypted putkey password as compilation of the Security Policy is finished. After validating the Management Console's IP address in the $FWDIR/conf/masters file, fwd authenticates the putkey password and accepts the compiled internal user databases and security policy and installs it in the Inspection Engine.

An authentication key needs to be created on the Management Console for each Firewall Module that this Management Console will remotely be in charge of:

  • Non-Unix putkey command syntax: fw putkey -p password firewall-module-ipaddress
  • Unix putkey command syntax: fw putkey -p abc123 204.32.38.10n

Removing Remote Management

Bouncing the Firewall is the process of stopping and restarting the firewall daemon fwd. This causes fwd to reread the local masters file and allow the Management Console to remotely install security policies.

To remove remote management, you remove the masters file in the $FWDIR/conf directory from the Firewall Module. Bounce the firewall and then log into the security policy. Change the location of the Firewall Module to external and install the policy again.

Placement of SPF File

Rules that make up a Security Policy File (SPF) for a single Firewall Module can be kept in an individual SPF on the Management Console or combined with rules of other Firewall Modules into a combined SPF. To avoid confusion, name the SPF to indicate it includes the combined rules of multiple Firewall Modules. Also, in the Install On column of each rule, specify the particular target(s) of the Firewall Module's object(s) clearly.

For Dual Management Console configuration, SPFs should be maintained on the Primary Management Console PMC. When a change is made to an SPF, that SPF and certain related firewall databases need to be copied to the Secondary Management Console SMC manually by the FW-1 Administrator. Each Firewall Module should include the IP address of both the PMC and SMC in their local master’s file.

Firewall Module will send each log entry to both MCs. All logs from all remote Firewall Modules will be displayed on both MCs in the order they were received. To display specific entries, use the Selection Criteria Manager.

Router Security Management

There are seven main steps in configuring router security for a specific router:

1. Configure router interfaces on the router via the console cable following the steps specified by the router manufacturer

2. Configure SNMP on the router

  • FireWall-1 can get (and set) SNMP information from (to) the router.
  • SNMP read and write community strings need to be configured into the router manually, so that SNMP information can be read from and written to the router by all who know the read/write community string.

3. Configure the enable password on the router

  • On a Cisco router, there are two passwords - the login password and the enable password.
  • Go into the global configuration mode and use the ena password command.

4. Define the Access Lists properties in the Security Policy Properties window

Available properties for controlling the router:

  • Enable Established TCP Connections - Accepts packets of established TCP connections
  • Enable RIP - Accept Routing Information Protocol
  • Enable Domain Name Queries (UDP) - Accept Domain Name Queries used by named.
  • Enable Domain Name Download (TCP) - Allow uploading of domain name-resolving tables.
  • Enable ICMP - Accept Internet Control Messages. (Pings)

5. Define the router object in the Network Objects Manager

6. Add security rules for the router in the Security Policy Editor

7. Install the security policy on the router

Encryption Technology

FireWall-1 encrypts packets traveling between two gateways on the Internet using the following encryption technologies:

Asymmetric encryption

  • secure key exchange mechanisms, Authentication and Data integrity checking
  • each node uses two mathematically related keys, one public one private
  • private key not derivable from the public key
  • public key can be freely distributed
  • only the holder of the private key can decrypt the message encrypted by the corresponding public key

Symmetric encryption (DES, 3DES, FWZ-1, RC2, RC4)

  • used to encrypt data at a higher performance
  • same key used to encrypt cleartext is used to decrypt ciphertext
  • uses symmetric keys derived from asymmetric key exchange via Diffie-Hellman key exchange protocol
  • privacy of the message based on protection of this one key
  • privacy is ensured because of the secure nature of the Diffie-Hellman key exchange protocols

Keys should be changed periodically, as cracking the key is possible. This depends on the amount of encrypted data

Different Terms:

Certificate Authority Public/Private Key

  • Asymmetric key providing digitally signed authenticity to prove that a host's Public Key is valid

Diffie-Hellman Public/Private Key

  • Asymmetric key exchange system used to create a shared secret key on each VPN node

Basic Session Key

  • Shared secret key produced by the Diffie-Hellman key exchange process

Session Key

  • Symmetric key for deriving Packet & Data Integrity keys

Data Integrity Key

  • Asymmetric key system for providing data integrity

Packet Key

  • Symmetric key for encrypting/decrypting a packet

Certificate Authority (CA)

  • Trusted third party from whom someone's public key can be reliably obtained, through either secure or insecure channel. It certifies a public key by generating a certificate (digital signature) for the key.

Digital signature

  • Proof of the sender's identity and the message's integrity
  • Created using a public encryption key system

One Way Hash Functions (128 bit MD4 and MD5, 160 bit SHA-1)

  • For creating Digital Signature
  • Receives a variable length message as input and generates a fixed size message-digest (or hash). Once combined with the sender's private key, the message digest becomes the digital signature
  • To provides certification of the sender's identity, the sender signs the message with his private key and the recipient verifies the signature with the sender's public key
  • Up to 1000 times slower than symmetric cryptography, so only used for small amount of data, such as for shared keys

Key Management Schemes

Manual IPSec

  • Fully manual key management for IPSec

FWZ

  • Check Point's proprietary key management scheme
  • Provides automated updates of Public Keys
  • Encrypts all data behind the IP and transport (UDP/TCP) header
  • Uses Reliable Data Protocol (RDP) to manage VPN session keys, encryption methods and data integrity
  • Firewalls use Reliable Datagram Protocol (RDP) for an out-of-band session to negotiate session key, to agree on encryption method, and to decide whether MD5 data integrity will be used for that session. In addition, RDP supports an automated and secure way of synchronizing public keys that are not up-to-date
  • Uses in-place encryption which has its data integrity bits inserted into header fields
  • Packet size is fixed
  • Supports FWZ1 48bit which is exportable outside the US

IPSec

  • Standards describing the general framework for encryption and authentication of IP packets
  • Employ DES and Triple DES for encryption, and MD5 and SHA-1 for authentication
  • Can be used manually (Manual IPSec) or with automated key management schemes such as ISAKMP and SKIP
  • IPSec with ISAKMP is mandatory for IP version 6
  • Uses Security Association (SA) to define the security parameters for a specific IP host, including usage of Encryption and/or Data Integrity, Encryption and/or Data Integrity methods and keys. SA itself is identified using a 32bit Security Parameters Index (SPI) that refers to a specific SA value for VPN partners. There are two headers for identifying the relevant SA: Authentication Header (AH), containing the message digest; and Encapsulating Security Payload (ESP), containing a per packet Initialization Vector (IV) for enhancing security
  • SPI should be conveyed to the other party using an external secure channel

SKIP

  • Sun's IP layer key management scheme for IPSec
  • Encapsulates the original packet with a SKIP header and IPSec headers
  • Diffie-Hellman key pair for each participating node
  • Uses one fixed SPI (0x1)

SecuRemote Client Encryption

  • Enables mobile users to communicate
  • Allows VPLs (Virtual Private LAN) over a single physical LAN

Steps to set up VPN

Establishing a FWZ VPN between two FW-1 gateways:

1. Define each gateway's encryption domain

2. Specify FWZ as the encryption method

3. Set up the FWZ public keys on both sides

4. Install Security Policy

5. Exchange public keys between the gateways

6. Add VPN rule to rule base

7. Define FWZ encryption properties for VPN rule

8. Verify and install the rule base


Establishing a Manual IPSec VPN between two FW-1 gateways:

1. Specify each gateway's encryption domain

2. Specify Manual IPSec as the encryption method

3. Create the IPSec SPIs on each gateway

4. Add VPN rule and then IPSEC rule to rule base

5. Define IPSEC encryption properties for VPN rule

6. Verify and install Security Policy


Establishing a SKIP VPN between two FireWall-1 gateways:

1. Specify each gateway's encryption domain

2. Specify SKIP as the encryption method

3. Set up the SKIP public keys on both sides

4. Exchange DH public keys between the gateways

5. Add VPN rule and then the SKIP rule to rule base

6. Define SKIP encryption properties for VPN rule

7. Verify and install Security Policy

Load Balancing

For HTTP, when FireWall-1 detects a service request to a Logical Server and determines that the session is to be redirected to a chosen server, it redirects the connection to the Load Balancing daemon (lhttpd) and notifies the HTTP client that the URL is being redirected.

For Non-HTTP, FireWall-1 uses the Address Translation mechanism by modifying the destination IP address of the incoming/outgoing packet and the source IP address of reply packets for the session.

Balancing Algorithms:

Server Load:

  • FireWall-1 connects to an agent which sits on each server and queries the current load of each server. The lowest loaded server is selected
  • Default agent is provided
  • Customer can build their own agent

Round Trip:

  • Server with the fastest round trip time between it and the Firewall Module is selected

Round Robin:

  • Server takes turn as the next server is selected from the list

Random:

  • Server is selected purely by random means

Domain:

  • DNS name of the client is compared with the DNS names of the servers, and the one with the best match will be selected

Logical server is defined by creating a group object consisting of all the servers that will be providing the given service. A network object of type Logical Server should then be created, with corresponding rules followed in the rule base.

Log Handling and User Activities Tracking

Firewall-1 allows administrators to write their own custom log handling function(s) to meet complex condition. Called User Defined Tracking, a single rule can generate different types of alarms for different conditions.

User Defined functions can be written in different computer programming languages like C/C++, Perl or Bourne Shell, etc.

SNMP

  • A mechanism in which a single console is used to control multiple vendor devices
  • Performance monitoring provides trend analysis
  • Performance control functions for altering device parameters
  • Interface with Network Management Stations (NMS's)
  • 'Get' SNMP information from network devices/agents
  • 'Set' SNMP values for SNMP manageable devices
  • SNMP daemon snmpd is started when the FireWall-1 system is started
  • Supports both SNMP V1 and V2
  • Make use of the CheckPoint provided MIB files
  • Snmp_trap is an 'executable' that sends an SNMP trap to a specified host
  • Other files used by the FireWall-1 platform to define and configure its SNMP capability include:
      mib.txt2
  • mib file compatible with the Sun NetManager
  • Defines MIB II and FireWall-1 Objects
      mib.txt
  • Defines MIB II and FireWall-1 Objects
  • Includes Group/Attribute definitions for SNMP V2
      Wellfleet.mib
  • For defining Objects for Wellfleet routers from Bay Networks
      Traps.def
  • Defines 'traps' supported by FireWall-1

Important Commands

fwconfig

  • configures FireWall-1

fw

  • together with command line arguments manages the system

fwuninstall

  • stops the firewall
  • removes FW-1 from the kernel and .rc files
  • restores inetd.conf
  • does not remove the FW-1 software

fwstart

  • loads the Firewall Module
  • starts fwd, the snmp daemon, authentication daemons, and fwm

fwstop

  • kills fwd, fwm, snmpd, authentication daemons
  • unloads the Firewall Module

fw load

  • compiles and installs a security policy

fw unload

  • uninstalls the currently loaded security policy

fw logswitch

  • creates a new log file named fw.log

fw putlic

  • installs a FireWall-1 license

fw dbload

  • downloads the user database

fw stat

  • shows the hosts status

fw log

  • displays the log files content

fw ver

  • shows the version number of FireWall-1

Special Thanks to Michael Yu for contributing material for this Cramsession. Make sure to visit his site at: http://michaelyu.freeservers.com/