Restructuring existing networks that are protected by firewalls often involves isolating and migrating existing firewall policy. This exercise will throw you in the doldrums and require a high degree of precision. Using the addresses of the networks that are affected by the restructuring, engineers have to go through each rule and object group and check if they are relevant to the restructuring being performed. Some rules and objects might be broader, and they need to be narrowed to the networks being restructured when migrating. Engineers also need to identify and resolve any conflicts that exist with the rules being migrated in the target firewall.

This tedium is easily avoided with the features available in firewall analytics solution Athena FirePAC from Athena Security.

1. You can import the firewall configurations and work offline without taxing the production firewalls.
2. You can filter rules and objects in the firewall using name wild cards, IP address ranges and subnets and ports, security zones and interfaces on which the rules are applied. This filtering capability is essential to isolate the required rules and objects
3. You can view object definitions and the complete membership hierarchy of object groups in place in the filtered rule and object views. This is essential to understand very quickly if the rule or the object is broader than what is required, and to narrow the rule to handle only the networks that are being restructured.
4. You can view the rules and objects in an easy to read tabular format along with the CLI statements as an additional column. This is a powerful feature in FirePAC allowing both technical and non-technical users do their job. You can copy specific columns from specific rows in the filtered results and paste them into a text file. This copy and paste feature is essential to create a script with the CLI strings.
5. You can generate an Excel report containing the filtered rule or object results. This is useful for communicating with all the stake holders, both technical and non technical.

Let’s look at an example to demonstrate how FirePAC was used to segregate the traffic from the 172.120.0.0/16 subnet coming into the outside interface of a PIX firewall into another new interface on the same firewall. Previously this traffic was combined with other network traffic including public traffic. It took more than two weeks of painful work for a customer to complete a similar project. With FirePAC, it takes a few days to complete this work allowing the engineers to spend their valuable time on more important work.

ACL rules: For isolating the ACL rules that use addresses in the 172.120.0.0/16 subnet, you need to filter the ACL rules using 172.120.0.0/16 subnet in the source address filter field and outside interface as the entering interface. You can then copy and paste the CLI string column into a script. In this particular case, ACL rules with 172.120..0.0/16  as destination might be defined on other interfaces in the ingress direction but we do not need to migrate them.

NAT rules: For isolating the NAT rules, you need to perform filtering twice. First find all NAT rules that use addresses in the 172.120.0.0/16 as either original or translated source. Then you need to find all NAT rules that use addresses in the 172.120.0.0/16 as either original or translated destination. You can then copy and paste the CLI string column into a script.

FirePAC shows you the original and translated source, destination and service values in a NAT rules that are created and all the CLI statements that combine to form that rule. As a result, the NAT rule browsing and filtering available in FirePAC is indispensable for understanding and isolating address translations for Cisco firewall users. Even the most experienced Cisco firewall engineers get tripped up by the complex NAT syntax and the number of NAT variations. Imagine a policy nat rule created from a combination of global, nat and access-list statements that appear in different places in the configuration or static NAT policy rule created from static and access-list statements.

Object Groups: For isolating the object groups that use addresses in the 172.120.0.0/16 subnet, you can use the 172.120.* in the IP address filter field.

Generate a report: You can generate an excel report for the filtered results for ACL rules, NAT rules and Objects and use it to communicate to all the stakeholders, technical and non technical.

Please note that the features that are described here can be employed to solve any firewall operations and compliance problem where rules need to be isolated based on some criteria and a report needs to be generated from those isolated rules to communicate with appropriate stake holders. Our customers rely on it heavily when performing projects such as:

• Segregating existing business critical assets to provide better security
• Moving a data center or other critical business assets to a different location
• Consolidating firewalls and other network infrastructure to simply network traffic flow and management
• Segmenting traffic flow based on the type of traffic to provide better quality of service

In all these cases, existing policies for portions of the affected traffic need to be understood, isolated and migrated appropriately.

Tags: Athena FirePAC, firewall rules, network restructuring

This entry was posted on Friday, October 15th, 2010 at 8:59 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.