GoSecure has conducted several network security migration projects in the past years, gathering technical experience on top Next-Generation Firewall (NGFW) products. These projects not only required deep knowledge of two separate products (the source and the destination) but also the ability to build tools and automate tasks. Unfortunately, tools released by vendors are either limited, not flexible enough or simply hard to find.

Today, GoSecure wish to contribute to the Open Source community by releasing under the GPLv3 license a useful tool used during Cisco to Checkpoint firewall migration, the Cisco2Checkpoint converter.



Cisco2Checkpoint can be found on GitHub.

git clone --recursive c2c

Instructions can be found on the GitHub page.


How does it work?

The tool imports a Cisco ASA or IOS running-config file and converts it to a file that can be parsed by dbedit, a tool provided by Checkpoint to automate tasks. The converter supports objects including:

Checkpoint objects Cisco syntax
hosts/networks/ranges “object network”
services “object service”
hosts/networks/ranges groups “object-group network”
service groups “object-group service”
firewall rules “ip access-list”, “access-list”


For instance, be the host definition below from an ASA config file:

object network myHost
 description someone's VM in lab


The following text block will be produced by the script. Color can be customized with an additional argument.

create host_plain myHost
modify network_objects myHost ipaddr
modify network_objects myHost comments "someone's VM in lab"
modify network_objects myHost color "black"
update network_objects myHost

A security analyst then uses dbedit to import the data.


Real-life example

The true power of this tool comes to life on huge policies. The extract below is a summary of one of the biggest policy that was converted by the tool.

# Number of hosts (imported from cisco file): 149
# Number of hosts (imported from checkpoint xml): 0
# Number of hosts (dynamically created): 168
# Number of hosts (after merge/cleanup): 0
# Number of subnet (imported from cisco file): 63
# Number of subnet (imported from checkpoint xml): 0
# Number of subnet (dynamically created): 36
# Number of subnet (after merge/cleanup): 0
# Number of acl rules (not imported: established): 52
# Number of acl rules (not imported: source port): 276
# Number of acl rules (before merge/cleanup): 2012
# Number of acl rules (after merge/cleanup): 746
# Number of single ports (imported from cisco file): 307
# Number of single ports (imported from checkpoint xml): 0
# Number of single ports (dynamically created): 27
# Number of port range (imported from cisco file): 0
# Number of port range (imported from checkpoint xml): 0
# Number of port range (dynamically created): 21

Dynamic Object Creation

An important difference between Cisco and Checkpoint is that Checkpoint requires anything to be an object. For example, an IP address must be defined through a host object to be used in a group while Cisco doesn’t need an explicit definition.

In this project, 149 hosts were defined in the Cisco file but 168 new hosts needed to be created on the fly because they were referenced by a group or an access-list.


Prevent Inconsistencies

The script identified 52 access-list with the statement “established” and 276 access-list with the use of source port, which shows an old way to configure a firewall. It is rare to need a source port in the rule of a NGFW. For this reason, the script excluded these rules from the import and a security analyst took care of them.

This cleanup leads to an improvement of the customer’s policy. In fact, those rules were potentially allowing unwanted access in the environment.


Firewall Rationalization

Finally, the most time-saving feature of the tool is the firewall rules rationalization. In the current example, the tool merged 2012 access-list into 746 firewall rules, keeping almost only 30% of the initial access-list while keeping the same level of security.

The number of rules in a firewall policy has an important effect on its management. A clean policy reduces the time required to make a change. It also makes the policy much easier to understand, reducing risks of errors during a change.



This piece of code aims to help firewall administrators by saving time and performing security improvements early when migrating to a new Checkpoint firewall. Hopefully, it will be useful to some of you.

Détection et réponse gérées Titan
Antivirus de nouvelle génération
Détection et réponse sur les terminaux
Détection et réponse sur le réseau
Détection et réponse sur les boîtes de messagerie
Détection et réponse face aux menaces internes
Gestion des pare-feu
Gestion des SIEM
La gestion des vulnérabilités en tant que service
GoSecure Titan
Logiciel Titan
Sécurité de la messagerie
Sécurité Web
Boîte à outils «Responder PRO Forensics»
Services professionnels
Services de préparation aux brèches
Les services-conseils personnalisés en cybersécurité
Évaluation de la cybersécurité
Services de réponse aux incidents
Services des équipes « Red & Purple »
Services de tests d'intrusion
Services de conformité et d'audit
Évaluation de la compromission de la sécurité
Technologies tierces

Pin It on Pinterest

Share This