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.

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.

We recently released Athena FirePAC v3.7, which adds several cool features to help you get a handle on out-of-control firewall configurations.  The new features make it much easier to identify object definitions that are not needed and to deploy consistent and systematic object definitions across an inventory of firewalls.

Object usage analysis helps you determine how objects are being used on a per-rule basis and also globally for each object.  For firewalls like Juniper Netscreen and Check Point, which allow multiple values in the source, destination, and service fields, you can now determine how much each object contributes to the overall usage of a rule.  For example, suppose you have the following rule in a Netscreen firewall:

ID	Source	Destination	Service	Action
17	client1 client2 client3	abc_dmz_proxies abc_dmz_remotes xyz_dmz_proxies xyz_dmz_remotes	HTTP HTTPS HTTP-ALT 8000

You’d like to know which of the DMZ proxy and remote destination objects specified by this rule are actually being hit.  Looking at the hit counts for the rule will only tell you that the rule is being used, but it will not tell you which of the objects in the rule are actually being used.  The new object usage analysis in Athena FirePAC will tell you exactly the percentage of total hits to the rule is contributed by each object.  This gives you valuable information about the traffic passing through your firewall and can help you identify which objects are unnecessary and can be removed from the rule.

You can also find out the aggregate usage of each network or service object in the configuration.  This makes it very easy to identify the objects that are not being used at all and can be removed.

Check it out!  You can download a free evaluation of Athena FirePAC from our web site.

Most network engineers will agree that keeping a firewall rulebase free of unnecessary rules is good practice.  This involves finding candidates for removal based on traffic data captured in the firewall logs to identify which rules and objects were actually used.

With this data, it is possible to clean up rules and objects within the rules that are never hit, as well as remove object members that are not hit in any rule.  The benefits of rule cleanup are not only for improving the maintainability, but also the performance of the firewall.  In high-transaction systems, such as financial trading systems or e-commerce platforms, squeezing the most performance out of the firewall can become a crucial exercise.  Once cleanup is completed, additional improvements in performance can be achieved by using the same traffic log data to determine the most used rules and objects. This forms the basis for re-ordering rules, where the objective is to move the most frequently used rules to the beginning of the rulebase as long as there is no impact on policy.

Re-ordering rules to improve performance requires rule dependencies to be taken into account so that the firewall’s behavior is not adversely impacted. Moving a rule will change the behavior if any of the rules passed over by the moved rule have a rule order dependency with it, i.e. they overlap with it and perform a different action.  For example, moving an allow rule over an overlapping deny rule would cause some previously denied packets to now be allowed.  You even need to take into account rule options such as logging or user authentication.

Often, only specific objects within the rule are frequently used and these specific portions might not have any rule order dependencies.  In these cases it might be easier to simply carve out separate rules using these most-used objects and add them at the beginning of the rulebase.

To illustrate some of these points, consider the following example ruleset for a perimeter firewall connected to the Internet, a DMZ network hosting publicly accessible web servers, and an internal network hosting some application servers.

In this rulebase, rules 100 and 60 were the two most used rules, in that order.  Determining whether or not these rules overlap requires identifying the specific IP addresses and subnets used in each of the network groups and the services included in the service groups.  If the service groups DangerousSvcs and InventorySvcs contain any of the same services, then rule 60 cannot be moved up in the rulebase any further than rule 5 because both rules refer to the network group InventorySvrs and they have differing actions.  Similarly, rule 100 cannot be moved in front of the rule 60 if they overlap since rule 60 has a user authentication option even though they have the same rule action.  It might be better to redefine rule 100 to exclude the addresses and services referred to by rule 60 so that rule 100 can be moved higher up in the rulebase.

It is possible to determine the most used rules or most used addresses and services in the firewalls with the help of scripts. The log data can be parsed and stored in a database and SQL queries used to count the number of rows for each rule ID to get the rule usage.  However, determining rule order dependencies does require examining the relationships between each rule and every other rule in the rulebase.  You need to determine the effective portion of each rule, taking into account the content of each object used in the rule before you even try to determine the overlaps between the rules.  Correlating these addresses or services to the object groups requires an understanding of object and rule structures within the firewall configuration.  Performing this analysis manually requires a lot of time and is error prone because of the large number of rule and object combinations that have to be looked at.  If the rulebase is non-trivial, even a scripting solution is untenable.

Fortunately, Athena FirePAC automates this process and generates a report that identifies all structural redundancies in rules and objects that can be cleaned up, all unused objects and rules that can be cleaned up using the firewall log data, and provides an optimized rule order where the rules are reordered based on most used rules and rule order dependencies.