In this series of posts, we examine some of the challenges involved in migrating firewall configurations between different firewall platforms and discuss some strategies for approaching these issues.  The previous 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.  In this post, we investigate converting security rules.

Converting Security Rules

The basic elements of a security rule (sometimes called ACLs or filtering rules) are defined similarly in all firewall platforms.  Each rule specifies a set of source addresses, a set of destination addresses, and a set of services that are matched against an incoming network data packet, and an action to take: typically to allow or deny the matching packets.

The syntax of these rules is quite different across different firewall platforms as are the mechanisms for grouping rules to provide higher-level abstractions and partitioning rules for better management of rule bases.

Some firewall platforms, such as Cisco security appliances, allow only a single network or service object value for source, destination, and service elements.  The Cisco Security Manager (CSM) management console allows you to specify multiple values per element in a rule, but when the configuration is installed on a target firewall, the rules are expanded to have only one value per element.  Other firewalls, like Check Point and Juniper Netscreen, allow multiple values per element to allow for an aggregated and smaller rule base.

In Check Point firewalls, all rules are grouped into a single, flat rule base.  This entire rule base is evaluated for each packet entering the firewall, regardless of entering or exiting interface.  Thus it is not possible to organize the rules to take advantage of the network structure based on the set of network address ranges reachable from each interface.  In Cisco firewalls, security rules are organized into access groups that are assigned to one or more interfaces to be evaluated for packets either entering or exiting through that interface.  In Juniper Netscreen firewalls, interfaces that have networks behind them with similar security posture can be grouped into security zones.  Rules are defined by packets entering and exiting through the source and destination zone.

These different ways of organizing and grouping rules pose the biggest challenge in converting the security rules from one platform to another.  It is necessary to understand which networks are reachable from each interface or security zone and then partition the rules accordingly.  This can get interesting when converting rules using zone-spanning objects on a firewall with a flat architecture to an architecture that requires the rules to be partitioned by interface or zone.

Because of these different approaches to grouping of rules, the impact of using “Any” values in source and destination elements is varies across different firewall platforms.  When “Any” is used as Source or destination in a Check Point configuration, it means any address that is reachable from any interface.  However when “Any” is used as a source in a filtering rule on a Cisco firewall, it means only the networks that are reachable from the interface(s) that the rules are applied to.  Similarly in a Netscreen firewall, when “Any” is used as a source or destination value in a filtering rule, it really means only the networks that are reachable from the interfaces belonging to the source or destination security zones.

Zone-spanning objects pose a similar issue.  In a Cisco or Juniper firewall, only the addresses reachable from the relevant interface or security zone are allowed or denied by the filtering rules, even if a zone spanning object is used.  When converting such rules to a flat rule base, as in Check Point, the zone spanning object will have to be divided so as to specify only the reachable networks for the correct interface.

In general, when converting rules from a firewall platform where rules have higher level of grouping to a platform with lesser level of grouping or no grouping, “Any” values or zone spanning objects need to be resolved with networks that are actually reachable from interface(s) in the target firewall.  When converting rules from a firewall platform with flat or lower level of grouping to a higher level of grouping, source networks and destination addresses in each rule have to be analyzed to find the proper interface or security zone through which the networks are actually reachable and place them in the proper ruleset.

In the next blog post, we will examine some of the issues involved in migrating network address translation (NAT) rules.

Migrating a firewall configuration is the process of converting the configuration from one vendor’s platform to another vendor’s platform in such a way that the original firewall policies are preserved on the target firewall.  In this series of posts, we will examine the some of the challenges involved in such migrations involving Cisco, Juniper, and Check Point firewalls and discuss some strategies for approaching these issues.

All firewall vendors provide essentially the same basic firewall capabilities that are required to control the traffic entering and exiting their corporate network. The following elements make up the bulk of a firewall configuration:

• Interfaces through which the traffic which enter and exit the firewall and optionally security zones to group interfaces with common network availability and security posture.
• Routing rules to route packets through specific interface(s) based on destination and source addresses.
• Network and service objects and groups to define address and service elements and use them in the filtering and address translation rules for better maintenance of the firewall rule base,
• Filtering rules to control traffic entering the device based on Source, Destination and Service of an IP packet.
• Address translation rules to translate virtual ip addresses to real ip addresses and vice-versa,

To get a working baseline configuration for the target firewall platform, all of the above essential configuration elements have to be translated from the original firewall configuration to the target firewall platform.  This simple-sounding task is made very difficult by the myriad of architectural differences and incompatibilities between different vendors’ products.  Some firewall platforms group all security rules into a single flat rule base and evaluate those rules for all packets entering the firewall, regardless of entering interface.  Others provide capabilities to group rules into one or more rule sets and apply them either by specific ingress and egress interfaces or security zones. Similarly, even though the semantics of the address translation rules are the same, the syntax used for creating these rules is quite different in across the various platforms.  These differences pose significant challenges when converting these rules, whether manually or automatically.  Many vendors provide tools for performing these conversions, but all of them have major shortcomings because of these architectural differences.

Network Interfaces and Routing Rules

In this discussion of migration, we will assume that a drop-in replacement of one firewall for another is being done.  This means that there are no changes being made to the structure of the network itself.  This assumption implies that there is a one-to-one mapping of network interfaces from the original firewall to the target and that the target will be connected to the same networks as the original.  This also implies that the routing table will carry over directly from the original to the target.  The routing table is used to identify the networks that are reachable from each network interface.  It is sometimes useful to create network object groups that identify these reachable networks for each interface in the target.  For example, when migrating from a Cisco device to a Check Point firewall, it is necessary to replace “Any” used in filtering rules with network objects that specify the reachable networks for the interface that the filtering rule was applied to.

The syntax and semantics of the routing rules are similar across different firewall platforms, so converting routing tables is essentially a syntax conversion.  The most common type of routes on firewalls are static routes and converting these is very straight-forward.  If dynamic routing is used, it will be necessary to verify that the routes are learned properly on the target firewall.  If the network should change during the migration process, then it will be necessary to update the network object groups created to specify the reachable networks to match any changes in routes.

For appliance firewalls such as Cisco or Juniper devices, the routing rules are part of the firewall configuration.  For Check Point firewalls, the routing rules have to be configured using the native operating system syntax provided for configuring the routing instead of via the management server.

Converting Networks and Service Objects

Network and service objects and object groups provide an abstraction for better management of the firewall rule base. Using objects, you can reuse address and service values in multiple rules.  When making changes, you need modify the values only once in the object definition and it will apply to all rules that refer to the object. By using object groups, you can group network and service objects that serve a common purpose and reuse them in multiple rules and rule bases. When a management server is used, global object definitions can be shared across multiple firewall configurations.

Converting object definitions from one firewall platform to another is fairly easy.  This is largely a matter of converting the source syntax to the target syntax.  The challenge is in reusing existing object groups and detecting conflicts when the target firewalls are managed using a management server that shares global objects between multiple firewalls.

In such environments, it is not sufficient to simply convert the object definitions.  Objects with same content but different names and objects with the same name but different content might already exist in the target management server.  In addition to identifying potential conflicts with existing objects, we might also want to reuse  existing objects where the content is the same.  This requires that we identify the congruent object definitions in the target management server and replace the corresponding object references from the source configuration with references to objects in the management server.

This becomes a significant process issue when migrated configurations are developed in a staging environment and then have to be pushed to production systems.  It is typically not realistic to freeze the production systems for the duration of the entire migration process.  Even if a snapshots are taken at the start of the migration process, the production system is likely to change while the migrations are being worked on.  When the migration is complete, there may still be conflicts between the migrated and production object definitions that must be identified and resolved.

In the next blog post, we will examine some of the issues involved in migrating ACL or filtering rules.