A well-formed network change request typically specifies a source IP address, a destination IP address, and a service to allow.  Getting this request from the initial submitter to a final, validated deployment of a correct network device configuration can be a challenging task.

Although the change process will vary from organization to organization, there are several common roles and process steps.  The change process will typically involve many stakeholders who require different levels of access to information about the change and the network itself.  The request will be initiated by an end-user who desires access to particular services or specific devices.  A security auditor may review the security implications of the request.  A change manager may review the request for correctness and completeness.  A network engineer will design configuration changes based on the requirements in the request.  A change manager may review the proposed changes for impact on network behavior and compliance to network standards.  Once approved, a network engineer will deploy the changes to the network.  Finally, the actual change deployed to the network may be validated to ensure it was made correctly and corresponds to an actual change request.

In networks of any reasonable size, it is quite likely that a packet specified by a change request will traverse multiple network devices along its path from source to destination.  Identifying the path and knowing which devices will need to be touched along the path requires significant knowledge of and experience with the network in question.  Not all of the stakeholders will have access to this information, either for security reasons or simply that it’s irrelevant to their jobs.

The application developers and other end-users who request access to particular services or specific devices are frequently unclear on the nuts and bolts of the network architecture.  They are not likely to be familiar with the intricate details of IP subnetting or network address translations.  They may not even be sure of the exact port numbers used by their favorite services.  This all leads to change requests that may be ill-formed and even strewn with erroneous IP addresses or port values.

Another issue is that even if a change request contains the correct host and service parameters, the request may be spurious because the service is already available and accessible.  Even so, just determining that a request is spurious requires identifying the correct path through the network from source to destination and finding the network devices that could potentially block the packet.  In this case, the network engineer’s valuable time is wasted even just responding to the request because there’s nothing to be done.

Assuming the change request is accurate and non-spurious, the network engineer still has to identify the correct path through the network from source to destination and determine which, if any, devices must be touched in order to complete the request.

Using traditional tools like ping or traceroute, the network engineer can only identify the first device along the path that is blocking the packet.  He would then have to identify the change required in that device, deploy the change to the network, and then continue pinging or tracerouting to the next blocking device and so on.  Since the changes to each device are made individually, they can only be tested and validated individually as well.  This can be a very time-consuming and potentially error-prone process.

Finally, once the correct devices have been identified, the network engineer must determine which ruleset in each device has to be modified and where in the ruleset to make the change.  In many cases, even if the engineers understand the network well enough to know which devices need to be touched, the devices themselves are so complex that designing the correct change is a challenge all by itself.

With so many stakeholders having various and differing interests in changes to the network, a single change request can spend a lot of time going back and forth between different people.  Each additional step in the process introduces the possibility of error and represents more time taken before the change can actually be deployed into production.

Athena Security’s Change Advisor addresses these issues by automating the change process.  It takes advantage of Athena’s core technology of deep dataflow understanding of firewall and network device behavior to determine how packets would traverse the network, based on connectivity, routing and the firewall devices involved in the change request.  It moves analysis of the change to the front of the process and makes the results of that analysis available to the different stakeholders when and how they need it.  This can dramatically reduce the change cycle time and the incidence of errors while ensuring that sensitive information about the network configurations is made available only to those who need it.

Application developers and other end-users use a web form to submit change requests.  They can select the source and destination parameters from a list of known hosts, cutting down on potential errors at the point of entry.

Once a complete request has been entered, Change Advisor issues a packet tracer query based on the request’s source, destination and service parameters to determine the path the requested packet would take through the network and identifying the firewalls and routers involved.  The result is an answer to the application engineer that shows whether or not the change is needed.  Since no data is injected into the network, and the application engineer does not view or access the configurations directly, this is a secure process.

If the packet tracer query shows that the change is required, the request is then forwarded to a network engineer for fulfillment.  The packet tracer query issued from the change request parameters identifies the routable path through the network from the specified source to the specified destination.  This process determines whether or not the packet can be routed to its proper destination.  If NAT’ing is involved, the packet tracer will calculate the proper translated address ranges.  Then if there are any devices along the path that can apply security rules, the packet tracer determines whether or not the packet will be filtered from reaching its destination.

When presented to the network engineer, this analysis result shows precisely where in the network the packet will travel, which devices along the path will need to be modified to allow the requested service, and even which rules in those devices need to be changed.

The network engineer then has all of FirePAC’s extensive capabilities for exploring firewall configurations, understanding firewall behavior, and modeling the effects of change on firewalls and routers and can design and verify the change prior to deployment out to the network.  Following deployment to the network, FirePAC’s Change Impact Monitor can validate that the correct change has actually been deployed.

In this series of posts, we have examined some of the challenges involved in migrating firewall configurations between different firewall platforms and discuss some strategies for approaching these issues.  The first post introduced the basic firewall configuration elements that have to be migrated and discussed some of the issues in converting routing table entries, and network and service objects.  The second post examined some of the issues involved in migrating ACL or filtering rules.  The third post discussed the challenges of migrating network address translation (NAT) rules.  In this post, we will examine the issue of validating the migrated policy in the target firewall.

Validation

Once the source firewall configuration has been migrated to the target, you will want to validate that the conversion has been done correctly.  There are two aspects to this process.  The first is to ensure that all elements in the source configuration have been accurately and completely transferred to the target.  This is typically done by a object-by-object and rule-by-rule comparison of the two configurations.  Each object definition and rule in the source is traced to the corresponding object definition and rule in the target.  In many cases, this is not actually a one-to-one correspondence because architectural differences between platforms may force one source object or rule to be decomposed into multiple objects or rules in the target.  This is particularly a challenge when tracing the conversion of NAT rules.

The second aspect of validation is to verify that the policies in the target firewall are functionally equivalent to those of in the source.  This means analyzing the traffic flows across each pair of ingress and egress interfaces in the source firewall and comparing it to the traffic flows across the corresponding interface pair in the target.  Calculating the traffic flows involves determining what traffic is allowed/denied for all possible sources, destinations, and services and must take into account the combined effects of the reachable networks for each interface, filtering from security rules, address translations, and routing table entries.  Performing this kind of analysis manually is feasible only for some small number of critical connections; performing a full traffic comparison analysis for the entire configuration is only possible using automated tools.

Athena FirePAC provides a Firewall Migration module that can perform automated traffic flow comparison between configurations from different firewall vendors.  This can be used to validate migrated configurations and to find all packets that are being dropped or added in the new target configuration. The comparison report also provides a list of all added and deleted traffic flows along with the rules that allow and deny the traffic on both the sides.  Not only is it very useful for validating policy equivalence between migrated configurations, but it will also identify the specific rules responsible for deviations in the target firewall.

FirePAC now also provides a fully automated process for migrating Cisco configurations to Check Point firewalls.  This capability addresses many of the limitations in the Confwiz migration tool provided by Check Point.  Specifically:

1. Identifies global rules in the Cisco firewall configuration (generated from CSM) and ignores them when generating rules on the Check Point side.
2. Uses the routing rules to perform network reachability and generates the interface reachable network objects correctly and fixes zone spanning objects when generating acl rules.
3. Generates flat basic objects instead of group objects with one member for basic objects defined in CSM and converted as an object group in the Cisco configuration.
4. Fixes the limitations in ConfWiz ACL generation like protocol object groups, tcp-udp service object groups, acl rules with source ports, non classic subnet masks such as 255.255.255.192,  port operators like ne, neq etc.,
5. Reuses all predefined and user defined service objects on the Check Point management server when generating objects.
6. Flexibility to specify the customer desired object naming conventions for naming the generated network and service object groups and renaming existing objects. ConfWiz uses fixed naming conventions with a mandatory prefix that the users need to fix manually later on.
7. Aggregates the expanded ACEs back to the aggregated form as specified in CSM when converting configuration of a Cisco firewall that is managed by CSM.
8. Generates the NAT rules accurately and in the correct order as evaluated by Cisco firewall irrespective of the order of NAT statements in the configuration. Generates all possible Twice NAT rules from Static Source and Static Destination NAT, Dynamic NAT and Static Destination NAT, Policy NAT and Static Destination NAT, NAT 0 and Static destination NAT etc., Identity NAT statements will not be generated only if other NAT rules that follow them do not overlap with them.
9. Optimizes the generated NAT rules by removing redundant NAT rules and NAT rules whose effective rule portion is covered by any of the ACL rules and hence would never be triggered. This optimization removes a significant number of Twice NAT rules and irrelevant nat rules formed from bidirectional static nat statements.
10. Uses Excel format to display the generated rules and objects and uses this excel document to deploy the rules and objects to the Check Point management server using CPMI interface. Users can very easily review this Excel and modify this excel to make desired changes before pushing the configuration to the Check Point management server.
11. Performs an offline gap analysis on the original and the converted configurations using nat, acl and routing rules on adds rules to fix the gaps.
12. Generates a validation report to identify all traffic flows (IP packets) that were added or dropped along with the responsible acl, nat and route rules in both the source and target configurations.
13. When the converted configuration is ready for deployment to production, it compares the objects on the production and the staging management server and flags all conflicts in an excel document with the conflicts merged. These conflicts are then pushed to the production server if desired or the users can manually resolve them using the excel report. This feature addresses major work flow issues with merging the changes that keep happening in production systems while the engineers work on the migration.

If you are engaged in or planning a Cisco to Check Point migration project and would like to evaluate this new capability in FirePAC, please contact sales@athenasecurity.net.

In this series of posts, we examine some of the challenges involved in migrating firewall configurations between different firewall platforms and discuss some strategies for approaching these issues.  The previous post introduced the basic firewall configuration elements that have to be migrated and discussed some of the issues in converting routing table entries, and network and service objects.  In this post, we investigate converting security rules.

Converting Security Rules

The basic elements of a security rule (sometimes called ACLs or filtering rules) are defined similarly in all firewall platforms.  Each rule specifies a set of source addresses, a set of destination addresses, and a set of services that are matched against an incoming network data packet, and an action to take: typically to allow or deny the matching packets.

The syntax of these rules is quite different across different firewall platforms as are the mechanisms for grouping rules to provide higher-level abstractions and partitioning rules for better management of rule bases.

Some firewall platforms, such as Cisco security appliances, allow only a single network or service object value for source, destination, and service elements.  The Cisco Security Manager (CSM) management console allows you to specify multiple values per element in a rule, but when the configuration is installed on a target firewall, the rules are expanded to have only one value per element.  Other firewalls, like Check Point and Juniper Netscreen, allow multiple values per element to allow for an aggregated and smaller rule base.

In Check Point firewalls, all rules are grouped into a single, flat rule base.  This entire rule base is evaluated for each packet entering the firewall, regardless of entering or exiting interface.  Thus it is not possible to organize the rules to take advantage of the network structure based on the set of network address ranges reachable from each interface.  In Cisco firewalls, security rules are organized into access groups that are assigned to one or more interfaces to be evaluated for packets either entering or exiting through that interface.  In Juniper Netscreen firewalls, interfaces that have networks behind them with similar security posture can be grouped into security zones.  Rules are defined by packets entering and exiting through the source and destination zone.

These different ways of organizing and grouping rules pose the biggest challenge in converting the security rules from one platform to another.  It is necessary to understand which networks are reachable from each interface or security zone and then partition the rules accordingly.  This can get interesting when converting rules using zone-spanning objects on a firewall with a flat architecture to an architecture that requires the rules to be partitioned by interface or zone.

Because of these different approaches to grouping of rules, the impact of using “Any” values in source and destination elements is varies across different firewall platforms.  When “Any” is used as Source or destination in a Check Point configuration, it means any address that is reachable from any interface.  However when “Any” is used as a source in a filtering rule on a Cisco firewall, it means only the networks that are reachable from the interface(s) that the rules are applied to.  Similarly in a Netscreen firewall, when “Any” is used as a source or destination value in a filtering rule, it really means only the networks that are reachable from the interfaces belonging to the source or destination security zones.

Zone-spanning objects pose a similar issue.  In a Cisco or Juniper firewall, only the addresses reachable from the relevant interface or security zone are allowed or denied by the filtering rules, even if a zone spanning object is used.  When converting such rules to a flat rule base, as in Check Point, the zone spanning object will have to be divided so as to specify only the reachable networks for the correct interface.

In general, when converting rules from a firewall platform where rules have higher level of grouping to a platform with lesser level of grouping or no grouping, “Any” values or zone spanning objects need to be resolved with networks that are actually reachable from interface(s) in the target firewall.  When converting rules from a firewall platform with flat or lower level of grouping to a higher level of grouping, source networks and destination addresses in each rule have to be analyzed to find the proper interface or security zone through which the networks are actually reachable and place them in the proper ruleset.

In the next blog post, we will examine some of the issues involved in migrating network address translation (NAT) rules.

Migrating a firewall configuration is the process of converting the configuration from one vendor’s platform to another vendor’s platform in such a way that the original firewall policies are preserved on the target firewall.  In this series of posts, we will examine the some of the challenges involved in such migrations involving Cisco, Juniper, and Check Point firewalls and discuss some strategies for approaching these issues.

All firewall vendors provide essentially the same basic firewall capabilities that are required to control the traffic entering and exiting their corporate network. The following elements make up the bulk of a firewall configuration:

• Interfaces through which the traffic which enter and exit the firewall and optionally security zones to group interfaces with common network availability and security posture.
• Routing rules to route packets through specific interface(s) based on destination and source addresses.
• Network and service objects and groups to define address and service elements and use them in the filtering and address translation rules for better maintenance of the firewall rule base,
• Filtering rules to control traffic entering the device based on Source, Destination and Service of an IP packet.
• Address translation rules to translate virtual ip addresses to real ip addresses and vice-versa,

To get a working baseline configuration for the target firewall platform, all of the above essential configuration elements have to be translated from the original firewall configuration to the target firewall platform.  This simple-sounding task is made very difficult by the myriad of architectural differences and incompatibilities between different vendors’ products.  Some firewall platforms group all security rules into a single flat rule base and evaluate those rules for all packets entering the firewall, regardless of entering interface.  Others provide capabilities to group rules into one or more rule sets and apply them either by specific ingress and egress interfaces or security zones. Similarly, even though the semantics of the address translation rules are the same, the syntax used for creating these rules is quite different in across the various platforms.  These differences pose significant challenges when converting these rules, whether manually or automatically.  Many vendors provide tools for performing these conversions, but all of them have major shortcomings because of these architectural differences.

Network Interfaces and Routing Rules

In this discussion of migration, we will assume that a drop-in replacement of one firewall for another is being done.  This means that there are no changes being made to the structure of the network itself.  This assumption implies that there is a one-to-one mapping of network interfaces from the original firewall to the target and that the target will be connected to the same networks as the original.  This also implies that the routing table will carry over directly from the original to the target.  The routing table is used to identify the networks that are reachable from each network interface.  It is sometimes useful to create network object groups that identify these reachable networks for each interface in the target.  For example, when migrating from a Cisco device to a Check Point firewall, it is necessary to replace “Any” used in filtering rules with network objects that specify the reachable networks for the interface that the filtering rule was applied to.

The syntax and semantics of the routing rules are similar across different firewall platforms, so converting routing tables is essentially a syntax conversion.  The most common type of routes on firewalls are static routes and converting these is very straight-forward.  If dynamic routing is used, it will be necessary to verify that the routes are learned properly on the target firewall.  If the network should change during the migration process, then it will be necessary to update the network object groups created to specify the reachable networks to match any changes in routes.

For appliance firewalls such as Cisco or Juniper devices, the routing rules are part of the firewall configuration.  For Check Point firewalls, the routing rules have to be configured using the native operating system syntax provided for configuring the routing instead of via the management server.

Converting Networks and Service Objects

Network and service objects and object groups provide an abstraction for better management of the firewall rule base. Using objects, you can reuse address and service values in multiple rules.  When making changes, you need modify the values only once in the object definition and it will apply to all rules that refer to the object. By using object groups, you can group network and service objects that serve a common purpose and reuse them in multiple rules and rule bases. When a management server is used, global object definitions can be shared across multiple firewall configurations.

Converting object definitions from one firewall platform to another is fairly easy.  This is largely a matter of converting the source syntax to the target syntax.  The challenge is in reusing existing object groups and detecting conflicts when the target firewalls are managed using a management server that shares global objects between multiple firewalls.

In such environments, it is not sufficient to simply convert the object definitions.  Objects with same content but different names and objects with the same name but different content might already exist in the target management server.  In addition to identifying potential conflicts with existing objects, we might also want to reuse  existing objects where the content is the same.  This requires that we identify the congruent object definitions in the target management server and replace the corresponding object references from the source configuration with references to objects in the management server.

This becomes a significant process issue when migrated configurations are developed in a staging environment and then have to be pushed to production systems.  It is typically not realistic to freeze the production systems for the duration of the entire migration process.  Even if a snapshots are taken at the start of the migration process, the production system is likely to change while the migrations are being worked on.  When the migration is complete, there may still be conflicts between the migrated and production object definitions that must be identified and resolved.

In the next blog post, we will examine some of the issues involved in migrating ACL or filtering rules.

Recently we have seen a problem in some organizations where a management console was being used to automatically generate firewall rules across multiple firewalls.  These consoles tend to generate lots of very simple, primitive rules that specify a single source, destination, and service and that do not use object groups.  Over time, the console will generate lots of these primitive rules, resulting in very large rulesets. This problem becomes compounded when the network administrators decide to switch to a different firewall management product.  Suddenly they are faced with a large and complex rulebase that is difficult to understand and manage.

The size of the rulebase in each firewall can be significantly reduced by a process, based on rule aggregation, that creates large address and service objects and new replacement rules that use them. This has the potential of providing order of magnitude reductions in the number of rules in the rulebase.

The process consists of initially creating objects on one (source, destination or service) dimension at a time, based on the number of rules that the object covers in that dimension. This step requires powerful analysis capabilities and  cannot be done manually or by using simple scripts. The initial step is followed by further iterations to create new replacement rules that contain objects in two dimensions, and then finally in all three dimensions. Athena FirePAC, unlike other firewall analysis products, provides features such as content-based rule search and filtering on source, destination, and service elements to quickly isolate the rules that can be aggregated.  FirePAC also has the capability to create scripts that generate the replacement rules at each iterative step to minimize errors.

When multiple firewall configurations are involved, it is also good practice to standardize the objects used across the firewalls for better management. Athena Security has special tools and processes for object standardization and automated generation of all the firewall configurations using the standardized objects.

Check out FirePAC’s features for rule and object cleanup.  You can download it for free and have it up and running in minutes.

One of the more difficult things to understand in a firewall is network address translation (NAT). There are so many varieties: NAT, PAT, twice-NAT, bidirectional NAT, dynamic NAT.  It’s difficult to keep them all straight.  You never know if a particular IP is mapped or real.  Does the IP in an ACL refer to an actual host or to the packet coming in from the Internet?

The recent release of Athena FirePAC v4.2 includes a new capability called the NAT Browser. This feature displays all of the address translations in your config in a very tabular format that makes it very easy to understand what translations are being applied to data traffic passing through your firewall.

You can find the NAT Browser in FirePAC by double-clicking on a firewall in your inventory.  This will open the Firewall Details view on the config and display the Security Rules tab.  Next to the Security Rules tab is the new NAT Browser tab.  Click on the screenshot below to see a full-size image.

The table depicts all of the address translations in the configuration in a standard format.  The Source, Destination, and Service columns indicate the original address and service values prior to the address translation being applied.  The Trns. Src. (translated source), Trns. Dst. (translated destination), and Trns. Svc. (translated service) columns indicate the address and service values after the address translation has been applied.  On the far right are shown the actual CLI commands in the configuration that apply the indicated translation. At the top of the view are fields that let you search the address translations for specified IP and port values.  You can search for either original or translated values.  Not only does this make it trivial to determine what translation will be applied to a given IP address, but you can determine the specific commands that make it so as well.

I expect you’ll find this new feature very useful in decyphering what’s going on inside your firewall.  Check it out and let me know what you think.

The new release of Athena FirePAC v4.2 adds several capabilities to the comprehensive firewall audit and operations tool you’ve come to know.  The most exciting of these is Rule Tracker.  This tool allows you to record the reason why individual rules exist and track the changes in documentation as the rules change and evolve over time.  Documenting the business purpose of firewall rules has become a pressing issue with compliance auditors, such as PCI QSAs, demanding to know the reason for each rule in the firewall.  Traditional change management systems keep track of change requests, but knowing which rules were modified because of a specific CMR ticket is virtually impossible.  Network engineers typically feel the need to deploy changes quickly and disdain cumbersome process-heavy change systems that get in the way of making it work now.  Documenting the change takes a distant second-place as the next fire comes along and needs to be put out.

Rule Tracker offers an easy way to set things right.  Unlike elaborate systems that may involve months of process re-alignment, Rule Tracker recognizes that teams collaborate far more easily with spreadsheets.  By using a spreadsheet approach and built-in intelligence to make the system highly user-friendly, Rule Tracker is flexible enough to be used in any change process.  It compares two versions of a configuration and identifies precisely what changed.  The changes can be exported to a spreadsheet format and the missing documentation can be added at any time, based on the changes that were made.  The resulting annotations can then be imported back into FirePAC from the spreadsheet format, where they will be automatically retained and are available for review and reporting.  While the system is designed to keep documentation current on a perpetual basis, consultants will also find the tool a handy way to bring clients up-to-date on regularly scheduled intervals.

I’ve recorded a video that shows how Rule Tracker works, which you can view here.  Check it out!

In an upcoming post, I’ll be describing another new feature in FirePAC v4.2, the NAT Browser.

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.

When something goes wrong in a firewall, finding the problem can be difficult.  Manual review of a configuration or analyzing traffic flow is tedious, frustrating, and error-prone.  In particular, NAT rules can trip the unwary, as evidenced by the frequent posts on NAT problems in the Cisco Users forum. For Cisco users NAT can be specified in a multiplicity of ways, and the Cisco documentation is not always a model of clarity. Due to the complexity of the configuration or the complex interplay of NAT rules, not being able to clearly understand the effect of NAT on packet flow can result in unanticipated access or denial of legitimate access to the network.

Let’s take a look at a real-life example of NAT confusion that we found in the Cisco support forums.  Although it is a simple example in terms of NAT semantics, the user found its analysis difficult and confusing enough to post it.  In his example, the author has a simple three-port PIX firewall, with the inside interface bound to 10.1.10.2 and the DMZ interface bound to 192.168.1.2.  He wanted all packets from inside going to the DMZ to be NAT’ed to 192.168.1.254.  So a global NAT rule was inserted.  Below is a fragment of the ACL rules the configuration that frames the discussion.  The complete configuration can be viewed here.

access-list dmz permit tcp host 192.168.1.1 host 10.1.10.1
access-list dmz permit udp host 192.168.1.1 host 10.1.10.1
access-list dmz permit tcp object-group db_svrs 10.1.10.0 255.255.255.0 eq 118
access-list dmz permit udp object-group db_svrs 10.1.10.0 255.255.255.0 eq 118
access-list NO_NAT permit ip host 10.1.10.1 host 192.168.1.1
access-list inside permit tcp host 10.1.10.1 host 192.168.1.1 eq smtp

Here are the NAT rules of interest.

global (dmz) 1 192.168.1.254
nat (inside) 0 access-list NO_NAT
nat (inside) 1 0.0.0.0 0.0.0.0
static (inside,dmz) 10.1.10.0 10.1.10.0 netmask 255.255.255.0

By examining the traffic flow data, the poster found that in fact no packets were being source-NAT’ed to 192.168.1.254.  The question is: why?

Using the Configuration Debugger tool in Athena FirePAC, it becomes very easy to determine the answer.  The Debug tool allows you to trace the flow of sets of packets through a firewall and determine precisely the ACL rules, NAT rules, and routes acting on each packet.   We’ll issue a debug query using the following parameters:

src=10.1.10.0/24, dst=192.168.1.0/24, svc=TCP

The Debug query result shows us that only two ACLs and the implied deny are involved in filtering these packets.  Here are the two ACL rules:

46 access-list inside permit tcp host 10.1.10.1 host 192.168.1.1 eq smtp
47 access-list inside permit tcp any any object-group web_svcs

The completed set of permitted packets that match these rules are identified by the Debug tool and shown in the following table.

As identified in this table, the NAT rules that apply here are shown below.

45: access-list NO_NAT permit ip host 10.1.10.1 host 192.168.1.1
64: nat (inside) 0 access-list NO_NAT
66 static (inside,dmz) 10.1.10.0 10.1.10.0 netmask 255.255.255.0 0 0

The Debug tool identifies the effect of these NAT rules, as shown in the following table.

Through this result, we see that any packets coming from the 10.1.10.0/24 network are being source NAT’ed to have the same source addresses as the original, although it happens because of different rules.  We also see that the NAT/global rule added to transform the source addresses of the packets originating from the inside interface do not have any effect because of the precedence in which the different types of NAT rules are applied in the Cisco PIX firewall.

The fix is relatively straight-forward.  The static rule at line 66 should be removed.  Once gone, the NAT/global rule will have the proper effect and all packets originating from the 10.1.10.0/24 network will be properly source NAT’ed, with the exception of packets with a source of 10.1.10.1, which will not be NAT’ed because of the NAT exemption rule at line 64.

As we have seen, the FirePAC Configuration Debugger is a very powerful tool for figuring out what’s going on inside a firewall configuration. It will identify the exact packets that are allowed for entire ranges of source and destination addresses and services and it will identify the specific rules that act upon each packet. The analysis is performed completely offline and does not require any data to be put on the network.  The solution is available now for all Cisco Security Appliances, Juniper Netscreen firewalls, and Check Point FW-1.

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.