Moving Management Modules

As a company grows from needing one firewall to several, it may be desirable to move the management functions from the firewall platform to a separate box that functions only as a management module. Check Point has, unfortunately , made the process of doing so far more complicated in NG than it was in earlier versions.

The assumption is that the two management modules will be of the same type (i.e., they will both be UNIX-type platforms or they will both be Windows-type platforms). This is critical because there is currently no way to convert a UNIX-type registry to a Windows-type registry or vice versa. Also, both management modules should be at the same software revision level, that is, if one management module has NG FP3 with Hotfix Accumulator patch 308 (HFA-308) loaded, then the other management module needs to be at that level as well. Note that the two management modules do not ultimately have to have the same IP address. Before proceeding, perform a cpstop on both management servers.

For the purposes of discussion, let us assume you have a machine that has a management module installed on it. This will be the source machine. Let us also assume that you have a newer , more powerful machine that will replace the source machine. This will be the destination machine. The destination machine has had Check Point FireWall-1 loaded on it, configured as a management module. Whether these are both UNIX or Windows machines at this point is not relevant because I provide steps for both UNIX and Windows and will note any differences. What is relevant is that both management modules are the same type of platform (i.e., you cannot do this where one platform is Windows, the other a UNIX type).

If the management modules are UNIX, issue the following commands on the destination server:

 destination#  rm rf $CPDIR/conf/* $CPDIR/database/*  destination#  rm rf $FWDIR/conf/* $FWDIR/database/* $FWDIR/log/*  

For Windows, the commands are:

 C:\>  del /s %CPDIR%\conf\*  C:\>  del /s %CPDIR%\database\*  C:\>  del /s %FWDIR%\conf\*  C:\>  del /s %FWDIR%\database\*  C:\>  del /s %FWDIR%\log\*  

Next , copy the contents of the following directories from the source machine to the destination machine.

• $CPDIR/conf (and all subdirectories)

• $CPDIR/database/*.C

• $FWDIR/conf/* (with subdirectories)

• $FWDIR/log/*

On the destination machine, remove the following files, if they exist. They will get recreated when FireWall-1 starts up.

• $FWDIR/conf/CPMILinksMgr.db

• $FWDIR/conf/CPMILinksMgr.db.private

Now you need to copy the SIC key from the registry on the source machine to the destination machine. These steps depend on whether the management stations are UNIX or Windows.

On a UNIX platform, edit the registry file. In NG FP1 and NG FP2, the file is $CPDIR/../registry/HKLM_registry.data . In NG FP3 and above, the file is $CPDIR/registry/HKLM_registry.data . On the destination management server, find the entries between the line that begins with : (SIC and the line that contains only a right parenthesis. Delete any entries between those two lines. For example, prior to making this change, the section in the registry file might look like the following:

 : (SIC         :ICAState ("[4]3")         :ICAdn ("o=chef.phoneboy.com..iz6ech")         :HasCertificate ("[4]1")         :MySICname ("cn=cp_mgmt,o=chef.phoneboy.com..iz6ech")         :CertPath ("/opt/CPshrd-50-03/conf/sic_cert.p12")) 

After you make the deletion, the section will look like this:

 : (SIC) 

NOTE!

The actual lines in the file will be indented more. The indents are reduced in this text for readability.

Once you have deleted those entries on the destination machine, copy all entries between the : (SIC and ) lines in the registry file from the source machine to the same location in the destination machine's registry.

On a Windows platform, use regedit to export the key HKEY_LOCAL_MACHINE\SOFTWARE\CheckPoint\SIC from the source platform's registry and copy to the destination. If the destination machine had FireWall-1 installed to a different directory than the source, change the CertPath registry entry accordingly .

Next, load up new licenses on the destination platform. If the destination server's IP is different, you will need new licenses. Finally, start the destination management server.

If the source and destination servers have the same IP, you can skip to Testing Your Migrated Management Module, which follows the next subsection.

Source and Destination Management Servers Have Different IP Addresses

Assuming that a new management object was created (it should be in most cases), all instances of the source management server's object must be replaced with the destination management server's object. You can easily find all the relevant locations by selecting the source object, right-clicking, and selecting Where Used. If a new management object was not created, simply edit the existing one to match the new configuration.

If a new management object was created, both objects now have the same SIC name . This is bad and must be corrected. Close Policy Editor/SmartDashboard and use either dbedit or the Check Point Database Tool to clear the SIC name from the old object. The attribute is called sic_name . For example, if your management object were called charlie_brown, the command in dbedit would be:

 dbedit>  modify network_objects charlie_brown sic_name ""  dbedit>  update network_objects charlie_brown  

If you wish to delete the source management object, cpstop the destination management server, then edit $FWDIR/conf/objects_5_0.C (see FAQ 4.2 for guidelines). Find the source management object. Change the attribute Deleteable to true (it will be under the AdminInfo section). Save the changes. Now cpstart the management station, and use Policy Editor/SmartDashboard to remove the object.

WARNING!

If the source management station has certificates on it, deleting the source object will also delete these certificates. Also, relevant ICA certificates will also be revoked . If you intend to use this management server again and need these certificates, do not delete the source management station .

Next, you must adjust the fully qualified domain name (FQDN) in the ICA. This is used to generate the Certificates Revocation List (CRL) distribution point URL that is written on the ICA-generated certificates. In many cases, you will need to change the FQDN definition to the destination management module's FQDN. You do this in the cpconfig program on UNIX platforms or with the Check Point Configuration Tool on Windows.

When gateways managed by the management station are using VPNs with external entities (nonmanaged) and the authentication of these VPNs is done with ICA-generated certificates, changing the FQDN may not be desirable because the authentication of these VPNs will likely fail. There are two possible ways to resolve this.

1. On the destination management server, change the FQDN in the ICA to the destination machine's FQDN and generate new certificates for all relevant gateways and users.

2. Update the DNS so that the source FQDN will now be resolved to the destination management server FQDN. After doing this, change the FQDN on the source management server to avoid ambiguity.

Finally, adjust the masters and log servers for each module to point at the destination management server before attempting to install the security policy on these modules.

Testing Your Migrated Management Module

There are five actions you should perform to verify that the destination management station is functional and that the relevant firewall modules are now using it.

1. Use SmartDashboard/Policy Editor to check communication with each module using the Test SIC option.

2. Install the security policy on any module now controlled by the destination management server.

3. Use the SmartView Status/Status Manager application to check the status on all modules.

4. Use the SmartView Tracker/Log Viewer application to verify that each module is sending log entries.

5. Use the fw fetch command to fetch policy from each module onto which you installed policy.

If all of these steps work, congratulationsyou've successfully moved a management station from one system to another.

Limitations on Moving Management Stations

There are some limitations related to moving management stations.

• If the source and destination management servers use different IP addresses and you manage FireWall-1 version 4.1 firewalls, you will need to redo putkeys with each module.

• If both management servers are used simultaneously and changes are done on both, these changes cannot be merged automatically . All changes need to be applied manually to both management servers.

• Changes that involve ICA modifications, which include issuing or revoking certificates, cannot be synchronized, even manually . For example, if you revoke a certificate on one management server, it will be added to the CRL on that server, but there is no way to add this to the other management server's CRL.

Moving the Management Module off a Standalone Gateway

Often, a small organization begins with a standalone gateway that has the firewall and management module on the same platform. However, there comes a time when the firewall needs to be "just a firewall" and the management module duties are best done on a separate platform. The following section explains how to accomplish this task.

Once the new management module is set up with the proper IP addresses and FireWall-1 is configured, you can follow the steps provided earlier. Follow the instructions for deleting the old primary management object because you will need to recreate that object as a firewall module only.

Now for the tricky part: convincing your old management plus firewall module to be just a firewall module. In this instance, Check Point recommends reinstalling the software. However, it is possible to take an unsupported shortcut here. After stopping the module with cpstop , you will need to edit the $CPDIR/registry/HKLM_registry.data file to do two things:

1. Remove SIC information.

2. Tell FireWall-1 it is not a management station.

To remove SIC information, look for the lines in the registry file that look like this:

 : (SIC         :ICAState ("[4]3")         :ICAdn ("o=chef.phoneboy.com..iz6ech")         :HasCertificate ("[4]1")         :MySICname ("cn=cp_mgmt,o=chef.phoneboy.com..iz6ech")         :CertPath ("/opt/CPshrd-50-03/conf/sic_cert.p12")) 

Remove everything between the first and last lines shown above so the result looks like this:

 : (SIC) 

Below the SIC section is the FW1 section. In this section, the following lines will likely need to be changed:

 :StandAlone ("[4]0") :FWManagement ("[4]0") :Management ("[4]0") :LogServer ("[4]0") :Primary ("[4]0") :HAManagement ("[4]0") 

On your ex-management station, one or more of these values may be set to "[4]1" . All of the preceding lines should be set to "[4]0" as shown above.

At this point, you should use cpconfig to establish a new OTP on the firewall module. If you haven't done so already, create the new gateway object for the firewall module, and establish SIC using the OTP you specified on the firewall module.