Migrating from a Check Point to a Cisco Environment: Firewall … · Firewall Rule and Policy Conversions and the Cisco Security Conversion Tool ... Lab Testing

Operational Best Practice

Migrating from a Check Point to a Cisco Environment: Firewall Conversion Best Practices

The best practices and tools used by Cisco Advanced Services to help customers convert from a Check Point firewall environment to a corresponding Cisco environment.

Introduction This document summarizes the recommended firewall conversion best practices developed and refined during the course of several actual customer conversion projects undertaken by Cisco’s Customer Advocacy (Advanced Services) organization. These best practices greatly increase the overall success of a Check Point-to-Cisco firewall conversion project, and reduce the time required for a migration. The phases that must be addressed in any migration are reflected in the sections of this document:

• Evaluation of security policies – This assessment ensures that the new Cisco deployment complies with the overall security goals and management practices for the organization.

• Use of the Cisco Security Conversion Tool – This tool greatly reduces the amount of time required for the conversion of firewall rules and policies, minimizes the amount of work that must be done manually, and reduces the chance for error during the conversion. For example, converting a site with 100 to 200 firewall appliances would typically require manually converting thousands of rules. This process, if done by a skilled, experienced engineer would take approximately six to eight weeks of work (with much more time required for a conversion novice). With the Cisco Security Conversion Tool, this process is automated and can be accomplished in a few days, with much less error-prone results.

• Plan the complete migration – The installation team must plan and rehearse all the steps leading up to the go-live event for deployment of the new hardware.

• Review potential pitfalls, tips, and tricks – The migration plan should be adjusted as needed to take into account the recommendations from the Cisco Advanced Services team, based on lessons learned during dozens of migrations.

These phases encourage a migration process that follows the best practices developed by Cisco Advanced Services, and contribute to the successful outcome of any Check Point-to-Cisco firewall migration project.

Scope of the Firewall Conversion Best Practices The documentation included with Cisco firewall solutions provides the required information for properly deploying the hardware. This paper focuses on the steps that must precede and follow the hardware installation to ensure a successful migration. The most difficult steps focus on the conversion of firewall rules and policies. Section Two explains the conversion process and describes how the Cisco Security Conversion Tool greatly shortens the time required for this otherwise complex part of the migration.

© 2005 Cisco Systems, Inc. All right reserved. Important notices, privacy statements, and trademarks of Cisco Systems, Inc. can be found on Cisco.com

Page i

Manual vs. Automated Conversions Some third-party software vendors market tools that they claim can automate firewall conversions. Cisco Advanced Services has found that these tools sidestep important security policy evaluations that are necessary for any successful conversion. Inherent differences between Check Point and Cisco firewalls make it essential that customers evaluate and determine the business requirements and optimal security policies for their particular environment. For example, consider these points of comparisons between Check Point and Cisco firewalls:

• Feature sets: Differences in features and feature default settings can result in security policies that are being enforced without the customer’s knowledge.

• Rule enforcement: Check Point firewalls enforce rules globally, without regard to the interfaces through which data passes. Cisco enforces firewall rules on an interface-specific basis.

• Level of security: Check Point firewalls result in fewer restrictions imposed on systems and users. Cisco solutions, in contrast, enforce a more controlled, secure environment. Many Check Point users are not aware of the “loose” controls in their current environment. It is essential that they understand the additional layers of protection applied with Cisco solutions and the required policy adjustments to define the operation according to their needs.

Due to these fundamental differences, no firewall conversion tools can guarantee a drop-in Cisco firewall configuration to replace all Check Point FireWall-1 configurations. Customers that have attempted conversions by solely relying on these tools invariably uncover many pitfalls during conversion.

Recognizing that tools are a great help when properly designed and applied, Cisco recommends its Security Conversion Tool be applied as part of an overall methodology taking into account all of the security issues that can affect a migration. The best practices described in this document will help avoid pitfalls by correctly applying the tool in combination with a comprehensive migration methodology.

© 2006 Cisco Systems, Inc. All right reserved.

Important notices, privacy statements, and trademarks of Cisco Systems, Inc. can be found on cisco.com Page ii

ii

Contents

Introduction.................................................................................................................................................... i Scope of the Firewall Conversion Best Practices ...................................................................................... i Manual vs. Automated Conversions ......................................................................................................... ii

Section 1: Assessing Business Requirements .....................................................................1-1

Management............................................................................................................................................... 1-1 Cisco PIX Device Manager ................................................................................................................... 1-1 CiscoWorks VPN/Security Management Solution (VMS) 2.x ............................................................. 1-1 Cisco Security Manager (VMS 3.0) ...................................................................................................... 1-1 Command-Line Interface (CLI) Control................................................................................................ 1-1 Real-Time Event Viewing ..................................................................................................................... 1-1

Audit Requirements ................................................................................................................................... 1-2 Failover Policy........................................................................................................................................... 1-2 Event Correlation and Anomaly Detection................................................................................................ 1-2

Section 2: Converting Firewall Configurations .....................................................................2-1

Firewall Rule and Policy Conversions and the Cisco Security Conversion Tool ..................................... 2-1 Earlier Software Release Levels ................................................................................................................ 2-2 The Conversion Process with the Cisco Security Conversion Tool .......................................................... 2-2

Hardware Configuration and Route Table Conversion ......................................................................... 2-2 NAT Policy ............................................................................................................................................ 2-3 Firewall Policy....................................................................................................................................... 2-3 Advanced Firewall Features .................................................................................................................. 2-3

Section 3: The Migration Plan.................................................................................................3-1

Check Point FireWall-1 Considerations .................................................................................................... 3-1 Check Point Rule Sets............................................................................................................................ 3-1 Global nature of Check Point Objects ................................................................................................... 3-1

Pre-Implementation Planning .................................................................................................................... 3-2 Lab Testing ............................................................................................................................................ 3-2 Implement a Production Firewall Freeze............................................................................................... 3-2 Implement an Application Freeze.......................................................................................................... 3-2 Create a Detailed Network Drawing...................................................................................................... 3-3 Develop Implementation and Fall-Back Scripts .................................................................................... 3-3 Develop a Connectivity Test Plan ......................................................................................................... 3-3 Develop an Application Test Plan ......................................................................................................... 3-4 Develop a Master Implementation Plan................................................................................................. 3-4 Pre-Position Packet Analyzers............................................................................................................... 3-4 Perform a Walkthrough of the Master Implementation Plan................................................................. 3-5 Open a Proactive TAC Case .................................................................................................................. 3-6 Perform a System Health Check ............................................................................................................ 3-6

Section 4: Tips, Best Practices, and Pitfalls..........................................................................4-1


Important notices, privacy statements, and trademarks of Cisco Systems, Inc. can be found on cisco.com Page iii

iii

Tips ............................................................................................................................................................ 4-1 Tip #1 ..................................................................................................................................................... 4-1 Tip #2 ..................................................................................................................................................... 4-1

Best Practices ............................................................................................................................................. 4-1 Best Practice #1 ( ) ................................................................................................................ 4-1 Best Practice #2 ( ) ....................................................................................................................... 4-1 Best Practice #3 ( ) ................................................................................................................ 4-1 Best Practice #4 ( ).................................................................................................................... 4-1 Best Practice #5 ( ) ................................................................................................................ 4-2 Best Practice #6 ( ).................................................................................................................... 4-2 Best Practice #7 ( ): Virtual Firewalls................................................................................... 4-2 Best Practice #8 ( ) ....................................................................................................................... 4-2 Best Practice #9 ( ): Virtual Firewalls.......................................................................................... 4-2 Best Practice #10 ( ).................................................................................................................. 4-2 Best Practice #11 ( ) ..................................................................................................................... 4-2 Best Practice #12 ( ) .............................................................................................................. 4-2 Best Practice #13 ( ) ..................................................................................................................... 4-2 Best Practice #14 ( )......................................................................................................................... 4-3 Best Practice #15 ( ): Cisco PIX Device Manager/ASDM Environments................................... 4-3 Best Practice #16 ( ) ............................................................................................................................ 4-3 Best Practice #17( ): Implementation........................................................................................... 4-3

Pitfalls ........................................................................................................................................................ 4-3 Pitfall #1 ( ): Asymmetric Routing Across Disparate Firewall Interfaces ....................... 4-3 Pitfall #2 ( ): Secondary IP Addressing on Interfaces........................................................... 4-3 Pitfall #3 ( ): Split-Horizon Behavior ................................................................................... 4-3 Pitfall #4 ( ) ........................................................................................................................... 4-4 Pitfall #5 ( ) ........................................................................................................................... 4-4 Pitfall #6 ( )................................................................................................................................ 4-4 Pitfall #7 ( ) .................................................................................................................................... 4-4 Pitfall #8 ( )................................................................................................................................ 4-4 Pitfall #9 ( )................................................................................................................................ 4-4 Pitfall #10 ( )....................................................................................................................................... 4-4 Pitfall #11 ( ): Cisco PIX Device Manager/ASDM................................................................... 4-4 Pitfall #12 ( ): The Cisco Security Conversion Tool.......................................................................... 4-5 Pitfall #13 ( )..................................................................................................................... 4-5

Section 5: Deployment ............................................................................................................5-1

Implementation Checklist .......................................................................................................................... 5-1 Further Recommendations ......................................................................................................................... 5-5 Conversion to Multiple Cisco Firewall Contexts ...................................................................................... 5-5

Appendix: Questionnaires ..................................................................................................... A-1


Important notices, privacy statements, and trademarks of Cisco Systems, Inc. can be found on cisco.com Page iv

iv

Section 1: Assessing Business Requirements

In general, the interface-specific nature of Cisco® firewalls results in stricter—and therefore more secure—implementations of organizational policies compared to Check Point FireWall-1 deployments. While the Cisco solution will provide excellent security and inevitably tighten controls on the customer’s infrastructure, a successful conversion requires that companies more thoroughly understand the business requirements that will be supported after the migration to a Cisco firewall solution.

To assess these business requirements, the following topics should be discussed as the first step in the migration planning process.

Management How will the environment be managed? Considerations should be made based on the customer’s preferences for management platforms.

Cisco PIX Device Manager Cisco PIX® Device Manager provides security management and monitoring services for Cisco PIX security appliances (running Cisco PIX Security Appliance Software Version 6.3 and prior) and the Cisco Catalyst® 6500 Series Firewall Services Module (FWSM). For environments using Cisco PIX Device Manager, select the option for “no-object nesting” when using the Cisco Security Conversion Tool (SCT). Some meta-data associated with description of objects may be lost during the conversion. Check Point administrators will typically only use Cisco PIX Device Manager for very simple firewall rule sets. Cisco PIX Device Manager has no database of its own; it uses the configuration of the firewall to maintain information. Changes to the configuration to accommodate Cisco PIX Device Manager should be made clear to the system administrators.

CiscoWorks VPN/Security Management Solution (VMS) 2.x CiscoWorks VMS provides security management for Cisco devices. Cisco is not adding support for additional features and new devices in CiscoWorks VMS. Customers that require provisioning for Cisco firewalls, VPNs, and intrusion prevention systems (IPSs) should consider the successor product Cisco Security Manager. Existing customers can plan their migration to take advantage of significant enhancements in the new software. CiscoWorks VMS 2.x is not capable of administrating firewall functions. CiscoWorks VMS is frequently required for revision control and workflow management. For more information about CiscoWorks VMS deployments, including Cisco Advanced Services best practice documents on the subject, please visit www.cisco.com.

Cisco Security Manager Cisco Security Manager provides an excellent management platform for firewall administration. Cisco Security Manager supports the same revision control and workflow management as CiscoWorks VMS 2.x, while maintaining the logical nature of rules rather than the line-by-line command-line interface (CLI) of CiscoWorks VMS 2.x or Cisco PIX Device Manager.

CLI Control Rule sets with nested objects are challenging and tedious to administer using CLI. A Check Point administrator will typically require an easier-to-use solution. However, expect Check Point administrators to learn how to use common CLI troubleshooting tools.

Real-Time Event Viewing Check Point provides a very good application for real-time viewing of traffic passing through the Check Point firewall. It is important to understand traffic monitoring requirements and how those requirements will be met for the Cisco firewalls. CiscoWorks Security Information


Page 1-1

http://www.cisco.com/

Management Solution (SIMS) and Cisco Security Monitoring, Analysis and Response System (Cisco Security MARS) 4.2 or later can be used to monitor the Cisco firewalls.

Audit Requirements How will audit requirements be met? Options include:

• Automated Cisco Security Manager/CiscoWorks VMS configuration check • Syslog of all configuration changes • Syslog of all denied traffic • Syslog of all permitted traffic

Failover Policy Investigate the current policy to determine the requirements for failover after migration. For example, does the current failover policy (with Check Point) dictate a failover when a single interface fails? If going to a multiple context environment, does the failover policy need to be altered? Is the existing Check Point firewall clustered or using Virtual Router Redundancy Protocol (VRRP) for redundancy?

Event Correlation and Anomaly Detection Questions to ask about this topic include:

• Is there a product currently in place that is providing event correlation and anomaly detection? • Is this a third-party product like NetForensics or ArcSight that can be used for Cisco firewalls? • Is Check Point Eventia being used? Can it be replaced by Cisco Security MARS? It is a Cisco Advanced Services best practice to ensure that a system is in place for this function. Cisco has two products that customers should consider: Cisco Security MARS, and Cisco SIMS (NetForensics).


Important notices, privacy statements, and trademarks of Cisco Systems, Inc. can be found on cisco.com Page 1-2

2

Section 2: Converting Firewall Configurations

Prior to the deployment of the new hardware, it is important to understand the configuration conversions that must be addressed. Some of these can be greatly streamlined with the Cisco SCT; some conversions must be done manually. The use of the tool also varies depending on the release level of the network software. The Cisco SCT converts a single Check Point 4.x or NG device configuration to a single Cisco configuration file for Cisco ASA Software/Cisco PIX Security Appliance Software Version 7.0 or higher, and Cisco Catalyst FWSM Version 2.3 or 3.1.

Firewall Rule and Policy Conversions and the Cisco SCT For migrating from Check Point to Cisco firewalls, four areas of configuration conversion must be addressed:

• Basic hardware configuration: Neither time-consuming nor prone to human error, this step of the conversion is the easiest. It includes the creation of the route.cfg file.

• Network Address Translation (NAT) policy: Manual conversions for NAT policies can range from easy to difficult or impossible. • Firewall policy: The firewall policy conversion is consistently the most complex step in any firewall migration project. It is difficult, time-

consuming, and extremely prone to human error. • Advanced firewall features: Typically identified during the pre-migration interview process, the advanced firewall features must be

converted on an application-by-application basis. Performing this step manually varies according to the application requirements. It is the most overlooked area for a conversion and therefore the most likely source of complications during the migration.

The Cisco SCT can be used to automate some or all of the above configuration conversions within environments supporting Cisco PIX/ASA Software Version 7.0 or later, or Cisco FWSM 3.1 or later. For earlier software releases, some or all of the conversion must be done without the assistance of the Cisco SCT.

To determine if a particular conversion can employ the Cisco SCT, answer the following questions:

• Is the Check Point software version 4.x, 5.0 (NG/NG AI), or 6.0 (NGX)? If not, the Cisco SCT cannot be used.

• Is Check Point running on a Nokia platform or on SecurePlatform? If yes, follow the directions in the Cisco SCT readme notes. If not, then the routing table for the Check Point firewall will have to be manually converted and supplied for the Cisco SCT. The format is explained in the Cisco SCT readme documentation. Please note that there are no spaces in the route.cfg file.

• Is Check Point running virtual firewalls? If so, the right files must be gathered for each virtual firewall. Virtual firewalls are only available with the Check Point VSX product. This is not fully supported by the Cisco SCT, so conversion issues will likely arise. Luckily, the use of virtual (or transparent) firewalls is rare.

• Is the Check Point firewall to be converted to multiple Cisco firewalls or contexts? Please refer to the section in this document that discusses this topic. Note that the Cisco SCT does not convert a single Check Point firewall policy into multiple firewall policies. Splitting a Check Point firewall policy into multiple Cisco firewall contexts (virtual firewalls) must be done manually.

• Is the Check Point firewall performing NAT?


Page 2-1

There are some NAT features that Check Point supports that Cisco does not. Review the Check Point NAT policy for details.

• Is the Check Point firewall performing VPN services (for example, IPsec terminations)? The Cisco SCT does not convert VPN configurations. The FWSM does not support VPN service termination. The replacement of a Check Point gateway that functions as a client-to-site VPN termination device will require the Check Point VPN-1 SecureRemote software to be uninstalled from remote devices and the Cisco VPN Client to be deployed. If the customer is using Check Point VPN-1 SecureClient, then they are likely using desktop firewall features that must be configured and enabled on the Cisco device to manage the clients. Cisco Security Agent may also be used to replace the desktop firewall.

• Is the Check Point firewall performing any IDS/IPS services? The set of rudimentary IDS/IPS services Check Point provides is called SmartDefense. These configurations are typically global and are not converted by the Cisco SCT, but many similar functions are provided by the service policy rules in Cisco PIX, ASA, and FWSM software, and others are provided by Cisco IDS/IPS services.

• Are you converting to a supported Cisco firewall software release? If not, please review the next section to determine what steps can be assisted with the Cisco SCT.

Earlier Software Release Levels Although the Cisco SCT cannot be used in all steps of a conversion involving software releases earlier than Cisco PIX/ASA 7.0 or Cisco FWSM 3.1, the tool can still be used to avoid some of the manual conversion steps. For example, the Cisco SCT can convert the firewall rules (ACLs), leaving users to manually convert the other easier areas of configuration. The only caveat is that FWSM 2.x code and code before Cisco PIX Security Appliance Software 7.0 does not support ‘disabled’ rules. These will need to be manually removed from the output of the Cisco SCT.

Alternatively, the Cisco SCT can be used to convert configurations into Cisco Security Manager-friendly configurations. Within Cisco Security Manager, policies and different aspects can be copied from one device to another, independent of versions. This will speed the process, but it will not be as simple and direct as importing to the correct platform and version.

The Conversion Process with the Cisco SCT

Hardware Configuration and Route Table Conversion The basic hardware configuration is easily accomplished manually. The other part of this initial conversion step involves the creation of a seed routing table (the route.cfg file) required for the other conversion steps that can be accomplished using the Cisco SCT. Plan on creating the initial route.cfg file manually. This is typically easy; however, an unruly routing table can make this a time-consuming and error-prone task.

If there is a Nokia platform supporting the Check Point firewalls, the Cisco SCT can input the Nokia IPSO configuration output to the Cisco SCT to automatically generate the new route.cfg file. In this case, you will need to update interface names and security levels and prune out any unused interfaces from the generated route.cfg file. This occurs because the Cisco SCT has no way to evaluate the interface details provided by Nokia IPSO. Even with this manual step required, the use of the Nokia IPSO information is recommended.

For environments that do not include Nokia platforms, the route.cfg table must be manually generated using information from the ‘netstat –rn’ command. The output from this command will vary, with codes indicating which interfaces are direct connected, host routes, network routes, etc. Examples that indicate how to interpret the codes include:

• Interfaces with IP addresses: 10.10.10.0 10.10.10.2 U 1 347 qfe0 A ‘U’ flag and the presence of an interface ‘qfe0’ in this example indicate an interface with an assigned IP address of 10.10.10.2.



2

• Interfaces with secondary IP addresses: 10.10.12.0 10.10.12.4 U 1 262673 qfe5 20.10.12.0 20.10.12.103 U 1 0 qfe5:1

( ) In this example there are two IP addresses assigned to an interface named ‘qfe5.’ The secondary address on interface ‘qfe5:1’ is an indication that Check Point secondary IP addressing is being used. Secondary addressing is not supported on Cisco firewalls.

Note: If the ‘qfe5:1’ has an IP address on the same IP network as ‘qfe5,’ this is probably a ‘shared’ Check Point cluster IP address. This is not a problem unless there are virtual interfaces residing on differing IP subnets.

• Network routes: 10.0.0.0 10.116.130.1 UG 162060382 This shows a route to a 10.0.0.0 network, but what is the correct mask? 255.0.0.0? Host routes:

10.15.1.2 10.10.10.2 UGH 1 0 This is a host route to 10.15.1.2 with a network mask of 255.255.255.255. Notice the flag of UGH.

NAT Policy Check Point supports some NAT features that Cisco does not. In these cases, a workaround must be engineered on a case-by-case basis. There may be Check Point NAT configurations that the Cisco SCT cannot convert. Review the ‘errors’ and ‘warnings’ returned by the Cisco SCT to ensure that no issues were encountered.

Firewall Policy For the firewall rule conversion process, what would otherwise take 160 man-hours can be done in less than a minute with far fewer errors with the Cisco SCT. Review the ‘errors’ and ‘warnings’ returned by the Cisco SCT to ensure that no issues were encountered.

Advanced Firewall Features The Cisco SCT considers administrative access to the firewall an advanced firewall feature. The tool does not attempt to configure administrative access components of the configuration. These are included with the other advanced features that must be identified during the pre-migration ‘interview’ process on an application-by-application basis.



3

Section 3: The Migration Plan

Check Point FireWall-1 Considerations Experience has shown that Check Point firewall administrators perceive their firewall rules to be well-organized and “clean.” However, a comparison of the Check Point and Cisco features brings to light a number of areas in which the Cisco solutions enhance overall security.

Check Point Rule Sets Some Check Point rule set features allow loose or sloppy definitions. For example, the Check Point keyword “any” for a source or destination is applied regardless of the interface. When converting to a Cisco environment, a rule is defined on every Cisco firewall interface. Similarly, there will likely be a number of interface rule sets that will have the corresponding Check Point firewall rule deleted during conversion. Customers must be aware of these facts to ensure that the new Cisco definitions reflect the business needs. The Cisco rule definitions result in tighter controls and an increased awareness of the need for comprehensive security policies.

While Check Point rule sets tolerate sloppy definitions, a security-savvy firewall administrator can implement a tightly controlled environment by making appropriate adjustments to the default Check Point values. If this is the case, the Cisco SCT may generate unnecessary rules that clutter the rule set and require manual adjustment.

There will be rules after the conversion that will require manual pruning. If a Check Point firewall allows ‘any’ host to access a particular device, the Cisco SCT will apply that rule to every interface on a Cisco firewall. Often, it is the intent of the firewall administrator to allow Internet access to a particular host and not necessarily allow DMZ or inside access to that host. Although the conversion tool provides the same effective policy as the original Check Point firewall configuration, most administrators will want to manually prune these rules from some of the interfaces of the Cisco firewall.

NOTE: It is highly recommended that the Check Point rule sets and objects be scrutinized and “cleaned up” prior to conversion. There is a significant risk of a failed migration if the Check Point rule set is first converted, followed by attempts to clean up and de-clutter the converted rule set. Issues will arise during the deployment of the resulting configuration.

Global Nature of Check Point Objects Check Point administrators often group networks and hosts together within an object, from a strictly functional perspective. The Cisco Advanced Services best practice involves defining objects in an interface-relevant manner. During a Check Point firewall conversion, this results in objects that have networks and hosts that reside on multiple firewall interfaces.

If a source object includes members that reside on another interface (compared to the one for which the rule set is applied), the rule set is allowing the opportunity for inappropriate traffic to pass through the firewall. This creates the possibility of a device spoofing a source address of that invalid object member. In essence, this is nothing more than the same level of security previously enforced with the Check Point solution. The Cisco SCT will parse through the Check Point source objects to automatically generate an interface-specific object. During this process, it will parse out non-relevant members of source objects such that only relevant members of source objects remain.

Given the global nature of Check Point objects, rules may be applied inappropriately to interfaces on which they should not reside. This is generally an issue with rules that use the keyword ‘any’ for a source or destination address. These rules will need to be manually parsed out.


Page 3-1

Check Point administrators define objects from a strict functional perspective without consideration of where the members of the object reside. That is, ‘Network X’ may be defined to encompass three networks. Each of these three networks may exist on three different firewall interfaces. The Cisco SCT will clone network objects with members residing off multiple interfaces. In the case of ‘Network X’, there will be three network objects created.

Global Nature of Check Point Architecture

The global nature of a Check Point product allows traffic to arrive on any interface without penalty. Therefore, traffic may reside on one interface and leave on another. Traffic may even arrive on multiple interfaces from a single source device without any penalty. A Cisco firewall does not support this type of traffic behavior. Similarly, a Check Point firewall with the anti-spoofing feature in place will not tolerate such environments. If the Check Point environment can currently support an application while the Check Point anti-spoofing feature is enabled, this is a good indication that a Cisco firewall will operate well within the same environment.

Pre-Implementation Planning After assessing the business needs (Section 1), converting the firewall configurations (Section 2), and reviewing the Check Point firewall considerations, the next steps in the migration involve the development of the detailed go-live plans for the various steps and teams involved in the event. This section covers activities that can be carried out to create these plans. Section 4 provides details about potential pitfalls, tips, and tricks that can be applied to refine migration plans. For the actual implementation phase, Section 5 includes the Cisco Advanced Services implementation checklist for firewall migration projects, and details about some special cases that may be encountered during a migration.

Lab Testing For many organizations, testing in a lab environment is a requirement. For other organizations, a lab environment is considered an unaffordable luxury with limited benefits. Lab environments are expensive from a time and a cost perspective. Benefits include the possible identification of critical issues and pre-implementation verification of application function. However, a lab environment typically cannot duplicate all the production applications. Therefore, only a limited subset of functions can be tested. When application testing is occurring it is important for the firewall administrator to confirm that traffic is flowing as expected through the firewall (looking at xlates and connections). This is extremely important if the application testing is limited to performing pings (see Section 4 for details).

Implement a Production Firewall Freeze At some point, the changes to the production firewall, routing, and switching environments must be suspended. The Cisco SCT saves a great deal of time by automating much of the conversion process; however, the converted configuration must be validated: checked for warning and error messages, and checked for correct conversion of rules and objects. Some portions of the configuration will require manual configuration. Typically, an organization will want to develop a confidence level with the tool, the Cisco firewall, and the management and monitoring applications that are going to be used. At some point, the members of an organization will be ready for the conversion and migration – this is the time to call for a production firewall freeze. Take the configurations from the production environment, convert them, validate them, test them in the lab, and proceed with the implementation.

Implement an Application Freeze Fundamentally, applications in the production environment should behave the same before and after a firewall migration. When ‘things are the same’ in regards to the application, it serves as one measure of a successful migration. When the production firewall enters a change freeze, it makes sense to freeze any changes within the application environment as well. Certainly, any changes that require any routing, switching, or firewall changes will be frozen due to the production firewall freeze above. However, changes are frequently made in the application environment that are not expected to affect routing, switching, or firewall configurations. It is advisable to freeze the application environment as



2

well; however, the risks associated with a dynamic application environment may be mitigated with careful planning of the pre- and post-migration application tests.

Create a Detailed Network Drawing While some consider this step unnecessary, it is essential for a successful migration. All teams—application staff, security staff, routing and switching staff, and outside partners—need a common reference from which to operate. This drawing should be attached to the proactive TAC case to be opened in the event of a critical implementation issue.

There will be a temptation for each cross-functional team to create an individual detailed network drawing. During troubleshooting, cross-team communications will be greatly complicated if multiple diagrams are being used by the various teams involved.

A single detailed network drawing is the first step for synchronizing the cross-functional teams: it provides a common reference and allows the cross-functional teams to synchronize their data, validate/verify their information against other teams’ data, and facilitate communication.

Develop Implementation and Fall-Back Scripts The word ‘script’ means different things to different people. In this paper, the term refers to a detailed implementation plan complete with configuration changes. Scripts may be copied and pasted into the configuration of a router, switch, firewall, etc.

There can be many reasons for migrating from one firewall vendor to another. A migration may be driven by the deployment of other technologies or design changes. A migration can affect IP addresses of servers and thus DNS. It can require that servers be moved to new subnets or new switches, and can coincide with the deployment of content switches or global selection switches. In an ideal world, it’s best to follow the best practice of performing a firewall migration while all other factors remain constant, but reality does not always allow this to occur.

Scripts are necessary to take into account all the other changes that are happening in conjunction with the firewall migration. All changes need to be captured in the form of a script. Likewise, fall-back procedures and detailed configuration changes need to be captured in a fall-back script. While application testing can take a long time, fall-back procedures can be done quickly. Include in the fall-back script the steps that will be taken to capture ‘forensic’ information. This may include logging error messages, saving packet captures, and performing ‘show tech-support’ on all relevant Cisco devices.

Develop a Connectivity Test Plan A frequent issue that arises during implementation troubleshooting is confusion as to which devices, servers, or hosts should be reachable from a particular source. Can traffic get to some devices behind the firewall but not others on the same VLAN? Is the firewall dropping traffic? Is the host or server not responding to connection requests? Does the host or server exist in production or is someone working from out-of-date information? Should the firewall be dropping that traffic because the source is not allowed to communicate with that destination? A great deal of time can be lost chasing non-issues during an implementation window. A connectivity test plan will avoid this wasted effort.

A connectivity test plan identifies what destinations particular test points (source devices) should be able to reach. Suggested test points and issues to address in the test plan include:

• Firewalls: Can the firewall ping directly connected hosts, servers, and routers? Can the firewall ping devices several router hops away? • Router(s) directly connected to the firewall: Can they ping the directly connected firewall interface? Can they ping the directly connected

firewall interface with a source IP addresses upstream from the router? (Refer to Tip #1, Section 4.) Can the pings through the firewall be seen via the capture command? (Refer to Tip #2, Section 4.)

• Inside client: Can it ping hosts/servers? • External (outside) client: Can it ping hosts/servers?



3

• VPN client: Can it ping hosts/servers? A connectivity test plan should be executed at three different times:

• Prior to implementation, on the production network. Results should be analyzed to confirm expectations. • Immediately after the implementation of the new firewall with temporary ‘permit icmp any any’ statements but prior to any application

testing. This provides the connectivity baseline and confirms connectivity. (Please see Pitfall #6, Section 4.) It should be expected that connectivity has been established. Any host-based firewalls, host-based IPSs, or network-based IPSs should be tuned to allow the relevant test points to ping the remote systems.

• Immediately after the successful completion of the first post-firewall implementation with the temporary ‘permit any any’ statements removed. It should be expected that any host-based firewalls, host-based IPSs, or network-based IPSs should be returned to their ‘pre-connectivity baseline testing’ posture/policy. (Please see Pitfall #7, Section 4.)

Develop an Application Test Plan The application test plan is extremely important. It defines what processes must work for the firewall migration to be considered successful. A weak application test plan can result in a good deal of confusion during and after the implementation should problems arise that weren’t identified during application testing. If testing is to be done in the lab, those steps in the application test plan that can be tested in the lab need to be noted on the application test plan. More importantly, steps that cannot be tested in the lab need to be noted on the application test plan. At the end of the implementation phase, the ability to reference what was and was not tested during application testing in the lab will enable critical post-implementation failure analysis.

If the application test plan has a weakness, that is, a particular process was not documented in the test plan, you cannot be guaranteed that the process worked prior to the implementation attempt.

Asking an application team to develop a detailed application test plan, down to the socket level, can be a formidable request. In many cases the application team must use a packet analyzer to determine what port numbers an application uses. Regardless, an application test plan should be much like the connectivity test plan. Test points should be identified from which different levels of access are allowed (for example, from administrator machines versus normal application user machines). At a minimum, the application test plan should indicate step-by-step what the application tester is doing. If the source IP address, destination IP address, and destination port number are known, any required troubleshooting will be greatly simplified.

An application test plan should be executed on the production network prior to the implementation of the new firewall, again during lab testing, and a final time after the successful completion of the connectivity test plan.

Develop a Master Implementation Plan A master implementation plan serves as a tool to improve communications. It is the consolidation of all implementation documentation: conference call information, proactive TAC case number, detailed network diagram, connectivity test plan, application test plan, etc. A vital characteristic of the master implementation plan involves the method for enumerating each step in the plan. When someone states that they are on Step 2.4.3.3, for example, all teams should instantly understand the task or step being discussed.

Pre-Position Packet Analyzers The purpose of deploying packet analyzers (such as Sniffer or Ethereal) is to reduce the time to resolution of issues that arise during the implementation and to capture forensic information for post-implementation analysis. Reducing the time to resolution of implementation issues is accomplished by providing independent verification of the information given by the cross-functional teams. This proves critical when the firewall team claims that they are passing traffic to a particular server, but that server’s team claims that the server is not seeing the traffic. The packet analyzer breaks the impasse.



4

From a post-implementation analysis perspective, packet analyzers are vital for identifying asymmetric routing, dual-homed servers receiving traffic on one interface but sending on another interface, spoofed traffic, Address Resolution Protocol (ARP) collisions, packet retransmissions, and any device that is not performing properly during the establishing of connections.

Perform a Walkthrough of the Master Implementation Plan The purpose of a walkthrough is to improve cross-functional team communications. Individual, functional teams tend to work as a “silo” within their organizations, producing their own diagrams, scripts, test plans, etc. Teams typically do not always review the other teams’ documentation or verifying the other teams’ information against their own data. If the detailed network diagram and network connectivity test plan have been created, and the cross-functional teams have adopted them as a common reference within their documentation, preparations for an effective walkthrough of the master implementation plan are in place. The walkthrough provides a final opportunity for everyone to come together as a single team and review the required tasks.

A major part of the walkthrough is the definition of roles and responsibilities and of the rules of engagement. For example, one migration project might involve the following steps as part of the walkthrough:

• Define two conference call numbers: one for support staff (routing, switching, and firewall support) and one for application testers. • Define a liaison role: an individual that tracks issues from the application testers, collects relevant information (source and destination IP

addresses and port numbers), and provides that information to the support staff. This allows the support team to focus on one issue at a time without impeding the application testing.

• Define lead support roles: individuals who will make major technical decisions. For example, if an issue arises because of a dual-homed server resulting in asymmetric routing, the lead technical staff will decide whether to attempt a workaround and what workaround will be attempted.

• Define lead implementation manager role: the individual who will decide whether the implementation was successful and at what point it is considered completed. In particular, this person blows the whistle for an all-stop, reviews current outstanding issues, and makes the ‘go’ or ‘no go’ call.

• Runners: individuals that will physically disconnect or reconnect the Check Point firewall interfaces, make cable plant changes, and reload servers or other equipment in the instance of equipment issues.

• TAC liaison: the person responsible for opening the proactive TAC case and subsequent engagement of Cisco TAC. This person knows how to request an escalation engineer, a re-queue of the case, an escalation of the priority of the case, and the involvement of the TAC Duty Manager.

In this example, the rules of engagement are as follows:

• Support staff will work on a single issue at a time. Perhaps a connection to a server is not connecting. The team responsible for operating the packet analyzers will immediately look for relevant connection information. The firewall team will be looking for the creation of an xlate and connection and the entry of permit or deny statements in the logs. The firewall team may have an individual using the ‘capture’ feature of the Cisco firewall to determine packet flow. The routing and switching team may be confirming cable plant, VLAN configuration, or routing statements. All cross-functional teams will engage a single issue at a time. Any valid findings will be announced on the support conference call so that all support staff are synchronized.

• Application testers will step through their test plans. Any issues will be explored from multiple test points and the findings passed to the support liaison. Application testers will attempt to identify all test issues as thoroughly and quickly as possible.

• The support liaison will ask detailed questions of the application testers to properly identify the nature of the problem, document the problem, and announce the issue to the support staff. The support liaison will ask any support staff questions of the problem of the application testers. If required, the liaison will ask application testers to re-initiate a particular test to generate relevant traffic for the support staff to



5

troubleshoot. Once support staff believe the problem’s root cause has been identified and resolved, the liaison will ask the application testers for confirmation.

• The lead support staff will determine in what order particular issues will be addressed. For this to be effective, the liaison must document the issues on some shared media—for example, a white board for staff in the same room or a Web-based collaboration space for geographically dispersed teams.

Open a Proactive TAC Case The idea is to open a TAC case as early as a week prior to the implementation date in anticipation of any required assistance during the implementation. The detailed network diagram is uploaded to the TAC case along with any other relevant supporting information. A request is made for a TAC engineer that will be available during the downtime window (this requires coordination of schedules and resources). It is very important to consider time zone differences and scheduling. Essentially you are scheduling a priority-1 ‘network down’ emergency, but opening the case as a priority-3 proactive TAC case. It is possible that your scheduled engineer may be unavailable or may be the wrong engineer for a given problem. That is, you may open the pro-active TAC case in anticipation of a firewall issue but end up encountering a routing and switching issue. Understand the procedures in advanced that will be required to escalate the case to a TAC duty manager or escalation engineer, or to re-queue the case to a different technology team.

Perform a System Health Check It is advisable to perform a health check of relevant systems: checking CPU utilization, memory utilization, interface statistics, etc. If the implementation is going to impact a high-service availability (HSA) environment, check to ensure that active devices are still active and standby devices are still in standby. Perhaps this involves checking Hot Standby Router Protocol (HSRP) groups on routers and active-standby firewall pairs. Check administrative access (internal, external VPN, CLI, terminal server, and GUI) and management server connections for devices that are reporting to HP OpenView, SolarWinds, CiscoWorks, Tivoli, syslog servers, Network Time Protocol (NTP) servers, and any other management platforms.



6

Section 4: Tips, Best Practices, and Pitfalls

This section contains tips, recommended best practices, and pitfalls to avoid.

Tips

Tip #1 Extended pings from a router can source a router interface that is not the nearest interface to the destination device being pinged.

Tip #2 The capture command is simple to use but may take some practice prior to the implementation window. For example, execute ‘capture sniffer1 interface outside interface dmz1.’ Then perform a ‘show capture sniffer1’ to see what packets have passed through the firewall. Note: The capture feature is unpredictable; sometimes the firewall logic will drop traffic prior to the packet ever registering with the capture feature. When in doubt, use an external packet analyzer.

Best Practices

Best Practice #1 ( ) Audit and clean up firewall rule sets prior to or after a firewall migration—do not perform a cleanup after conversion of the rules but before the actual migration to the new hardware. Performing a cleanup during a firewall migration introduces unnecessary risks.

Organizations are frequently tempted to clean up their firewall rule set during the process of the migration. This is natural. The migration process requires that firewall administrators validate the converted configuration as an accurate reflection of the production firewall configuration. During the validation process, the firewall administrators will inevitably discover configuration issues in the production firewall rule set. Avoid the temptation to fix these during the migration; make a note of all the production configuration issues. Either implement them in the production environment and then begin the firewall conversion, or wait to deploy the changes after the successful firewall migration.

Best Practice #2 ( ) Define objects from both a functional and interface perspective. For example, if you have SMTP servers connected to two DMZs, define two objects: SMTP-Server-DMZ1 and SMTP-Server-DMZ2. This is important when using a device manager such as Cisco PIX Device Manager or Cisco Adaptive Security Device Manager (ASDM) to configure a Cisco firewall.

Best Practice #3 ( ) Deploy the Check Point counter-spoofing feature in production prior to considering a conversion to a Cisco environment. If enabling the counter-spoofing feature results in a production issue, resolve these issues prior to proceeding with a conversion to Cisco since the issue is indicative of a situation that will cause a problem in the network.

Best Practice #4 ( ) It is a best practice to enable the following features on a Cisco FWSM, PIX, or ASA: [[on the hardware or the software?]]

• Enable counter-spoofing: ‘ip verify reverse-path’ • Disable proxy-arp, ‘ ’ [[ is this correct? ]]


Page 4-1

• Enable logging

Best Practice #5 ( ) Do not share interfaces across multiple firewall contexts, with the exception of a management interface.

Best Practice #6 ( ) Use a shared management interface for firewall contexts (see Pitfall #5). Using a shared interface is recommended, but not required. Typically, there should not be any static NAT commands for the management interface as the management interface should not be a transit interface for any production traffic. A benefit of using a shared interface for the management network is the de-facto PVLAN behavior of the FWSM—it will not allow one firewall context to communicate to another firewall context.

Best Practice #7 ( ): Virtual Firewalls Place a router (msfc interface) between firewall contexts. Do not directly daisy-chain firewall contexts where one firewall’s interface is directly connected to another firewall’s interface.

Best Practice #8 ( ) Avoid using Policy-Based Routing (PBR). Multicast traffic and PBR do not mix well. PBR typically cannot support high service availability (HSA) requirements. PBR is a more complicated form of static routing.

Best Practice #9 ( ): Virtual Firewalls Use relevant interface names in the system configuration and individual security contexts. This eliminates any possible confusion as to the purpose of any VLAN, regardless of what portion of the configuration is being reviewed. For example, in the system configuration, include: “allocate-interface vlan101 vlan101-outside.” In the security context, include: “nameif vlan101-outside outside security0.” When looking at the system configuration, it is apparent that VLAN 101 corresponds to the outside interface of the relevant context. When looking at the relevant context, it is apparent that VLAN 101 is tied to the outside of the context. Fundamentally these two commands (‘allocate-interface’ and ‘nameif’) perform the virtual cabling of the virtual firewall. By following a best practice naming convention, the virtual cables are essentially well-labeled. This simple best practice reduces the time to resolution of any possible misconfiguration that results in a VLAN being tied to the wrong interface.

Best Practice #10 ( ) Use CiscoWorks VMS or Cisco Security Manager to manage firewalls and security contexts; they support nested objects and software configuration version control and can automatically audit deployed firewalls for unauthorized changes in the configuration.

Best Practice #11 ( ) Secure management servers behind a standalone appliance such as a Cisco ASA platform. The benefits include the use of IPS, firewall, and SSL Proxy VPN access. SSL VPN access in particular allows remote administrators to access the management network over a VPN. Additionally, SSL Proxy VPN will continue to allow administrators to access Web applications and e-mail.

Best Practice #12 ( ) Some specific best practices should be considered when installing the CiscoWorks VMS application. Following Cisco Advanced Services best practice will result in a robust and responsive CiscoWorks VMS application.

Best Practice #13 ( ) Avoid the use of the ‘name’ command. Define network objects instead.



2

Best Practice #14 ( ) If the ‘name’ command is to be used, append to the name of the object its expected network mask in significant bit notation. For example, change the command ‘name george 10.10.10.0’ (with an expected network mask of 255.255.255.0) to ‘name george-24 10.10.10.0.’ This best practice provides a quick and easy means of verifying the consistent use of the correct network mask with the associated named object.

Best Practice #15 ( ): Cisco PIX Device Manager/ASDM Environments Manually create the Cisco PIX Device Manager/ASDM location and group commands. Be careful to not make any mistakes. Place the commands in the order that you would like them displayed (alphabetical or otherwise) via the GUI (Cisco PIX Device Manager/ASDM).

Best Practice #16 ( ) Do not pre-deploy a firewall with the monitoring (for failover) of interfaces enabled. This is especially important for virtual firewalls; some security contexts may already be deployed in production. The primary firewall may initiate failover procedures and become the standby firewall. If nothing else, it is alarming to begin the firewall implementation and find that the secondary firewall is active.

Best Practice #17( ): Implementation A best practice for troubleshooting is to use the CLI of a Cisco firewall. Multiple terminal programs are available that support CLI for a Cisco firewall. Choose a terminal program that can capture all terminal output to a file and use that feature. This may be critical for post-implementation analysis.

Pitfalls

Pitfall #1 ( ): Asymmetric Routing Across Disparate Firewall Interfaces Check Point firewalls are very tolerant of network issues resulting in asymmetric routing due to Check Point’s global enforcement of firewall policy. While this may simplify a firewall administrator’s job, it can cause problems for others. A Cisco firewall will not tolerate such asymmetric routing.

The most common cause of asymmetric routing is multi-VLAN, multi-homed servers. Many customers have servers that have multiple Ethernet interfaces connected to more than one IP subnet or VLAN. This can create an issue where traffic with the source IP address of one server interface is forwarded out a second server interface, frequently due to a default route. That is, a server connected to VLAN 10 and 20 with a default gateway set to an IP address on VLAN 10 may experience traffic being received on VLAN 10 with a source IP address of the server’s VLAN 20 Ethernet interface. Check Point firewalls tolerate this situation by default.

Check to see if Check Point has an anti-spoofing or counter-spoofing feature enabled. If so, the possible scenario described above should not occur or should not have a negative impact during the migration from Check Point to Cisco.

It may be wise to deploy the Check Point anti-spoofing or counter-spoofing feature to verify that this situation does not exist or will not have a negative impact prior to performing a migration to Cisco product. Please see Best Practice #3.

Pitfall #2 ( ): Secondary IP Addressing on Interfaces Secondary IP addressing is not supported on Cisco FWSM, PIX, and ASA platforms.

Pitfall #3 ( ): Split-Horizon Behavior By default, Cisco devices do not allow a packet to be forwarded out the interface by which it was received. Check Point supports this kind of behavior by default. Enable ‘intra-interface’ communications to allow a Cisco FWSM, PIX, or ASA device to support this function.



3

Pitfall #4 ( ) Do not share interfaces across multiple firewall contexts, with the exception of a shared management interface (see Pitfall #5). There are multiple pitfalls associated with sharing interfaces across multiple firewall contexts. Many of these pitfalls can be avoided with a carefully designed deployment; however, there is a particular risk that cannot be mitigated by a careful design: overlapping static NAT translations. Should a static NAT translation on one firewall context be misconfigured, it can negatively impact another firewall context. Further, there is the promise of a future release of code that will remove the requirement to configure some static NAT statements. Should a shared interface be deployed across multiple firewall contexts, static NAT statements would be required going forward.

Pitfall #5 ( ) When using a device management GUI such as Cisco PIX Device Manager and a shared interface for the management network of multiple firewall contexts, exclude any firewall context that supports VPN access for firewall administrators. The Cisco FWSM has a de-facto PVLAN behavior. A remote administrator will not be able to remotely administer a firewall context using a device management GUI. This is not an issue if a centralized management server such as CiscoWorks VMS or Cisco Security Manager is used.

Pitfall #6 ( ) Successful pings through a firewall may give a false confirmation of connectivity. This is due to the fact that Internet Control Message Protocol (ICMP), a connectionless protocol, may pass through the standby firewall and successful responses pass back through the primary firewall. For example, an outside router may be misconfigured with a static route with a next-hop address of the standby firewall instead of the active firewall. When performing a ping, successful replies may be received, but any Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) connections are dropped.

Pitfall #7 ( ) There are frequently implicit Check Point rules that allow ‘icmp’ traffic. Cisco firewalls do not implicitly allow ‘icmp’ traffic.

Pitfall #8 ( ) If ‘names’ is used as an option with the Cisco SCT, meta-data will be lost. Expect that the description of the objects to be converted will be lost. A feature enhancement has been requested that will allow the ‘name’ command to have a description field such that this meta-data will not be lost. Even with this feature enhancement, meta-data may still be lost under some circumstances with the ‘names’ option.

Pitfall #9 ( ) Cisco PIX Device Manager and ASDM do not support nested-object groups. (A nested object is an object with members that are network objects themselves.)

Pitfall #10 ( ) Mixed use of network objects and name commands may result in a named object having the exact same name as a network object. Besides being confusing, this may result in an inconsistent network mask application, which in turn may result in a too broad or too narrow application of a rule.

Pitfall #11 ( ): Cisco PIX Device Manager/ASDM With a large number of objects, some objects may not display correctly in the Cisco PIX Device Manager/ASDM GUI. Some objects may not appear under an interface or as an unknown object. Further, the objects may appear in seemingly random order. (Please see Best Practice #15.)



4

Pitfall #12 ( ): Cisco SCT Administrative access to the firewall is considered an advanced firewall feature, from the perspective of the Cisco SCT. The tool does not attempt to configure administrative access components of the configuration. RSA key generation for SSH or HTTPS access is an example of something that the Cisco SCT will not configure automatically.

Pitfall #13 ( ) Disconnect the Check Point firewall’s interfaces from the network before connecting the Cisco firewall’s interfaces to the network. This avoids ARP collisions should both firewalls have interfaces on the same network (or VLAN). Check Point firewalls experiencing ARP collisions are known to have ‘ceased’—a condition that requires a potentially ungraceful reboot. When preconfiguring and predeploying the Cisco firewall, ensure that the interfaces are not assigned to the same network as the Check Point firewalls until the implementation window.

See Table 1 for other types of pitfalls and recommended actions.

Table 1. Pitfalls and Recommendations Potential Areas for Concern Recommended Course of Action

Generic Pitfalls

Cisco VPN Concentrator deployments Remote management may require the intra-interface command.

Check Point-Related Issues

Concept of “not” objects Manual conversion of “not” objects is required.

SmartDefense settings These settings are not supported by Cisco FWSM.

Cisco-Related Issues

Cisco PIX Device Manager/ASDM does not support nested objects If a customer desires to use Cisco PIX Device Manager or ADSM, “flattening” of objects is required. The Cisco SCT will perform this function.

CiscoWorks VMS supports nested objects but cannot perform system functions such as creating contexts

The follow-on to CiscoWorks VMS, Cisco Security Manager, supports nested objects and system functions on the FWSM. In older environments, the system functions must be completed using CLI.



5

Section 5: Deployment

Implementation Checklist The following checklist summarizes all the steps described in the preceding sections, as well as the steps of an actual go-live event. This list is an example of an implementation checklist used by Cisco Advanced Services. Migration teams can use this checklist as a final review of their own customized implementation plans.

I. Identification of Requirements a. Identify business requirements. b. Identify operational requirements. c. Verify that the Cisco Security Conversion Tool may be used. d. Check for frequently encountered pitfalls.

II. Planning the Firewall Conversion a. Consider notification schedules. Many organizations require a minimum of 30 days advanced notice of downtime windows. b. Consider application process. Many organizations have blackout periods for downtime due to critical business processes

such as end-of-month reporting, etc. c. Consider availability of critical staff. Typically a firewall conversion requires many key staff to be available. Scheduling

around training, vacation, conferences, etc. may be a significant factor. d. Consider the impact of production firewall and application change freezes, if any. e. Budget time for the firewall configuration conversion and validation, lab testing, final validation, implementation script

creation, etc. f. Schedule the implementation window accordingly.

III. Performing the Firewall Conversion a. Capture the required information from the production firewall environment. b. Create a manual routing table. If you have used the output from a Nokia platform, you may wish to adjust the routing table

output from the Cisco SCT then re-run the tool. c. Perform the firewall conversion. It is assumed that the Cisco Security Conversion Tool was used to perform the firewall

conversion. A manual conversion process is too extensive to be listed here. i. Verify that the correct files were used.

ii. If using Cisco PIX Device Manager/ASDM, verify that no nested network objects exist. A nested object is an object with members that are network objects themselves.

iii. Review the ‘Messages’ section of the ‘Conversion Report’. Do not expect the Cisco SCT to convert Check Point specific objects. Are there any objects or rules that will require manual conversion?

iv. Review the ‘Interface’ section of the ‘Conversion Report’. Do the interfaces have the correct names, security levels, and IP addresses? If not, you should correct your manual routing table (route.cfg file) or create a manual routing table if you used the Nokia IPSO output.

v. Review the ‘Route’ section of the ‘Conversion Report’. Validate the routes: Correct interface, network, network mask, next hop IP address? Correct default route? If not, correct your manual routing table.

vi. Review the ‘Name’ section of the ‘Conversion Report’. The area of biggest concern with ‘named objects’ is the consistent use of network mask. Verify that network masks are correct everywhere a ‘named object’ is called.

vii. Review the ‘Network Object Group’ section of the ‘Conversion Report’. Review the converted objects. Be sensitive (1) to objects that have been split due to members residing off multiple interfaces and (2) to objects created to reduce rule set expansion. In the first case, you may want to verify that all members to the new object reside off the referenced interface. Manually prune those that do not belong. In the latter case, you may choose to rename the objects in a more meaningful fashion besides the default ‘net-group-dest-ruleno-23’. It is recommended that you make such changes in the existing production environment (by creating a new, consolidated object in your Check Point environment) then rerun the conversion tool or post-implementation (in your post-migration Cisco firewall environment). Please see Best Practice #1. Does the converted network object contain the same members as the original network object?

viii. Review the ‘Service Object Group’ section of the ‘Conversion Report’. Look for the same kinds of object splitting (here along protocol lines) and object consolidation that was seen earlier. Do not expect all service objects to be converted to a Cisco service object. Much of the validation of the service objects will be done during the rule validation.


Page 5-1

ix. Review the ‘NAT’ section of the ‘Conversion Report’. x. Review the ‘Access Rule’ section of the ‘Conversion Report’. There will be an access list for each interface. Step

through the rules one at a time to verify that the rule converted correctly. Questions to ask yourself: 1. Is this a Check Point specific rule? If it is, it shouldn’t be converted. 2. Does the source object(s) reside off the interface to which the ACL is being applied? If not, it should not

be applied to the interface. 3. Do you see a ‘! Warning:’ message? If so, you have some manual conversion work to perform.

d. Rule cleanup: The Cisco SCT will apply some rules to an interface that do not belong. Most commonly this will be due to a Check Point rule with an ‘Any’ source address; for example, to allow any Internet host to access a DMZ. To reduce the probability of human error, it is recommended that you do not remove these firewall rules now. However, you may find some outdated rules or firewall misconfiguration during the validation process of the converted rules. In essence, you are performing a de-facto firewall audit of your production environment. In these cases you have the following options:

i. Option 1: 1. Production firewall audit 2. Alter the production firewall configuration 3. Re-process the production firewall (Check Point) configurations through the Cisco SCT

ii. Option 2: 1. Document the changes that are required 2. Continue with the firewall migration 3. After migration, deploy the documented changes via any change control mechanisms in place for your

organization. e. (Optional) Initial lab testing: If you are implementing new products or technologies in addition to migrating to a new

firewall environment, significant test time in a lab environment may be required prior to proceeding with the ‘Pre-Implementation Planning’ steps below. In such cases, it is commonplace for the lab testing to become a training ground upon which many of the pre-implementation planning steps depend. For example, if IPS or CSS technologies are to be deployed concurrently with the new firewall environment, it may not be clear what the connectivity or application test plans should be. Further, the detailed network drawing may not be able to be finalized until a network design is verified as feasible in the lab.

IV. Pre-Implementation Planning a. Create a detailed network drawing:

i. Develop a detailed network drawing for the pre-implementation production environment. ii. Develop a detailed network drawing for the post-implementation production environment.

iii. Develop a detailed network drawing for the lab environment. iv. Understand the similarities and differences between the lab and production environments.

b. Develop an application test plan: i. This application test plan will be used to test:

1. In the lab environment 2. In the pre-implementation production environment 3. During the implementation window

ii. Perform the application testing in the production environment: 1. Document the results of the application testing versus expected results. 2. Update the application test plan as needed.

c. Test in a lab environment. i. Establish lab environment:

1. Should correspond to the detailed network drawing for the lab environment. 2. Perform connectivity testing (see Pitfall #6).

ii. Implement a production firewall freeze. Do not allow any changes to the production firewall rule set unless the entire conversion process is to be repeated.

iii. Implement an application freeze. Do not allow any changes to the application environments as this increases the risk to a successful migration.

iv. Perform the firewall conversion based upon the frozen production firewall configuration. This may seem redundant (this appears as Step III), but it is not. Step III will be a potentially time consuming process where you should have learned of any particular issues that you must accommodate. You should be at a point where you can perform the firewall conversion quickly with most, if not all, manual changes having been pre-identified.

v. Perform the application testing: 1. Document the results of the application testing versus expected results. In most environments it is not

possible to test the entire application test plan due to a limited lab environment. Note which tests can and cannot be tested in the lab.

2. For application tests that fail and thus require a change to the firewall configuration:



2

a. Validate any rule changes due to application testing results. Typically, there are three possible outcomes to an application testing issue:

i. The existing production firewall rule set is not correct. 1. This should have been identified in Step IV (b.ii.2). 2. See the two options in Section III (d) above.

ii. The conversion process had a Cisco SCT error or human error 1. Notify Cisco TAC if the tool did not work correctly. 2. Manually correct the configuration if it was human error or an advanced

configuration option that the Cisco SCT does not convert. 3. Document the error and the manual configuration change.

iii. The application environment has a new requirement: 1. Have the application team go through regular change management

channels. See the two options in Section III (d). 2. Note: If you are deploying multiple technologies or solutions concurrently

with the new firewall environment, you may expect for applications to develop new requirements as part of the lab testing process. Further, it will not make sense to apply changes to the production environment where the new technology or solution does not exist.

vi. Conclude lab testing. d. Develop implementation and fall-back scripts. e. Develop a connectivity test plan:

i. Identify ‘test points’ – the places in the network from which connectivity tests will be performed. 1. Outside user 2. Inside user 3. VPN user 4. Firewall 5. Application administrator hosts

ii. Identify ‘test targets’ – the destinations in the network that the ‘test points’ will attempt to contact. 1. Pre-determine what targets should and should not be reachable based upon firewall policy and host

policy (host-based firewall, host-based IPS). iii. Determine deployment location of packet analyzers (Sniffer/Ethereal) on the test plan, detailed network drawing,

or both. f. Develop a master implementation plan. g. Pre-position packet analyzers on the production network. h. Perform a walkthrough of the master implementation plan:

i. Cross-functional review of various implementation scripts, connectivity test plan, network topology, and application test plan.

ii. Define of roles and responsibilities. iii. Define the rules of engagement. iv. Schedule conference bridge(s). v. Identify and collect resources (conference phones, white boards, white boards with embedded scanner/printer,

etc.). i. Open a proactive TAC case. j. Limited pre-deployment of new firewall(s): Do not connect production interfaces to the network (virtual contexts: do not

map VLANs in the system configuration; appliances: assign them to temporary, isolated VLANs ). i. Apply configurations without monitoring interfaces for failover. Please see Best Practice #16.

ii. Apply a temporary ‘permit icmp any any log’ statement in preparation for the first round of connectivity testing.

iii. Connect the management interface. iv. Confirm connectivity to the management interface. v. Confirm management via the management interface (from the inside network as well as VPN access):

1. CLI via Telnet/SSH 2. Cisco PIX Device Manager/ASDM access (only if these will be used) 3. CiscoWorks VMS/Cisco Security Manager access (only if these will be used)

vi. Confirm that syslog/monitoring systems are receiving messages from the firewall. k. Perform a system health check (CPU, memory, crash files, uptime, and HSA components – primary devices still active?):

i. Firewall ii. Routers

iii. Switches



3

iv. Servers 1. Complete the application test plan on the production environment.

V. Implementation a. Final walkthrough of the master implementation plan:

i. Conduct a cross-functional review of various implementation scripts, connectivity test plan, network topology, and application test plan.

ii. Define roles and responsibilities. iii. Define the rules of engagement. iv. Schedule conference bridge(s). v. Identify and collect resources (conference phones, white boards, white boards with embedded scanner/printer,

etc.). b. Perform a system health check (CPU, memory, crash files, uptime, and HSA components – primary devices still active?):

i. Firewall ii. Routers

iii. Switches iv. Servers

1. Complete the connectivity test plan on the production environment. 2. Complete the application test plan on the production environment.

c. (Optional) Back up all system configurations. d. (CLI to firewalls, routers, switches) Enable logging on your terminal services program; for example, HyperTerminal,

Reflections, Putty (see Best Practice #17). e. Start the downtime window:

i. Disconnect the production (Check Point) firewall interfaces. Or isolate them in an isolated VLAN (assuming that you are not performing 802.1Q trunking to the Check Point firewall).

ii. Implement the new firewall(s): 1. Enable the monitoring of interfaces for failover. This step is needed if you pre-deployed the firewall and

turned off the monitoring of interfaces for failover. iii. Perform the routing and switching configuration changes. iv. Perform connectivity testing as per the connectivity test plan:

1. Verify that the expected results are experienced. 2. Verify that the ICMP echo-requests and echo-replies are passing through the firewall. You should have

placed a temporary ‘permit icmp any any log’ statement on each rule set. If you do not see the logs for both echo-requests and echo-replies, verify routing is correct on the routers bordering the firewall (see Pitfall #6).

3. Troubleshoot and resolve any connectivity issues. v. Remove the temporary ‘permit icmp any any log’ rules.

vi. Perform connectivity testing as per the connectivity test plan: 1. Verify that the expected results are experienced. 2. Compare results with that received during the system health check in V-b-iv-1. 3. Troubleshoot and resolve any connectivity issues.

vii. Perform the application testing: 1. Verify that the expected results are experienced. 2. Compare results with those received during the system health check in V-b-iv-2. 3. Troubleshoot and resolve any application issues.

f. Close the downtime window: i. If the migration has been a success, congratulations! And:

1. Clean up: a. If logging levels on the firewalls were altered for troubleshooting purposes, restore them to

the appropriate level. b. If the capture command was used, disable the captures. c. If temporary access was provided to a third party, such as Cisco TAC, remove that access.

2. Back up all system configurations. 3. Save all system configurations (write mem, copy run start, etc.). 4. Prepare for Day 2 operational support:

a. Capture the application test results (this is your proof of what worked and when). Time to resolution of an issue can be affected if you are troubleshooting an issue that is believed to have been previously working.

b. Leave the proactive TAC case open for Day 2 operational support. ii. If the migration has not been successful:



4

1. Capture forensic information: a. ‘show tech-support’ off firewalls, routers, switches, etc. b. Packet capture files. c. Collect all terminal programs (such as HyperTerminal or Putty) output from the migration

window. 2. Initiate roll-back procedures per the fall-back script:

a. Identify routing/switching configuration changes. b. Isolate the Cisco firewall. c. Reconnect the Check Point firewall interfaces. d. Perform application testing per the application test plan. e. Troubleshoot and resolve any issues.

3. Analyze the forensic data to determine a root cause for the outstanding issues. Test in the lab if possible, then try again.

Further Recommendations Firewall migration can be compared to moving to a new house. The current house may have seemed clean and relatively uncluttered. Yet during the process of moving, things are discovered that haven’t been cleaned in a very long time and unwanted clutter starts to surface in every room. Further, it seems that moving creates its own clutter as miscellaneous unrelated objects are tossed into a common box, to be dealt with later.

Firewall migrations are similar. There are rules and objects that need to be cleaned. There are orphaned objects cluttering the configuration. Fortunately, the Cisco SCT automatically de-clutters orphaned objects. However, just like moving, the conversion tool will create its own clutter. This includes rules being applied incorrectly to interfaces as a result of the use of the ‘any’ keyword. The Cisco SCT can also create objects to prevent rule set 'bloating; the names are automatically generated and identified by the Check Point rule number. These objects should be renamed for clarity.

Conversion to Multiple Cisco Firewall Contexts There is a process whereby a new (bogus) firewall can be created using Check Point management software. This will be reflected as a separate .W file. The rules from the production firewall can be copied into this new firewall configuration from within the Check Point management software. Then, all rules that do not apply to the security context being deployed can be deleted. Export the final files through the Cisco SCT. It is important to create or edit the route.cfg table to accurately reflect the interfaces that need to be converted and the relevant routes that the security context should contain. Using this method, it is quick and easy to reduce the effort required to create multiple security contexts from a single Check Point firewall.



5

Appendix: Questionnaires

The following questions can be used to help determine appropriate use of the Cisco SCT, determine requirements for the firewall solution, and avoid pitfalls during the migration.

1. Tool Requirements: Can the Cisco SCT Be Used? 1.1. Check Point software version is 4.x or 5.0 (NG)? 1.2. Is Check Point running on a Nokia platform?

1.2.1. If yes, follow the directions in the Cisco SCT readme notes. 1.2.2. If not, manually create the routing table for the Check Point firewall. The format is given in the readme notes. Please note

that there are no spaces in the ‘route.cfg’ file for the Cisco SCT. 1.3. Is Check Point running ‘virtual’ firewalls? Gather the files associated with each virtual firewall. 1.4. Is the Check Point firewall to be converted to multiple Cisco firewalls or contexts? (See the section on conversion to multiple

Cisco firewall contexts.) The Cisco SCT does not convert a single Check Point firewall policy into multiple Cisco firewall policies; this will be a manual process.

1.5. Is the Check Point firewall performing NAT? Check Point supports some NAT features that Cisco does not. Review the Check Point NAT policy.

1.6. Is the Check Point firewall performing VPN services (for example, IPsec terminations)? The Cisco SCT does not convert VPN configurations. The Cisco FWSM does not support VPN service termination.

1.7. Are you converting to a supported Cisco firewall software release? (See the section on using the Cisco SCT with a firewall version that is not supported.)

2. Business/Technical Requirements

2.1. How will the new firewall solution meet your various requirements? 2.1.1. Incident handling: How will incident handling procedures be met?

2.1.1.1. How will network forensic traffic be collected and analyzed? 2.1.1.2. How will real-time traffic be collected and analyzed?

2.1.2. Audit requirements: How will audit requirements be met? 2.1.2.1. Automated Cisco Security Manager/CiscoWorks VMS configuration check? 2.1.2.2. Syslog of all configuration changes? 2.1.2.3. Syslog of all denied traffic? 2.1.2.4. Syslog of all permitted traffic? 2.1.2.5. Authentication, accounting, and authorization (AAA) integration

2.1.3. Reporting 2.1.4. Configuration change control 2.1.5. Configuration change logging 2.1.6. Network management systems 2.1.7. Remote notification of critical errors 2.1.8. Workflow control 2.1.9. Syslog 2.1.10. AAA 2.1.11. Event correlation and anomaly detection: Is a product currently in place that provides event correlation and anomaly

detection? 2.1.11.1 Is this a third-party product, such as NetForensics or ArcSight, that can be used for Cisco firewalls? 2.1.11.2 It is a Cisco Advanced Services best practice to have such a system in place. Cisco has two products in particular

that customers may want to consider: Cisco Security MARS and CiscoWorks SIMS (NetForensics). 2.2 How will the new firewall solution dovetail with your other initiatives/solutions?

2.2.1 Antivirus 2.2.2 Spam filtering 2.2.3 Web filtering 2.2.4 User authentication 2.2.5 Network admission control 2.2.6 Outbreak prevention initiative


Page A-1

2.3 Is the network on which the network and/or security management servers/appliances secure? (See Best Practice #11.) 2.3.1 Firewall in place? 2.3.2 Network IPS in place? 2.3.3 SSL VPN in place? 2.3.4 Host IPS in place?

2.4 How is the Cisco environment to be managed? 2.4.1 Cisco PIX Device Manager: Select the option for no-object nesting with the conversion tool. Remember that you may lose

some meta-data associated with description of objects. Check Point administrators will typically only tolerate Cisco PIX Device Manager for very simple firewall rule sets; Cisco PIX Device Manager has no database of its own – it uses the configuration of the firewall to maintain information. The device manager changes to the configuration typically do a bit more than annoy Check Point administrators.

2.4.2 CiscoWorks VMS 2.x: CiscoWorks VMS 2.x is not capable of administrating system functions. It is frequently required for revision control and workflow management. Please look for the Cisco Advanced Services best practice document for CiscoWorks VMS deployments.

2.4.3 Cisco Security Manager (sometimes referred to as CiscoWorks VMS 3.0): Cisco Security Manager is promising. Expect for a Check Point administrator to be happy with nothing less than Cisco Security Manager. It supports the same revision control and workflow management as CiscoWorks VMS 2.x.

2.4.4 CLI: Rule sets with nested objects are difficult to administer via CLI. A Check Point administrator will typically not tolerate such a crude management option. However, expect Check Point administrators to learn how to use common CLI troubleshooting tools.

2.4.5 Real-time event viewing: Check Point provides a very good application for seeing in near-real time what traffic is passing through the Check Point firewall. It is important to understand traffic monitoring requirements and how those requirements will be met: CiscoWorks SIMS, Cisco Security MARS, the capture function of the Cisco firewall.

2.4.6 Incident handling procedures 2.5 Determine the failover policy.

2.5.1 Is the current failover policy in Check Point to fail over when a single interface fails? 2.5.2 If going to a multiple context environment, does the failover policy need to be altered? 2.5.3 Are the existing Check Point firewalls clustered or using VRRP for redundancy?

3 Pitfall Questionnaire 3.2 Is the Check Point anti-spoofing feature enabled?

3.2.1 If the anti-spoofing feature is not enabled, explore the option of enabling it. If there has been a previous experience where enabling the anti-spoofing feature has resulted in negative consequences, there are existing issues that will need to be resolved prior to attempting to migrate to a Cisco firewall.

3.2.2 One of the primary concerns here is the dual-homing of a server on two separate IP subnets. Check Point applying rules with global significance will allow the asymmetric data flow.

3.3 Is the Check Point firewall performing secondary IP addressing? Secondary IP addressing is not supported on Cisco firewalls. The secondary IP addressing issue must be resolved prior to moving forward with a migration.

3.4 (Speed bump) Is the Check Point firewall using virtual interfaces (trunking, such as 802.1Q trunking)? The Cisco SCT will create a Cisco configuration with physical interfaces. You will need:

3.4.1 Enough physical interfaces to match the sum of all Check Point physical and virtual interfaces, or 3.4.2 You will have to manually adjust the Cisco firewall configuration with the relevant 802.1Q trunked interfaces (virtual

interfaces). 3.5 Is the Check Point firewall performing any ‘one-armed firewalling’? That is, is the Check Point firewall allowing traffic to enter the

firewall on an interface then forwarding traffic back out that same interface? If so, deploy the Cisco inter-interface-communication feature.

2© 2006 Cisco Systems, Inc. All right reserved.

Important notices, privacy statements, and trademarks of Cisco Systems, Inc. can be found on cisco.com Page A-2

For additional Cisco IT case studies on a variety of business solutions, go to Cisco IT @ Work

www.cisco.com/go/ciscoitatwork

Note:

This publication describes how Cisco has benefited from the deployment of its own products. Many factors may have contributed to the results and benefits described; Cisco does not guarantee comparable results elsewhere.

CISCO PROVIDES THIS PUBLICATION AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR

IMPLIED, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Some jurisdictions do not allow disclaimer of express or implied warranties, therefore this disclaimer may not apply to you.

Corporate Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 526-4100

European Headquarters Cisco Systems International BV Haarlerbergpark Haarlerbergweg 13-19 1101 CH Amsterdam The Netherlands www-europe.cisco.com Tel: 31 0 20 357 1000 Fax: 31 0 20 357 1100

Americas Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA www.cisco.com Tel: 408 526-7660 Fax: 408 527-0883

Asia Pacific Headquarters Cisco Systems, Inc. Capital Tower 168 Robinson Road #22-01 to #29-01 Singapore 068912 www.cisco.com Tel: +65 317 7777 Fax: +65 317 7799

Cisco Systems has more than 200 offices in the following countries and regions. Addresses, phone numbers, and fax numbers are listed on

the Cisco Website at www.cisco.com/go/offices. Argentina • Australia • Austria • Belgium • Brazil • Bulgaria • Canada • Chile • China PRC • Colombia • Costa Rica • Croatia • Czech Republic • Denmark • Dubai, UAE• Finland • France • Germany • Greece • Hong Kong SAR • Hungary • India • Indonesia • Ireland • Israel • Italy • Japan • Korea • Luxembourg • Malaysia • Mexico• The Netherlands • New Zealand • Norway • Peru • Philippines • Poland • Portugal • Puerto Rico • Romania • Russia • Saudi Arabia • Scotland • Singapore • Slovakia • Slovenia • South Africa • Spain • Sweden • Switzerland • Taiwan • Thailand • Turkey • Ukraine • United Kingdom • United States • Venezuela • Vietnam • Zimbabwe

Copyright © 2005 Cisco Systems, Inc. All rights reserved. CCIP, CCSP, the Cisco Powered Network mark, Cisco Unity, Follow Me Browsing, FormShare, and StackWise are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, and iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, LightStream, Linksys, MeetingPlace, MGX, MICA, the Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, ScriptShare, SlideCast, SMARTnet, StrataView Plus, Stratm, SwitchProbe, TeleRouter, The Fastest Way to Increase Your Internet Quotient, TransPath, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries. All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0411R) Printed in the USA


http://www.cisco.com/go/ciscoitatwork

Documents

Migrating from a Check Point to a Cisco Environment: Firewall … · Firewall Rule and Policy Conversions and the Cisco Security Conversion Tool ... Lab Testing