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.
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:
Status of this CMA.
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
No comments:
Post a Comment