Sergey Nivens - Fotolia
Many organizations stick with the same firewall vendor because migrating the configuration from one vendor to another can be a daunting task. Automation can accelerate the process, enabling organizations to remove unused rules and turn a tedious, error-prone process into a shorter and reliable migration that improves overall network security.
This article describes an example of when we at NetCraftsmen helped one of our customers make the transition from one firewall vendor to another using automation. The exact firewall models are unimportant, but the number of firewalls was much larger than we wanted to handle manually.
What to migrate?
When it comes to firewall migration, do you migrate every object and rule, or do you try to clean up the rule sets as you go? If you make changes, there is a high probability you will make mistakes that result in application failures or insufficient security, where you block too much or don't block enough, respectively.
The least disruptive mechanism involves converting rules from one vendor's configuration to another vendor's configuration while applying some simple heuristics to identify orphaned objects.
The manual process
In our example, the on-site deployment team was slowly working through a manual conversion process. The source firewall rules operated on the IP tuple: source port, source address, destination port, destination address and protocol ID. They didn't care about the ingress interface or the egress interface.
The destination firewall, however, needed to specify the ingress and egress interfaces, which greatly complicates the task of converting firewall rules. The result was a tedious process. Fortunately, the deployment team's manual work identified the steps of a repeatable process, which led us to investigate an automation approach.
Migrating the firewall configurations
The first step for the automation process was to extract the objects, rules and interface information from the source firewall. We decided to import the extracted information into Excel spreadsheets so data items could be identified by spreadsheet column. While the conversion to Excel was a manual process, we only needed to do it once and finished relatively quickly.
We wrote the conversion system in Python, using the OpenPyXL Excel manipulation library. The result was a series of scripts that implemented three major steps, each of which did a part of the conversion:
- Step through all objects -- host, network, service or group -- and associate each one to an IP address or address range. This included multiple scripts, one for each object type.
- For each object and IP address pair, determine its associated firewall interface.
- Analyze each security policy, determine its direction and convert to the destination firewall configuration format.
A significant amount of effort went into handling exceptions. We declared any objects that didn't have interfaces associated with them as dead objects and wrote their information to a separate file. In other cases, the source firewall objects included references to what should have been multiple objects. We handled these by creating new objects or writing the object information to the dead objects file.
Big automation wins
The scripts were a big win. It was easily a 20-to-1 ratio of manual effort versus running the script. Even with automation, though, we had to validate the resulting configuration in the destination firewall to make sure it was doing what it was supposed to do. For example, we identified failures in the first few conversions where an object had to be broken into multiple objects. These failures became less frequent as we found them and incorporated changes in the scripts to automatically handle them. We now have the knowledge and basic system to streamline the firewall migration for the customer's remaining firewalls.
The second win was the improvement in overall network security. The new firewall rules identified ingress and egress interfaces, improving security, and eliminating hundreds of dead objects made the new firewalls more efficient. Finally, the separation of incompatible objects into separate objects and rules greatly simplified the rules. The security team now has fewer objects to manage, and the remaining objects are more consistent and use simpler rules.