Table Of Contents
Device Inventory and Configuration Discovery
Building Blocks and Policy Objects
Device Grouping and Policy Inheritance Differences
Policy Inheritance and Assignment Differences
Access Rules Description Patch
Differences involving NAT when Defining Access Rules
Automatic Identity Translation Rules
Multiple Service Types in a Rule
Migrating from Firewall MC
This chapter provides information and considerations that you should know before you migrate from Firewall MC to Security Manager 3.0. As mentioned in the Overview chapter, Security Manager 3.0 does not provide automated data migration from Firewall MC to Security Manager. The strategy for migrating from Firewall MC to Security Manager 3.0 is based on leveraging the device setting discovery capabilities of Security Manager and then performing manual adjustments as needed to the discovered settings.
This chapter contains these sections:
•
Device Inventory and Configuration Discovery
•
•
•
•
•
•
Device Bootstrapping
There are differences in the device bootstrapping requirements between Firewall MC and Security Manager. Firewall MC uses SSH for communication with PIX and FWSM devices. When these devices become managed by Security Manager, you will need to configure them for SSL. The SSH configuration can be retained; however, Security Manager does not use or require SSH for managing PIX or FWSM devices. Detailed instructions for bootstrapping devices for use with Security Manager are provided in the User Guide for Cisco Security Manager 3.0. See the section entitled Preparing the Devices for Security Manager to Manage.
Auto Update Server
Firewall MC supports using the Auto Update Server as a deployment transport option for PIX devices. If the AUS server IP address changes when migrating to AUS 3.0 (included with Security Manager 3.0), you need to update the auto-update server statement on each affected device. You can update the device AUS settings in Firewall MC and deploy to the devices before migrating to the new AUS 3.0 server. The AUS settings can also be configured using the CLI interface of the device, the PIX Device Manager, or Security Manager. If you change the AUS settings using Security Manager, then you will need to use a non-AUS transport option to make the update. Once you update the AUS settings on the device, you can configure Security Manager to use AUS as the deployment transport option.
Supported Device OS Versions
Cisco Security Manager 3.0 supports all PIX and FWSM devices that are supported by FWMC; however, there are differences in the specific supported OS versions. See the Supported Devices and Software Versions for Cisco Security Manager 3.0 to ensure that the device OS version is supported by Cisco Security Manager 3.0.
Device Inventory and Configuration Discovery
There is no device inventory data migration supported between Firewall MC and Cisco Security Manager. You can add device information into Cisco Security Manager using various methods as described in the User Guide for Cisco Security Manager 3.0.
Note that Security Manager only supports importing from configuration files consistent with the show running configuration command output format. In some cases configuration files generated by Firewall MC may not follow the show running configuration format and hence not import correctly. If a Firewall MC-generated configuration file is used, then you might need to modify the file to bring it into conformance with the show running configuration format. The following are some known issues that would need to be manually corrected:
•
For example, in the Firewall MC generated configuration file, the version might be a commented line as:
...:FWSM Version 1.1(3)...Assuming the software version on the device is 2.3(1), change this to:
...FWSM Version 2.3(1)...•
...nameif vlan17 outside security0ip address outside 10.238.3.20 255.255.255.240mtu outside 1500...In which case the following statement needs to be added:
interface outsideAnother tip is to use the Group Discovery feature in Firewall MC before generating device configurations that will be added to Security Manager. You can access the Group Discovery feature from the access rule tables. An algorithm identifies rules that can be grouped together. Group discovery also attempts to express the rules using either existing or new building blocks. Newly created groups have the name prefixes MC-SGroup (for a service group) and MC-NGroup (for a network object).The advantage of the building blocks is that when Firewall MC generates the CLI configuration, it will more likely represent the building blocks as PIX object groups. Security Manager can then discover the PIX object groups and represent them as re-usable objects in Security Manager.
Building Blocks and Policy Objects
Firewall MC supports the definition of named, re-usable policy components called building blocks. Security Manager provides the equivalent capability, however, they are called policy objects in Security Manager. Sometimes a building block definition only exists in the management layer and is not evident as an equivalent named object in the device configuration. Other times the device itself may support named, reusable objects and in those cases where Firewall MC leverages that device capability, Security Manager can discover the building block definition from the device itself. Depending on the type of building block you may need to manually create the equivalent Policy Object in Security Manager before doing device additions. Table 2-1 lists each building block type in Firewall MC, the equivalent Policy Object in Security Manager, and what level of migration is supported through the device discovery features of Security Manager.
Building blocks in Firewall MC are also defined in the context of the device grouping hierarchy. For example, it is possible to have a Network Object building block defined at the scope of the Global group called MyFTPServer with a value of 10.10.10.1 and another one of the same name, but with a value of 10.10.10.2 defined within the scope of one of the subgroups. A rule defined on a device using the MyFTPServer will get the appropriate value for the object based on its position in the grouping hierarchy.
In contrast, policy objects in Security Manager are defined independently of any device grouping hierarchy. In Security Manager, if two different FTP server definitions are required, you would create two shareable Network/Host policy objects with different names and then assign them to the appropriate devices. Another way to achieve the two different FTP server definitions is the device-level override feature of Security Manager. When a policy object is defined, you can specify whether to allow device-level overrides. If enabled, you can modify the value for a given policy object on a per-device basis as needed.
As a result if the hierarchy feature for building blocks has been used in Firewall MC, you will need to come up with an equivalent arrangement using the different mechanisms available in Security Manager.
Device Configuration Settings
Firewall MC allows you to configure many different device settings. You can configure device settings at the device level or anywhere in the group hierarchy. At any level in the hierarchy you can specify that the settings should be inherited from the level above. You can also specify whether the settings at a particular level should be default or mandatory. Default settings can be overridden at a lower level in the hierarchy. Mandatory settings cannot be overridden for any children entities lower in the hierarchy.
Security Manager has a simpler device configuration settings model compared to Firewall MC. In Security Manager, a particular category of device configuration can be defined as a shareable policy and then assigned to devices. In Security Manager, there is no hierarchy of device configuration policies and device configuration policies are not associated with device groups. Likewise there is no concept of default or mandatory settings for device configuration policies, rather just policy assignment to the device.
Figure 2-1 shows an example device configuration setting arrangement for SNMP settings. At the Global Device Group settings are defined, but the Mandatory for Children option is not selected, allowing the use of different settings lower in the hierarchy. Device A is contained by the Global Group and is inheriting the Global settings. Another SNMP settings is defined at the DataCenter device group. In this case the DataCenter SNMP settings are defined as mandatory for all children devices.
Figure 2-1 Example Device Configuration Settings for SNMP in Firewall MC
The equivalent arrangement in Security Manager is accomplished by creating two shared SNMP policies, one with the Global settings and another with the DataCenter settings (Figure 2-2). The Global policy is assigned directly to Device A and the DataCenter policy directly to Device B.
When a device is added to Security Manager, the particular device configuration settings are discovered as local non-shared settings. It is then a simple matter to convert the desired settings category (such as SNMP) to a named shared policy which can then be re-used and assigned to additional devices.
Figure 2-2 Corresponding Device Configuration Setting in Security Manager
Configuration Additions
Configuration Additions are a special category of device configuration supported by Firewall MC. Configuration Additions enable you to define CLI statements to be either prepended or appended to the configuration deployed by Firewall MC to the device. If the defined CLI covers features not managed by Security Manager, you should define the corresponding CLI manually in Security Manager using the FlexConfig feature. Doing so will ensure continued presence of the CLI additions on the device.
The FlexConfig feature in Security Manager has many enhancements compared to the Firewall MC Configuration Additions. Although you can copy the CLI from the Firewall MC Configuration Additions into a FlexConfig, FlexConfig also enables you to use variables that provide access to all the richness of the Security Manager policy object definition framework. Therefore you can better organize and optimize any necessary CLI additions using the FlexConfig feature.
FlexConfigs are treated in Security Manager just as any other device configuration setting. As such, FlexConfig settings on a device can be converted to a named shareable policy. Individual FlexConfigs can be defined as shareable policy objects and used in a larger device-level FlexConfig policy.
Device Grouping and Policy Inheritance Differences
Device grouping and policy inheritance provide the foundation for scalable multi-device management. Both Firewall MC and Cisco Security Manager support these capabilities, however, there are key differences you need to consider before migration.
Device Grouping Differences
Firewall MC enables you to define a device group hierarchy. There is a fixed top-level group called "Global" and you can define a hierarchy of subgroups under the Global group. You then explicitly assign devices to one and only one group within the hierarchy. Firewall MC does not support rule-based grouping, where a device is automatically assigned to a group based on characteristics of the device. Figure 2-3 shows an example Firewall MC device group hierarchy. A device can be contained directly by the Global group or any subgroup.
Figure 2-3 Example Firewall MC Group Hierarchy
With Security Manager you can define up to ten group hierarchies, where the top level of each hierarchy is identified by a Group Type that you define. You can then define a hierarchy of groups under each Group Type. You can assign a given device to none or at most one group for a given Group Type. Since you can have multiple Group Types, you can assign a given device to multiple groups, however, each of these groups will be a different Group Type. There is also a default Group Type called "All", which contains all devices. As with Firewall MC, you explicitly define the device to group assignments and rule-based grouping is not supported.
If you want to have the same group hierarchy that was defined in Firewall MC in Security Manager, then you need to manually redefine this hierarchy using one of the available Group Types. Likewise when devices are added in Security Manager, you need to manually assign the device to the correct group within the re-created hierarchy. Security Manager 3.0 does not support importing device groups and device group assignments maintained in Firewall MC.
Figure 2-4 shows an example device group hierarchy for Security Manager, where a group hierarchy equivalent to the one present in the Firewall MC example (Figure 2-3) is created under Group Type 1. Notice that devices cannot be contained directly by the Group Type itself. So to simulate the Firewall MC Global group, a single group labeled SubGroup0 is created under the Group Type. Also a device can be assigned to additional groups, but to no more than one group per Group Type.
Group Types and groups can be defined as any user meaningful values. For example, a Group Type of Location could be defined and then Groups such as Edge, Core, and Distribution could be defined. A second Group Type could be defined as such as DeviceType and Groups created under it such as PIX and FWSM, etc.
A complete description of the Firewall MC grouping can be found in Using Management Center for Firewalls. Likewise a complete description of Cisco Security Manager grouping features is available in the User Guide for Cisco Security Manager 3.0.
Figure 2-4 Example Cisco Security Manager Group Hierarchy
Policy Inheritance and Assignment Differences
In Firewall MC there is a strong relationship between policy inheritance and assignment and device groups. In fact, the device group hierarchy and policy hierarchy are one in the same. Security Manager, however, has decoupled the device group hierarchy from the policy hierarchy to allow greater flexibility. In Security Manager a device gets its settings based on either its local settings or an explicit assignment of a shared policy on the device.
Device groupings in Security Manager can facilitate the bulk assignment of a policy to a set of devices, however, the assignment is always maintained to the specific device. Therefore, if a policy is assigned to a set of devices in Group A and then later a new device is added to Group A, the new device does not automatically pick up the policy assignment made previously to the Group A devices.
When migrating from Firewall MC where policy inheritance has been used, the main challenge involves re-establishing the policy hierarchy in Security Manager. To accomplish this, you can leverage the discovery features of Security Manager. When Security Manager discovers the settings on a device previously managed by Firewall MC, Security Manager treats all the settings as local to that device. The policy hierarchy is re-established by converting the appropriate local settings to named shared policies, which can then be assigned to additional devices brought over into Security Manager.
An example procedure involving firewall access rules, which have been organized in a hierarchy follows:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
The policy hierarchy that was present in Firewall MC is now established in Security Manager for the device.
Figure 2-5 shows an example hierarchy of access rules illustrating both mandatory and default rules as well as shared and local device rules.
Figure 2-5 Sample Access Rule Policy Hierarchy
Figure 2-6 shows the policy hierarchy in Figure 2-5 implemented in Firewall MC.
Figure 2-6 Sample Access Rule Policy Hierarchy Implemented in Firewall MC
Figure 2-7 shows the device just after it has been added to Security Manager. All the discovered access rules are local to the device in Security Manager. At this point you should begin copying the appropriate rules from the access rule table to shareable policies to recreate the hierarchy.
Figure 2-7 Corresponding Access Rule in Security Manager after Device Import
Figure 2-8 shows the construction of the Global policy. The mandatory and default global rules have been copied from the device access list and pasted into the new Global policy.
Figure 2-8 The Creation of the Global Policy with Corresponding Access Rules Copied In
Figure 2-9 shows the completed policy hierarchy. The DataCenter policy has been created with the corresponding rules copied over from the device access list. The DataCenter policy has been set to inherit from the Global policy.
Figure 2-9 The Completed Policy Hierarchy
Figure 2-10 shows Device view again, but now with all the non-local access rules removed and the remaining local access rules set to inherit from the DataCenter policy. Now the device has the same set of rules and the same policy hierarchy as was defined in Firewall MC.
Figure 2-10 The Device with the Local Rules and Inherited Shared Policy
When additional devices are imported into Security Manager, you can re-use shared policies that have already been created. If there are no missing policies to create, you simply delete all the non-local access rules on the device and inherit from the appropriate shared policy.
If there are no strictly local policies on the device, you can do bulk assignments of a policy to devices in a single operation, rather than device by device.
Access Rules Description Patch
This section describes a patch which is available to facilitate the migration of Access Control Entry (ACE) descriptions.
Patch Background and Overview
Using Firewall MC you can define an optional description for each access rule. Normally the descriptions can not be migrated to Security Manager, because they are not present in the deployed configuration file or on the device for Security Manager to discover. However, an Access Control List (ACL) remark patch is available for Firewall MC that enables Firewall MC to include the descriptions in the deployed configuration file. With the descriptions present in the configuration file, you can migrate the descriptions to Security Manager. Two ACL remark patch versions are available: one for Firewall MC 1.3.4 and the other for 1.3.5 (Windows version only).
The ACL remark patch deploys the device configuration with the ACE descriptions (using the remark keyword in the CLI) to a separate directory: $NMSROOT\MDC\PIXMC\deploy\CSM_Migration. $NMSROOT is the directory in which Firewall MC is installed (Default C:\Program Files\CSCOpx). The deployed device config files are named $DeviceName.cfg. For example, if the device name is PIX-A , then the deployed config file is named PIX-A.cfg.
The associated ACE remark CLI will precede the ACE in the deployed configuration as shown in the example below:
access-list out-acl remark Permit HTTP traffic to the web serveraccess-list out-acl permit tcp any host 192.168.10.1 eq httpYou can download these patches from Cisco.com. Go to http://www.cisco.com/go/vms, then select "Download Software", then access the component level updates for Management Center for Firewalls (Firewall MC). The readme file for the patches includes important information on how the patch works and how to use it correctly.
Using the Patch
Refer to the patch readme file for patch installation instructions. Once the patch is installed, the following procedure describes how to generate configuration files that include the ACE descriptions.
Note
Step 1
Step 2
Step 3
Step 4
Note
Step 5
a.
b.
c.
Step 6
a.
b.
Step 7
Step 8
a.
b.
c.
d.
e.
Note
Step 9
Step 10
Step 11
You can retrieve the generated configuration files under $NMSROOT\MDC\PIXMC\deploy\CSM_Migration and then use them to import the devices into Security Manager. After use of the patch is complete you should uninstall the patch as described in the patch readme file.
Differences involving NAT when Defining Access Rules
Firewall MC enables you to specify all access rules using local IP addresses, and then it automatically translates the local address to the global address where required when deploying the configuration to the device. One advantage of this approach is that there is never any ambiguity as to whether an address is local or global, because local addresses are always used in the access rules. Security Manager on the other hand does not perform such translations. Instead, the actual IP addresses that are required in the device configuration need to be specified in the rule table. The advantage to this approach is that the rule table in the Security Manager GUI matches the actual addresses that would be seen by examining the device CLI.
No special steps are required when migrating from Firewall MC to Security Manager as a result of this difference in behavior. However, you should understand the differences when comparing the rule tables between the two applications.
To better understand the differences let's looks at a specific example. Figure 2-11 shows an example network configuration involving a PIX Firewall, static NAT, and access rules. In the example a web server is located on the dmz interface with a local address of 10.1.2.2. A static NAT entry is created to map the local address of 10.1.2.2 to a global address of 209.165.201.11 which clients on the outside interface can use to access the web server. An access rule is created on the outside interface to permit traffic from any address to the web server on port 80 (http). Likewise an access rule is created on the inside interface to permit traffic from any address to the web server on port 80 (http). These access rules employ a network building block for the web server called MyWebServer with a value of 10.1.2.2 (that is, the local address). The completed rules are shown in Figure 2-12.
Figure 2-11 Example PIX Configuration with Static NAT and Access Rules
Figure 2-12 Completed Rules in Firewall MC
When the configuration is deployed, Firewall MC automatically translates the local address for the MyWebServer to the global address, which is what is required for the access rule on the outside interface. It does this by creating another object group in the device configuration for the global address of the Web Server. The following shows the resulting CLI configuration fragment.
...: Object group MyWebServerobject-group network MyWebServernetwork-object 10.1.2.2 255.255.255.255:: Object group MyWebServer_1M640object-group network MyWebServer_1M640network-object 209.165.201.11 255.255.255.255: Static Commandsstatic (dmz,outside) 209.165.201.11 10.1.2.2 netmask 255.255.255.255 0 0:: acl_mdc_outside_access Access Listaccess-list acl_mdc_outside_access permit tcp any object-group MyWebServer_1M640eq 80 log defaultaccess-group acl_mdc_outside_access in interface outside:: acl_mdc_inside_access Access Listaccess-list acl_mdc_inside_access permit tcp any object-group MyWebServer eq 80log defaultaccess-group acl_mdc_inside_access in interface inside:...When this device is added to Security Manager, Security Manager discovers and represents the addresses just as they appear in the CLI. Two network objects are discovered for the web server, one with the local address and the other with the global address. The discovered rules are shown in Figure 2-13.
Figure 2-13 Discovered Rules in Security Manager
Automatic Identity Translation Rules
Firewall MC has a feature to automatically define identity NAT rules. You can configure this option in Firewall MC under Configuration > MC Settings > Management > Identity Address Translation Rules. When such identity translation rules are automatically defined, they appear in the device configuration, however, not in the Firewall MC Translation Rules GUI. Security Manager does not provide an automatic identity translation rules feature, so you need to explicitly define each translation rule. As a result Security Manager also shows all translation rules in its GUI.
VPN Configuration
Firewall MC supports the ability to manage VPN features of PIX devices. Security Manager 3.0, however, does not support the ability to discover existing VPN configurations on devices. Therefore, to migrate from Firewall MC management of VPN settings to Security Manager you must redefine an equivalent IPSec configuration using the Security Manager GUI. It is recommend to first delete the VPN configuration on the device from Firewall MC before the migration. When the device is added to Security Manager an equivalent VPN configuration can be defined and deployed to the device.
Miscellaneous Caveats
This section includes additional caveats you should be aware of when migrating from Firewall MC to Security Manager.
Access Rule Categories
In Firewall MC you can also define an optional category for each access rule. The category information does not appear in the device configuration, so the category information cannot be migrated to Security Manager through device discovery. If you want to retain the category information, you need to manually set the category for each discovered access rule in Security Manager.
Multiple Service Types in a Rule
A single access rule defined with Firewall MC that has multiple service types (for example, tcp and udp), is migrated to multiple rules in Security Manager.
