In this series of posts, we have examined some of the challenges involved in migrating firewall configurations between different firewall platforms and discuss some strategies for approaching these issues.  The first post introduced the basic firewall configuration elements that have to be migrated and discussed some of the issues in converting routing table entries, and network and service objects.  The second post examined some of the issues involved in migrating ACL or filtering rules.  The third post discussed the challenges of migrating network address translation (NAT) rules.  In this post, we will examine the issue of validating the migrated policy in the target firewall.

Validation

Once the source firewall configuration has been migrated to the target, you will want to validate that the conversion has been done correctly.  There are two aspects to this process.  The first is to ensure that all elements in the source configuration have been accurately and completely transferred to the target.  This is typically done by a object-by-object and rule-by-rule comparison of the two configurations.  Each object definition and rule in the source is traced to the corresponding object definition and rule in the target.  In many cases, this is not actually a one-to-one correspondence because architectural differences between platforms may force one source object or rule to be decomposed into multiple objects or rules in the target.  This is particularly a challenge when tracing the conversion of NAT rules.

The second aspect of validation is to verify that the policies in the target firewall are functionally equivalent to those of in the source.  This means analyzing the traffic flows across each pair of ingress and egress interfaces in the source firewall and comparing it to the traffic flows across the corresponding interface pair in the target.  Calculating the traffic flows involves determining what traffic is allowed/denied for all possible sources, destinations, and services and must take into account the combined effects of the reachable networks for each interface, filtering from security rules, address translations, and routing table entries.  Performing this kind of analysis manually is feasible only for some small number of critical connections; performing a full traffic comparison analysis for the entire configuration is only possible using automated tools.

Athena FirePAC provides a Firewall Migration module that can perform automated traffic flow comparison between configurations from different firewall vendors.  This can be used to validate migrated configurations and to find all packets that are being dropped or added in the new target configuration. The comparison report also provides a list of all added and deleted traffic flows along with the rules that allow and deny the traffic on both the sides.  Not only is it very useful for validating policy equivalence between migrated configurations, but it will also identify the specific rules responsible for deviations in the target firewall.

FirePAC now also provides a fully automated process for migrating Cisco configurations to Check Point firewalls.  This capability addresses many of the limitations in the Confwiz migration tool provided by Check Point.  Specifically:

1. Identifies global rules in the Cisco firewall configuration (generated from CSM) and ignores them when generating rules on the Check Point side.
2. Uses the routing rules to perform network reachability and generates the interface reachable network objects correctly and fixes zone spanning objects when generating acl rules.
3. Generates flat basic objects instead of group objects with one member for basic objects defined in CSM and converted as an object group in the Cisco configuration.
4. Fixes the limitations in ConfWiz ACL generation like protocol object groups, tcp-udp service object groups, acl rules with source ports, non classic subnet masks such as 255.255.255.192,  port operators like ne, neq etc.,
5. Reuses all predefined and user defined service objects on the Check Point management server when generating objects.
6. Flexibility to specify the customer desired object naming conventions for naming the generated network and service object groups and renaming existing objects. ConfWiz uses fixed naming conventions with a mandatory prefix that the users need to fix manually later on.
7. Aggregates the expanded ACEs back to the aggregated form as specified in CSM when converting configuration of a Cisco firewall that is managed by CSM.
8. Generates the NAT rules accurately and in the correct order as evaluated by Cisco firewall irrespective of the order of NAT statements in the configuration. Generates all possible Twice NAT rules from Static Source and Static Destination NAT, Dynamic NAT and Static Destination NAT, Policy NAT and Static Destination NAT, NAT 0 and Static destination NAT etc., Identity NAT statements will not be generated only if other NAT rules that follow them do not overlap with them.
9. Optimizes the generated NAT rules by removing redundant NAT rules and NAT rules whose effective rule portion is covered by any of the ACL rules and hence would never be triggered. This optimization removes a significant number of Twice NAT rules and irrelevant nat rules formed from bidirectional static nat statements.
10. Uses Excel format to display the generated rules and objects and uses this excel document to deploy the rules and objects to the Check Point management server using CPMI interface. Users can very easily review this Excel and modify this excel to make desired changes before pushing the configuration to the Check Point management server.
11. Performs an offline gap analysis on the original and the converted configurations using nat, acl and routing rules on adds rules to fix the gaps.
12. Generates a validation report to identify all traffic flows (IP packets) that were added or dropped along with the responsible acl, nat and route rules in both the source and target configurations.
13. When the converted configuration is ready for deployment to production, it compares the objects on the production and the staging management server and flags all conflicts in an excel document with the conflicts merged. These conflicts are then pushed to the production server if desired or the users can manually resolve them using the excel report. This feature addresses major work flow issues with merging the changes that keep happening in production systems while the engineers work on the migration.

If you are engaged in or planning a Cisco to Check Point migration project and would like to evaluate this new capability in FirePAC, please contact sales@athenasecurity.net.

Tags: Check Point, cisco, firewall configuration migration, Juniper Netscreen, validation

This entry was posted on Tuesday, October 4th, 2011 at 11:55 am and is filed under Athena Insights, Firewall Tips. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.