Checkpoint Firewall CLI tool “dbedit” and quick lab
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.
Contents [hide]
- Step 1. Download
- Step 2. Unpack & Install R77.20 into VirtualBox VM
- Step 3. Basic CLI configuration of Checkpoint FW interfaces
- Step 4. First time setup via WebGUI
- Step 5. Setup initial routing, initial sample ruleset and simple NAT
- Step 6. Preparing access to CLI expert mode
- Step 7.Entering dbedit
- Step 8. FINAL – dbedit exercises
- Summary
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 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
- VMWare Virtual Machine OVF Template
Check_Point_Security_Gateway_R77.20_T124_OVF_Template_Gaia.tgz - SmartDashboard and other GUI management components for Windows
Windows – SmartConsole and SmartDomain Manager [INSTALL EXE package]
Check_Point_Security_Gateway_R77.20_T124_OVF_Template_Gaia.tgz
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.
set interface eth0 ipv4-address 192.168.125.20 subnet-mask 255.255.255.0 set interface eth1 ipv4-address 192.168.177.2 subnet-mask 255.255.255.0 set interface eth0 state on set interface eth1 state on
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.
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).
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.
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:
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.
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:
set expert-password
The system is going to ask you to enter new password like below screenshot from my system:
and afterwards you can enter the expert mode with the command
expert
in my system then :
checkpointvirtualGW> expert Enter expert password: Warning! All configuration should be done through clish You are in expert mode now. [Expert@checkpointvirtualGW:0]#
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:
[Expert@checkpointvirtualGW:0]# dbedit Enter Server name (ENTER for 'localhost'): Please enter a command, -h for help or -q to quit: dbedit>
#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.
[Expert@checkpointvirtualGW:0]# dbedit -globallock Enter Server name (ENTER for 'localhost'): Please enter a command, -h for help or -q to quit: dbedit>
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:
print <table_name> <object_name> printxml <table_name> <object_name>
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.
dbedit> print network_objects H_FAKE_1.1.1.1
Object Name: H_FAKE_1.1.1.1
Object UID: {30DE66BD-8F54-4B2A-95A5-E59A30B6E2EA}
Class Name: host_plain
Table Name: network_objects
Last Modified by: admin
Last Modified from: HAVRILA2
Last Modification time: Fri Feb 26 16:22:01 2016
Fields Details
--------------
DAG: false
NAT: (
<NULL>
)
SNMP: (
<NULL>
)
VPN: (
<NULL>
)
add_adtr_rule: false
additional_products: (
<NULL>
)
addr_type_indication: IPv4
certificates: (
(
<NULL>
)
)
color: black
comments:
connectra: false
connectra_settings: (
<NULL>
)
cp_products_installed: false
data_source: not-installed
data_source_settings: (
<NULL>
)
edges:
enforce_gtp_rate_limit: false
firewall: not-installed
floodgate: not-installed
gtp_rate_limit: 2048
interfaces: (
(
<NULL>
)
)
ipaddr: 1.1.1.1
ipaddr6:
macAddress:
os_info: (
osBuildNum:
osName: Gaia
osSPMajor:
osSPMinor:
osType: 0
osVerMajor:
osVerMinor:
osVersionLevel:
)
type: hostThe 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.
dbedit> modify fw_policies ##Standard rule:12:disabled true dbedit> update_all fw_policies::##Standard Updated Successfully dbedit> savedb Database saved successfully dbedit> quit [Expert@checkpointvirtualGW:0]# fwm load Standard Installing policy on R77 compatible targets: Warning: Anti-Spoofing is not configured for some interfaces and gateways. This will allow address spoofing through these gateways. Anti-Spoofing should be configured on the following objects: Gateway: checkpointvirtualGW, Interface: eth2 Gateway: checkpointvirtualGW, Interface: eth1 Gateway: checkpointvirtualGW, Interface: eth0 Standard.W: Security Policy Script generated into Standard.pf export Standard.Set: Compiled OK. Standard: Compiled OK. export Standard.Set: Compiled OK. Standard: Compiled OK. Installing Security Gateway policy on: checkpointvirtualGW ... Security Gateway policy installed successfully on checkpointvirtualGW... Security Gateway policy installation complete Security Gateway policy installation succeeded for: checkpointvirtualGW
And now the final view, in the SmartDashboard in read-only mode, reload the policy and you should see the last rule 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
# Create the object (of type network)
create network net10-internal
# Configure the network IP address
modify network_objects net10-internal ipaddr 10.0.0.0
# Configure the netmask (in dotted decimal notation) of the network
modify network_objects net10-internal netmask 255.0.0.0
# Add a comment to describe what the object is for (optional)
modify network_objects net10-internal comments "Created by networkgeekstuff with dbedit"– NEW HOST OBJECT
# Create the actual object (of type host_plain)
create host_plain PC1host
# Modify the host IP address
modify network_objects PC1host ipaddr 192.168.125.10
# Add a comment to describe what the object is for (optional)
modify network_objects PC1host comments "Created by fwadmin with dbedit"#OPTIONAL NEW HOST#2, just one more time to help the next excercises with grouping multiple objects
# Create the actual object (of type host_plain)
create host_plain PC2host
# Modify the host IP address
modify network_objects PC2host ipaddr 192.168.125.15
# Add a comment to describe what the object is for (optional)
modify network_objects PC2host comments "Created by fwadmin with dbedit"– NEW ADDRESS RANGE OBJECT
# Create the actual object (of type address_range)
create address_range dbedit_IP_range
# Modify the first IP address in the range
modify network_objects dbedit_IP_range ipaddr_first 192.168.125.100
# Modify the last IP address in the range
modify network_objects dbedit_IP_range ipaddr_last 192.168.125.110
# Add a comment to describe what the object is for (optional)
modify network_objects dbedit_IP_range comments "IP range for dbedit"– RENAME OBJECT
# Rename the network object addr-range to IPv4-range
rename network_objects dbedit_IP_range IPv4-range– DELETE OBJECT
# Delete the network object addr-range
delete network_objects IPv4-range– CREATING NETWORK GROUPS
# Create a group object
create network_object_group dbedit_host_group– Add the individual elements to the group
addelement network_objects dbedit_host_group '' network_objects:PC1host
addelement network_objects dbedit_host_group '' network_objects:PC2host– Remove individual elements from the group
rmelement network_objects dbedit_host_group '' network_objects:PC2host
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.
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:
#creates empty rule at the end, you have to change the #12 to your rule base!!! addelement fw_policies ##Standard rule security_rule modify fw_policies ##Standard rule:12:comments "Deny All RULE - dbedit" modify fw_policies ##Standard rule:12:disabled false addelement fw_policies ##Standard rule:12:action drop_action:drop addelement fw_policies ##Standard rule:12:src:'' globals:Any addelement fw_policies ##Standard rule:12:dst:'' globals:Any addelement fw_policies ##Standard rule:12:services:'' globals:Any
OPTIONAL, activate Log tracking on the rule:
rmbyindex fw_policies ##Standard rule:12:track 0 addelement fw_policies ##Standard rule:12:track tracks:Log
OPTIONAL, if you by chance want, change from DROP to PERMIT ANY
rmbyindex fw_policies ##Standard rule:12:action 0 addelement fw_policies ##Standard rule:12:action accept_action:accept
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.
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:
addelement fw_policies ##Standard rule:7:src:'' network_objects:PC1host addelement fw_policies ##Standard rule:7:src:'' network_objects:PC2host
Adding more destination objects:
addelement fw_policies ##Standard rule:8:dst:'' network_objects:dbedit_host_group
OPTIONAL #1, you can remove the unneeded parts from the rule in a similar way:
rmelement fw_policies ##Standard rule:7:src:'' network_objects:H_FAKE_1.1.1.1 rmelement fw_policies ##Standard rule:8:dst:'' network_objects:H_FAKE_2.2.2.2
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:
modify fw_policies ##Standard rule:8:dst:op 'not in'
