Monthly Archives: April 2012

Check Point SecurePlatform Backup Options

One aspect of the Check Point SecurePlatform OS that I struggle to get my head around is backups.  There are a few different options, and during the course of researching an upgrade I came across the best explanation I’ve seen yet.  I’ve decided to grab a copy of the relevant text and post it in my blog for future reference here.

I cannot take any credit for this information, it is taken directly from a post on this very informative site:  So, a big thank you to the blog’s author .


Oversimplified Executive Summary

  • upgrade_export contains just Check Point configuration
  • A backup is an upgrade_export plus SPLAT OS configuration
  • A snapshot is a backup plus binary files, both Check Point and SPLAT OS
  • As a general rule of thumb, if your restoring on the same hardware a snapshot would be the easiest to use since it contains the most info and an upgrade_export would be the worst, since you’d have to manually restore the most stuff.


  • It doesn’t backup any OS (i.e. SPLAT) settings, it only backup up CheckPoint settings
  • It will let you export on one OS and then import on a different OS (i.e. go from Windows to SPLAT)
  • You can upgrade_import on different hardware (i.e. go from IBM to HP)
  • You can restore an export from an older version to a newer version of CheckPoint. A SPLAT backup/restore requires that you have the exact same versions. Note that when upgrading from an older to newer version, you must use the newer version’s upgrade_export utility to create the export file.
  • It restores the product list as well. The SPLAT restore command won’t restore the Check Point settings if you don’t have the exact same products (and product versions) installed.


  • A SPLAT backup will back up both the SPLAT OS settings as well as the CheckPoint settings
  • Basically it’s an upgrade_export with OS settings added in
  • Restoring a backup file requires the exact same software installation. I.e. you can’t restore a backup from R55 on to R60 (the HFA level must match as well). The installed product list must match as well. Note that you can still restore the OS settings even if your installed Check Point product list doesn’t match.
  • The SPLAT OS settings are hardware specific. If you restore the system settings you must restore on the same hardware. However, if you only restore the Check Point settings you can restore on different hardware. Restoring just the Check Point settings is essentially the same thing as doing an “upgrade_import” of an exported file.


  • A snapshot is even better than a backup since it contains binary files. I.e. you can revert from R60 to R55 with a snapshot. The downside to this is that a snapshot file is much larger than an upgrade_export or backup file.
  • A snapshot can also roll you forward for minor software changes. For example if I revert from R60 HFA05 to HFA01 I can later revert back to R60 HFA05 from R60 HFA01
  • A snapshot cannot revert to a newer major release of Check Point. I.e. you can’t revert from R55 to R60.
  • If you’re reinstalling SPLAT on the same hardware you don’t have to install any HFA’s or change any configuration. Simply reverting to your saved snapshot file will restore all configurations and HFAs. The only stipulation is that the major software version must match. I.e. a R60 snapshot file will only work on a R60 install (regardless of HFA level).
  • You can only revert on the same hardware, since the snapshot file contains hardware specific SPLAT settings.

An exception to the rules

If you’re feeling lucky I’ve noticed that you can actually restore a backup file or snapshot file on different hardware as long as you:

  • Delete “/etc/sysconfig/hwconf” (this is automatically re-created during the reboot)
  • In the case of a snapshot file also delete “/etc/modules.conf

**Backups don’t contain this file

**modules.conf controls which drivers are loaded

**This is be automatically re-created during the reboot

  • Remove the “hwaddr” lines from /etc/sysconfig/netconf.C
  • Reboot

You must remove the hwaddr lines since the firewall will use the MAC addresses stored in the snapshot/backup file, not your network card’s physical MAC addresses. You can verify which MAC addresses you’re using with these commands:

  • ifconfig | grep HWaddr  – This shows which MACs you’re currently using
  • grep hwaddr /etc/sysconfig/hwconf -This should contains your NICs’ physical MAC addresses. If in doubt, delete this file, reboot and this file will be automatically created on startup.
  • grep hwaddr /etc/sysconfig/netconf.C -This shows which MACs your server is configured to use. If there are no “hwaddr” lines, then your NIC’s physical MACs will be used. If there are no “hwaddr” lines you can create them by running “cpnetconf store“.
  • To remove the hwaddr lines in “/etc/sysconfig/netconf.C” run these commands:
        cd /etc/sysconfig
        mv netconf.C netconf.C.old
        grep -v hwaddr netconf.C.old >netconf.C
        rm /etc/sysconfig/hwconf

How To – Back up and restore Check Point SecurePlatform Gateways and Managemement servers

This blog post details how to back up and restore Check Point Security Management Servers and Security Gateways running on the SecurePlatform OS, on Open Server hardware.

There are two types of backup available – Snapshot and Backup.

**note** it is recommended to only carry out backup procedures during a maintenance window due to the performance impact it will have on the device and the fact that the snapshot process will stop and re-start the Check Point services. Also, be aware that backing up a management server will fail if any SmartConsole connections are active.

Also, there is a third backup option for Management servers, called Upgrade Export which is used when you are upgrading to a newer version of the OS.  For a fantastic overview of all the options, take a look at this post on the excellent CP Shared forum.



A snapshot takes an image of the whole system, including device drivers, HFA’s and Hotfixes.  Typical scenarios where you would want to use the snapshot method would be:

  •  You are about to make a major change to the system eg. software upgrade. Take a snapshot prior to the upgrade and if it all goes horribly wrong you can always reset the box back to the exact state it was in before you broke it (useful to prevent tears/tantrums in the early hours of the morning during your change window)
  • Snapshot after an upgrade, and use it as a means to rebuild the box if it dies. Restore the snapshot and then and add the most recent backup (think of as incremental backups) to get you up and running again.

The snapshot will generate a large file (typically at least 1GB for a SCS) and can only be restored onto the same machine ie. same hardware and OS version.  Remember also to copy the snapshot file off the box to another location on your network, otherwise the snapshot is completely useless if the hard drive fails (the same goes for a backup).

Snapshot via the CLI:

  1. run the command: snapshot
  2. select the location you wish to save the file to, supply any credentials for ftp or scp servers, and supply a name for the snapshot file
  3. if you select a local, the snapshot file will be created in /var/CPsnapshot/snapshots, so copy the file from here into a safe location on your network if you selected the local option in step 2

Rather than follow the menu prompts you you can specify other parameters with the command, such as the name you want to give the file and your remote server details. To see a list of options type snapshot -h.

For example, to take a snapshot and copy it to your TFTP server with the file name “scs_snapshot_20052012”:

[SCS]# snapshot -t scs_snapshot_20052012

To restore from a snapshot:

You can restore a snapshot from a file located in /var/CPsnapshot/snapshots, or from a network location. Simply type the command revert in expert mode, select the source (local, tftp, ftp, scp server) and file name.

As with the snapshot command, you can specify extra options. For a list of options available with this command, type revert -h.


A backup is very similar to a snaphot, in that in contains all the Check Point configuration, networking settings (routing info etc), but it does not include device drivers, HFA’s and Hotfixes.  The the idea is that you would restore the backup onto onto the same machine ie. same hardware, OS, Check Point version and patch level.

Backups can be run without stopping the Check Point services, and the backup files are typically much smaller than with a snapshot (as they contain only the configuration information).

Backup via the CLI:

  1. run the command: backup
  2. by default the backup file will be created in /var/CPbackup/backups, so copy the file from here into a safe location on your network
  3. as with snapshots, you can supply parameters with the command such as the FTP server details and also schedule a backup.  type backup -h for more info.

To restore from a backup:

In order to restore from a back up, you must first have installed SPLAT and all the required Check Point components and hot fixes etc.  You can restore a backup from a file located in /var/CPbackup/backups, or from a network location. Simply type the command restore, select the source (local, tftp, ftp, scp server) and file name.

Once you’ve selected the back up file to restore from, you can then chose to modify which information to restore, the “system” or “cp_products”.  So for example if you wanted to restore your backup onto new hardware, you could first install the OS, and then just selectively restore the Check Point configuration.

As with the backup command, you can specify extra options. For a list of options available with this command, type restore -h.

Backup via the WebUI:

1.  log onto the device via https://<IP-Address>  (the default port is 443 unless it has been changed to avoid a clash with SSL VPN)

2.  select Device –> Backup –> Back Up Now

3.  select the location you wish to save the file to, supply any credentials for ftp or scp servers, and optionally select to include logs files in the backup.  Then click Apply

4.  click Yes to proceed.  (on a management server note the warning to close GUI clients)

5.  to view the status of the backup, click View Backup Log


**note** it is not possible to restore from a backup via the WebUI, it has to be done via the CLI.

How To – Backup Check Point SPLAT Routing and Interface Information

A quick post showing how to save the routing and interface information from your Check Point Management Servers and Gateways running on the Secure Platform OS.

Simply SSH onto the box and enter

netstat -rn > routes.txt
ifconfig > ifconfig.txt

Copy the 2 txt files off the box and then also grab a copy of /etc/sysconfig/netconf.C and you’re done.

Check Point SecurePlatform CLI reference

To save me time searching for commonly used commands for administering Check Point SecurePlatform (SPLAT) based boxes, I’ve started to put together a list of them here:



chsh -s /bin/bash username – ensures that user “username” is dropped automatically into Expert Mode when logging in through the console

fw ctl pstat (displays data about Capacity, Kernel, INSPECT, connections, NAT and Sync on firewalls)

idle 120 – extends the CLI timeout to 120 seconds when logged into SPshell

unset tmout – disables the CLI timeout when logged into Bash shell or in Expert Mode

cpadmin stop – shuts down the WebUI management services

cpadmin start – starts the WebUI management services

rpm-qa | grep kernel – determine the kernel build



Cluster XL:

cphaprob state (shows the cluster load state)

cphaprob -a if (shows the status of interfaces monitored)

fw ctl pstat – check the output of the Sync section to confirm if sync packets are being sent/received between the cluster members:

 Version: new
 Status: Able to Send/Receive sync packets
 Sync packets sent:
 total : 51348080, retransmitted : 7, retrans reqs : 0, acks : 2373
 Sync packets received:
 total : 1026629, were queued : 0, dropped by net : 0
 retrans reqs : 5, received 71 acks
 retrans reqs for illegal seq : 0
 dropped updates as a result of sync overload: 0


eth_set eth0 100f (sets the speed and duplex of eth0 to 100Mb Full Duplex – survives a reboot)

ethtool eth0 (displays the settings for interface eth0 such as speed/duplex etc

netstat -rn (to show the routing table of your device)

ifconfig ( to show the list of available interfaces)

tcpdump -i eth0 -s 1500 net -w/var/tmp/xxw.pcap

* If you want to filter based on the network address, you should put as above, if filter based on host, change it to ‘host’.
**The -s 1500 indicate the normal 1500 size packet you want to capture. If you don’t define 1500, the packets captured will show incomplete details.
***-w is used to save the files to a specific folder. By defining the file extension with .pcap, you’d be able to double click the file to open it via ethereal.

netstat -rn | more (displays the routing table, without resolving names – if you wish to display it per page, use | more at the end of your command line)

netstat -i (displays the Interface Table – useful for displaying error statistics)


Other Useful Linux Commands

gtar -zxvf <file name.tgz> – extracts the contents of a .tgz file to the directory that you are currently in


cat /proc/meminfo or free – Will tell you how much memory is available, how much is used, and how much is swapped, as well asother metrics associated with memory.


grep command can be used at the end of the normal commands to grab specific names you wish to search for. eg. if you wish to see routing table entries for eth3, the command would be:

netstat -rn | grep eth3


df -h displays the amount free disk space no each mounted drive in human readable form ie. GB’s and MB’s.  For example:

[Expert@checkpoint_box]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda6 1004M 160M 793M  17%  /
/dev/sda1 145M  11M  126M  8%   /boot
/dev/sda5 3.4G  3.4G 0     100% /opt
/dev/sda2 1.5G  569M 861M  40%  /sysimg
/dev/sda7 215G  200G 3.9G  99%  /var

How To – Upgrading the software and ASDM images on a Cisco ASA

I recently to needed to upgrade the Software Image on a Cisco ASA 5510 security appliance from version 8.2(2) to 8.2(5).  This process also required upgrading the ASDM software to version 6.4(5) so that the newly upgraded appliance could still be managed via the GUI.


The process for both pieces of the upgrade is very straight forward, so here goes:

Upgrading the ASA image from 8.2(2) to 8.2(5)


Step 1.  Copy the new IOS software image from a TFTP server to the ASA, using the following commands:


ASA5510# copy tftp disk0
Address or name of remote host []?
Source filename []? asa825-k8.bin
Destination filename [disk0]? asa825-k8.bin
Accessing tftp://;int=Inside_Interface...!!!!!!!!!!!!!
Writing file disk0:asa825-k8.bin...
15390720 bytes copied in 19.930 secs (810037 bytes/sec)


Step 2.  Verify the new image has been copied to the local disk:


ASA5510# show flash | include asa825-k8.bin


Step 3. Set the ASA to boot from the new image not the old one:


ASA5510# conf t
ASA5510(config)# no boot system disk0:/asa822-k8.bin
ASA5510(config)# boot system disk0:/asa825-k8.bin
ASA5510# write mem
ASA5510# reload


Step 4.  After the reboot, check that the ASA has booted from the new image by issuing the command show version. Verify that the software version and system image file are listed correctly.



Upgrade the ASDM software from version 6.2(5) to 6.4(5):


Step 1.  Copy the new ASDM software image from a TFTP server to the ASA, using the following commands:


ASA5510# copy tftp disk0
Address or name of remote host [] ?
Source filename [] ? asdm-645.bin
Destination filename [asdm-645.bin] ? asdm-645.bin


 Step 2.  Verify the new image has been copied to the local disk:


ASA5510# show flash | include asdm-645.bin


Step 3.  Set the ASA to use the new ASDM image:


ASA5510# conf t
ASA5510(config)# asdm image disk0:/asdm-645.bin
ASA5510# write mem


Step 4.  Verify that new ASDM version is working by launching the ASDM and checking the version number is reported 6.4(5), by clicking Help –> About Cisco ASDM 6.4.


Follow Rich on Twitter