Provider-1 Quick Guide

Simplified Provider 1 overview

I read the Provider-1 book so you dont have to.

Terms:

MDG- Multi Domain GUIs

MDS- Multi Domain Servers

MLM- Multi Customer Log Modules (included in MDS)

CMA- Customer Management Add-on

CLM- Customer Log Module

Customer Gateway or Gateway- The customer’s Checkpoint firewall

Overview:

Provider 1 consists of atleast 1 MDS Manager and 1 MDS Container. System wide information is stored on the Manager along with logs, while CMA/CLM data is stored on the Container. The MDG can run in both Windows and Solaris.

Both Managers and Containers can be configured for HA.

To save money it is more cost effective to store logs on a dedicated log server (MLM) rather than store logs on Managers.

Provider 1 uses a single public Ip address to implement many private “virtual” addresses. The MDS Container uses virtual IPs to provide CMA, and CLMs, which reside on a Container, with IP addresses.

Each Container has an interface with a routable IP address. Behind the interface’s IP address, the CMAs have a range of virtual IP addresses to the interface IP and back. The mapping is supported by a route table.

For CMAs and CLMs, it is recommended that virtual IP set is with routale IPs, non-natted.

Route paths needed:

Customers gateway to CLM

CMA to CLM(s)

CMA t0 CMA-HA

CMA to customer’s gateway

Customers gateway to CMA

Virtual IP limitations:

250 Virtual IPs per interface

If you have more than one interface per MDS, you must specify which will be the leading interface. This interface will be used by MDSs to communicate with each other and perform db synchronization. During MSD installation, you will be prompted to choose the leading interface.

Each interface must be routable. The CMAs and CLMs must be able to communicate with their Customer’s gateway.

For MDSs to sync, all MDSs’ system clock must be synched.

Two managers cannot share the same computer. Each Container must also be on a separate computer. However a Manager and Container can share the same computer. As the number of CMAs increase, more Containers are needed, not Managers.

MDS File Structure and processes:

MDS Filesystem:

The MDS consists of the following main components:

• Several Check Point infrastructure packages

• CPshared (NG SVN Foundation package)

• CPfw1-50 (NG VPN-1/FireWall-1 package)

• CPfwbc-41 (4.1backward compatibility package)

• A single MDS package — CPmds-54.

This package contains all the Provider-1/SiteManager-1-related configuration files,

libraries and binaries, and is installed under /opt/CPmds-54.

MDS has a basic $FWDIR structure under /opt/CPmds-54. There is a special sub-directory

called customers, which includes a subdirectory for each CMA. This directory is named

after the CMA (e.g. Flowers_CMA1), and contains the CMA FireWall-1, SVN

Foundation and backward compatibility directories.

Information that is unique per Customer, such as objects, rules, the database etc., is not

linked. Customer directories such as conf, database, state are therefore private and per

Customer. Inspect files are also treated as private data, and therefore each Customer has

a private lib directory containing its inspect files, for both NG inspect files and 4.1

inspect files. Each CMA has its own unique registry file, located in its registry

directory.

The MDS server consists of processes running on two levels: the MDS level and the

CMA level. Each CMA has its own processes.

MDS Level Processes

• cpd — SVN foundation infrastructure process

• cpca — The certificate authority manager process

• fw d — Audit log server process

• fw mds — MDS main process

For proper operation, all four processes must be running. The proper order to run the

processes is: cpd, cpca, fw d, fw mds.

CMA Level Processes

• cpca — The certificate authority manager process

• cpd — SVN foundation infrastructure process

• fwd — Log server process

• fwm — SmartCenter Server main process

For proper operation, all four processes must be running. The proper order to run the

processes is: cpd, cpca, fwd, fwm.

The main MDS process (fwm mds) looks for CMAs it has no CPMI connection with

but are running and can be reached. This connection is used for collecting statuses on

the CMA and its Modules, and for receiving changes in objects that are relevant to the

MDS/MDG system.

Normally, a special task “wakes up” every 120 seconds and searches for “CMA

connection candidates”. If the task has previously found connection candidates, then by

default the next time it wakes up after only 90 seconds. This shorter interval boosts

CMAs connections upon MDS startup.

You can change both of these values:

• To change the CMA connection candidates search interval, set the

MSP_RETRY_INTERVAL variable to the desired number of seconds.

• To change the status collection interval, set the MSP_RETRY_INIT_INTERVAL variable

to the desired number of seconds.

Licensing:

MDS License Description

CPPR-MDS-M-NG Manager component without CMAs (for login,

Certificate Authority and MDS, Global Policy and

Certificate data synchronization purposes only)

CPPR-MDS-C10-NG Container hosting up to 10 CMAs

CPPR-MDS-C25-NG Container hosting up to 25 CMAs

CPPR-MDS-C50-NG Container hosting up to 50 CMAs

CPPR-MDS-C100-NG Container hosting up to 100 CMAs

CPPR-MDS-C200-NG Container hosting up to 200 CMAs

CPPR-MDS-MC10-NG Combined Manager and Container hosting up to 10

CMAs

CPPR-MDS-MC25-NG Combined Manager and Container hosting up to 25

CMAs

CPPR-MDS-MC50-NG Combined Manager and Container hosting up to 50

CMAs

CPPR-MDS-MC100-NG Combined Manager and Container hosting up to 100

CMAs

CPPR-MDS-MC200-NG Combined Manager and Container hosting up to 200

CMAs

SiteManager-1 (low cost MDS) License Description

CP-SM1-BASE100-NG Framework license for 100 CMAs. Mandatory license.

CPSM-TR-B-10-CUSTBUND

LE-NG

Bundle license for 10 CMAs. Each of these licenses

installed at the MDS level enables adding and running

up to 10 additional CMAs.

CPSM-SMM-M-NG SiteManager-1 Manager without CMAs (for

login, Certificate Authority and MDS, Global

Policy and Certificate data synchronization

purposes only)

CPSM-SMM-MC100-NG SiteManager-1 Combined Manager and

Container hosting up to 100 SiteManager-1

CMAs

CPSM-SMM-MC200-NG SiteManager-1 Combined Manager and

Container hosting up to 200 SiteManager-1

CMAs

CPSM-SMM-C100-NG SiteManager-1 Container hosting up to 100

SiteManager-1 CMAs

CPSM-SMM-C200-NG SiteManager-1 Container hosting up to 200

SiteManager-1 CMAs

CPSM-SO-CMA-1-NG First SiteManager-1 CMA managing one Small

Office Module

CPSM-ST-CMA-2-NG First SiteManager-1 CMA managing two

Modules, each protecting up to 250 internal

IPs.

CPSM-SO-CMA-1-HA-NG Secondary SiteManager-1 CMA managing one

Small Office Module

CPSM-ST-CMA-2-HA-NG Secondary SiteManager-1 CMA managing two

Modules, each protecting up to 250 internal

IPs.

MLM Licenses

CPPR-MLM-C10-NG MLM hosting up to 10 CLMs

CPPR-MLM-C25-NG MLM hosting up to 25 CLMs

CPPR-MLM-C50-NG MLM hosting up to 50 CLMs.

CPPR-MLM-C100-NG MLM hosting up to 100 CLMs.

CPPR-MLM-C200-NG MLM hosting up to 200 CLMs.

CMA licenses-updated via SmartUpdate:

CPPR-CMA-1-NG First CMA, managing one Module.

CPPR-CMA-2-NG First CMA, managing up to two Modules.

CPPR-CMA-4-NG First CMA, managing up to four Modules.

CPPR-CMA-U-NG First CMA, managing an unlimited number of Modules.

CPPR-CMA-1-HANG

Mirror CMA, managing one Module.

CPPR-CMA-2-HANG

Mirror CMA, managing up to two Modules.

CPPR-CMA-4-HANG

Mirror CMA, managing up to four Modules.

CPPR-CMA-U-HANG

Mirror CMA, managing an unlimited number of

Modules.

Module Licenses:

CPFW-FM-25-NG VPN-1 Pro Module protecting up to 25 internal nodes.

CPFW-FM-50-NG VPN-1 Pro Module protecting up to 50 internal nodes.

CPFW-FM-100-NG VPN-1 Pro Module protecting up to 100 internal nodes.

CPFW-FM-250-NG VPN-1 Pro Module protecting up to 250 internal nodes.

CPFW-FM-U-NG VPN-1 Pro Module protecting an unlimited number of

internal nodes.

License types:

Attached

Central

License

Check Point NG uses a Central license. The customer VPN-1 Pro

gateway’s license is tied to the IP address of the CMA instead of the IP

address of the customer’s module. The benefits are:

• Only one IP address is needed for all licenses.

• A license can be taken from one module and given to another.

The license remains valid when changing the IP address of the module, so

there is no need to create and install a new license.

When a Central license is attached, it means that it has been both added to

the License Repository and installed on a Check Point Node.

Unattached

Central

License

If a Central license has been added to the License Repository, but is not

installed on any Check Point Node, it is available for attachment to any

computer belonging to the Customer who owns the license.

Attached

Local

License

A local license is associated with the IP address of a specific module in a

customer’s internal network, and can only be used for the module or

SmartCenter Server with that IP address. The SmartCenter Server itself

requires a Local license.

When an NG Local license is added to the License Repository, it is

automatically attached to the remote Check Point Node and cannot be

detached from it.

Trial Period

License

Check Point products have a 15 day trial period license, during which the
software is fully functional and all features are available without a full (or an evaluation) license.

Management:

The customer needs a CMA created to actually mange the customer’s VPN-1 Gateway. The CMA is put on an MDS Container. Administrators must be selected to manage customer maintenance within Provider-1.

A Global Policy can be created using the Global Smartdashboard in Provider-1. This policy will be applied to all CMAs specified.

New customers can be added using the Add Customer Wizard, which will take you step by step through the creation of a new customer. You must be a superuser inorder to create a customer and once that customer is created, you are automatically added as an administrator. As new users are added as administrators for this company, by an authorized superuser, Read/Write permissions can be supplied based on the Administrator’s needs.

To launch the New Customer wizard:

In the MDG Customer Contents Mode (the view to which the MDG first opens):

To create a customer, click the New Customer tool in the toolbar, or from the

Manage, choose New Customer..., or right-click the Provider-1/SiteManager-1 root

and choose New Customer... from the drop-down menu. The Add Customer Wizard

will then guide you through the definition of the new customer and the customer’s

CMA(s). You can create a primary and secondary CMA for the customer at the

same time.

When creating a new user for Provider-1 administration, the authentication type must be specified. The authentication options are either local username and password (such as the case for the ISS R55 Provider/CMAs), certificate, or domain (as is the case for the ISS R60 Provider/CMAs).

The Add Customer Wizard also allows a CMA to be created. When the Get Automatic IP Address option is selected, the CMA is assigned the next available Virtual Ip address (the range was setup when the MDS was built).

The Add Customer Wizard will also allow the CMA license to be applied, however this license must already be on hand.

Gui clients define which computers can be used to manage the MDG and customer (includes the CMA and MLM).

Once the CMA has been created, a connection must be established between the CMA and the Gateway. To do so, launch SmartDashboard from the CMA and create a gateway object with the IP address of the gateway. The Provider-1 managerment network must allow communication between the CMA and the gateway.

Security rules for the Provider-1 management must be configured to allow communications between the CMA and the gateway.

Managing CMAs:

You can check the run status of the CMA in the Status column of the MDG General

View:

— This CMA is started.

— This CMA is stopped.

— Unknown Status information has been received regarding the Run

Status of this CMA.

— This CMA is waiting for a status update. Displayed from the time the

MDG starts running until the time the first status is received.

Starting or Stopping a CMA

To start or stop a CMA, proceed as follows:

1 Select the CMA.

2 From the Manage, choose Start Customer Management/Start Customer Log Module

or Stop Customer Management/Stop Customer Log Module as appropriate, or select

Start or Stop from the toolbar. The run status of the CMA will change accordingly,

and the change will be reflected in the Status column.

An alternative way to start or stop a CMA is from the MDS command line, by

using the mdsstart_Customer and mdsstop_Customer commands.

Connected Administrators

To see which administrators are active in the system at any time, use the Connected

Administrators View. This view allows you determine if any questionable activity has

taken place, for example that an administrator is logged in twice, from separate GUI

Clients. This view also allows the Provider-1 Superuser to use mouse’s right-click and

regular menus to delete an administrator’s connection

Global Policies:

Types of global policies can be designed for groups of customers with similar security

needs. This eliminates the need to recreate identical policies for each customer. This

feature greatly improves management efficiency.

Global policies are created using the global rule base, which contains a hierarchy of

rules. In a global policy, you define common (global) rules, which are given priority in

the rule base. These rules can be distributed (or assigned) to whichever customers you

choose. The global policy rule base is similar to the management rule base, except that

it includes a demarcation or a “place holder” for customer-specific rules.

The placeholder signifies that all the rules before and after it are global rules. The rule

base layout is hierarchical: the most important global rules are highest up in the rule

base. They take precedence over the customer rules. Global rules that are designated as

being of lower priority than customer rules appear below the place holder.

The rules of the global policy are not specific to a single policy of single customer, but

apply to all customers assigned the global policy.

Only one set of objects is used for all the global policies. The global policies database

contains this set of objects, which can be used in any global rule in any global policy.

The administrator creates objects just with a Customer’s SmartDashboard. Global

Object Icons are displayed with a purple G. For example, a Global Check Point Node

has the icon.

Dynamic global objects can be created as place holders for customer specific objects that should be assigned global policies.

To understand how the dynamic global object is used, let us consider an example. An

administrator creates a global rule applying to a dynamic global object representing a

generic ftp server. But instead of specifying exactly which ftp servers and their IP

addresses will be affected by the rule, the servers are represented by a dynamic global

object (FTPserver_global).

Once the global policy is complete, the administrator assigns it to one or more

Customers, and installs it on the Customers’ gateways. Then, at the gateway level,

administrators can specify IP address for local ftp servers.

Global objects can be removed either by removing a global policy from a CMA via the

MDG, or by deleting a global object from the Global SmartDashboard. When the

global policy is re-assigned to the Customer, the deleted global object is removed from

the Customer’s database.

When changes are made to a global policy, you will have to reassign it to all customers who have been assigned the policy and reinstall it onto the customer;s gateway.

You cannot assign a global policy to a Customer if a Read/Write SmartDashboard is

logged in to the customer’s CMA. First, close SmartDashboard and then assign the

global policy. You can, however, assign a global policy to a Customer if there is a Read

Only SmartDashboard logged in to the CMA.

To assign a Global Policy

1 Select a customer, then choose Manage > Assign/Install Global Policy..., or

right-click the customer and select Assign/Install Global Policy...

2 The Assign/Install Global Policy window allows you to select the policy to be

installed. Select one or more gateways. A policy must already have been installed on

the gateways, or the operation will not work. Click OK.

3 The global policy is assigned to the Customer’s CMA and the customer policy is

re-installed on the selected gateways.

Global Policy History File

Each customer’s log directory includes a history file (named gpolicy.elg), which

maintains a summary of all actions taken by the Global SmartDashboard that affect the

customer. It records all actions taken, including editing objects, assigning global policies

to a CMA, and installation on a remote gateway. The file includes time, operations

performed, global objects added, problems.

To view the customer’s history file, select a customer, right-click and choose View

History File..., or from the Manage, select View History File.....

SmartCenter applications

Administrators use the following SmartCenter applications to design, manage, monitor

and log the firewall enforcement policies:

• SmartDashboard is used by the system administrator to define and manage the

Security Policy. From this SmartConsole you can create and define networks,

gateways, hosts, user groups, services, and policy rules. You can also access many

Check Point features and add-ons.

• SmartView Tracker is used for managing and tracking logs throughout the system.

• SmartView Status is used for managing, viewing alerts and testing the status of

various Check Point components throughout the system.

• SmartUpdate is used to manage and maintain a license repository, as well as to

facilitate upgrading Check Point software.

• SecureClient Packaging Tool is used to define user profiles for

SecuRemote/SecureClient clients.

• SmartView Monitor is used to monitor and generate reports on traffic on interfaces,

Provider-1/SiteManager-1 and QoS modules, as well as on other Check Point

System counters.

• SmartView Reporter is used to generate reports for different aspects of network

activity

Logging:

A special MDS Container that hosts only CLMs, and is actually dedicated to housing

logs for multiple Customers, is called a Multi-Customer Log Module (MLM). If you

expect heavy logging, it is advisable and more cost effective in terms of licensing to

dedicate a separate server to deal solely with logs. If you intend to dedicate a machine

solely for logging, use an MLM, as it is more cost effective in terms licensing than a

regular MDS Container (which can also host CMAs).

Following is a brief overview of the steps to set up logging.

1 If you want to create an MLM, the procedure is the same as to create a Container.

2 Using the MDG, create one or more CLMs per customer. Each must be on a

different MDS.

3 Remember that you must enable communication between the Provider-1 network

and the customer’s gateways. Add appropriate rules permitting the CLMs to

communicate from the Provider-1 network with the customer’s Modules, and

install the policy on the relevant gateways.

4 Logs are not automatically forwarded for new CLMs. Once you have created a

CLM, to start the logging process, you must manually setup each relevant module

to the send its logs to the new CLM.

5 To process logs properly, the new CLM database should be synchronized with the

CMA’s database using the "install-database" operation.

Configure the MDS for the log exporting procedure.

7 If you want to enable automatic log exporting, create a Log Export Profile and

assign it to the customer’s CLMs and CMAs.

8 If you experience any difficulty, consult the Troubleshooting section.

To configure a customer module to send logs to the CLM or MLM:

1 Launch SmartDashboard for the Customer’s CMA and double-click the gateway

object to display its Check Point Gateway window.

2 Display the Additional Logging page (under Logs and Masters) and check Forward

log files to SmartCenter Server. The SmartCenter Servers drop-down list is enabled.

3 Select the new CLM from the SmartCenter Servers drop-down list and click OK.

Logs can be exported to text using fw logexport from the MLM or Container that houses the logs, manually exported to an Oracle db, or automatically exported to an Oracle db.

Logged data is stored to

this file for a scheduled period, after which the fw.log file is saved with a new

extension, say fw.log.109, and a new file is open (also known as log “switching”). Log

switching can also occur not just because of scheduled time limits, but also because of a

size limit for the active log file, or a manual user request to switch the file. Once a log

file is closed, it is possible to export the file, automatically or manually.

Commands and Utilities:

cma_migrate

This utility is used to migrate a source database, whether from a

SmartCenter Server (Management), or another CMA.

The cma_migrate utility can be accessed from the MDG, by right clicking

a CMA and selecting Import Customer Management Add-on from the menu. It is

also available within the mdscmd utility. However, the most detailed output is

available when using the cma_migrate command directly via the command

line.

The source database’s subdirectories to be migrated are conf, database and

log. If you are migrating an NG-type source database, the CPshared conf

and database directories should be put inside the

directory path>. They should be renamed conf.cpdir and

database.cpdir (respectively), to avoid overwriting the FWDIR conf and

database directories.

Usage: cma_migrate

directory>

cpmiquerybin

cpmiquerybin utility is the binary core of the Database Query Tool.

This command-line CPMI client connects to the specified database,

executes a query and displays results as either a collection of FW-1 Sets or

tab-delimitered list of requested fields from each retrieved object. The target

database of the query tool depends on the environment settings of the shell

being used by the user.

Whenever the user desires to access one of MDS databases, he/she should

execute the mdsenv command, in order to define the environment variables

necessary for database connection. In order to connect to a database of a

certain CMA, the user should execute mdsenv command providing CMA

name or IP address as a first parameter.

Usage: cpmiquerybin

[-a ]

Argument Description

query_result_type Requested format of the query result.

Possible values:

• attr – display values of specified

(with –a parameter) field of each

retrieved object

• object – display FW-1 sets

containing data of each retrieved object.

database Name of the database to connect to, in

quotes. For instance, “mdsdb” or “”.

tabel Table to retrieve the data from, for

instance, network_objects

query Empty query (“”) or a query specifying

objects range for retrieval, for instance

name=’a*’.

-a attributes_list If query_result_type was specified

“attr”, this field should contain a comma

delimited list of objects fields to display.

Object name can be accessed using a special

“virtual” field called “__name__”.

Example: __name__,ipaddr

Dbedit

This utility can be used in Provider-1 configuration and is further described

in the SmartCenter Guide. It is used in conjunction with the mdsenv

command. Particular commands for accessing the MDS and CMA

environment are included here.

Usage: dbedit –s -u -p

mds_backup

This utility stores binaries and data from your MDS installation. Runs the

gtar command on the root directories of data and binaries. Any extra

information located under these directories is backed up except from files

that are specified in mds_exclude.dat file. The collected information is

wrapped in a single zipped tar file. The name of the created backup file is

constructed by the date and time of the backup, followed by the extension

.mdsbk.tgz. For example: 13Sep2002-141437.mdsbk.tgz.

mds_restore

Restores a MDS that was previously backed up with mds_backup. For

correct operation, mds_restore should be restored onto a clean MDS

installation.

Usage: mds_restore

Mdscmd

Logs into the MDS environment. As the command is a CPMI client,

logging into an MDS Manager is required. Login is local if no argument is

provided. For remote login, include connection parameters. As the

command is a CPMI client, it has an audit log.

You are able to add customers, cmas, deleted customers, start/stop a cma,etc.

Usage: mdscmd startcma BestCustomer -n BestCustomerCMA

mdscmd stopcma <-n cma_name | -i IP > -m mds

-u username -p password

mdscmd migratecma

Use this command to migrate/import an existing source database (from a

SmartCenter Server or CMA) into another CMA. The migration will

override existing data with the data imported from the original CMA.

CMA migration from NG is not supported.

Usage: mdscmd migratecma BestCustomer -l

/opt/CPmds-41/customers/4.4.4.4/fw41 -n BestCustomerCMA

mdscmd mirrorcma

Use this command to mirror the CMA configuration from one MDS to

another MDS. This command is used to create CMA High Availability.

This command parses all Customers and checks which Customers have a

single CMA defined. If a Customer has a CMA on the source MDS, a

secondary CMA is created on the target MDS. No additional CMAs are

created for Customers that already have two CMAs.

Usage: mdscmd mirrorcma <-s source_mds> <-t target_mds> [-m mds -u

user -p password]

mdsenv

This command prepares the shell environment variables for running MDS

level command lines or specific CMA command lines. Without an

argument, the command sets the shell for MDS level commands (mdsstart,

mdsstop, etc.).

usage: mdsenv [cma name]

mdsquerydb

The mdsquerydb command runs the Database Query Tool. The purpose of

the Database Query Tool is to allow advanced users to create UNIX shell

scripts which can easily access information stored inside the CheckPoint

SmartCenter Server databases.

Mdsstart

This command starts the MDS server and all CMAs. You can reduce the

time it takes to start and stop the MDS if you have many CMAs. To do so,

set the variable NUM_EXEC_SIMUL to the number of CMAs to be launched or

stopped simultaneously. When this variable is not defined, the system

attempts to start or stop up to 10 CMAs simultaneously.

mdsstart [-m|-s]

-m –Use to start only the MDS server without starting the CMAs

-s – Use to start the CMAs sequentially

Mdsstat

This command utility gives detailed information on the status of the

processes of the MDS and CMAs, the up/down status per process.

Usage: mdsstat [-h] []

-h – Help file

Status Legend:

up: The process is up.

down: The process is down.

pnd: The process is pending initialization.

N/A: The process's PID is not yet available.

N/R: The process is not relevant container MDS.

Mdsstop

This command stops the MDS server and all the CMAs. You can reduce the

time it takes to start and stop the MDS if you have many CMAs. To do so,

set the variable NUM_EXEC_SIMUL to the number of CMAs to be launched or

stopped simultaneously. When this variable is not defined, the system

attempts to start or stop up to 10 CMAs simultaneously.

migrate_assist

This utility is a helper utility for cma_migrate. It copies all relevant files

from the original source database (from a SmartCenter Server or CMA) to

the MDS machine. It can be used to pull the original source database

directories to the current disk storage using ftp. This file copy is NOT

encrypted. Once finished with migrate_assist, you can run cma_migrate,

whose input directory is the output directory of migrate_assist.

Usage: migrate_assist