Today we announced the release of a cool new Athena FirePAC solution focused on debugging configurations for enterprise firewalls.  The Firewall Configuration Debugger allows you to troubleshoot service availability problems in an offline mode, using FirePAC’s traffic flow query capabilities.  The advantage of offline analysis is that it does not require you to enable logging or to inject test packets into your network to understand your firewall’s behavior.  When a service disruption occurs, and a quick answer is required to rule out the firewall as the cause or to isolate an actual problem in the rules, the Debugger is a fast, thorough and convenient way to get the job done.

The Debugger allows you to specify individual packets or entire subnets as source and destination addresses and the services to test.  It performs a reachability analysis using the routing rules and address translations to automatically determine the ingress or egress access lists or zone to zone policies, and evaluates how they act on the user’s input.  This traffic flow analysis makes it easy to troubleshoot rules as well as the packets that they allow or deny, so answers can be found in minutes, rather than hours when using ad-hoc testing.  When trying to identify what changes in the configuration may be responsible for the service availability problem, the Debugger can compare two versions and link each rule and object change to its impact on added or deleted traffic flows.  With the introduction of the Debugger, Athena applies its advanced analytics, that traditionally served the audit market and project-based requirements, and provides a tool that is highly useful to operations groups.

For more detailed information, watch my video about the Debugger.  Or request an evaluation from our excellent sales team.

Although the 8.3 release of Cisco ASA contains many new firewall features, there are two significant changes that network engineers should be aware of. The first is the way NAT commands are specified; NAT configuration is now easier and flexible. This is a long overdue change and makes it significantly easier to maintain NAT policy containing hundreds of NAT rules. The second, moves the firewall engineers towards using real untranslated addresses in the filtering ACEs instead of addresses (mapped or real) as seen in the IP packets appearing at the ingress and egress interfaces of the firewall. This approach avoids the need to modify the filtering ACEs when there is a change in the mapped addresses.

For example,

static (dmz, outside) 12.12.12.12 192.168.1.12 netmask 255.255.255.255
access-list acl_outside extended permit tcp any host 12.12.12.12 eq https
is specified in ASA 8.3 as
object network website
     host 192.168.1.12
     nat (dmz, outside) static 12.12.12.12
access-list acl_outside extended permit tcp any host 192.168.1.12 eq https

The firewall engineers are usually more familiar with the real IP addresses, handling change requests that come in to the network engineers often require figuring out the mapping from real IP address to mapped address, before investigating the ACEs using the mapped address and hence they might be more comfortable with using real IP addresses in the access-list entries.

So at the outset, this looks like a better approach; however this is a significant departure from how mapped addresses are used in filtering rules in not only prior Cisco versions but also other firewall vendors. Also this approach will not avoid changes to ACEs if the real address itself is changed. Configurations that are being migrated to the 8.3 release should be carefully analyzed to see if the polices are migrated properly and make sure that overly broad policies or narrow policies are not created when there is a one-to-many or many to many NAT mappings of unequal sizes. Also the cumulative impact of NAT and ACL rules should be taken in account during migration; broader ACEs used with very specific NAT rules and specific ACEs used with very broad NAT rules.

Here is how the new NAT redesign makes it easier to specify the NAT commands when compared to the prior versions:

Fewer NAT commands to deal with: Engineers can use a relatively small number of commands to accomplish what they want; they do not have to learn myriad NAT syntactic variations like Regular Dynamic NAT/PAT, Regular NAT policy, NAT Exemption, Identify NAT, Static NAT/PAT, Static Policy NAT, Outside NAT, Bidirectional/Twice NAT using multiple NAT statements etc.,. In the ASA 8.3 release, engineers need to learn about only a couple of syntactic constructs: Network Object NAT and Twice NAT to specify NAT. Using Network Object NAT, engineers can specify dynamic or static NAT on an individual real IP address. Using Twice NAT, engineers can define the desired address or service translation based on any combination of matching source, destination and service in a single rule for any ingress, egress interfaces.

Network object dynamic and static nat 

object network name

nat [(real_ifc,mapped_ifc)] dynamic {mapped_inline_host_ip [interface] | mapped_obj
               [interface] | interface} [dns]

object network name

nat [(real_ifc,mapped_ifc)] static {mapped_inline_ip | mapped_obj | interface}
                     {dns | service {tcp | udp} real_port mapped_port]

Twice NAT

nat [(real_ifc,mapped_ifc)] [line | {after-object [line]}] source dynamic {real_obj | any}
        {mapped_obj [interface] | interface}  [destination static {mapped_obj | interface}
        {real_obj | any}] [service {mapped_dest_svc_obj real_dest_svc_obj}]
        [dns] [unidirectional] [inactive] [description desc]

nat [(real_ifc,mapped_ifc)] [line | {after-object [line]}] source static {real_obj | any}
        {mapped_obj | interface | any} [destination static {mapped_obj | interface}
        {real_obj | any}] [service {real_src_mapped_dest_svc_obj | any} 
        mapped_src_real_dest_svc_obj][dns] [unidirectional] [inactive] [description desc]

Control over order of NAT commands: The order in which the commands were assessed in prior versions depended on the type of NAT used, and in some cases, the order in which the commands appeared in the configuration. If the engineer wanted to add a new rule at a desired location or modify the order, it was really difficult. This has been simplified in the ASA 8.3 release. The NAT table in the 8.3 release contains 3 sections assessed in the following order: section 1 contains the twice NAT rules based on the order in which these commands appear in the configuration. It is possible to insert a new NAT command at any position using the “line” option. Section 2 contains the automatic rules generated by Cisco using a fairly simple internal order from the Network Object NAT definitions. Section 3 contains twice NAT rules that are specifically inserted after section 2 using “after-object line” twice NAT command option. This is simple when compared to the pretty complex ordering that engineers need to understand in the ASA versions 8.2 and prior.

Twice NAT in a single NAT command: In the prior versions, users have to use multiple NAT commands to perform both source and destination translation for a given IP packet. This also means that users had to be aware of any unintended bidirectional NAT rules that are formed because various NAT commands defined with in the configuration could be combined. For example, 2 static NAT statements or a static with nat/global commands could combine to perform twice NAT. The user had to be mindful of what are the possible twice NAT rules and whether those are assessed in the right order he intended. With the 8.3 release, it is now possible to specify both source and destination translation for any source, destination and service in a single rule and define any number of them in the order they want.

Besides the NAT redesign, the 8.3 release provides the following additional firewall features:

Interface independent Access policies: You can now configure access rules that are applied globally, as well as access rules that are applied to an interface. If the configuration specifies both a global access policy and interface-specific access policies, the interface-specific policies are evaluated before the global policy. This is somewhat similar to the Global policies available in the Juniper NetScreen firewall.

Basic Network and Service Objects: You can now create named network objects that you can use in place of a host, a subnet, or a range of IP addresses in your configuration and named service objects that you can use in place of a protocol and port in your configuration. You can then change the object definition in one place, without having to change any other part of your configuration. This avoids the need to use the object-group even for simple network or service objects and brings this feature in line with other firewall vendors like Check Point and Juniper NetScreen.

To summarize, ASA release 8.3 provides simplified and flexible NAT specification making it easy to maintain large NAT configurations. For customers using Cisco infrastructure, ASA 8.3 release provides significant benefits when deploying brand new firewalls. However, the requirement to use real IP addresses in the access list statements is a significant architecture change and would complicate the migration effort when attempting to migrate NAT configurations from prior versions. The migration of NAT configurations should be performed with close attention to the gaps created by the Cisco ASA 8.3 migration tool.

Athena FirePAC from Athena Security offers a migration tool that performs offline policy analysis for understanding the interactions between ACL, NAT and routing rules.  It is extremely useful when performing migrations between firewall versions or across vendor platforms.  Despite the availability of vendor provided conversion tools, the most critical step in the process is validating that the policies were migrated correctly.  Identifying where gaps were introduced so that they can be fixed is the primary benefit of Athena’s migration solution and it has proven to cut down the manual effort by at least 85%.  To learn more, read about Athena’s Migration Tool.

Network and service objects are often used by firewall engineers in firewall policy implementation. For a network environment with a large number of firewalls, it is highly recommended that all common objects across the firewall inventory be standardized. Without standardization, the same objects can be created in different firewalls for commonly used services or IP addresses, or worse the same object name can be associated with different object definitions. Objects with the same name but different definitions (called Conflict Objects) can cause configuration errors. Objects with different names but the same definition (called Redundant Objects) unnecessarily increase the size of an object library, and can cause redundant rules in the configuration.

Object standardization involves the following steps applied across all the firewalls in the inventory:

1. Find all objects from all firewalls in the inventory
2. Identify conflicting and redundant objects based on object name and definition
3. Renaming an object
4. Replacing redundant objects with a single object
5. Replacing an object with  another object
6. Splitting an object into smaller objects
7. Resolving conflicts between objects
8. Updating all configurations with new object names and definitions
9. Validating changes in the configuration

If all firewalls are already managed by a single management console, e.g. Cisco CSM, object modifications in the management console can be reflected to all referring objects and rules across all managed firewalls. When many objects are being modified simultaneously, this can be very dangerous because there is no evaluation of the impact of change in firewall configurations on network security. Moreover, consolidation of redundant objects cannot be done through management consoles since management consoles do not perform searching and merging objects based on their IP addresses and port values.

One of our customers, a Fortune 500 company encountered many problems when they started their company-wide object standardization project. They were attempting to deploy Cisco CSM for managing a couple of hundred Cisco firewalls. However, CSM does not resolve conflict objects, but simply creates new objects with a suffix of 1, 2 etc. A huge manual effort could have been necessary to resolve and consolidate the object library that had more than 10k objects, had they blindly deployed CSM. Among the issues they encountered that would delay their project significantly were:

1. Cisco firewall CLI (prior ASA 8.3) does not support object rename or replacement. A new object has to be created. All referring rules and objects have to be manually found and replaced.
2. Cisco firewall CLI does not support object replacement in a rule. A new rule with the replacing object(s) has to be manually created and inserted to the proper position within the access list.
3. Cisco firewalls do not support splitting object. New object(s) has to be created. All referring rules or objects have to be manually found and replaced.
4. After the standardization process, no validation can be done except a simple text compare.
5. The manual standardization is very time consuming and error-prone. It took about one week to standardize one firewall with unguaranteed accuracy.

With the help of Athena FirePAC Object Standardization tool, the customer’s object standardization effort was reduced significantly for the following reasons:

1. The overall standardization workload was reduced very significantly.
2. FirePAC rule/object cleanup tool removed more than 30% redundant rules and unreferenced object.
3. A global object table was exported from FirePAC. Objects were grouped by firewall, object name, and object definition. All conflict objects were automatically identified and treated as separate objects.
4. A global object mapping table was defined and imported into FirePAC. All objects in the inventory were included in the mapping table.
5. Various object mapping types were handled by FirePAC, including rename, replace, modify and split.
6. Object mapping scripts were generated automatically by FirePAC with the consideration of rule sequence and object member hierarchy.
7. FirePAC rule/object compare and policy compare provided a solid validation to the new firewall configuration after the object standardization.

Overall, the object standardization took only half day per firewall with the guaranteed accuracy.  The Customer said “FirePAC has contributed greatly to the success of our object standardization project”.

The above screenshot shows the object mappings and mapping scripts (at the top of the screen) that are generated by FirePAC.

Check out more about FirePAC through these videos: Impact Analysis, Rule/Object Cleanup, and Object Standardization.

A common problem that network engineers encounter is ensuring that firewall policies are migrated properly when replacing an old firewall with new hardware and making associated structural changes to the network.  We recently helped a customer who was replacing an old Cisco PIX 525 and an FWSM with a new Cisco ASA 5550 firewall and combining several subnets that were previously connected to different network interfaces on the FWSM. We decided to use AthenaVerify, our network analysis product, to model the changes in the network and to identify differences in policies between the various subnets before and after the changes.

The digrams below are screenshots from AthenaVerify showing the structure of the network before the change and after the change.  In the original network, the PIX 525 has three network interfaces, connecting to a public network, a DMZ network, and an internal network.  The FWSM connects to the public network through a router and also has four additional internal subnets connected on different network interfaces.  In the migrated network, the PIX 525 and FWSM have been replaced by a single, four-port ASA 5550.

Original Network Topology

Migrated Network Topology

The migration process involved several steps.  The ASA was set up in a lab environment that replicated the structure of the migrated network.  A snapshot was taken of the configurations from the production devices.  The configuration from the PIX was used as the baseline for the ASA and then rules from the FWSM configuration were added to this baseline.  The original was modeled as a topology in AthenaVerify.  This was saved as a version and then the PIX and FWSM were deleted from the topology and replaced with the ASA to model the changes in the network.  Comparing the network policies between the different versions of the topology allowed us to easily identify policy differences.  Using AthenaVerify, we were able to quickly find the rules responsible for the policy differences and determine the appropriate corrections.  The rule changes were applied to the ASA and the updated configuration imported back into Verify.  This process was iterated until the policies converged, which happened quite quickly.

A complicating factor was that changes were being applied to the production devices during the period that the migrated configuration was being built.  This meant that corresponding changes had to be applied to the ASA as well.  The original topology had to be updated in AthenaVerify several times to reflect the changing nature of the production network.

Merging the rulesets from the PIX and FWSM onto the ASA caused some interesting problems.  We found that there were object definitions in the PIX and FWSM that had the same names but different definitions.  During the merge, the definitions from the PIX were preserved, causing policy differences in the rules that were migrated from the FWSM.  Using AthenaVerify, we were easily able to catch this problem.

We also found some allow policies in the FWSM that should not have been there; apparently there were some errors in the configuration.  This was not an issue in the original network because the connections were blocked in the PIX.  But after migration, the ASA was now allowing these connections and the policies had to be changed.  This was a good example of the difference between firewall policy and network policy.  Although the FWSM did (erroneously) allow these connections, the combination of devices in the network did not.  But, what was previously just a firewall policy became the network policy when the errors were propagated to the ASA in the migrated network.  These errors were fixed in the FWSM prior to the final migration to the ASA.

The outcome of this project was very successful.  Had this process been performed manually, it would have required extensive testing of each rule moved to the target firewall.  Finding the types of errors and conflicts that that were encountered would have been very difficult and taken a lot of time to get correct.  Using AthenaVerify made it very easy to identify the network policy differences between the original and migrated networks and to quickly determine what changes were required to preserve the network policy. A process that could have taken months to complete manually was finished in just a few days using AthenaVerify.  The customer reported being “extremely confident” that the changes had been made accurately and that the migrated policies were correct.

Today we launched a major upgrade of Athena FirePAC.  This release has a brand-new look, which is consistent with our free Firewall Browser tool.  If you liked the Browser, you’ll really like FirePAC v4.0.  We’ve also added a bunch of great new features as well.  Upgrading to the new version is extremely painless and simple and will bring you many benefits that are sure to make your job easier!

Here just a few of the advancements you’ll find in the new release:

Usability

The FirePAC 4.0 UI has been redesigned to match the operational need for more dynamic and interactive analysis. You’ll really love what we’ve done to make the rulebases really explorable, plus we’ve added many new search and query options.

Impact Analysis

Now you can compare side by side the additions, deletions, and modifications to rules and objects based on the semantic dependencies.

Automated Scripts

All cleanup reports come with commented and well structured scripts so you can complete the entire process with more automated help.

Device support

We’ve added support for routers, so you can include the ACLs from these devices into your overall risk and service availability analysis.

Licensable solution-based components

These options allow you to mix and match the solutions you need for different groups of firewalls. When you are ready for your next project, you can buy exactly what you need and have the flexibility to add more on at anytime.

We’re really excited about this new release and have added a bunch of new videos to the Athena web site so you can review the highlights at your own convenience.  Check out these videos: Impact Analysis, Rule/Object Cleanup, and Object Rationalization.

To upgrade from v3.7.1 to v4.0, follow these easy steps:

1. Launch FirePAC
2. When you see the dialog informing you that a new version is available, click on the Update button.
3. Download the new release.
4. Send an email to support@athenasecurity.net letting us know you’re ready and we’ll mail over the new license.
5. Launch the installer.
6. Launch FirePAC and apply the new license.

Your existing data will be retained, so you need not worry about re-importing your firewalls.

PCI DSS frequently gets attention for being a comprehensive industry standard to improve the security of production networks. Another body of guidelines with highly useful controls that should be referred as a source for best practices in network security are the Security Technical Implementation Guides (STIGs) published by the Defense Information Systems Agency (DISA).  In particular, the Network Infrastructure STIG provides useful recommendations for securing firewalls and routers.  Unlike the PCI DSS requirements, whose focus is on protecting cardholder data, the focus of the Network Infrastructure STIG is network security in general. This means that security policy prescriptions address network security related processes and security related aspects of policy configurations in firewall/router and other device, but not issues such as data encryption.

Despite its DoD focus, STIG is very useful for the network security professional because many of its recommendations can be directly applied to enterprise network security. These recommendations are in the form of policy bulletins that are actionable and specific. Here are examples of both process and configuration related policy bulletins:

(NET0135: CAT II) The IAO/NSO will review all connection requirements on a semi-annual basis to ensure the need remains current, as well as evaluate all undocumented network connections discovered during inspections.

(NET0923: CAT I) The router administrator will restrict the premise router from accepting any inbound IP packets with a local host loop back address (127.0.0.0/8).

The policy bulletins related to device configurations are extensive and cover the following issues:

• Checks for specific TCP, ICMP, BGP, ARP protocol settings.
• Checks for device access parameter settings
• Checks for specific protocol versions that are used to access the firewall/router like SSH.
• Checks for commonly compromised services like http, dhcp, ftp, traceroute, SNMP being enabled.
• Checks for logging of Access Control rules.
• Checks for correct parameters in messages originating from the firewall/router.

Network security is a 24/7 effort, and so compliance under these STIG policy bulletins has also got to be 24/7. This means that policy bulletins that relate to device configurations need to be checked whenever there is a change in the configuration. Athena FirePAC provides support for the Network Infrastructure STIG and can perform these checks in an entirely automated fasion for Cisco routers and security appliances, Juniper Netscreen firewalls, and Check Point firewalls.

In an earlier post, we discussed the need for cleaning up and simplifying firewall rulesets.  There are two techniques for determining whether a rule can be removed from a rule base: one based on rule redundancy and the other on rule usage.

There can be an overlap between the two techniques in the sense that a rule can be both redundant and also have zero usage. Despite that, it is often the case that the majority of rules will fall into one category or the other. To get the maximum benefit of keeping your rulebase efficient and simple, it makes sense to maximize rule removal by trying both approaches.  Automated tools, such as Athena FirePAC, can apply both approaches. The question then is how to proceed and in what order.  The straightforward technique would be to use a two-pass approach: remove, say, zero usage rules using log data in the first pass, create the new configuration with rules removed, and then in the second pass run the modified configuration through the tool again to identify redundant rules. This two-step approach is untenable in most situations, since we need access to the production device (or even a laboratory device) twice. If there is a formal validation step as part of the rule cleanup process, the validation step will also have to be repeated twice again. If there are a large number of firewalls to be cleaned up, this two-step process can add extra months to the schedule and thousands of dollars in cost.

Clearly the answer is a one-step process that incorporates both techniques. In one such process, the firewall configuration is run through the rule cleanup tool at most twice — once to identify redundant rules, and the other to identify zero usage rules. It does not matter in which order the rules are identified, because both sets of rules are then combined in the following manner to determine the rules that will actually be removed: All rules with zero usage that are identified are marked for removal. The remaining rules that can potentially be removed are all redundant rules. Of these, identify rules that are redundant and have their source rules (i.e. the rules that make it redundant) above it in the rulebase. All such redundant rules can be marked for removal. The remaining redundant rules have their source rules below them in the rule base. Of these, mark a rule for removal only if none of its source rules have zero usage, and any rule options associated with the redundant rule can be ignored. You may wish to manually review the rules with zero usage prior to removal to ensure that there is no business case to retain them.

To ensure that the rules are removed correctly, it is advisable to use a script that will remove the rules one at a time, in an automated fashion.

Athena FirePAC automates the cleanup process from start to finish, by first identifying all rules based on redundancy and usage that can be removed without impacting the traffic allowed through the firewall.  It then generates the scripts so that rule removal is straightforward and consistent.  To learn more, download a free trial of FirePAC.

Yesterday I participated in a webinar discussing the must-do’s of network security and configuration management with SolarWinds‘ Head Geek Josh Stephens.  We discussed some best practices for managing configurations and some guidelines for firewall configs themselves.  The meat of the webinar was a demonstration of Orion NCM and the integration with Athena FirePAC.  The combined products make a dynamite solution for firewall configuration management.  You can watch the webinar online (registration required) and the slides are available here.  Check it out!

Most of the major firewall vendors provide similar features for controlling network access and providing service availability; network and service objects, filtering, network address translation, VPN and routing rules. However, they still differ in significant ways. For example, firewall configuration syntax, how the firewall is managed, and how changes are deployed to the firewall are all different. But the most significant difference is the way policies are grouped or partitioned and applied on packets entering and exiting the firewall.

For example, Check Point has a flat security rule base that is evaluated for every packet entering the firewall while Cisco firewalls define security levels and specific access lists on an interface basis, including default behavior when traffic has to traverse the interfaces of different security levels. Juniper NetScreen allows interfaces to be grouped into zones and specify policies based on packets entering and exiting specific zones.  As a result, what is allowed by a filtering rule with any source address or any destination address is quite different on a Check Point, Cisco and NetScreen box.  Then there is the issue of NAT specification: Check Point supports NAT objects as well as twice NAT to specify translation of Source, Destination and Service; Cisco has a fairly complex specification for NAT rules including nat control feature that serves as an additional access control function (note: the specification has been simplified to a great extent in ASA 8.3 with the support of NAT objects and twice NAT); while NetScreen combines the specification of Filtering and NAT rules, providing support for NAT objects in the form of MIP, VIP and DIP objects. Besides all of this, each of these firewalls have different settings and default behaviors that affect what traffic is allowed through the firewall.

Fortunately, there are some tools available from the vendors to handle the syntactic translation; however these still do not address the semantic differences, leaving a lot of policy gaps still to be addressed in the conversion. These gaps could result in security holes or disruptions to service availability.  Projects that try to convert from one vendor to another vendor are pretty challenging. For a successful conversion effort, understanding the policy gaps that result in these conversions, the impact of gaps, and how to plug them is very important and not supported by available firewall vendor conversion tools.

Athena FirePAC has a policy comparison solution that verifies the policy equivalence between the original and converted configurations. It identifies the policies added or removed as a result of the conversion, and the specific rules that were responsible on both the sides for the differences. This solution can check the policy equivalence between Cisco, Check Point and NetScreen configurations.  For advanced conversion support, Athena also has a more specific migration solution for Cisco to Check Point conversions where FirePAC identifies the source of the policy gaps and provides recommendations for closing the gaps.