Open Frames Download Complete PDF Send Feedback Print This Page

Previous

Running CLI Commands in Automation Scripts

In This Section:

Introduction to Automation Scripts

Working with dbedit

Using XML to Export Settings for a Domain Management Server

Introduction to Automation Scripts

Use these CLI commands and tools to create automation scripts:

  • dbedit - Creates and configures objects and rules in the database for the Security Policy.
  • fwm load - Installs the specified Security Policy on Security Gateways. The Security Policy is validated, and only valid Policies are installed.
  • send_command - Runs functions which are not included with standard Check Point CLI commands and tools.

We recommend that you use a separate SmartConsole administrator account for automation scripts. This additional account lets you easily monitor automatic changes and ones made by system administrators.

Creating a Domain Management Server

Create a new Domain Management Server on the Multi-Domain Server. Make sure that you have this data before you start:

  • Name or Identifier of the domain, for example Cust_ID
  • Name or Identifier of the new Domain Management Server, for example Cust_CMA
  • IP address for the new Domain Management Server, for example 192.0.2.61
  • IP Address for the Multi-Domain Server, for example 192.0.2.50
  • The Multi-Domain Server username and password for a superuser that has permission to create the new Domain Management Server. For example fwadmin and vpn123

To create a new Domain Management Server:

  1. Open a terminal emulation program (such as PuTTY).
  2. Open an SSH connection to the Multi-Domain Server.
  3. Log in with the superuser credentials.
  4. Enter expert mode.
  5. Run these commands.
[Expert@mds]# mdscmd addcustomer Cust_ID -n 
[Expert@mds]# mdscmd addcma Cust_ID -n Cust_CMA -i 192.0.2.61 -t 192.0.2.50 -m 192.0.2.50 -u admin -p vpn123
[Expert@mds]# mdscmd startcma Cust_ID -n Cust_CMA -m 192.0.2.50 -u fwadmin -p vpn123

The Domain Management Server is created. Log in to 192.0.2.61 to configure the settings.

Working with dbedit

Introduction to dbedit

dbedit is a CLI utility that lets you make changes to objects in the Check Point databases. Run dbedit in these modes:

  • Interactive - For a few changes to the database
  • Batch - Import many changes at one time

We recommend that you use batch mode (dbedit -f) for automation scripts. You can write the script on the Security Management Server or Multi-Domain Server with standard Linux commands, or import a text file with the script.

Launching the dbedit Utility

When the dbedit prompt is showing, you can run dbedit commands or scripts. Before you use the dbedit utility, make sure that you can log in to Expert mode on the Security Management Server or Multi-Domain Server.

To launch the dbedit utility:

  1. Log in to the CLI of the Security Management Server or Multi-Domain Server.
  2. Enter Expert mode, run expert

    The Expert prompt is shown.

  3. Run dbedit
  4. Enter the name of the Security Management Server or Multi-Domain Server:
    • For localhost, press Enter
    • For a remote connection, enter the hostname or IP address

    The dbedit prompt is shown.

Please enter a command, -h for help or -q to quit:
dbedit>

Using dbedit Commands in a Script

Use these dbedit commands to create and configure objects and rules:

  • create - Creates the object
  • modify - Changes the applicable object
  • update - Commits the most recent change to the Security Management Server database
  • update_all - Commits all the changes to the Security Management Server database

This table shows sample commands and the results.

Example

Result

create network net-internal

Creates the object for the network net-internal

modify network_objects gateway-10 ipaddr 192.0.2.100

Changes the IP address of the gateway-10 object to 192.0.2.100

update network_objects net-internal

Saves the changes for the net-internal objects and updates the Security Management Server database

Locking the Database

We recommend that you use the -globallock option when you use dbedit to make changes to the Security Management Server database. dbedit partially locks the database, if a user configures objects with SmartDashboard, there can be problems in the database. The -globallock option does not let SmartDashboard or a dbedit user make changes to the database.

When the -globallock option is enabled, dbedit commands run on a copy of the database. After you change the database and run the savedb command, it is saved and committed on the actual database. You can use the savedb command multiple times in a dbedit script.

At the end of a script, it is good practice to run these commands:

update_all
savedb

Showing Parameters for a Sample Object

You can create sample objects in SmartDashboard that have the parameters that you are using in a script or dbedit command. Export these objects to help make sure that you are using the correct names for the parameters. You can show the parameters in plain or XML format.

To show the parameters for a sample SmartDashboard object:

  1. In SmartDashboard, create the object that uses the necessary parameters and settings.
  2. From the dbedit prompt, run one of these commands:
    • print network_objects <object name>
    • printxml network_objects <object name>

Using Automation Scripts

You can use dbedit to configure the initial settings for a Security Gateway and the Security Policy, then update and change the settings when necessary.

Note - Make sure that the script in the text files does not contain blank lines. Otherwise the script will stop with an error.

Initial Configuration

  1. Create a text file with an automation script. The script can create and configure the necessary objects and rules for the Security Policy.
  2. Make a database revision of the management. Use this revision if there is a problem with the script and to identify unauthorized changes to the database.
  3. Run fwm load and install the policy on one or more Security Gateways.

Updating and Changing the Policy

  1. Make sure that the automation administrator changed the database most recently.
    1. Run send_command -s <domain_server> –u <admin> –p <password> –o db_change_since_last_save

      The Last modifier field shows the administrator name.

    2. If a different administrator changed the database, do not continue to use the automation script. A system administrator must do an analysis of the database.
  2. Edit the automation script, create and configure objects and rules for the Security Policy.
  3. Run fwm load and install the policy on one or more Security Gateways.

To update and change the commands for a Domain Management Server:

This sample script installs the Standard policy from Domain Management Server Cust_CMA on the Security Gateway examplegw.

mdsenv Cust_CMA
send_command –s Cust_CMA –u admin –p adminpw –o db_change_since_last_save
dbedit –globallock -s Cust_CMA -u admin -p adminpw -f dbedit_modifypolicy_objects.txt
fwm load Standard examplegw

Create or Modify Policy Objects (Hosts, Networks)

This section shows sample scripts that create one or more new network or service objects. You can combine one or more of these samples into one script file.

We recommend that you add the update_all command to the end of the script file.

Networks

You can use a script to manage database objects that include:

  • Networks
  • Hosts
  • Address Ranges

These are sample scripts that show how to create and configure the database objects.

Creating a Network

Create an object for the database that represents a network. This sample script creates the network net-internal with the IP address 190.0.2.0.

# Create the object (of type network)
create network net-internal
# Configure the network IP address
modify network_objects net-internal ipaddr 192.0.2.0
# Configure the netmask (in dotted decimal notation) of the network
modify network_objects net-internal netmask 255.255.255.0
# Add a comment to describe what the object is for (optional)
modify network_objects net-internal comments "Created by fwadmin with dbedit"

Configuring Automatic NAT

If your network uses NAT (Network Address Translation), you can use dbedit to configure an Automatic NAT rule. Add these lines to a script only for a network that uses Automatic NAT rules.

This sample script creates an Automatic NAT rule for the net-internal network that starts with the IP address 190.0.2.100.

# The next four modify lines are optional and are only needed if you want
# to do an automatic NAT rule for this object.
modify network_objects net-internal add_adtr_rule true
modify network_objects net-internal NAT NAT
# Set the NAT type, adtr_static or adtr_hide 
modify network_objects net-internal NAT:netobj_adtr_method adtr_hide
# Set the "valid" IP address for this object.
# For a static NAT on a network, the assumption is there is a 1-to-1 ratio
# between untranslated and translated addresses and the valid range is
# contiguous. This setting is the first IP address in this range.
modify network_objects net-internal NAT:valid_ipaddr 192.0.2.100

Creating a Host

This sample script creates the host host-10 with the IP address 192.0.2.10.

# Create the actual object (of type host_plain)
create host_plain host-10
# Modify the host IP address
modify network_objects host-10 ipaddr 192.0.2.10
# Add a comment to describe what the object is for (optional)
modify network_objects host-10 comments "Created by fwadmin with dbedit" 

You can also add the lines to this script to configure Automatic NAT for the host. The modify commands for this sample rule starts with: modify network_objects host-10

Creating an Address Range

This sample script creates the address range object addr-range with the IP addresses 192.0.2.150 to 190.0.2.200.

# Create the actual object (of type address_range)
create address_range addr-range
# Modify the first IP address in the range
modify network_objects addr-range ipaddr_first 192.0.2.150
# Modify the last IP address in the range
modify network_objects addr-range ipaddr_last 192.0.2.200
# Add a comment to describe what the object is for (optional)
modify network_objects addr-range comments "Created by fwadmin with dbedit"

You can also add the lines to this script to configure Automatic NAT for the address range object. The modify commands for this sample rule starts with: modify network_objects addr-range

Renaming and Deleting Objects

You can change the name of an object or delete it from the database. When you change the name of an object the Security Policy is also updated with the new name.

# Rename the network object addr-range to IPv4-range
rename network_objects addr-range IPv4-range 

When you delete an object, the references to it are also deleted from the Rule Base. The delete command fails if there is a different object that is dependent on it.

# Delete the network object addr-range
delete network_objects addr-range 

Network Groups

You can create and use a group object as a container for network and host objects.

Creating a Network Group

Create a network group that uses networks and hosts. Make sure that these objects are in the management database before you create a network group.

This sample script creates the object host-group for the hosts host-100 and host-101.

# Create a group object
create network_object_group host-group
# Add the individual elements to the group
addelement network_objects host-group '' network_objects:host-100
addelement network_objects host-group '' network_objects:host-101

Configuring and Deleting a Network Group

You can remove a network or host from a network group. This sample script removes host-100 from host-group.

 # Remove individual elements from the group
rmelement network_objects host-group '' network_objects:host-100

You can rename or remove a network group almost the same as objects.

 # Rename the network object host-group to host-ipaddrs
Rename network_objects host-group host-ipaddrs
# Delete the network object host-ipaddrs
delete network_objects host-ipaddrs

Services

Services are objects that are used for network protocols.

Creating a Service

This sample script creates these services:

  • tcp_8081 - TCP protocol port 8081
  • udp_8082 - UDP protocol port 8082
  • inspect_svc - Inspect SVC protocol 6 and with an optional feature that uses the INSPECT expression
# Create a TCP service 
create tcp_service tcp_8081
# Set port 8081 for TCP service
modify services tcp_8081 port 8081
# Create a UDP service
create udp_service udp_8082
# Set port 8082 for UDP service 
modify services udp_8082 port 8082
# Create a service of type "other." This can be used for random IP protocols
# as well as services that require more complex INSPECT code for matching.
#
# Create the service of type other
create other_service inspect_svc
# Modify the IP Protocol that matches the service
modify services inspect_svc protocol 6
# (Optional) Modify the INSPECT expression that matches this service.
modify services inspect_svc exp "dport=123”

Renaming and Deleting a Service

You can rename or remove a service almost the same as objects.

# Rename inspect_svc to inspect_tcp123
rename services inspect_svc inspect_tcp123
# Delete the network object inspect_tcp123
delete services inspect_tcp123

Service Groups

You can create and use a group object as a container for service objects.

Creating a Service Group

Create a service group for more than one service. Make sure that the service objects are in the management database before you create a service group.

This sample script creates the object mysvc-group for the services SSH and HTTPS.

# Create a group object
create service_group mysvc-group
# Add the individual elements to the group
addelement services mysvc-group '' services:ssh
addelement services mysvc-group '' services:https

Configuring and Deleting a Service Group

You can remove a network or host from a network group. This sample script removes the SSH service from mysvc-group.

# Remove individual elements from the group
rmelement services mysvc-group '' services:ssh

You can rename or remove a network group almost the same as objects.

# Rename the service group mysvc-group to myservices
rename services mysvc-group myservices
# Delete the network object my services
delete services myservices

Object Naming Restrictions

These are some of the restrictions for object names:

  • Objects names can contain only ASCII letters, numbers, and dashes. Other characters such as a plus sign, asterisk, parenthesis, square brackets, and so on, are not supported.
  • Object names can have a maximum of 100 characters.
  • You cannot use reserved words for objects names and they include words that are policy elements. For example, names of colors, common networks terms (ipv6, nets, routers, servers, and so on).

To see a full list of the naming restrictions, go to sk40179.

Changing a Rule Base

This section shows sample scripts that change the Policy on a Domain Management Server named Standard. We recommend that you write the scripts in a text file and then you import the file to dbedit.

Adding a Rule - End of Rule Base

When you use dbedit to add a rule, it is automatically added to the end of the Rule Base. Then run commands that configure the different fields of the new rule.

Note - Rules in SmartDashboard start with rule number 1. Rules in dbedit start with rule number 0.

This sample script adds this rule to the end of the Rule Base:

Source

Destination

Service

Action

Any

Any

Any

Accept

#
# Add any any accept rule
#
addelement fw_policies ##Standard rule security_rule
modify fw_policies ##Standard rule:0:comments "Any any accept"
modify fw_policies ##Standard rule:0:disabled false
rmbyindex fw_policies ##Standard rule:0:track 0
addelement fw_policies ##Standard rule:0:track tracks:None
addelement fw_policies ##Standard rule:0:time globals:Any
addelement fw_policies ##Standard rule:0:install:'' globals:Any
rmbyindex fw_policies ##Standard rule:0:action 0
addelement fw_policies ##Standard rule:0:action accept_action:accept
addelement fw_policies ##Standard rule:0:src:'' globals:Any
modify fw_policies ##Standard rule:0:src:op ''
addelement fw_policies ##Standard rule:0:dst:'' globals:Any
modify fw_policies ##Standard rule:0:dst:op ''
addelement fw_policies ##Standard rule:0:services:'' globals:Any
modify fw_policies ##Standard rule:0:services:op ''

Changing a Rule

This sample script changes this rule:

 

Source

Destination

Service

Action

Original rule 4

Any

Any

Any

Accept

New rule 4

Any

DMZ

SSH

Accept

#
# Modify Rule 4 
# Previous rule was any any any accept, it will now be any dmz ssh accept
#
modify fw_policies ##Standard rule:3:comments "Allow SSH to firewall with logging"
modify fw_policies ##Standard rule:3:disabled false
rmbyindex fw_policies ##Standard rule:3:track 0
addelement fw_policies ##Standard rule:3:track tracks:Log
rmbyindex fw_policies ##Standard rule:3:action 0
addelement fw_policies ##Standard rule:3:action accept_action:accept
rmelement fw_policies ##Standard rule:3:src:'' globals:Any
addelement fw_policies ##Standard rule:3:src:'' globals:Any
modify fw_policies ##Standard rule:3:src:op ''
rmelement fw_policies ##Standard rule:3:dst:'' globals:Any
addelement fw_policies ##Standard rule:3:dst:'' network_objects:DMZ
modify fw_policies ##Standard rule:3:dst:op ''
rmelement fw_policies ##Standard rule:3:services:'' globals:Any
addelement fw_policies ##Standard rule:3:services:'' services:ssh
modify fw_policies ##Standard rule:3:services:op ''

Adding a Rule - Middle of Rule Base

When it is necessary to add a rule to the middle of a Rule Base, you cannot use dbedit to simply insert a rule.

  1. Delete all the rules that are after the new rule you are adding.
  2. Create one or more new rules.
  3. Add again the rules that you deleted in step 1.

This sample script adds a new rule number 2 in a Rule Base that has three rules.

Note - Rules in SmartDashboard start with rule number 1. Rules in dbedit start with rule number 0.

#
# Delete rule 2 and 3 (delete in reverse order)
#
rmbyindex fw_policies ##Standard rule 2
rmbyindex fw_policies ##Standard rule 1
#
# Add new rule 2
#
addelement fw_policies ##Standard rule security_rule
modify fw_policies ##Standard rule:1:comments "Firewall stealth rule"
modify fw_policies ##Standard rule:1:disabled false
rmbyindex fw_policies ##Standard rule:1:track 0
addelement fw_policies ##Standard rule:1:track tracks:Log
addelement fw_policies ##Standard rule:1:time globals:Any
addelement fw_policies ##Standard rule:1:install:'' globals:Any
rmbyindex fw_policies ##Standard rule:1:action 0
addelement fw_policies ##Standard rule:1:action drop_action:drop
addelement fw_policies ##Standard rule:1:src:'' network_objects:net-internal
modify fw_policies ##Standard rule:1:src:op 'not in'
addelement fw_policies ##Standard rule:1:dst:'' globals:Any
modify fw_policies ##Standard rule:1:dst:op ''
addelement fw_policies ##Standard rule:1:services:'' globals:Any
modify fw_policies ##Standard rule:1:services:op ''
#
# Add New Rule 3 (Old Rule 2)
#
addelement fw_policies ##Standard rule security_rule
modify fw_policies ##Standard rule:2:comments "Allow selected hosts outbound"
modify fw_policies ##Standard rule:2:disabled false
rmbyindex fw_policies ##Standard rule:2:track 0
addelement fw_policies ##Standard rule:2:track tracks:Log
addelement fw_policies ##Standard rule:2:time globals:Any
addelement fw_policies ##Standard rule:2:install:'' globals:Any
rmbyindex fw_policies ##Standard rule:2:action 0
addelement fw_policies ##Standard rule:2:action accept_action:accept
addelement fw_policies ##Standard rule:2:src:'' network_objects:flamer-100
addelement fw_policies ##Standard rule:2:src:'' network_objects:flamer-101
modify fw_policies ##Standard rule:2:src:op ''
addelement fw_policies ##Standard rule:2:dst:'' network_objects:net-internal
modify fw_policies ##Standard rule:2:dst:op 'not in'
addelement fw_policies ##Standard rule:2:services:'' globals:Any
modify fw_policies ##Standard rule:2:services:op ''
#
# Add New Rule 4 (Old Rule 3)
#
addelement fw_policies ##MyPolicy rule security_rule
modify fw_policies ##MyPolicy rule:3:comments "Drop all"
modify fw_policies ##MyPolicy rule:3:disabled false
rmbyindex fw_policies ##MyPolicy rule:3:track 0
addelement fw_policies ##MyPolicy rule:3:track tracks:Log
addelement fw_policies ##MyPolicy rule:3:time globals:Any
addelement fw_policies ##MyPolicy rule:3:install:'' globals:Any
rmbyindex fw_policies ##MyPolicy rule:3:action 0
addelement fw_policies ##MyPolicy rule:3:action drop_action:drop
addelement fw_policies ##MyPolicy rule:3:src:'' globals:Any
modify fw_policies ##MyPolicy rule:3:src:op ''
addelement fw_policies ##MyPolicy rule:3:dst:'' globals:Any
modify fw_policies ##MyPolicy rule:3:dst:op ''
addelement fw_policies ##MyPolicy rule:3:services:'' globals:Any
modify fw_policies ##MyPolicy rule:3:services:op ''

Pushing the Security Policy to Security Gateways

After you change or update the Security policy, you can use fwm load command to push the configuration to the Security Gateways. This command validates the policy and makes sure that rules agree with each other.

In this example, the fwm load command successfully pushes the policy (Standard) to the Security Gateway (samplegw).

[Expert@mds]# fwm load Standard samplegw
Installing policy on R77 compatible targets:
Standard.W: Security Policy Script generated into CustomerPolicy.pf
Standard:
Compiled OK.
Installing Security Gateway policy on: examplegw ...
Security Gateway policy installed successfully on examplegw...
Security Gateway policy installation complete
Security Gateway policy installation succeeded for:
examplegw

If the policy did not install successfully, the output of the fwm load command shows an error message. The Security Gateway continues to enforce the policy that was installed before you ran the script.

Installing Policy with a Multi-Domain Server

To install the policy for a Domain Management Server, run the necessary Multi-Domain Server CLI commands. You can run them individually or as part of a script.

This sample script installs the Standard policy from Domain Management Server Cust_CMA on the Security Gateway examplegw.

[Expert@mds]# mdsenv Cust_CMA
[Expert@mds]# dbedit –globallock -s Cust_CMA -u admin -p adminpw -f dbedit_createpolicy_objects.txt
[Expert@mds]# fwm load Standard examplegw

Error Codes in dbedit

  • If there is a syntax error in the dbedit script, this error is shown:

    “syntax error in line 1 Aborting.”

    The script stops running at the error.

  • When a script uses tables or objects that are not in the database, dbedit stops the script and shows this message:

    “Object Not Found”

    “Error in line: 2”

  • You can use the parameter ignore_script_failure to continue running the script and ignore errors
  • You can use the parameter continue_updating to ignore errors and run the update_all command at the end of the script

Using XML to Export Settings for a Domain Management Server

You can export the settings for a Domain Management Server to an XML file that you can use with external automation systems. You can include the printxml commands in a script or run them individually from the CLI.

This sample script exports these settings to XML:

  • Security policy Rule Base
  • Network objects
  • Services
printxml fw_policies ##Standard
printxml network_objects
printxml services 



						

						
					
 
Top of Page ©2014 Check Point Software Technologies Ltd. All rights reserved. Download Complete PDF Send Feedback Print