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.

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.

Firewall Browser, our recently released free tool, has a very powerful search capability that automatically explores object hierarchies to catch all matching object groups and rules. We often see nested object groups in complex firewalls. Object and rule searches in various management consoles only look at direct matches. They are not capturing the matches that happen at child groups. When a user tries to add new object groups for new security rules, incomplete results can lead to duplicate or overlapping object groups.

Here is an interesting case from a Cisco FWSM firewall:

object-group service ldap-ports udp
 port-object eq ldap
 port-object eq ldaps

object-group service netbios-name-ports udp
 port-object eq 137
 port-object eq 138

object-group service domain-controller-udp-ports udp
 group-object ldap-ports
 group-object netbios-name-ports

object-group service std-dc-udp-port udp
 port-object range 137 138
 port-object eq ldap
 port-object eq ldaps

Object group “domain-controller-udp-ports” is exactly the same as object group “std-dc-udp-port”. With the management console, a user has to manually expand child groups with multiple searches to figure this out. Using Firewall Browser, a user can instantaneously view all object groups that match the given criteria (e.g. object name, IP address or service port) no mater how deep the values are hidden in object hierarchies.

The Firewall Browser rule search facility supports object hierarchies as well. In the above example, any access-list rule that refers to “domain-controller-udp-ports” is captured in Firewall Browser if the rule search is against any member object in “ldap-ports” or in “netbios-name-ports”.

You can download Firewall Browser from the Athena Security web site with no license restrictions for end-users.

Firewall rule bases have an annoying tendency to grow larger over time. It’s easy to add new rules to a firewall. But nobody likes to remove rules from the firewall because they don’t know what the effect of the change will be. As a consequence, firewall rule bases will accumulate a lot of redundant and unused rules.

Redundant rules exist in firewall rule bases because of structural relationships between the rules; one or more rules duplicate the functionality of other rules. As firewalls evaluate the rules in the sequence they are defined in the rule base, rules whose functionality is covered by other preceding rules in the rule base will never be triggered and hence can be removed safely. There can also be redundant rules that exist as special cases preceding more general rules that succeed them. Removing these special cases will not change the firewall functionality; the later general rules allow or deny the same traffic. Identifying the redundant rules requires an understanding what traffic is allowed or denied by each rule. From this, you can identify rules that are redundant. If object groups are used heavily in the rule base, identifying the redundant rules manually will be painful and time consuming because of the large number of expanded combinations that need to be investigated. Tools are good at automating this type of analysis and easily identify these rules. Once identified, cleaning up these rules is very safe. Here at Athena Security, we have found as much as 30%-40% of the rules in large rule bases are structurally redundant and contribute nothing to the functionality of the firewall. Removing these rules will simplify the firewall configuration, making it easier manage and less error-prone to make changes.

On the other hand, identifying unused rules requires a lot more time and effort invested up front. These are the rules that have become stale over a period of time. They were not removed because the business owner could not be identified or the business owner is not sure. Some times you have to prove to the business owner that they are not really using the services allowed in the rule base. So identifying these unused rules requires capturing firewall logs for reasonable time duration. These logs then need to be analyzed to see which rules were never triggered during the period of log capture. Trending might also be required to accurately identify rules that might only be used at certain points in the year. On most firewalls, capturing logs for rules requires enabling of the log option on the rules that are being monitored. This could have an impact on the firewall performance, depending on the traffic being logged. Even though this process is time-consuming, often this is the only way to make the overly permissive rules less specific or to remove unused services from existing rules.

Cleaning up firewall rule bases is an important part of auditing your firewalls. This process can be very complex and time-consuming to attempt by hand. By using tools such as Athena FirePAC that automatically identify redundancies and unused rules, you can complete the process in only a day or two rather than weeks.

As firewall engineers, we all have an intuitive sense for how complex a given firewall configuration is. We see it in the size of the ruleset. We see it in the errors that we know are there but don’t have time to track down. We see it in the amount of hair-pulling in involved in making sure a simple change is correct. (From my photo in the sidebar, you can tell I’ve seen my share of complex firewalls!) But what exactly is it about a given firewall configuration can make it so complex and difficult to manage?

Here at Athena Security, we felt there must be a way to identify the factors that really contribute to firewall complexity and quantify them.  We have accumulated a large database of firewall configurations from companies in a wide variety of industries, including financial services, health care, construction, human resources, manufacturing, IT services, and network security. These configurations were manually assessed for a firewall administrator’s “intuitive” sense of complexity and then analyzed using Athena FirePAC to identify configuration errors and policy risks. These results were subjected to intensive statistical analysis to find correlations between different aspects of the configurations that might contribute to complexity.

After evaluating over 100 firewall configurations, we found twelve factors that correlate strongly with our intuitive sense of complexity. These factors include obvious items like the number of ACLs and NATs in the ruleset.  Large rulesets are clearly more difficult to understand and maintain, and thus more complex.  But we also found that certain structural elements correlate strongly with complexity, including the number of discrete address elements (individual IP addresses, subnets, or address ranges), rules that have a wildcard match for source, destination, or service, and rules with a deny action.  These factors all cause complex interactions between the rules, magnifying the complexity of even small rulesets.

Based on the results of this study, we have developed a tool, called Firewall Grader, to measure these factors in Cisco, Checkpoint, or Juniper Netscreen firewall configurations.  It derives a complexity metric for the firewall based on the assessment of all twelve factors and generates a report of the findings.  We have found the metric useful in identifying those firewalls that are most difficult to manage or to audit.  Tracking the complexity metric over time can help you ensure that your firewall configurations don’t get out of control.   It will also recommend ways to restructure the configuration to reduce overall complexity.

Firewall Grader is available as a free download from our web site. Try it out!  Let us know what you think.

Jamey Heary over at Network World compiles five little-known but useful features of the Cisco ASA firewall.  He gives examples of configuring application firewalling, embedded host posture assessment and remediation for VPN clients, authentication and authorization for your ASA Admin users directly via LDAP, allowing TCP applications over clientless sslvpn without plugins, and controling clientless sslvpn user access via URL access lists.