Checkpoint Firewall CLI tool “dbedit” and quick lab examples

In this article, I am going to give you a quick guide how to run a single checkpoint FW as virtual machine quickly on your notebook and then super-quick introduction to configuring such checkpoint firewall via CLI instead of the much more typical SmartDashboard. This articles is very focused on what I personally needed to do lab for in work and is in no way a comprehensive guide to the “dbedit” tool from Checkpoint or any firewall automation.

Background

We are using Checkpoint firewalls in our customer networks at work and are heavily using SmartDashboard and other GUI based tools to manage these firewalls in a large datacenter environments (rulebase of 10k+ firewall rules!) because that is simply our internal standard. However recently there came a push to try to automate a certain aspects of configuring these firewalls because several customer wanted to achieve shorter lead-times at least on few aspects of firewall configurations.

And since Checkpoint FWs do not support any real API for managing policies with it, it came down to CLI tools like dbedit, which we will explore here a little for the purpose of learning the practicalities of managing firewall policies with this tool. The firewall automation itself is out of scope of this article, but you should get the idea what needs to be done to achieve it after learning the basics of dbedit.

Topology of our LAB and LAB components

For this lab I was using GNS3 and VirtualBox to create my small topology, but your should be perfectly fine to use vmWare workstation with only logical interfaces from it (the vmnetX interfaces it creates) to simulate the same logic, the focus here is to manipulate the FW rules with dbedit tool, so I am not even going to do FW cluster or install Domain Management Systems (MDS) as a typical Checkpoint production environment should have.

Checkpoint LAB topology, using R77.20 release installed inside VirtualBox VM host

Checkpoint LAB topology, using R77.20 release installed inside VirtualBox VM host

Checkpoint Components used

In regards to Checkpoint software used here, I only used the 15 day trials as these are fully functional for this period and enough for a quick LAB. However even to download these, you need a partners account or any other checkpoint product, so here I need to ask you to check in what way you can download this software as for me it was easy thanks to my employer being a partner with Checkpoint so I have this access.

From the following download page for R77.20 of checkpoint:
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk101208

Step 1. Download

  1. VMWare Virtual Machine OVF Template
    Check_Point_Security_Gateway_R77.20_T124_OVF_Template_Gaia.tgz
  2. SmartDashboard and other GUI management components for Windows
    Windows – SmartConsole and SmartDomain Manager [INSTALL EXE package]

Step 2. Unpack & Install R77.20 into VirtualBox VM

Unpack the downloaded Check_Point_Security_Gateway_R77.20_T124_OVF_Template_Gaia.tgz, inside will be an OVF packaged virtual machine files that should be easy to import into VirtualBox or vmWare Workstation. Please do so.

Afterwards run the VM and follow install wizard. On this point you can do this even without GNS3 or other network around, but since in next steps immediately setting the interfaces, I recommend that you already put this VM in middle of your virtual network to test access to the VM interfaces.

Step 3. Basic CLI configuration of Checkpoint FW interfaces

After your new VM firewall is booted, we are going to configure its interfaces with IPs as basic first step. I am going to use:
eth1 – external bridge to GNS3 virtual LAN with 192.168.177.2/24 IP
eth0 – internal “host only” adapter that will simulate our corporate intranet with 192.168.125.20/24 IP

Open the checkpoint CLI console in VirtualBox and login with the default “admin” username and “admin” password.

Step 4. First time setup via WebGUI

Simply open a browser, and go to https://192.168.125.20/ and complete the first time configuration wizard. It will ask you for very basic things like what packages to install (Select all), if you are installing a Secure Gateway or MDS (here answer that you are installing Secure Gateway) and that this system is either not part or will be part of a VRRP cluster later.

Simply try to push everything to as much stand-alone minimal firewall deployment possible.

Step 5. Setup initial routing, initial sample ruleset and simple NAT

Step 5.1 IPv4 Static Route

Routing is practically not needed here, but if nothing else please setup a default gateway (or default route) towards your external inteface next hope (the router on the other side0. This is simply done via the WebGUI -> Ipv4 Static Routes and add it, example below.

Static Route via WebGUI of Checkpoint Gaia

Static Route via WebGUI of Checkpoint Gaia

Step 5.2 Simple FW policy

To configure FW policy and/or NAT in the next step, you have to install the SmartDashboard 77.20 client on your windows host, launch it and point to to your virtual checkpoint firewall IP  and the new admin username/password you created during your first-time-configuration in step #3 (since the admin/admin might not be valid here anymore).

SmartDashboard 77.20 login screen

SmartDashboard 77.20 login screen

Inside the SmartDashboard, on the top-left side navigate to the “Policy” section. This GUI is very intuitive, create a few rules with a few new network objects in the background. I am not going to give a full guide here as this is not a Checkpoint FW tutorial for SmartDashboard but simply try to create a few basic rules as I have just to have something to play later with.

Basic FW policy structure with managment / base rules / default rules / automated / non-automated and default DENY collector rules

Basic FW policy structure with managment / base rules / default rules / automated / non-automated and default DENY collector rules

In the above ruleset I have created a sample rule (very primitive really) of what we use in production. We have management rules first, then comes base rules (rules needed for servers to operate like logging), then default rules (used for each security zone like default flat access), then new section of automate rules that we want to later work with using dbedit/CLI. Followed by a section of non-automated rules and DENY ANY collector rule.

#IMPORTANT! See above the rule index numbers, from this vie it looks like rules are numbered from #1 to #7, however in the dbedit and CLI, these rules are practically indexed starting from #0, but allso the comment sections are using an index, which means that there rules will be in CLI later edited using indexes of #0 – #12 (the DENY ANY rule at the end is practically rule #12 in CLI!!). This can confuse very much so remember this from this point.

Step 5-3. Configure basic NAT rule to hide internal network behind external interface IP

This is the same NAT (or in Cisco terminology PAT) that will hide the internal network behind behind this firewall. I used this because in both my LAB networks I didn’t wanted to change the routing for this exercise so everything that transits from internal 192.168.125.0/24 network to external networks is hidden behind the 192.168.177.2 IP of the eth1 interface of the FW.

Configuring this is a single NAT rule, in the SmartDashboard top-left part, select the “NAT” section and create the following rule:

New NAT rule to hide internal network behind single translated source of the firewall IP

New NAT rule to hide internal network behind single translated source of the firewall IP, additionally, open the “NAT Method..” to activate PAT

Additionally, as shown above, select the Translated Source with right-click and select the “NAT Method…” and as shown below, switch to “Hide”. Otherwise your policy application will fail because by default Checkpoint wants to do a static one-to-one NAT and here we need to have a one-to-many NAT which is hiding the whole network behind one IP.

New NAT rule to hide internal network behind single translated source of the firewall IP

New NAT rule to hide internal network behind single translated source of the firewall IP

After all is done, hit the “Install Policy” button and hope all is accepted.

Step 6. Preparing access to CLI expert mode

dbedit is accessible from expert mode of checkpoint FW, to access this, you first need to configure password access to it with the below command  executed in the checkpoint CLI:

The system is going to ask you to enter new password like below screenshot from my system:

6_set_expert_mode

and afterwards you can enter the expert mode with the command

in my system then :

Step 7.Entering dbedit

When you are in expert mode (check that your CLI prompt ends with “#” and you actually have many unix commands available), we can now enter the dbedit,

You can use dbedit in two modes, interactive mode that we will use here, but there is also a batch processing mode where you can store your dbedit commands in a text file and then execute all at once using the “-f” parameter and the text file as argument. However in this guide we are going to use interactive mode (the default one).

Enter dbedit simply by typing dbedit in the CLI, you should get output similar to this:

 #IMPORTANT!: I actually recommend that (and it is actually mandatory to edit FW policy) that you close any SmartDashboard sessions that you have with the checkpoint FW as dbedit needs an explicit lock on policy editing to do real work. To make this explicit, I recommend using dbedit always with parameter “-globallock” as in the example below, this will ask dbedit to make explicit lock of the policy editing to dbedit, this will fail if any other SmartDashboad and/or other dbedit sessions are running.

Step 8. FINAL – dbedit exercises

EXERCISE A – basic print examples

dbedit is definitely not much user friendly when it comes to printing network objects or the fw policies using the CLI, therefore I actually recommend that you open a SmartDashboard, but in “read-only” mode to the FW so that you can search for object definitions and verify your policy changes with it in a much more visually friendly way.

dbedit provides two basic print commands, print and printxml, they do the same only the output is in xml format with the second one. The syntax is roughly:

For both however, you will have to learn some basic ways how dbedit calls various objects, when we get to editing in later excercises, you can get back to print commands and use it with the network objects we create later to display them.

For now, the two examples you can try:

dbedit > print H_FAKE_1.1.1.1
note:
the H_FAKE_1.1.1.1 is one of the host object definitions I have created during policy creation in previous steps, if you have somethign different, change this to any other object that you have in your policy.

The second example you can try is to display the whole FW policy with:

dbedit> print fw_policies ##Standard

however this output is very long even for the policy shown in, so just for your comparison, this policy SmartDashbord screenshot is represented by this dbedit print output in TXT file.

EXERCISE B – disabling a simple rule from the policy

Our first example of editing a policy we keep simple, I will simply disable the last “DENY ANY” rule in my policy. In SmartDashboard, the last rule is #7, however, as explained above, dbedit is indexing rules starting with 0 and also the section names are considered an indexed output from the policy, so if you count everything from the policy I have, the last rule is actually #12!! You can doublecheck this using the print commands from previous excercise, but there is no index there, so you have to manually count the number of rules printed, what is error prone…. as I said, dbedit was not meant for visual human readability.

The one command that we need to edit the policy and change the rule 12 into disabled state is:

dbedit> modify fw_policies ##Standard rule:12:disabled true

after this command, the sequence of commands that we will use to update the policy and install it into firewalls is:

dbedit> update_all
dbedit> savedb

to install the policy, you need to exit the dbedit using the quit command, and from expert mode launch:

dbedit> quit
[Expert@checkpointvirtualGW:0]# fwm load Standard

Here is a full output of all the messages that follow a successfully update of policy, saving the db and loading the firewall with the new policy.

And now the final view, in the SmartDashboard in read-only mode, reload the policy and you should see the last rule disabled:

FW policy with the last rule #7 (#12 from dbedit indexing) disabled

FW policy with the last rule #7 (#12 from dbedit indexing) disabled

EXERCISE C – creating a few new network objects

Just to give you a reference point to creating network objects (before we jump into policy editing), here are a few examples of basic operations:

– NEW NETWORK  OBJECT

– NEW HOST  OBJECT

#OPTIONAL NEW HOST#2, just one more time to help the next excercises with grouping multiple objects

– NEW ADDRESS RANGE OBJECT

– RENAME OBJECT

– DELETE OBJECT

– CREATING NETWORK GROUPS

– Add the individual elements to the group

–  Remove individual elements from the group

EXERCISE D – removing a rule, and adding a new rule at the end of policy

We will continue to play with the last deny any rule for a little longer, we are now going to delete it, and then put it back (optionally with PERMIT ANY if you want). Again, return back to the dbedit, to make this quicker I am now going to only show the commands needed and will minimize the text around it :).

Remove the deny any rule with #12

dbedit> rmbyindex fw_policies ##Standard rule 12

in the usual way, do the update_all, savedb commands in dbedit, then exit dbedit and install policy from expert mode using the fwm load Standard. The result will be that in your policy the last rule will be removed.

FW policy with the last deny all rule removed

FW policy with the last deny all rule removed

To put the rule back, e.g. create a new rule, return to dbedit and use these commands that are the minimum commands to describe a new rule with deny any:

OPTIONAL, activate Log tracking on the rule:

OPTIONAL, if you by chance want, change from DROP to PERMIT ANY

in the usual way, do the update_all, savedb commands in dbedit, then exit dbedit and install policy from expert mode using the fwm load Standard. The result will be similar to the picture below.

FW policy with edited two rules in the middle of the policy

FW policy with edited two rules in the middle of the policy

EXERCISE E – Editing existing rule

The last exercise here is that we will edit an existing rule by adding more network objects to the source and destination parts.

#IMPORTANT!: If you are asking why were are not adding new rule to the middle of the policy then please note that this is not easily possible. dbedit is only capable of adding a new rule to the end of the policy, this means that if you have a ruleset of five rules (#0-#4) and you want to enter a new rule that will be, lets say, second (#2), you need to delete rules #2-#4, add your rule and then re-create the deleted rules again as new rules #3-#5 behind your newly inserted rule #2.

Let’s  now  do something like editing an existing rule and I will use the two rules I pre-created for this purpose in my policy #4(7 for dbedit) source and #5(8 for dbedit) and I will add more items to the source and destination parts.

Adding more source objects:

Adding more destination objects:

OPTIONAL #1, you can remove the unneeded parts from the rule in a similar way:

OPTIONAL #2, if you need to change the logic of a rule field to a negation (ergo “not containing XY”) you can do so like this:

Summary

What to say, dbedit is the only tool I currently see that at least in a limited way will allow us to automate a portion of the firewall policy, however due to the problematic insertion of new rules I am much more expecting a semi-automated solution where rule templates will exist, while automated script is only adding systems to the source/destination part of pre-existing template rules. We will see, at this point this was just a quick introduction to the dbedit as a summary of my quick LAB I did and maybe will be interesting for someone else.

REFERENCES

Checkpoint Gaia web admin documentation:
https://sc1.checkpoint.com/documents/R76/CP_R76_Gaia_WebAdmin/75697.htm

Checkpoint R77 CLI command reference guide:
https://sc1.checkpoint.com/documents/R77/CP_R77_CLI_ReferenceGuide_WebAdmin/index.html

 

If you enjoyed this blog, please share.

About Peter Havrila

Author's Profile