User Guide for Cisco Security Manager 3.2.2 - Managing Objects [Cisco Security Manager]

Table Of Contents

Managing Objects

Introduction to Objects

Creating Objects

Using Category Objects

Guidelines for Managing Objects

Managing Existing Objects

Editing Objects

Deleting Objects

Managing Object Overrides

Duplicating Objects

Generating Object Usage Reports

Viewing Object Details

Understanding AAA Server Group Objects

Predefined AAA Authentication Server Groups

Default AAA Server Groups and IOS Devices

Creating AAA Server Group Objects

Understanding AAA Server Objects

Supported AAA Server Types

AAA Support on ASA Devices

Creating AAA Server Objects

Creating Access Control List Objects

Creating Extended Access Control List Objects

Creating Standard Access Control List Objects

Creating Web Access Control List Objects

Understanding How Security Manager Handles ACL Names

Preserving User-Defined ACL Names

How ACL Names Are Generated

Identifying Original ACL Names

Naming Conflicts and Resolutions

Notes on ACL Naming

Understanding ASA User Group Objects

Creating ASA User Group Objects

Understanding Credential Objects

Creating Credential Objects

Understanding File Objects

Creating File Objects

Understanding IKE Proposal Objects

Creating IKE Proposal Objects

Understanding Inspection Map Objects

Creating Class Map Objects

Creating DCE/RPC Map Objects

Creating DNS Map Objects

Creating ESMTP Map Objects

Creating FTP Map Objects

Creating GTP Map Objects

Creating H.323 Map Objects

Configuring HTTP Policy Map Objects

Creating HTTP Map Objects (ASA 7.1.x/PIX 7.1.x/FWSM 3.x/IOS)

Creating HTTP Map Objects (ASA 7.2+/PIX 7.2+)

Creating IM Map Objects for Devices running ASA/PIX 7.2 and Higher

Creating IM Map Objects for IOS Devices

Creating IPSec Pass Through Map Objects

Creating NetBIOS Map Objects

Creating SIP Map Objects

Creating Skinny Map Objects

Creating SNMP Map Objects

Creating Regular Expression Group Objects

Creating Regular Expression Objects

Metacharacters Used to Build Regular Expressions

Creating TCP Map Objects

Understanding Interface Role Objects

Creating Interface Role Objects

Specifying Interfaces During Policy Definition

Exceptional Cases When Using Interface Roles

Understanding IPsec Transform Set Objects

IPsec Protocols

IPsec Modes

Creating IPsec Transform Set Objects

Understanding LDAP Attribute Map Objects

Creating LDAP Attribute Map Objects

Understanding Network/Host Objects

Supported IP Address Formats

Contiguous and Discontiguous Network Masks

Creating Network/Host Objects

Using Unspecified Network/Host Objects

Specifying IP Addresses During Policy Definition

Understanding PKI Enrollment Objects

Creating PKI Enrollment Objects

Defining CA Server Properties

Defining PKI Enrollment Parameters

Defining Additional PKI Attributes

Defining the Trusted CA Hierarchy

Understanding Port Forwarding List Objects

Creating Port Forwarding List Objects

Understanding Port List Objects

Creating Port List Objects

Understanding Cisco Secure Desktop Configuration Objects

Creating Cisco Secure Desktop Configuration Objects

Understanding Service Objects

Creating Service Objects

Understanding Single Sign-On Server Objects

Creating Single Sign-On Server Objects

Understanding SLA Monitor Objects

Creating SLA Monitor Objects

Understanding SSL VPN Bookmark Objects

Creating SSL VPN Bookmark Objects

Understanding SSL VPN Customization Objects

Understanding SSL VPN Customization Objects

Localizing SSL VPN Web Pages for ASA Devices

Creating Your Own SSL VPN Logon Page

Creating SSL VPN Customization Objects

Understanding SSL VPN Gateway Objects

Creating SSL VPN Gateway Objects

Understanding SSL VPN Smart Tunnel List Objects

Creating SSL VPN Smart Tunnel List Objects

Understanding Style Objects

Creating Style Objects

Creating Text Objects

Understanding Time Range Objects

Creating Time Range Objects

Creating Traffic Flow Objects

Understanding IP Precedence Bits

Understanding User Group Objects

Creating User Group Objects

Understanding WINS Server List Objects

Creating WINS Server List Objects

Overriding Global Objects for Individual Devices

Allowing a Global Object to Be Overridden

Creating Device-Level Object Overrides

Creating Object Overrides for a Single Device

Creating Object Overrides for Multiple Devices

Deleting Device-Level Object Overrides

Deleting Overrides from the Device Properties Window

Deleting Overrides from the Policy Object Manager window

Selecting Objects for Policies

How Policy Objects are Provisioned as PIX/ASA Object Groups

How Network/Host Objects are Provisioned as PIX/ASA Object Groups

How Port List Objects are Provisioned as PIX/ASA Object Groups

How Service Objects are Provisioned as PIX/ASA Object Groups

Managing Objects

This chapter contains the following topics:

•Introduction to Objects

•Managing Existing Objects

•Understanding AAA Server Group Objects

•Understanding AAA Server Objects

•Creating Access Control List Objects

•Understanding How Security Manager Handles ACL Names

•Understanding ASA User Group Objects

•Understanding Credential Objects

•Understanding File Objects

•Understanding IKE Proposal Objects

•Understanding Inspection Map Objects

•Understanding Interface Role Objects

•Understanding IPsec Transform Set Objects

•Understanding LDAP Attribute Map Objects

•Understanding Network/Host Objects

•Understanding PKI Enrollment Objects

•Understanding Port Forwarding List Objects

•Understanding Port List Objects

•Understanding Cisco Secure Desktop Configuration Objects

•Understanding Service Objects

•Understanding Single Sign-On Server Objects

•Understanding SLA Monitor Objects

•Understanding SSL VPN Bookmark Objects

•Understanding SSL VPN Customization Objects

•Understanding SSL VPN Gateway Objects

•Understanding SSL VPN Smart Tunnel List Objects

•Understanding Style Objects

•Creating Text Objects

•Understanding Time Range Objects

•Creating Traffic Flow Objects

•Understanding User Group Objects

•Understanding WINS Server List Objects

•Overriding Global Objects for Individual Devices

•Selecting Objects for Policies

•How Policy Objects are Provisioned as PIX/ASA Object Groups

Introduction to Objects

Objects enable you to define logical collections of elements. They are reusable, named components that can be used by other objects and policies. Objects aid policy definition by eliminating the need to define that component each time you define a policy. When used, an object becomes an integral component of the object or policy. This means that if you change the definition of an object, this change is reflected in all objects and policies that reference the object.

Objects facilitate network updates, because you can identify objects separately but maintain them in a central location. For example, you can identify the servers in your network as a network/host object called MyServers, and the protocols to allow on these servers in a service object. You can then create an access rule that permits the service object to access the MyServers network/host object. If a change is made to these servers, you need only update the network/host object and redeploy, instead of trying to locate and edit each rule in which the servers are used.

By default, objects are defined globally. This means that the definition of an object is the same for every object and policy that references it. However, many object types (for example, interface roles) can be overridden at the device level. Thus, you can create an object that works for most of your devices, yet customize the object to match the configuration of a particular device that has slightly different requirements. For more information, see Overriding Global Objects for Individual Devices.

Related Topics

•Creating Objects

•Guidelines for Managing Objects

•Policy Object Manager Window, page F-1

•Managing Existing Objects

•Understanding How Security Manager Handles ACL Names

Creating Objects

Security Manager provides predefined objects of various types that you can use to define policies. Additionally, you can create your own objects, as required.

You can create objects in one of two ways:

•Using the Policy Object Manager window. This option is best suited for situations where you are defining one or more objects outside of the context of defining a particular policy. See Policy Object Manager Window, page F-1.

•Using object selectors. When you define a policy that uses objects, object selectors include buttons for creating and editing objects without your having to first leave the policy that you are defining. See Selecting Objects for Policies.

The following topics describe the types of objects that are available in Security Manager and how to create them:

•Understanding AAA Server Group Objects

•Understanding AAA Server Objects

•Creating Access Control List Objects

•Understanding ASA User Group Objects

•Using Category Objects

•Understanding Credential Objects

•Understanding File Objects

•Understanding FlexConfig Policies and Policy Objects, page 19-1 and Creating FlexConfig Policy Objects, page 19-24 (in Chapter 19, "Managing FlexConfigs")

•Understanding IKE Proposal Objects

•Understanding Inspection Map Objects

•Understanding Interface Role Objects

•Understanding IPsec Transform Set Objects

•Understanding LDAP Attribute Map Objects

•Understanding Network/Host Objects

•Understanding PKI Enrollment Objects

•Understanding Port Forwarding List Objects

•Understanding Port List Objects

•Understanding Cisco Secure Desktop Configuration Objects

•Understanding Service Objects

•Understanding Single Sign-On Server Objects

•Understanding SLA Monitor Objects

•Understanding SSL VPN Bookmark Objects

•Understanding SSL VPN Customization Objects

•Understanding SSL VPN Gateway Objects

•Understanding SSL VPN Smart Tunnel List Objects

•Understanding Style Objects

•Creating Text Objects

•Understanding Time Range Objects

•Creating Traffic Flow Objects

•Understanding User Group Objects

•Understanding WINS Server List Objects

Related Topics

•Introduction to Objects

•Guidelines for Managing Objects

•Policy Object Manager Window, page F-1

•Managing Existing Objects

Using Category Objects

Categories provide an intermediate level of detail to objects. By assigning a category to an object, you can look for the name and color of a category to more easily identify rules and objects in rules tables. You can assign a category to a rule or object when you create the rule, or you can edit the rule or object to include category information later. No device configuration commands are generated for category assignments.

The benefits of assigning categories to policy objects are:

•Visibility is improved when you view rules tables using objects that are categorized.

•Objects can be filtered in the rules tables based on category, facilitating rule maintenance.

For example, you might want to create a network/host object and keep track of its use for administrative purposes. When you define this network/host object, you associate it with a category. When you view the access rules table, you can easily identify those rules that use your network/host object. You can also filter the table to display only those items associated with the category.

Security Manager includes a set of predefined categories. Although you cannot change the colors, you can change their names and descriptions. The following procedure explains how to change the name and description.

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select Categories from the Object Type selector.

Step 3 Click Edit Object to open the Category Editor dialog box (see Category Editor Dialog Box, page F-44).

Step 4 Modify the names and descriptions of the predefined category objects, as required. Names can have a maximum of 128 characters, including special characters and spaces. Descriptions can have a maximum of 1024 characters.

Step 5 Click OK to save your changes.

Guidelines for Managing Objects

You should keep in mind the following guidelines when working with objects:

•Object names are not case-sensitive and are limited to 128 characters. You can begin object names with a letter, a number, or an underscore. You can use a mix of letters, numbers, special characters, and spaces for the remainder of the object name. Supported special characters include hyphens (-), underscores (_), periods (.), and plus signs (+).

Note Certain object types, such as AAA Server Groups, ASA User Groups, Inspect Maps, Network Objects, Service objects, and Traffic Flows, have different naming guidelines. For more details, refer to the online help when you are creating each object type.

•You can rename an object that is referenced by policies or other objects. Security Manager synchronizes the references with the new object name.

•Objects are defined on the global level and are available for use with all relevant policies and other objects. To override the definitions of certain types of objects for specific devices, see Overriding Global Objects for Individual Devices.

•If you change the definition of an object, this change is reflected in all policies that reference that object.

•Your ability to create multiple objects with the same definition depends on a setting on the Policy Objects page in the Security Manager Administration window (Tools > Security Manager Administration). By default, Security Manager warns you when you create an object whose definition is identical to that of an existing object, but it does not prevent you from proceeding. For more information, see Policy Objects Page, page A-34.

•You cannot delete an object that is referenced by policies or other objects.

•In certain situations, you might not be allowed to delete an object, even though the usage report indicates that it is not being used by any other objects or policies. For example, if you configured a device with a local policy that uses network/host object A and later replace that local policy with a shared policy that does not use that object, you will still be prevented from deleting object A. This can also happen when Security Manager creates an internal object from the configuration of a discovered device, and the device is later deleted. If you are prevented from deleting an object and you do not find any policies or objects that use that object, we recommend that you submit or discard all pending changes, then try again.

Related Topics

•Introduction to Objects

•Creating Objects

•Policy Object Manager Window, page F-1

•How Policy Objects are Provisioned as PIX/ASA Object Groups

•Understanding Locking and Objects, page 7-10

Managing Existing Objects

The following topics describe the actions that you can perform on the objects defined in the Policy Object Manager:

•Editing Objects

•Deleting Objects

•Managing Object Overrides

•Duplicating Objects

•Generating Object Usage Reports

•Viewing Object Details

You can access the options for performing all these actions by right-clicking an object in the Policy Object Manager and selecting from the displayed shortcut menu. Not all options are available for all objects. For example, predefined objects cannot be edited, and certain object types cannot be overridden for individual devices.

Related Topics

•Guidelines for Managing Objects

•Policy Object Manager Window, page F-1

•Chapter 9 "Managing Objects"

Editing Objects

You can edit any user-defined object as required. Changes that you make to the object are reflected in all policies (and other objects) that use the object. This procedure describes how to edit an object.

Note Predefined objects cannot be edited, but they can be copied. See Duplicating Objects.

Tip You can also edit objects when you define policies or objects that use this object type. For more information, see Selecting Objects for Policies.

Before You Begin

•Determine if the object is being used, and which policies, objects, and devices would be affected by the changes. You can generate a usage report for this purpose. See Generating Object Usage Reports.

Related Topics

•Policy Object Manager Window, page F-1

Procedure

Step 1 Select Tools > Policy Object Manager. The Policy Object Manager window appears.

Step 2 Select an object type from the Object Type selector.

Step 3 In the work area, right-click the object you want to edit, then select Edit Object.

Step 4 Modify the fields in the Edit dialog box for that object type as required, then click OK to save your changes.

Deleting Objects

You can delete user-defined objects only when they are not being used by policies or other objects. Predefined objects cannot be deleted. If you delete an object for which device-level overrides are defined, all overrides are also deleted.

This procedure describes how to delete user-defined objects.

Note You might be prevented from deleting an unreferenced object from the database, if, for example, you replace a local policy that used the object with a shared policy that does not. If object deletion fails, submit or discard all pending changes (in Workflow mode, submit or discard all pending activities), then try again to delete the object. Alternatively, you can leave unreferenced objects in the database, because they will not affect Security Manager operation.

Before You Begin

•Determine if the object is currently being used and which policies, objects, and devices would be affected by the deletion. You can generate a usage report for this purpose. See Generating Object Usage Reports.

•You need to remove all references to the object before you can delete it.

Related Topics

•Managing Existing Objects

Procedure

Step 1 Select Tools > Policy Object Manager.

Step 2 Select an object type from the Object Type selector.

Step 3 In the work area, right-click a user-defined object, then select Delete Object.

Tip You can select multiple objects by pressing Ctrl and clicking on the desired objects.

Step 4 When prompted, click Yes to confirm the deletion.

Note To verify that the object was deleted, select Tools > Audit Report and view the generated report.

Managing Object Overrides

From the Policy Object Manager window, you can select a global object that can be overridden and generate a table of device-level overrides that are defined for that global object. For example, you can select a global AAA server group object and view a table of all devices for which you defined a local variation of the global object.

For more information, see Overriding Global Objects for Individual Devices.

Object override definitions are displayed in the Policy Object Override window. This procedure describes how to create, edit, and delete object overrides from this window.

Related Topics

•Managing Existing Objects

•Creating Object Overrides for a Single Device

•Creating Object Overrides for Multiple Devices

•Policy Object Manager Window, page F-1

Procedure

Step 1 Select Tools > Policy Object Manager.

Step 2 Select an object type from the Object Type selector to display the table of existing objects of that type.

Step 3 In the work area, select a global object for which device-level overrides have been permitted. These objects are indicated by a green checkmark in the Overridable column. See Allowing a Global Object to Be Overridden.

Step 4 Double-click the checkmark, or right-click the object and select Edit Device Overrides. The Policy Object Overrides window is displayed.

Each device-level override defined for the selected object is displayed in a table containing the name of the device to which the override applies, the category assigned to the object, and the object definition. See Policy Object Overrides Window, page F-181 for a description of the fields in this window.

Step 5 (Optional) Do one of the following:

•To create a device-level override, click the New Object button. For more information, see Creating Device-Level Object Overrides.

•To edit a device-level override, select the object from the table, then click the Edit Object button.

•To delete a device-level override, select the object from the table, then click the Delete Object button. For more information, see Deleting Device-Level Object Overrides.

Step 6 Click Close to return to the Policy Object Manager window.

Duplicating Objects

An alternative to creating a policy object from scratch is to duplicate an existing object. The new object contains all the attributes of the copied object and a default name. You can then modify the name and all attributes as required.

Duplicating is useful for creating objects that are based on predefined objects that cannot be edited.

This procedure describes how to duplicate an object.

Related Topics

•Managing Existing Objects

•Policy Object Manager Window, page F-1

Procedure

Step 1 Select Tools > Policy Object Manager. The Policy Object Manager window is displayed.

Step 2 Select an object type from the Object Type selector.

Step 3 In the work area, right-click the object you want to duplicate, then select Create Duplicate.

The dialog box for that object type appears. The Name field contains the following default name for the new object: Copy of name of copied object. The remaining fields contain the same values as the copied object.

Step 4 Modify the name of the new object and its configuration, as required.

Step 5 Click OK to save your changes.

Generating Object Usage Reports

Before you make any changes to a user-defined object, you should determine if the object is being used. You can do this by generating usage reports that show which policies, objects, and devices are using the selected object and would therefore be affected by changes to that object. Usage reports contain any references to the selected object in your current activity as well as references found in the data committed to the Security Manager database.

Related Topics

•Managing Existing Objects

•Policy Object Manager Window, page F-1

Procedure

Step 1 Select Tools > Policy Object Manager. The Policy Object Manager window appears.

Step 2 Select an object type from the Object Type selector.

Step 3 In the work area, right-click the object for which you want to generate a report, then select Find Usage.

The Usage Reports window appears, displaying all references to the selected object. See Table F-139 on page F-181 for a description of the fields in this window.

Tip Click a column header to sort the table according to the contents of that column. Click the column header again to sort the table in reverse order.

Step 4 (Optional) Filter the information displayed in the usage report by deselecting one or more of the following check boxes:

•Devices

•Policies

•Other Objects

The deselected entries are removed from the report.

Viewing Object Details

You can view detailed object information in read-only mode, even when the object is locked by another activity. This is useful when you need to view complete configuration details for complex objects whose definitions cannot be fully displayed in the Policy Object Manager window or when your user privileges allow you only to view object information.

Note You can display object details without opening an activity.

This procedure describes how to display complete configuration details for a selected object in read-only mode.

Related Topics

•Managing Existing Objects

•Policy Object Manager Window, page F-1

Procedure

Step 1 Select Tools > Policy Object Manager. The Policy Object Manager window is displayed.

Step 2 Select an object type from the Object Type selector.

Step 3 In the work area, right-click the object that you want to view configuration details for, then select View Object.

The dialog box for that object appears in read-only mode.

Understanding AAA Server Group Objects

In Security Manager, policies requiring AAA (such as Easy VPN, Remote Access VPNs, and router platform policies such as Secured Device Provisioning and 802.1x) refer to AAA server group objects. These objects contain multiple AAA servers that use the same protocol, such as RADIUS or TACACS+. In essence, AAA server groups represent collections of authentication servers focused on enforcing specific aspects of your overall network security policy. For example, you can group those servers dedicated to authenticating internal traffic, external traffic, or remote dial-in users, as well as servers that authorize the administration of your firewall devices.

AAA server groups objects are typically made up of individual AAA server objects. For more information, see Understanding AAA Server Objects. Security Manager policies always refer to the AAA server group, rather than individual AAA servers.

The following topics describe how to work with AAA server group objects:

•Predefined AAA Authentication Server Groups

•Default AAA Server Groups and IOS Devices

•Creating AAA Server Group Objects

Related Topics

•Creating Objects

Predefined AAA Authentication Server Groups

Security Manager contains several predefined AAA server groups that define an authentication method without specifying particular AAA servers. In policies such as IPsec proposals, you can use these predefined server groups to define the types of AAA authentication to perform and the order in which to perform them.

Table 9-1 lists the predefined AAA authentication server groups.

Table 9-1 Predefined AAA Authentication Server Groups

Name

Description

Enable

Uses the enable password for authentication.

KRB5

Uses Kerberos 5 for authentication.

Note For Cisco IOS routers, Security Manager supports Kerberos 5 client configuration only on selected platforms running IOS Software versions that support this protocol. Server configuration is not supported. The device must include an Advanced series feature set (k9 crypto image).

Line

Uses the line password for authentication.

Local

Uses the local username database for authentication.

None

Uses no authentication.

RADIUS

Does not apply to Cisco IOS routers.

Uses RADIUS authentication.

Note This AAA server group does not contain any AAA servers at the global level. To use this AAA server group when defining a policy, you must create a device-level override and define the AAA servers to associate with the group. For more information, see Creating Device-Level Object Overrides.

TACACS+

Does not apply to Cisco IOS routers.

Uses TACACS+ authentication.

Note This AAA server group does not contain any AAA servers at the global level. To use this AAA server group when defining a policy, you must create a device-level override and define the AAA servers to associate with the group. For more information, see Creating Device-Level Object Overrides.

Related Topics

•Creating AAA Server Group Objects

•Default AAA Server Groups and IOS Devices

•Understanding AAA Server Group Objects

Default AAA Server Groups and IOS Devices

IOS software enables you to define AAA servers either as members of AAA server groups or as individual servers. Security Manager, however, requires all AAA servers to belong to a AAA server group.

Therefore, when you discover an IOS device whose device configuration contains individual AAA servers that do not belong to a AAA server group, Security Manager creates the following server groups to contain these servers:

•For RADIUS: CSM-rad-grp

•For TACACS+: CSM-tac-grp

Both of these special AAA server groups are marked in the Policy Object Manager as the default groups for their protocol. This is indicated by the Make this Group the Default AAA Server Group check box.

These groups are created solely for the purpose of management by Security Manager. During deployment, the AAA servers in these special groups are deployed back to the IOS device as individual servers, not as part of the group.

Note If you use one of these default AAA server groups in a policy defined for a PIX/ASA/FWSM device, the AAA servers are deployed as a group to that device, not as individual servers. This is because all AAA servers on PIX/ASA/FWSM devices must belong to a AAA server group.

Caution We recommend that you use caution when using these default AAA server groups in a policy definition. There are certain commands (for example, ip radius and ip tacacs, which are configured using the Interface field in the AAA Server dialog box) that can be defined once for each AAA server group and once for all individual AAA servers. Because the AAA servers in the default group are deployed to IOS devices as individual servers, you might inadvertently change the ip radius or ip tacacs settings for all the individual AAA severs configured on the device, including servers that are not being managed by Security Manager (and whose configurations would otherwise be left undisturbed).

Related Topics

•Predefined AAA Authentication Server Groups

•Creating AAA Server Group Objects

•Understanding AAA Server Group Objects

•Understanding AAA Server Objects

Creating AAA Server Group Objects

You can create AAA server group objects for Security Manager policies requiring AAA services, such as authentication and authorization. Each AAA server group object can contain multiple AAA servers, all of which use the same protocol, such as RADIUS or TACACS+. For example, if you want to use RADIUS to authenticate network access and TACACS+ to authenticate CLI access, you must create at least two AAA server group objects, one for RADIUS servers and one for TACACS+ servers.

In addition, only one source interface can be defined for the AAA servers in the group. An error is displayed when you submit your changes if different AAA servers in the group use different source interfaces.

Note The error is triggered by the actual interface defined as the source, not the name of the interface role that represents the interface. That is, two AAA servers can have different interface roles defined as the source interface as long as they both resolve to the same device interface. An error is also displayed if the interface role defined for the source interface matches more than one actual interface on the device.

The number of AAA server group objects that can be created and the number of AAA server objects that can be included in each group object depend on the selected platform. For example, ASA devices support up to 18 single-mode server groups (with up to 16 servers each) and 7 multi-mode server groups (with up to 4 servers each). PIX firewalls support up to 14 server groups, each containing up to 14 servers.

Objects are defined at the global level, which means that they are applied identically to every object and policy that references them. However, you can override AAA server group object definitions at the device level. For more information, see Managing Object Overrides.

This procedure describes how to create AAA server group objects.

Note Security Manager includes a predefined AAA server group object that you can use when you perform authentication locally inside the Cisco IOS router.

Tip You can also create AAA server group objects when you define policies or objects that use this object type. For more information, see Selecting Objects for Policies.

Before You Begin

•Read and understand Guidelines for Managing Objects.

Related Topics

•Predefined AAA Authentication Server Groups

•Default AAA Server Groups and IOS Devices

•Understanding AAA Server Group Objects

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select AAA Server Groups from the Object Type selector.

Step 3 Right-click inside the work area, then select New Object.

The AAA Server Group dialog box appears. For a description of the fields in this dialog box, see Table F-3 on page F-6.

Step 4 Enter a name for the object. The maximum name length is 16 characters if you plan to use this object with firewall devices and 128 characters for Cisco IOS routers. Spaces are not supported.

Note Cisco IOS routers do not support the following AAA server group names: RADIUS, TACACS, TACACS+. In addition, we do not recommend using an abbreviation of one of these names, such as rad or tac.

Step 5 (Optional) Enter a description for the object. The maximum length is 1024 characters (special characters are permitted).

Step 6 Select the protocol to be used by the servers in the group.

Step 7 Enter the names of the AAA servers to include in the group, or click Select to display a selector (see Selecting Objects for Policies). Only those servers corresponding to the selected protocol are displayed.

Tip If the required AAA server is not listed, click the Create button or the Edit button in the selector to open the AAA Server Dialog Box, page F-8. From here you can define a AAA server to include in the server group.

When you finish, click OK to return to the AAA Server Group dialog box. Your selections are displayed in the AAA Servers field.

Step 8 (IOS devices only) Select the check box if this group is to be the default group in the network for RADIUS or TACACS+. Use this option if you intend to have a single global server group for this protocol for all policies requiring AAA.

The default group can be used in most cases, except when you need to configure multiple AAA server groups that use the same protocol. For example, you might want to define multiple RADIUS groups so that one group can be used for authentication and another group for authorization. Service providers may want to define multiple groups with the same protocol in order to provide customer separation when using VRF.

Note Default groups are created automatically when you discover individual AAA servers configured on an IOS router. These server groups are created solely for the purpose of management by Security Manager. For more information, see Default AAA Server Groups and IOS Devices.

Step 9 (PIX/ASA/FWSM devices only) Configure the following settings:

a. Specify the number of connection attempts that can fail before a server is considered inactive.

b. Select the method for reactivating failed servers in the group:

•Depletion—All servers in the group are permitted to fail before all the servers are reactivated (known as depletion). This is the default.

•Timed—Causes failed servers to be reactivated after 30 seconds of downtime. This option is useful when customers use the first server in a server list as the primary server and prefer that it is online whenever possible.

Note The Timed option must be used when simultaneous accounting has been enabled, as described in d. below.

c. (When Depletion is selected) You can configure the deadtime, which determines how long (in minutes) the system waits after the last server in the group has become inactive before beginning reactivation.

d. Select the method to use for sending accounting messages (single or simultaneous). This setting applies only to RADIUS to TACACS+.

Step 10 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 11 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 12 Click OK to save the object.

Understanding AAA Server Objects

You can create AAA server objects in Security Manager. AAA enables devices to determine who the user is (authentication), what the user is permitted to do (authorization), and what the user actually did (accounting), as described below:

•Authentication—Authentication is the way a user is identified before being allowed access to the network and network services. It controls access by requiring valid user credentials, which are typically a username and password. All authentication methods, except for local, line password, and enable authentication, must be defined through AAA. You can use authentication alone or with authorization and accounting.

•Authorization—After authentication is complete, authorization controls the services and commands available to each authenticated user. Authorization works by assembling a set of attributes that describe what the user is authorized to perform. These attributes are compared to the information contained in a database for a given user and the result is returned to AAA to determine the user's actual capabilities and restrictions. The database can be located locally on the access server or router or it can be hosted remotely on a RADIUS or TACACS+ security server. Were you not to use authorization, authentication alone would provide the same access to services to all authenticated users. You must use authorization together with authentication.

•Accounting—Accounting is used to track the services users are accessing, as well as the amount of network resources they are consuming. When AAA accounting is activated, the network access server reports user activity to the RADIUS or TACACS+ security server (depending on which security method you have implemented) in the form of accounting records. Accounting information includes when sessions start and stop, usernames, the number of bytes that pass through the device for each session, the service used, and the duration of each session. This data can then be analyzed for network management, client billing, and/or auditing. You can use accounting alone or together with authentication and authorization.

AAA provides an extra level of protection and control for user access over using ACLs alone. For example, you can create an ACL allowing all outside users to access Telnet on a server on the DMZ network. If you want only some users to access the server (and you might not always know the IP addresses of these users), you can enable AAA to allow only authenticated and/or authorized users to make it through the device.

AAA server objects are collected into AAA server group objects. In Security Manager, all policies requiring AAA (such as EzVPN, Remote Access VPNs, and router platform policies such as Secured Device Provisioning and 802.1x) use AAA server group objects. See Understanding AAA Server Group Objects.

The following topics describe how to work with AAA server objects:

•Supported AAA Server Types

•AAA Support on ASA Devices

•Creating AAA Server Objects

Related Topics

•Creating Objects

Supported AAA Server Types

Security Manager supports AAA servers using one of the following protocols:

RADIUS

Remote Authentication Dial-In User Service (RADIUS) is a distributed client/server system that secures networks against unauthorized access. In the Cisco implementation, RADIUS clients run on Cisco devices and send authentication requests to a central RADIUS server that contains all user authentication and network service access information. RADIUS is a fully open protocol, distributed in source code format, that can be modified to work with any security system currently available on the market.

Cisco supports RADIUS under its AAA security model. RADIUS can be used with other AAA security protocols, such as TACACS+, Kerberos, and local username lookup. RADIUS is supported on all Cisco platforms, but some RADIUS-supported features run only on specified platforms.

TACACS+

Terminal Access Controller Access Control System (TACACS+) is a security application that provides centralized validation of users attempting to gain access to a router or network access server. The goal of TACACS+ is to provide a methodology for managing multiple network access points from a single management service.

TACACS+ provides for separate and modular authentication, authorization, and accounting facilities. TACACS+ allows for a single access control server (the TACACS+ daemon) to provide each service—authentication, authorization, and accounting—independently.

Related Topics

•AAA Support on ASA Devices

•Creating AAA Server Objects

•Understanding AAA Server Objects

AAA Support on ASA Devices

In addition to supporting RADIUS and TACACS+, ASA devices can support AAA servers running the following protocols:

•AAA Support on ASA Devices

•AAA Support on ASA Devices

•AAA Support on ASA Devices

•AAA Support on ASA Devices

•AAA Support on ASA Devices

Note For more information, see Configuring AAA Servers and the Local Database at this URL:
http://www.cisco.com/en/US/docs/security/asa/asa72/configuration/guide/aaa.html

Kerberos

ASA devices can use Kerberos servers for VPN authentication. When a user attempts to establish VPN access through the ASA device, and the traffic matches an authentication statement, the device consults the Kerberos server for user authentication and grants or denies user access based on the response from the server. 3DES, DES, and RC4 encryption types are supported.

NT

ASA devices can use NT servers for VPN authentication. When a user attempts to establish VPN access and the applicable tunnel-group policy specifies an NT authentication server group, the ASA device consults the Microsoft Windows domain server for user authentication and grants or denies user access based on the response from the domain server.

SDI Servers

SecurID servers from RSA Security, Inc. are known as SDI servers. When a user attempts to establish VPN access and the applicable tunnel-group policy specifies an SDI authentication server group, the ASA device sends the username and one-time password to the SDI server. The device then grants or denies user access based on the response from the server. Version 5.0 of SDI introduced the concept of SDI master and slave servers that share a single-node secret file (SECURID). As a result, when you configure an SDI server as a AAA server object in Security Manager, you must specify whether the server is version 5.0 or an earlier version.

LDAP

ASA devices can use Lightweight Directory Access Protocol (LDAP) servers for VPN authorization. ASA devices support LDAP version 3 and are compatible with any v3 or v2 directory server. However, password management is supported only on the Sun Microsystems JAVA System Directory Server and the Microsoft Active Directory.

With any other type of LDAP server (such as Novell or OpenLDAP), all LDAP functions are supported except for password management. Therefore, if someone tries to log in to an ASA device using one of these other servers for authentication and their password has expired, the ASA device drops the connection and a manual password reset is required.

You can configure Simple Authentication and Security Layer (SASL) mechanisms to authenticate an LDAP client (in this case, the ASA device) to an LDAP server. Both ASA devices and LDAP servers can support multiple mechanisms. If both mechanisms (MD5 and Kerberos) are available, the ASA device uses the stronger mechanism, Kerberos, for authentication.

When user authentication for VPN access has succeeded and the applicable tunnel-group policy specifies an LDAP authorization server group, the ASA device queries the LDAP server and applies the authorizations it receives to the VPN session.

HTTP-Form

The security appliance can use the HTTP Form protocol for single sign-on (SSO) authentication of WebVPN users only. Single sign-on support lets WebVPN users enter a username and password only once to access multiple protected services and Web servers. The WebVPN server running on the security appliance acts as a proxy for the user to the authenticating server. When a user logs in, the WebVPN server sends an SSO authentication request, including username and password, to the authenticating server using HTTPS. If the server approves the authentication request, it returns an SSO authentication cookie to the WebVPN server. The security appliance keeps this cookie on behalf of the user and uses it to authenticate the user to secure websites within the domain protected by the SSO server.

Table 9-2 describes the AAA services that are supported by each protocol:

Table 9-2 AAA Services Supported by ASA Devices

AAA Service

Database Type

Local

RADIUS

TACACS+

SDI

NT

Kerberos

LDAP

HTTP Form

Authentication of...

VPN users

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Firewall sessions

Yes

Yes

Yes

Yes

Yes

Yes

Yes

No

Administrators

Yes

Yes

Yes

Yes2

Yes

Yes

Yes

No

Authorization of...

VPN users

Yes

Yes

No

No

No

No

Yes

No

Firewall sessions

No

Yes3

Yes

No

No

No

No

No

Administrators

Yes4

No

Yes

No

No

No

No

No

Accounting of...

VPN connections

No

Yes

Yes

No

No

No

No

No

Firewall sessions

No

Yes

Yes

No

No

No

No

No

Administrators

No

Yes5

Yes

No

No

No

No

No

^{1. HTTP Form protocol supports single sign-on (SSO) authentication for WebVPN users only.}^{2. SDI is not supported for HTTP administrative access.}^{3. For firewall sessions, RADIUS authorization is supported with user-specific ACLs only, which are received or specified in a RADIUS authentication response.}^{4. Local command authorization is supported by privilege level only.}^{5. Command accounting is available for TACACS+ only.}

Related Topics

•Supported AAA Server Types

•Creating AAA Server Objects

•Understanding AAA Server Objects

Creating AAA Server Objects

You can create AAA server objects to populate the AAA server group objects that are referenced by Security Manager policies, such as Easy VPN and 802.1x. When creating a AAA server object, you must specify the IP address of the external AAA server, the key used for data encryption, the protocol used by the server, and the timeout interval.

This procedure describes how to create AAA server objects.

Note On PIX/ASA/FWSM devices, AAA objects in a device configuration that are not referenced by any policies are removed from the device during the next deployment. However, the predefined AAA objects named RADIUS and TACACS+ are never removed from PIX 6.3 devices, even if they are unreferenced by any policies.

Before You Begin

•Read and understand Guidelines for Managing Objects.

•Configure the external AAA server that will be referenced by the AAA server object.

Related Topics

•Supported AAA Server Types

•AAA Support on ASA Devices

•Understanding AAA Server Objects

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select AAA Servers from the Object Type selector.

Step 3 Right-click in the work area, then select New Object.

The AAA Server dialog box appears. For a description of the fields in this dialog box, see Table F-4 on page F-8.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 In the Connect to Host Using field, do one of the following:

•Enter the IP address of the AAA server in the IP Address field, or click Select to display a selector. See Selecting Objects for Policies.

•(ASA 7.2 devices only) Enter the DNS name of the AAA server.

Step 6 (Optional) In the Interface field, enter the interface or interface role whose IP address that should be used for all outgoing RADIUS or TACACS packets, or click Select to display a selector. See Selecting Objects for Policies.

When you enter the name of an interface, make sure the policy that uses this AAA object is assigned to a device containing an interface with this name. Otherwise, deployment will fail.

When you enter the name of an interface role, make sure the role represents a single interface, not multiple interfaces. Otherwise, an error message is displayed.

Tip If the required interface role is not listed, click the Create button or the Edit button to open the Interface Role Dialog Box, page F-108. From here, you can define an interface role to use in the object. The interface role you define must correspond to a single interface on the device.

Step 7 Enter the amount of time to wait until a AAA server is considered unresponsive.

Step 8 Select the protocol used by the AAA server and configure protocol-specific properties. For details about these properties, see Table F-4 on page F-8.

Note The Kerberos, LDAP, NT, SDI, and HTTP-FORM protocols can be used only with ASA, PIX 7.x, and FWSM 3.1 and above devices.

Step 9 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 10 Click OK to save the object.

Creating Access Control List Objects

An Access Control List (ACL) object is made up of one or more access control entries (ACEs), one or more ACL objects, or a combination of both. Each ACE is an individual permit or deny statement within an ACL. You can use ACL policy objects in several other policies and policy objects.

You can create the following types of ACL objects:

•Extended—Extended ACLs enable you to specify source and destination addresses and service (or traffic protocol), and, based on the protocol type, the ports (for TCP or UDP), or the ICMP type (for ICMP) can be specified. For information on extended ACL objects, see Creating Extended Access Control List Objects.

•Standard—Standard ACLs use the source address for matching traffic. For information on standard ACL objects, see Creating Standard Access Control List Objects.

•Web Type—Web ACLs use destination address and port or a URL filter. For information on Web Type ACL objects, Creating Web Access Control List Objects.

When you add devices to the device inventory that already have ACLs configured, Security Manager tries to preserve your ACL names to some extent. For more information, see Understanding How Security Manager Handles ACL Names.

Creating Extended Access Control List Objects

Extended access control lists allow you to permit or deny traffic from specific IP addresses to specific destination IP address and port, and specify the protocol of the traffic, such as ICMP, TCP, UDP, and so forth. Extended ACLs range from 100 to 199, and for devices running Cisco IOS Software Release 12.0.1 and higher, 2000 to 2699.

Extended ACL example:
access-list 110 - Applied to traffic leaving the office (outgoing)
access-list 110 permit tcp 10.128.2.0 0.0.0.255 any eq 80
ACL 110 permits traffic originating from any address on the 10.128.2.0 network. The "any" statement means that the traffic is allowed to have any destination address with the limitation of going to port 80. The value of 0.0.0.0/255.255.255.255 can be specified as "any".

Uses:

•Identifying addresses for NAT (policy NAT and NAT exemption)—Policy NAT lets you identify local traffic for address translation by specifying the source and destination addresses and ports in an extended access list. Regular NAT can only consider local addresses. An access list that is used with policy NAT cannot be configured to deny an access control entry (ACE).

•Identifying addresses for IOS dynamic NAT—For user-defined ACLs, the NAT plug-in generates its own ACL CLIs when deducing NAT traffic from VPN traffic.

•Filtering traffic that will be intercepted by Network Admission Control (NAC).

•Identifying traffic in a traffic class-map for modular policy—Access lists can be used to identify traffic in a class-map, which is used for features that support Modular Policy Framework such as TCP and general connection settings, inspection, IPS, and QoS. You can use one or more access lists to identify specific types of traffic.

•For transparent mode, enabling protocols that are blocked by a routed mode security appliance, including BGP, DHCP, and multicast streams. Because these protocols do not have sessions on the security appliance to allow return traffic, these protocols also require access lists on both interfaces.

•Establishing VPN access—You can use an extended access list in VPN commands to identify the traffic that should be tunneled on the device for an IPsec site-to-site tunnel or to identify the traffic that should be tunneled on the device for a VPN client. Use in conjunction with the policy objects and settings shown in Table 9-3:

Table 9-3 Policy Objects and Settings

Policy Object

Device

Purpose

VPN Topology

Any

Selecting Protected Networks.

ASA User Group

ASA

Inbound Firewall Policy; Outbound Firewall Policy; Filter ACL.

Traffic Flow

ASA 7.x, PIX 7.x

Service Policy Rules (MPC). The traffic flow BB (class-map) uses Extended ACL as one of its traffic match types.

User Group

•IOS

•Catalyst 6500/7600

•PIX 6.3

For Easy VPN, Split Tunnel ACL and Firewall ACL (IOS devices only).

Related Topics

•Guidelines for Managing Objects

•Creating Access Control List Objects

•Understanding Network/Host Objects

•Understanding Service Objects

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Access Control Lists.

The Access Control List page appears. The Extended tab opens by default.

Step 3 Right-click inside the work area, then select New Object.

The Add Extended Access List dialog box appears (see Add or Edit Access List Dialog Boxes, page F-19).

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Right-click inside the table, then select Add.

The Add Extended Access Control Entry dialog box appears.

Step 6 Create the access control entry:

•If you select Access Control Entry for Type, specify the characteristics of the traffic that you want to match and whether you are permitting or denying the traffic. Enter the source addresses whence the traffic originates, the destination addresses whither the traffic travels, and the services that define the characteristics of the traffic. Click Advanced to define logging options. For detailed information about the fields on the dialog box, see Add and Edit Extended Access Control Entry Dialog Boxes, page F-20.

•If you select ACL Object, select the object in the available objects list and click >> to add it to the list of selected objects.

Step 7 Click OK to save your changes.

The dialog box closes and you return to the Add Extended Access List page. The new entry is shown in the table. If necessary, select it and click the up or down buttons to position it at the desired location.

Step 8 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 9 Click OK to save the object.

Creating Standard Access Control List Objects

A standard access control list allows you to permit or deny traffic from specific IP addresses. The destination of the packet and the ports involved can be anything. Standard IP ACLs range from 1 to 99.

Standard ACL example:
access-list 10 permit 192.168.2.0 0.0.0.255
Uses:

•Identifying OSPF route redistribution.

•Filtering users of a community string using SNMP.

•Configuring VLAN ACLs for a Catalyst 6500/7600 device.

Related Topics

•Guidelines for Managing Objects

•Creating Access Control List Objects

•Understanding Network/Host Objects

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Access Control Lists.

The Access Control List page appears.

Step 3 Click the Standard tab.

Step 4 Right-click inside the work area, then select New Object.

The Add Standard Access List dialog box appears (see Add or Edit Access List Dialog Boxes, page F-19).

Step 5 Enter a name for the object and optionally a description of the object.

Step 6 Right-click inside the table, then select Add.

The Add Standard Access Control Entry dialog box appears.

Step 7 Create the access control entry:

•If you select Access Control Entry for Type, specify the characteristics of the traffic that you want to match and whether you are permitting or denying the traffic. Enter the source addresses whence the traffic originates and select logging options. For detailed information about the fields on the dialog box, see Add and Edit Standard Access Control Entry Dialog Boxes, page F-22.

•If you select ACL Object, select the object in the available objects list and click >> to add it to the list of selected objects.

Step 8 Click OK to save your changes.

The dialog box closes and you return to the Add Standard Access List dialog box. The new entry is shown in the table. If necessary, select it and click the up or down buttons to position it at the desired location.

Step 9 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 10 Click OK to save the object.

Creating Web Access Control List Objects

Web ACLs, also referred to as WebVPN, let you establish a secure, remote-access VPN tunnel to the security appliance using a web browser. There is no need for either a software or hardware client. WebVPN provides easy access to a broad range of web resources and both web-enabled and legacy applications from almost any computer that can reach HTTPS Internet sites. WebVPN uses Secure Socket Layer Protocol and its successor, Transport Layer Security (SSL/TLS1) to provide a secure connection between remote users and specific, supported internal resources that you configure at a central site.

Table 9-4 shows examples of Web VPN ACLs.

Table 9-4 Examples of Web VPN ACLs

Action

Filter

Effect

Deny

url http://*.yahoo.com/

Denies access to all of Yahoo!

Deny

url cifs://fileserver/share/directory

Denies access to all files in the specified location.

Deny

url https://www.company.com/ directory/file.html

Denies access to the specified file.

Permit

url https://www.company.com/directory

Permits access to the specified location

Deny

url http://*:8080/

Denies HTTPS access to anywhere via port 8080.

Deny

url http://10.10.10.10

Denies HTTP access to 10.10.10.10.

Permit

url any

Permits access to any URL. Usually used after an ACL that denies url access.

Uses:

•As a filter ACL in an ASA User Group policy object (under SSL VPN > Clientless).

Related Topics

•Guidelines for Managing Objects

•Creating Access Control List Objects

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Access Control Lists.

The Access Control List page appears.

Step 3 Click the Web tab.

Step 4 Right-click inside the work area and select New Object.

The Add WebType Access List dialog box appears (see Add or Edit Access List Dialog Boxes, page F-19).

Step 5 Enter a name for the object and optionally a description of the object.

Step 6 Right-click inside the access control entry table and select Add.

The Add Web Access Control Entry dialog box appears.

Step 7 Create the access control entry:

•If you select Access Control Entry for Type, specify the characteristics of the traffic that you want to match and whether you are permitting or denying the traffic. You can filter based on the network destination of the traffic (Network Filter) or the web address (URL Filter). For detailed information about the fields on the dialog box, see Add and Edit Web Access Control Entry Dialog Boxes, page F-23.

•If you select ACL Object, select the object in the available objects list and click >> to add it to the list of selected objects.

Step 8 Click OK to save your changes.

The dialog box closes and you return to the Add WebType Access List page. The new entry is shown in the table. If necessary, select it and click the up or down buttons to position it at the desired location.

Step 9 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 10 Click OK to save the object.

Understanding How Security Manager Handles ACL Names

Security Manager tries preserve user-defined ACL names as they appear in devices. For more information, see Preserving User-Defined ACL Names. Security Manager also has the ability to assign a name to an ACL, which requires no user intervention. For more information, see How ACL Names Are Generated.

ACL policy objects also support device-override during discovery. Device override allows policy objects that have different content to share the same policy object name in Security Manager. For example, Device A and Device B both have an ACL with the name `myACL', but each ACL contains different content. After discovering Device A, `myACL' policy object is created. Without device-override, Security Manager will create `myACL_1' for Device B because the content of the two `myACLs' is different. With device-override, Security Manager can create `myACL' for Device B, resulting in two `myACL' policy objects in Security Manager, one for Device A and one for Device B.

For IOS devices, when device override is not set, ACLs with duplicate names are imported with a suffix `_n', where n is a number. A numbered ACL can be imported as <ACL number>_n, such as 100_1. 100_1 is not a valid ACL name in IOS. As a result, _n is stripped from the numbered ACL at deployment. For example, IOS Device 1 has ACL 100. IOS Device 2 has ACL 100. Device 1 and Device 2 have different content. Both devices are imported in Security Manager. Security Manager creates 100 for device 1 and 100_1 for Device 2. 100_1 is not a valid name in IOS devices. Security Manager removes the _1 suffix at deployment and 100 is deployed to the device.

The _n suffix is not removed from the named ACL during deployment because <named ACL>_n is a valid ACL name in IOS.

Policies that do not support ACL name preservation are as follows:

•IOS Policies

–AAA rules

–SSL VPN

–Transparent firewall rules

•ASA/PIX Policies

–Service policy rules

–SSL VPN

–Transparent firewall rules

Related Topics

•How ACL Names Are Generated

•Preserving User-Defined ACL Names

•Identifying Original ACL Names

•Naming Conflicts and Resolutions

•Notes on ACL Naming

Preserving User-Defined ACL Names

For Access Control Rules

You can elect to retain user-defined ACL names instead of having Security Manager generate ACL names. Note, however, that a relationship exists between name preservation, deployment time, and non-traffic interruption. For example, name preservation will have an effect on deployment time and traffic interruption. (Deployment approaches and their effects are explained in detail in the Troubleshooting Guide.) To define user-defined ACL names, select Firewall > Settings > Access Control. For a description of the GUI elements, see Access Control Page, page I-101.

If the same ACL is applied to more than one interface and direction, you can specify the ACL name (e.g., MyInsideACL) for a maximum of one interface and direction. Security Manager automatically detects the sharing relationship and applies the same ACL to all sharing interfaces.

For Firewall Policies

For ACLs used by AAA, NAT, and firewall access (access-group), ACL sharing is preserved if you choose to reuse existing ACL names (Tools > Security Manager Administration > Deployment). By preserving ACL sharing, we mean that if an ACL is already shared by multiple commands on the device, Security Manager will continue to leave the sharing intact upon new deployments. This preservation, however, is only possible if the according Security Manager policies that this ACL corresponds to translate to the same ACL.

For example, an ACL is originally shared by AAA and NAT commands on a device. If you change the AAA policy in Security Manager so it translates to an ACL with different content from the NAT ACL, the two ACLs can no longer be shared. Two ACLs with different content and names are then provisioned.

Note Although ACL sharing is not commonly used, certain circumstances might find it beneficial with regard to ease-of-use and memory usage.

During deployment, Security Manager generates one ACL for each interface and direction. Names of the ACLs are determined in a number of ways.

•You can define a name in Access Control Settings. Go to Firewall > Settings > Access Control.

•You can select the method by which Security Manager deploys ACLs. Go to Tools > Security Manager Administration > Deployment.

If you select "reuse existing names," the names might correspond to the ACL name in the device, or a name previously generated by Security Manager.

Note In situations where an ACL name is not specified in Security Manager, but a name exists in the original configuration, Security Manager can reuse the ACL name instead of using the default ACL naming conventions. For example, if no name is specified in the Access Control page for an ACL that is applied to the inbound of the inside interface, but the device has an access-list named "InsideAcl" on the inbound direction of the inside interface, Security Manager can recognize "InsideAcl" if "Reuse existing names" is selected.

ACL names cannot be specified for all firewall rule types. For example, you can specify a name for ACLs used in access rules, but you cannot specify a name for ACLs used in IOS AAA or inspection rules. For these unnamed ACL policies, Security Manager automatically generates ACL names. For more information, see How ACL Names Are Generated.

You can retain names of user-defined VPN policies that use ACL policy object names. Supported use cases are shown in the table.

Access Type

Supported Device

How Used

Remote Access VPN

PIX 6.3

User Group Object/Split Tunneling

Remote Access VPN

IOS

User Group Object/Split Tunneling

User Group Object/Client Settings/Firewall Are You There

Remote Access VPN

ASA/PIX 7.0

User Group Object/Split Tunneling

User Group Object/Client Firewall Attributes/Inbound and Outbound Traffic Policies

Remote Access VPN

ASA/PIX 8.x

Dynamic Access

EZVPN

PIX 6.3

User Group Object/Split Tunneling

EZVPN

IOS

User Group Object/Split Tunneling

User Group Object/Client Settings/Firewall Are You There

Client Connection Characteristics/Tunnel Activation ACL

EZVPN

ASA/PIX 7.0

User Group Object/Split Tunneling

User Group Object/Client Firewall Attributes/Inbound and Outbound Traffic Policies

IPSec

IOS, PIX 6.3, PIX 7.0, ASA 7.0+

Peer/Protected Network

Additional policies that support ACL name preservation:

Device

Policies

IOS

Firewall Access Rules, NAT, VTY, Console, HTTP, QoS, NAC, SNMP, Advance Interface Settings, Dialer, VLAN ACl, IPS AIM, IPS Interface Rules, Client Connection Characteristics for Easy VPN, User Group Policy for Easy VPN and for Remote Access VPN, Protected Network for IPSec VPN

ASA/PIX/FWSM

AAA Rules

ASA/PIX

Firewall Acess Rules, NAT, RIP, Dynamic Access under Remote Access VPN, User Group Policy for Easy VPN and for Remote Access VPN (ASA, PIX 7.x, PIX 6.3), Protected Network for IPSec VPN

Note the following (for firewall rules):

•The activity validation process catches the duplication of the ACL name with policies that don't use ACL policy objects, for example, Access Control.

•For policies that use an ACL policy object and support ACL name preservation, deployment is stopped if the ACL name used in VPN policies is used in an "unsupported" command.

Related Topics

•Notes on ACL Naming

•Naming Conflicts and Resolutions

How ACL Names Are Generated

An ACL is assigned a name, which requires no user intervention; however, user-defined ACL names can be retained in Security Manager. For more information, see Preserving User-Defined ACL Names.

When the name for the ACL is generated by Security Manager, the name is derived from the type of rule or platform being defined and certain configuration settings that make it unique. A group command is then generated that binds the defined rules to the ACL.

Table 9-5 shows the naming conventions used for the rule types and platforms.

Table 9-5 ACL Naming Conventions for Rule Types and Platforms

Rule Type

Name

Access ACL

•CSM_FW_ACL_InterfaceName (for inbound)

•CSM_FW_ACL_OUT_InterfaceName (for outbound)

Note Only OUT is explicitly present as part of the ACL name.

Inspection

For ASA 7.0/PIX 7.0:

•CSM_CMAP_ACL_n where n is an integer beginning with 1.

For IOS devices:

•Devices use a numbered ACL.

AAA ACL

For PIX/ASA/FWSM:

•CSM_AAA_{AUTHO | ATHEN | ACCT}_InterfaceName _ServerGroupName

Authentication Proxy for IOS devices:

•On an interface without NAC: CSM_AUTH-PROXY_<InterfaceName > <traffic type >_ACL, where InterfaceName is the interface in which the rule is applied and traffic type is HTTP, Telnet, or FTP.

•AuthProxy and NAC on the same interface: CSM_ADMISSION_<ID of interface role in snapshot >_ACL, where ID of interface role in snapshot is an internal ID of the interface within Security Manager to which NAC is applied.

Web Filter ACL

For ASA 7.0/PIX 7.0:

•Devices correspond to a filter command.

For IOS devices:

•Devices use a numbered ACL.

NAT 0 ACL

•CSM_nat0_InterfaceName_in (for inbound)

•CSM_nat0_InterfaceName (for outbound)

Policy Nat ACL

•CSM_nat_InterfaceName_poolID_in (for inbound)

•CSM_nat_InterfaceName_poolID (for outbound)

•For PIX 6.3(x):

–_dns (for dns)

–_nrseq (for norandomseq)

–_emb## (for embryonic limit)

–_tcp## (for tcp max connection limits)

–_udp## (for udp max connection limits)

Policy Static ACL

•CSM_static_localIP_globalIP_LocalInterfaceName _globalInterfaceName (for IP)

•CSM_static_localIP_globalIP_LocalInterfaceName _globalInterfaceName_ protocol _globalPort (for other protocols)

During deployment, sometimes a suffix ".n " (where n is an integer) might get added to an ACL name if the existing ACL cannot be edited in place. For example, if an ACL named acl_mdc_outside_10 already exists on the device, a new ACL with the name acl_mdc_outside_10.1 is created if you do not remove the old ACL before you deploy the new ACL.

Related Topics

•Preserving User-Defined ACL Names

•Naming Conflicts and Resolutions

•Identifying Original ACL Names

•Notes on ACL Naming

Identifying Original ACL Names

ACLs are identified by a set of key attributes, which are described in Table 9-6. If Security Manager is provisioning the access ACL on the inbound of the interface "Inside," and the original configuration on the device has CLI
access-group acl-inside in interface inside
Then the corresponding original ACL is identified as "acl-inside".

Table 9-6 Identifying Original ACL Names

ACL

Attributes

Access

Interface, direction

AAA

Interface, AAA server tag

Nat 0

Interface, direction

Policy Nat

Interface, pool ID, direction (dns, norandomseq, embryonic limit, tcp/udp max connection limits for PIX 6.3(x)).

Policy Static

Local interface, global interface, local IP (if non-PIX 6.3(x) device), global IP (IP address and mask), global port (if protocol is tcp/udp).

Related Topics

•Notes on ACL Naming

•How ACL Names Are Generated

•Naming Conflicts and Resolutions

•Preserving User-Defined ACL Names

Naming Conflicts and Resolutions

When a naming conflict occurs that results from more than one ACL with different contents attempting to reuse the same ACL name in the original configuration, priorities determine where the original ACL name is used and where the Security Manager naming convention is used. The following order of priority is used, which recognizes the different types of ACLs in descending order:

Access ACLs > AAA ACLs > Static ACLs > NAT 0 ACLs > NAT ACL

For example, if an access ACL and a NAT 0 ACL attempt to reuse the same ACL named MyACL, the access ACL is assigned the user-defined name and the NAT 0 ACL is assigned a name automatically generated by Security Manager. (See Table 9-5.)

If the two competing ACLs are of the same type, (for example, they are both Access ACLs), and using the same naming convention generated by Security Manager, then the one recognized first based on alpha order will have higher priority.

Related Topics

•Identifying Original ACL Names

•Notes on ACL Naming

•How ACL Names Are Generated

•Preserving User-Defined ACL Names

Notes on ACL Naming

•If an ACL has a name specified in Security Manager, it can be retained. For a list of policies that support ACL name preservation, see Preserving User-Defined ACL Names.

•If an ACL is not shared on the device and you change only its content in Security Manager, then the original name is preserved.

•If an ACL is shared on the device and the according ACL policies are still identical in Security Manager, then the original name is preserved.

•If an ACL is shared on the device and the according ACL policies are not identical in Security Manager, then one version of the ACL policies will preserve the original name. The remaining policies will use the Security Manager naming conventions.

•Newly created ACLs use Security Manager naming conventions.

•For Policy Statics, if the source of the access list that is used by the static rule contains an object group, Security Manager flattens the object group and deploys the IP address it contains.

•All ACEs defined in the ACL on the device must have the same source.

•Additional Activity Validation For IOS:

–A device cannot reference two ACL policy objects with the same number prefix before an underscore. Since 100_1 is deployed as 100, 100_1 and 100 cannot be assigned to the same device.

•Validated ACL names (for IOS devices)

–Named ACLs cannot start with an underscore (_) or a number.

–Numbered ACLs must be within a certain range depending on the ACL type, for example, standard or extended.

•ACL object names not used in unsupported commands

–You cannot overwrite an ACL used by unsupported commands.

–You can overwrite an ACL if it is originally shared with Security Manager policies.

•NAT that participates in a VPN cannot share an ACL object with another policy.

–Security Manager does not support all IOS commands. NAT participates in VPN and adds additional ACEs to its ACL; therefore, NAT cannot share the ACL with unsupported commands.

–NAT that participates in a VPN adds additional ACEs to its referenced ACL. Thus, changing a shared ACL is not a desirable behavior.

•Firewall access rules cannot use the same ACL name as a referenced ACL object.

–Firewall access rules do not use ACL objects. The ACL name defined in firewall access rules can conflict with a referenced ACL object name. Therefore, the ACL name used in the firewall access rules cannot be the same as a referenced ACL object name.

Related Topics

•How ACL Names Are Generated

•Preserving User-Defined ACL Names

•Identifying Original ACL Names

•Naming Conflicts and Resolutions

Understanding ASA User Group Objects

ASA User Groups objects are group policies that you use to manage Virtual Private Networks (VPN) group policies.

ASA user groups are configured on ASA security appliances in Easy VPN topologies, IPSec VPNs, and SSL VPNs. When you configure an Easy VPN, IPSec VPN or SSL VPN connection, you must create user groups to which remote clients will belong. A user group policy is a set of user-oriented attribute/value pairs for SSL VPN connections that are stored either internally (locally) on the device or externally on an AAA server. The tunnel group uses a user group policy that sets terms for user connections after the tunnel is established. Group policies let you apply whole sets of attributes to a user or a group of users, rather than having to specify each attribute individually for each user.

An ASA user group object comprises the following attributes:

•Group policy source—Identifies whether the user group's attributes and values are stored internally (locally) on the security appliance or externally on an AAA server. If the user group is an external type, no other settings need to be configured for it. For more information, see ASA User Group Dialog Box, page F-25.

•Client Configuration settings, which specify the Cisco client parameters for the user group in an Easy VPN or remote access VPN. For more information, see ASA User Group Dialog Box: Client Configuration Settings, page F-27.

•Client Firewall Attributes, which configure the firewall settings for VPN clients in an Easy VPN or remote access VPN. For more information, see ASA User Group Dialog Box: Client Firewall Attributes, page F-28.

•Hardware Client Attributes, which configure the VPN 3002 Hardware Client settings in an Easy VPN or remote access VPN. For more information, see ASA User Group Dialog Box: Hardware Client Attributes, page F-30.

•IPsec settings, which specify tunneling protocols, filters, connection settings, and servers for the user group in an Easy VPN or remote access VPN. For more information, see ASA User Group Dialog Box: IPsec Settings, page F-32.

•Clientless settings, which configure the Clientless mode of access to the corporate network in an SSL VPN, for the ASA user group. For more information, see ASA User Group Dialog Box: SSL VPN Clientless Settings, page F-34.

•Full Client settings, which configure the Full Client mode of access to the corporate network in an SSL VPN, for the ASA user group. For more information, see ASA User Group Dialog Box: SSL VPN Full Client Settings, page F-35.

•General settings that are required for Clientless/Port Forwarding in an SSL VPN. For more information, see ASA User Group Dialog Box: SSL VPN Settings, page F-37.

•DNS/WINS settings that define the DNS and WINS servers and the domain name that should be pushed to remote clients associated with the ASA user group. For more information, see ASA User Group Dialog Box: DNS/WINS Settings, page F-39.

•Split tunneling that lets a remote client conditionally direct packets over an IPsec or SSL VPN tunnel in encrypted form or to a network interface in clear text form. For more information, see ASA User Group Dialog Box: Split Tunneling, page F-41.

•Remote access or SSL VPN session connection settings for the ASA user group. For more information, see ASA User Group Dialog Box: Connection Settings, page F-42.

To create ASA user group objects, see Creating ASA User Group Objects.

Related Topics

•Configuring a Tunnel Group Policy for Easy VPN, page 10-81

•Creating Objects

•Policy Object Manager Window, page F-1

Creating ASA User Group Objects

Use the ASA User Groups Objects page to create ASA user group objects for use in an Easy VPN, IPSec VPN, or SSL VPN.

Note You must select the technology (Easy VPN/IPSec VPN, SSL VPN, or Easy VPN/IPSec VPN and SSL VPN) for which you are creating the ASA user group object. If you are editing an existing ASA user group object, the technology is already selected, and you cannot change it. Depending on the selected technology, the appropriate settings are available for configuration.

Tip You can also create ASA User Group objects when defining policies or objects that use this object type. For more information, see Selecting Objects for Policies.

This procedure describes how to create ASA User Group objects.

Before You Begin

•Read and understand Guidelines for Managing Objects.

Related Topics

•Understanding ASA User Group Objects

•ASA User Group Dialog Box, page F-25

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select ASA User Groups.

The ASA User Groups page appears.

Step 3 From the work area, right-click inside the table, then select New Object.

The Add ASA User Group dialog box appears, displaying a list of settings that you can configure for the ASA user group object. For a description of the elements on this dialog box, see Table F-16 on page F-26.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Select whether to store the ASA user group's attributes and values locally on the device, or on an external server.

Note If you selected to store the ASA user group's attributes on an external server, you do not need to configure any Technology settings. After you specify the AAA server group that will be used for authentication and a password to the AAA server, click OK to save your definitions and close the ASA User Group dialog box.

Step 6 If you selected to store the ASA user group's attributes locally on the device, select the type of VPN for which you are creating the ASA user group from the Technology list.

Step 7 To configure the user group for an Easy VPN/IPSec VPN, from the Easy VPN/IPSec VPN folder in the Settings pane:

a. Select Client Configuration to configure the Cisco client parameters for the ASA user group. For a description of the elements required to configure these parameters, see ASA User Group Dialog Box: Client Configuration Settings, page F-27.

b. Select Client Firewall Attributes to configure the firewall settings for VPN clients for the ASA user group. For a description of the elements required to configure these settings, see ASA User Group Dialog Box: Client Firewall Attributes, page F-28.

c. Select Hardware Client Attributes to configure the VPN 3002 Hardware Client settings for the ASA user group. For a description of the elements required to configure these settings, see ASA User Group Dialog Box: Hardware Client Attributes, page F-30.

d. Select IPsec to specify tunneling protocols, filters, connection settings, and servers for the ASA user group. For a description of the elements required to configure these settings, see ASA User Group Dialog Box: IPsec Settings, page F-32.

Step 8 To configure the user group for an SSL VPN, from the SSL VPN folder in the Settings pane:

a. Select Clientless to configure the Clientless mode of access to the corporate network in an SSL VPN, for the ASA user group object. For a description of the elements required to configure the Clientless mode settings, see ASA User Group Dialog Box: SSL VPN Clientless Settings, page F-34.

b. Select Full Client to configure the Full Client mode of access to the corporate network in an SSL VPN, for the ASA user group object. For a description of the elements required to configure the Full Client mode settings, see ASA User Group Dialog Box: SSL VPN Full Client Settings, page F-35.

c. Select Settings to configure the general settings that are required for Clientless/Port Forwarding in an SSL VPN, for the ASA user group object. For a description of the elements required to configure these settings, see ASA User Group Dialog Box: SSL VPN Settings, page F-37.

Step 9 Specify the following settings for an ASA user group in an Easy VPN/IPSec VPN and SSL VPN configuration, in the Settings pane:

a. Select DNS/WINS to define the DNS and WINS servers and the domain name that should be pushed to clients associated with the ASA user group. For a description of the elements required to configure the DNS and WINS servers, see ASA User Group Dialog Box: DNS/WINS Settings, page F-39.

b. Select Split Tunneling to specify a secure tunnel to the central site and simultaneous clear text tunnels to the Internet. For a description of the elements required to configure split tunneling, see ASA User Group Dialog Box: Split Tunneling, page F-41.

c. Select Connection Settings to configure the SSL VPN connection settings for the ASA user group, such as the session and idle timeouts, including the banner text. For a description of the elements required to configure these settings, see ASA User Group Dialog Box: Connection Settings, page F-42.

Step 10 Click OK to save the object.

Understanding Credential Objects

Credential objects are used when authenticating user access to the network and network services. A credential object comprises user credentials, typically a username and password that identify the user during authentication.

In Security Manager, credential objects are used in Easy VPN configuration during IKE Extended Authentication (Xauth). When negotiating tunnel parameters for establishing IPsec tunnels in an Easy VPN configuration, Xauth identifies the user who requests the IPsec connection. If the VPN server is configured for Xauth, the client waits for a "username/password" challenge after the IKE SA has been established. When the end user responds to the challenge, the response is forwarded to the IPsec peers for an additional level of authentication. You can save the Xauth credentials (username and password) on the device itself so you do not need to enter them manually each time the Easy VPN tunnel is established.

To create Credential objects, see Creating Credential Objects.

Related Topics

•Easy VPN and IKE Extended Authentication (Xauth)

•Creating Objects

•Policy Object Manager Window, page F-1

Creating Credential Objects

You can create credential objects to use for IKE Extended Authentication (Xauth) in Easy VPN configurations. For more information, see Understanding Credential Objects.

Credential objects are defined at the global level, which means that they are applied identically to every object and policy that references them. However, you can override credential object definitions at the device level. For more information, see Managing Object Overrides.

This procedure describes how to create a credential object.

Tip You can also create credential objects when defining policies or objects that use this object type. For more information, see Selecting Objects for Policies.

Before You Begin

•Read and understand Guidelines for Managing Objects.

Related Topics

•Understanding Credential Objects

•Credentials Dialog Box, page F-46

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Credentials. The Credentials page opens, displaying the currently defined credential objects.

Step 3 Right-click in the work area, then select New Object.

The Credentials dialog box appears. For a description of the elements in this dialog box, see Table F-31 on page F-47.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Specify a name that will be used to identify the user during Xauth authentication.

Step 6 Enter a password that will be used to identify the user during Xauth authentication.

Step 7 Enter the password again to confirm it.

Step 8 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 9 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 10 Click OK to save the object.

Understanding File Objects

File objects represent files that are used in device configurations. Such files include XML configuration files, image logo files, plug-in jar files, and binary files. The files can be discovered from a device or added by users, managed in Security Manager, and deployed to devices.

When a file is introduced into Security Manager, Security Manager makes a copy of the file and keeps it. A file object is created for this file. A one-to-one relationship exists between a File Object and a file. The File Object keeps a reference to the file in the form of a file URL. The actual file content remains outside of Security Manager. Currently, the ability to edit the actual file content is not supported by Security Manager. However, you can access the file content using the link that is saved in the File Object.

Note Security Manager does not support modification to the actual configuration file. If the file content needs to be modified after the File Object is created, you must manually edit the file in Security Manager's file repository. The full path and filename of the file can be obtained from the File Object's file attribute.

The file storage system is implemented as an internal file directory within Security Manager. The files managed by the File Object are maintained in Security Manager's central file repository. The location of the file repository is: CSCOpx\MDC\FileRepository, where CSCOpx is the root directory of the Security Manager installation.

The files are put under the sub-folders within the file repository. The sub-folder is named after the file type.

Note When a file object is deleted in Security Manager, the actual file corresponding to the file object is not removed from Security Manager's file repository.

Note The Security Manager file repository is included in the standard Security Manager data backup/restore process.

Related Topics

•Policy Object Manager Window, page F-1

•Creating Objects

•Creating File Objects

Creating File Objects

You can create a file object to use when you are configuring a logo image for an SSL VPN customization object, or specifying the filename of the Cisco Secure Desktop (CSD) distribution package to install into the running configuration.

File objects are defined at the global level, which means that they are applied identically to every object and policy that references them. However, you can override credential object definitions at the device level. For more information, see Managing Object Overrides.

This procedure describes how to create a file object.

Tip You can also create file objects when you define policies or objects that use this object type. For more information, see Selecting Objects for Policies.

Before You Begin

•Read and understand Guidelines for Managing Objects.

Related Topics

•Understanding File Objects

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select File Objects. The File Objects page appears.

Step 3 Right-click in the work area, then select New Object.

The Add File Object dialog box appears. For a description of the GUI elements, see Table F-32 on page F-47.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Select the type of file from the list box.

Step 6 Click Browse to select the navigation path to the desired file. The File Name on Device field will automatically be set based on the actual filename. Note: The file can reside anywhere on the Security Manager server; however, it must reside on the server. File selection from the Security Manager client computer is not supported. After the File Object is created, Security Manager automatically copies the file into its central file repository.

Step 7 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 8 Click OK to save the object.

Understanding IKE Proposal Objects

Internet Key Exchange (IKE) proposal objects contain the parameters required for IKE proposals when defining remote access VPN policies. IKE is a key management protocol that facilitates the management of IPsec-based communications. It is used to authenticate IPsec peers, negotiate and distribute IPsec encryption keys, and automatically establish IPsec security associations (SAs).

The IKE negotiation comprises two phases. Phase 1 negotiates a security association between two IKE peers, which enables the peers to communicate securely in Phase 2. During Phase 2 negotiation, IKE establishes security associations (SAs) for other applications, such as IPsec. Both phases use proposals when they negotiate a connection.

For more information about IKE proposals, see Understanding IKE, page 10-47. To create an IKE proposal object, see Creating IKE Proposal Objects.

Related Topics

•Policy Object Manager Window, page F-1

•Creating Objects

Creating IKE Proposal Objects

You can create IKE proposal objects to use when you define IKE proposals for remote access VPN policies. When you create an IKE proposal object, you must enter the priority of the proposal and define the encryption and authentication methods to use. Additionally, you can modify the default lifetime of the SA, if required.

This procedure describes how to create IKE proposal objects.

Tip You can also create IKE proposal objects when defining policies that use this object type. For more information, see Selecting Objects for Policies.

Before You Begin

•Read and understand Guidelines for Managing Objects.

Related Topics

•Understanding IKE Proposal Objects

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select IKE Proposals from the Object Type selector.

Step 3 Right-click in the work area, then select New Object.

The IKE Proposal dialog box appears. For a description of the fields in this dialog box, see Table F-36 on page F-53.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 (Optional) Enter a priority value for the IKE proposal. Lower values indicate higher priorities. If the remote IPsec peer does not support the parameters selected in your first priority policy, the device tries to use the parameters defined in the policy with the next lowest priority number.

Note If you leave this field blank, Security Manager assigns the lowest unassigned value starting with 1, then 5, then continuing in increments of 5.

Step 6 Select the encryption algorithm to use to establish the Phase 1 SA for protecting Phase 2 negotiations. See Deciding Which Encryption Algorithm to Use, page 10-47.

Step 7 Select the hash algorithm to use for authentication and ensuring data integrity. See Deciding Which Hash Algorithm to Use, page 10-48.

Step 8 In the Modulus Group field, select the Diffie-Hellman group to use for deriving a shared secret between two IPsec peers without transmitting it to each other. See Deciding Which Diffie-Hellman Group to Use, page 10-48.

Step 9 Enter the SA lifetime, in seconds. As a general rule, the shorter the lifetime (up to a point), the more secure your IKE negotiations will be. However, with longer lifetimes, future IPsec security associations can be set up more quickly than with shorter lifetimes.

Step 10 Select the method of authentication to use to establish the identity of each IPsec peer. See Deciding Which Authentication Method to Use, page 10-49.

Step 11 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 12 Click OK to save the object.

Understanding Inspection Map Objects

Inspection map objects comprise class maps and policy maps. The Inspection Maps policy object is subdivided into several entries. The Class Maps folder contains all Layer 7 class-maps that are supported in ASA and PIX devices running software versions 7.2 and higher. The Policy Maps folder contains all Layer 7 policies that are supported. Also included in the Inspect Maps folder are entries for TCP Map objects, Regular Expression objects, and Regular Expression Group objects.

Class Maps

An inspection class map matches application traffic with criteria specific to the application, such as a URL string. You then identify the class map in the inspect map and enable actions. The difference between creating a class map and defining the traffic match directly in the inspect map policy object is that you can reuse class maps in more than one inspect map policy. You can create class maps for the inspection of DNS, FTP, HTTP, IM, and SIP traffic.

To create class maps, see Creating Class Map Objects.

To create the regular expressions and regular expression groups that you can use in class and policy inspection maps, see these topics:

•Creating Regular Expression Group Objects

•Creating Regular Expression Objects

Policy Maps

The algorithm the security appliance uses for stateful application inspection ensures the security of applications and services. Some applications require special handling, and specific application inspection engines are provided for this purpose. Applications that require special application inspection engines are those that embed IP addressing information in the user data packet or open secondary channels on dynamically assigned ports.

Application inspection engines work with NAT to help identify the location of embedded addressing information. This allows NAT to translate these embedded addresses and to update any checksum or other fields that are affected by the translation.

Each application inspection engine also monitors sessions to determine the port numbers for secondary channels. Many protocols open secondary TCP or UDP ports to improve performance. The initial session on a well-known port is used to negotiate dynamically assigned port numbers. The application inspection engine monitors these sessions, identifies the dynamic port assignments, and permits data exchange on these ports for the duration of the specific session.

In addition, stateful application inspection audits the validity of the commands and responses within the protocol being inspected. The security appliance helps to prevent attacks by verifying that traffic conforms to the RFC specifications for each protocol that is inspected.

You can create inspect maps for specific protocol inspection engines. You use an inspect map to store the configuration for a protocol inspection engine. You then enable the configuration settings in the inspect map by associating the map with a specific type of traffic using a global security policy or a security policy for a specific interface.

You can use Security Manager to create policy inspection map objects for the following applications: DCE/RPC, DNS, ESMTP, FTP, GTP, H.323, HTTP, IM, IPsec, NetBIOS, SIP, Skinny, and SNMP.

To create policy inspection maps, refer to the following:

•Creating DCE/RPC Map Objects

•Creating DNS Map Objects

•Creating ESMTP Map Objects

•Creating FTP Map Objects

•Creating GTP Map Objects

•Creating H.323 Map Objects

•Creating HTTP Map Objects (ASA 7.1.x/PIX 7.1.x/FWSM 3.x/IOS)

•Creating HTTP Map Objects (ASA 7.2+/PIX 7.2+)

•Creating IM Map Objects for Devices running ASA/PIX 7.2 and Higher

•Creating IM Map Objects for IOS Devices

•Creating IPSec Pass Through Map Objects

•Creating NetBIOS Map Objects

•Creating SIP Map Objects

•Creating Skinny Map Objects

•Creating SNMP Map Objects

You can also create TCP Maps, which are not a Layer 7 policy inspection map, as described in Creating TCP Map Objects.

Creating Class Map Objects

You can create class maps as independent policy objects and then assign them to specific policy inspection map objects. Although you can create class maps directly in a policy map object, by creating them separately, you can reuse the class maps in multiple policy objects.

The procedure for creating a class map is essentially the same for each type of class map. The only difference is that the available criteria differ based on the type of traffic for which you are creating the object.

Related Topics

•Guidelines for Managing Objects

•Understanding Inspection Map Objects

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select the type of class map object you want to create from the Inspect Maps > Class Maps folder.

Step 3 Right-click inside the work area, then select New Object.

The Add Class Map dialog box appears (see Add or Edit Class Maps Dialog Boxes, page F-54).

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Right-click inside the match criteria table, then select Add Row.

The Add Match Criterion dialog box appears.

Step 6 Select the criterion from the list. The available criteria differ depending on the type of class map you are creating. For more information regarding criterion, see the topic related to the type of class map:

•DNS Class and Policy Maps Add or Edit Match Condition (and Action) Dialog Boxes, page F-59

•FTP Class and Policy Maps Add or Edit Match Condition (and Action) Dialog Boxes, page F-66

•H.323 Class and Policy Maps Add or Edit Match Condition (and Action) Dialog Boxes, page F-75

•HTTP Class and Policy Map (ASA 7.2+/PIX 7.2+) Add or Edit Match Condition (and Action) Dialog Boxes, page F-87

•IM Class and Policy Map (ASA 7.2+/PIX 7.2+) Add or Edit Match Condition (and Action) Dialog Boxes, page F-92

•SIP Class and Policy Maps Add or Edit Match Condition (and Action) Dialog Boxes, page F-99

Step 7 Select the match type from the list.

Step 8 Complete the dialog box with appropriate values. The dialog box values vary based on your selection in the Criterion list.

Step 9 Click OK.

The Add Match Criterion dialog box closes and you return to the Add Class Map dialog box.

Step 10 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 11 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 12 Click OK to save the object.

Creating DCE/RPC Map Objects

A DCE/RPC inspection policy map lets you change the default configuration values used for DCE/RPC inspection.

DCE/RPC is a protocol widely used by Microsoft distributed client and server applications that allows software clients to execute programs on a server remotely.

This typically involves a client querying a server called the Endpoint Mapper listening on a well-known port number for the dynamically allocated network information of a required service. The client then sets up a secondary connection to the server instance providing the service. The security appliance allows the appropriate port number and network address and also applies NAT, if needed, for the secondary connection.

DCE/RPC inspection maps inspect for native TCP communication between the EPM and client on well-known TCP port 135. Map and lookup operations of the EPM are supported for clients. Client and server can be located in any security zone. The embedded server IP address and port number are received from the applicable EPM response messages. Because a client may attempt multiple connections to the server port returned by EPM, multiple use of pinholes are allowed, which have user configurable timeouts.

Related Topics

•Understanding Inspection Map Objects

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > Policy Maps > DCE/RPC Maps.

The DCE/RPC Maps page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add DCE/RPC Map dialog box appears.

Step 4 Enter the name of the object and optionally a description.

Step 5 Change the default parameter values if they do not suit your requirements. For information on the options, see Add or Edit DCE/RPC Dialog Box, page F-56.

Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 7 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 8 Click OK to save the object.

Creating DNS Map Objects

A DNS map lets you change the default configuration values used for DNS application inspection.

DNS application inspection supports DNS message controls that provide protection against DNS spoofing and cache poisoning. User configurable rules allow certain DNS types to be allowed, dropped, or logged, while others are blocked. Zone transfer can be restricted between servers with this function, for example.

The Recursion Desired and Recursion Available flags in the DNS header can be masked to protect a public server from attack if that server only supports a particular internal zone. In addition, DNS randomization can be enabled avoid spoofing and cache poisoning of servers that either do not support randomization or utilize a weak pseudo random number generator. Limiting the domain names that can be queried protects the public server further.

A configurable DNS mismatch alert can be used as notification if an excessive number of mismatching DNS responses are received, which could indicate a cache poisoning attack. In addition, a configurable check to enforce a Transaction Signature be attached to all DNS messages is also supported.

Related Topics

•Understanding Inspection Map Objects

•Creating Class Map Objects

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > Policy Maps > DNS Maps.

The DNS Maps page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add DNS Map dialog box appears (see Add and Edit DNS Map Dialog Boxes, page F-56).

Step 4 Enter the name of the object and optionally a description.

Step 5 Click the Protocol Conformance tab and select the options you want to enforce. For information on the available options, see DNS Map Protocol Conformance Tab, page F-58.

Step 6 Click the Filtering tab and select the options you want to enforce. For information on the available options, see DNS Map Filtering Tab, page F-58.

Step 7 Click the Mismatch Rate tab and select whether you want to log DNS mismatches based on threshold or time interval limits. For more information, see Add and Edit DNS Map Dialog Boxes, page F-56.

Step 8 Click the Match Condition and Action tab to configure the values for match criterion.

a. Right-click inside the table, then select Add Row.

The Add Match Condition and Action dialog box appears.

b. Select the match type from the list.

•If you select Use Specified Values as your match type, you can select a criterion from the list and configure the related fields. The dialog box values vary based on your criterion selection. For a description of the available criteria, see DNS Class and Policy Maps Add or Edit Match Condition (and Action) Dialog Boxes, page F-59.

•If you select Use Values in Class Map as your match type, enter the name of the class map or click Select, which opens the class map selector from which to make your selection.

c. Select the action to be performed when the criteria are met.

d. Click OK to save your changes and close the dialog box.

Step 9 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 10 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 11 Click OK to save the object.

Creating ESMTP Map Objects

An ESMTP policy map lets you change the default configuration values used for ESMTP inspection.

ESMTP inspection detects attacks, including spam, phising, malformed message attacks, and buffer overflow/underflow attacks. It also provides support for application security and protocol conformance, which enforce the sanity of the ESMTP messages as well as detect several attacks, block senders/receivers, and block mail relay.

Related Topics

•Understanding Inspection Map Objects

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > Policy Maps > ESMTP Maps.

The ESMTP Maps page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add ESMTP Map dialog box appears.

Step 4 Enter the name of the object and optionally a description.

Step 5 Select the settings you want to use on the Parameters tab. For an explanation of the options, see Add or Edit ESMTP Map Dialog Boxes, page F-62.

Step 6 Click the Match Condition and Action tab to configure the values for match criterion.

a. Right-click inside the table, then select Add Row.

The Add Match Condition and Action dialog box appears.

b. Select the criterion to use as your match type and configure the related fields. For a description of the available criteria, see ESMTP Policy Maps Add or Edit Match Condition and Action Dialog Boxes, page F-63.

c. Click OK to save your changes.

The Add Match Condition and Action dialog box closes and you return to the Add Skinny Map dialog box.

Step 7 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 8 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 9 Click OK to save the object.

Creating FTP Map Objects

An FTP policy map object lets you change the default configuration values used for FTP application inspection. When creating an FTP policy inspection map, you can use FTP class map objects as part of the map object.

FTP is a common protocol used for transferring files over a TCP/IP network such as the Internet. You can use an FTP map to block specific FTP protocol methods, such as an FTP PUT, from passing through the security appliance and reaching your FTP server.

Related Topics

•Understanding Inspection Map Objects

•Creating Class Map Objects

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select Inspect Maps > Policy Maps > FTP Maps from the Object Type selector. The FTP Maps page opens, displaying a list of the existing FTP Map objects.

Step 3 Right-click inside the work area, then select New Object.

The Add FTP Map dialog box appears (see Add and Edit FTP Map Dialog Boxes, page F-65).

Step 4 Enter the name of the object and optionally a description.

Step 5 On the Parameters tab, determine whether you want to mask server information from the user.

Step 6 Click the Match Condition and Action tab to configure the values for match criterion.

a. Right-click inside the table, then select Add Row.

The Add Match Condition and Action dialog box appears (see FTP Class and Policy Maps Add or Edit Match Condition (and Action) Dialog Boxes, page F-66).

b. Select the match type from the list.

•If you select Use Specified Values as your match type, you can select a criterion from the list and configure the related fields. The dialog box values vary based on your criterion selection. For a description of the available criteria, see FTP Class and Policy Maps Add or Edit Match Condition (and Action) Dialog Boxes, page F-66.

•If you select Use Values in Class Map as your match type, enter the name of the class map or click Select, which opens the class map selector from which to make your selection.

c. Select the action to be performed when the criteria are met.

d. Click OK to save your changes and close the dialog box.

Step 7 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 8 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 9 Although optional, you can select the platform for which you will use this object in the Validate For field and click Validate to verify that the object can be used on that platform. This can help you avoid deployment problems later.

Step 10 Click OK to save the object.

Creating GTP Map Objects

The GPRS Tunnel Protocol (GTP) provides uninterrupted connectivity for mobile subscribers between GSM networks and corporate networks or the Internet. GTP uses a tunneling mechanism to provide a service for carrying user data packets.

A GTP map object lets you change the default configuration values used for GTP application inspection. The GTP Map object page lets you create, view, and manage GTP inspect maps. The GTP protocol is designed to provide security for wireless connections to TCP/IP networks such as the Internet. You can use a GTP map to control timeout values, message sizes, tunnel counts, and GTP versions traversing the security appliance.

Tip GTP inspection requires a special license. If you do not have the required license, you will see device errors if you try to deploy a GTP map.

Related Topics

•Guidelines for Managing Objects

•Understanding Inspection Map Objects

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > Policy Maps > GTP Maps.

The GTP Maps page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add GTP Map dialog box appears (see Add and Edit GTP Map Dialog Boxes, page F-68).

Step 4 Enter the name of the object and optionally a description.

Step 5 On the Parameters tab, configure the desired settings. All settings on this tab are optional; change them only if the defaults do not suit your requirements. You can configure the following options:

•In the Country and Network Codes table, click Add Row to add codes to the table.

•In the Permit Response table, click Add Row to add Network/Host object pairs for which you will permit GTP responses from a GSN that is different from the one to which the response was sent.

•In Request Queue, you can specify the maximum requests allowed in the queue.

•In Tunnel Limit, you can specify the maximum number of tunnels allowed.

•You can select Permit Errors to allow packets with errors or different GTP versions that are invalid or that encountered an error during inspection to be sent through the security appliance instead of being dropped.

•By clicking Edit Timeouts, you can configure the time out values for various operations (see GTP Map Timeouts Dialog Box, page F-71).

Step 6 Click the Match Condition and Action tab to configure the values for match criterion.

a. Right-click inside the table, then select Add Row.

The Add Match Condition and Action dialog box appears.

b. Select the criterion to use as your match type and configure the related fields. For a description of the available criteria, see GTP Policy Maps Add or Edit Match Condition and Action Dialog Boxes, page F-71.

c. Click OK to save your changes.

The Add Match Condition and Action dialog box closes and you return to the Add GTP Map dialog box.

Step 7 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 8 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 9 Although optional, you can select the platform for which you will use this object in the Validate For field and click Validate to verify that the object can be used on that platform. This can help you avoid deployment problems later.

Step 10 Click OK to save the object.

Creating H.323 Map Objects

An H.323 policy map lets you change the default configuration values used for H.323 inspection.

H.323 inspection supports H.323 compliant applications such as Cisco CallManager and VocalTec Gatekeeper. H.323 is a suite of protocols defined by the International Telecommunication Union for multimedia conferences over LANs. The security appliance supports H.323 through Version 4, including H.323 v3 feature Multiple Calls on One Call Signaling Channel.

With H.323 inspection enabled, the security appliance supports multiple calls on the same call signaling channel, a feature introduced with H.323 Version 3. This feature reduces call setup time and reduces the use of ports on the security appliance. The two major functions of H.323 inspection are as follows:

•NAT the necessary embedded IPv4 addresses in the H.225 and H.245 messages. Because H.323 messages are encoded in PER encoding format, the security appliance uses an ASN.1 decoder to decode the H.323 messages.

•Dynamically allocate the negotiated H.245 and RTP/RTCP connections.

Related Topics

•Understanding Inspection Map Objects

•Creating Class Map Objects

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > Policy Maps > H.323 Maps.

The H.323 Maps page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add H.323 Map dialog box appears.

Step 4 Enter the name of the object and optionally a description.

Step 5 Select the settings you want to use on the Parameters tab. You can add HSI groups and end points and select other options if the default values do not meet your requirements. For an explanation of the options, see Add and Edit H.323 Map Dialog Boxes, page F-73.

Step 6 Click the Match Condition and Action tab to configure the values for match criterion.

a. Right-click inside the table, then select Add Row.

The Add Match Condition and Action dialog box appears.

b. Select the match type from the list.

•If you select Use Specified Values as your match type, you can select a criterion from the list and configure the related fields. The dialog box values vary based on your criterion selection. For a description of the available criteria, see H.323 Class and Policy Maps Add or Edit Match Condition (and Action) Dialog Boxes, page F-75.

•If you select Use Values in Class Map as your match type, enter the name of the class map or click Select, which opens the class map selector from which to make your selection.

c. Select the action to be performed when the criteria are met.

d. Click OK to save your changes and close the dialog box.

Step 7 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 8 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 9 Click OK to save the object.

Configuring HTTP Policy Map Objects

An HTTP map object lets you change the default configuration values used for HTTP application inspection. An HTTP Map object defines different HTTP packet criteria to be inspected, as well as the action to be taken when the criteria are met. The HTTP Map object only defines general HTTP protocol-related parameters; it is not specific to any particular traffic flow. This ensures that the same HTTP Map object can be reused for different devices or different traffic flow within a single device.

The enhanced HTTP inspection feature, also known as an application firewall, verifies that HTTP messages conform to RFC 2616, use RFC-defined and supported extension methods, and comply with various other criteria. This can help prevent attackers from using HTTP messages for circumventing network security policy.

Note When you enable HTTP inspection with an HTTP map, strict HTTP inspection with the action reset and log is enabled by default. You can change the actions performed in response to inspection failure, but you cannot disable strict inspection as long as the HTTP map remains enabled.

In many cases, you can configure the criteria and how the security appliance responds when the criteria are not met.

The following topics describe how to create HTTP inspection maps based on the target device operating system:

•Creating HTTP Map Objects (ASA 7.1.x/PIX 7.1.x/FWSM 3.x/IOS)

•Creating HTTP Map Objects (ASA 7.2+/PIX 7.2+)

Creating HTTP Map Objects (ASA 7.1.x/PIX 7.1.x/FWSM 3.x/IOS)

An HTTP map lets you change the default configuration values used for HTTP application inspection. This procedure explains how to create a map that you can deploy to devices that run ASA 7.1.x, PIX 7.1.x, FWSM 3.x, or IOS operating systems.

For more information about HTTP maps, see Configuring HTTP Policy Map Objects.

Related Topics

•Guidelines for Managing Objects

•Understanding Inspection Map Objects

•Configuring HTTP Policy Map Objects

•Creating HTTP Map Objects (ASA 7.2+/PIX 7.2+)

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > Policy Maps > HTTP Maps (ASA 7.1.x/PIX 7.1.x/FWSM 3.x/IOS).

The HTTP Maps page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add HTTP Map dialog box appears (see Add and Edit HTTP Map Dialog Boxes for ASA 7.1.x/PIX 7.1.x/FWSM 3.x/IOS Devices, page F-77).

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Click the General tab and define the actions you want to take when non-compliant HTTP requests are received and to verify content type. For a description of the options, see HTTP Map General Tab, page F-78.

Step 6 Click the Entity Length tab and define the actions you want to take if the length of the HTTP content falls outside of configured targets. For a description of the options, see HTTP Map Entity Length Tab, page F-79.

Step 7 The remaining four tabs function in the same way. You can select from a list of available methods, application categories, or encoding types, and configure an action and syslog setting for the ones you want to handle in specific ways. You can also select the option to specify an action to take for the ones you do not uniquely configure. The tabs, and what you can configure on them, are:

•RFC Request Method tab—Defines the action that the security appliance should take when specific RFC request methods are used in the HTTP request. For a description of the options, see HTTP Map RFC Request Method Tab, page F-81.

•Extension Request Method tab—Defines the action taken when specific extension request methods are used in the HTTP request. For a description of the options, see HTTP Map Extension Request Method Tab, page F-82.

•Port Misuse tab—Defines the action taken when specific undesirable applications are encountered. For a description of the options, see HTTP Map Port Misuse Tab, page F-83.

•Transfer Encoding tab—Defines the action taken when specific transfer encoding types are used in the HTTP request. For a description of the options, see HTTP Map Transfer Encoding Tab, page F-84.

Step 8 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 9 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 10 Click OK to save the object.

Creating HTTP Map Objects (ASA 7.2+/PIX 7.2+)

An HTTP map lets you change the default configuration values used for HTTP application inspection. This procedure explains how to create a map that you can deploy to devices that run ASA 7.2 or higher or PIX 7.2 or higher operating systems.

For more information about HTTP maps, see Configuring HTTP Policy Map Objects.

Related Topics

•Guidelines for Managing Objects

•Understanding Inspection Map Objects

•Configuring HTTP Policy Map Objects

•Creating HTTP Map Objects (ASA 7.1.x/PIX 7.1.x/FWSM 3.x/IOS)

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select Inspect Maps > Policy Maps > HTTP Maps (ASA 7.2+/PIX 7.2+) from the Object Type selector. The HTTP Maps page for ASA/PIX 7.2 and higher opens, displaying a list of the existing HTTP Map objects.

Step 3 Right-click inside the work area, then select New Object.

The Add HTTP Map dialog box appears (Add or Edit HTTP Map Dialog Boxes for ASA 7.2+/PIX 7.2+ Devices, page F-85).

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Complete the information in the Parameters tab. For a description of the options, see Add or Edit HTTP Map Dialog Boxes for ASA 7.2+/PIX 7.2+ Devices, page F-85.

Step 6 Click the Match Condition and Action tab to configure the values for match criterion.

a. Right-click inside the table, then select Add Row.

The Add Match Condition and Action dialog box appears. For a description of the GUI elements, see HTTP Class and Policy Map (ASA 7.2+/PIX 7.2+) Add or Edit Match Condition (and Action) Dialog Boxes, page F-87.

b. Select the match type from the list.

•If you select Use Specified Values as your match type, you can select a criterion from the list and configure the related fields. The dialog box values vary based on your criterion selection. For a description of the available criteria, see HTTP Class and Policy Map (ASA 7.2+/PIX 7.2+) Add or Edit Match Condition (and Action) Dialog Boxes, page F-87.

•If you select Use Values in Class Map as your match type, enter the name of the class map or click Select, which opens the class map selector from which to make your selection.

c. Select the action to be performed when the criteria are met.

d. Click OK to save your changes.

Step 7 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 8 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 9 Click OK to save the object.

Creating IM Map Objects for Devices running ASA/PIX 7.2 and Higher

An IM map lets you change the default configuration values used for IM application inspection.

Instant Messaging causes concern due to its use of clear text when conducting business and the potential for network attacks and the spreading of viruses. Thus, you might want to block certain types of instant messages from occurring, while allowing others.

For ASA and PIX devices, IM application inspection provides detailed access control to control network usage. It also helps stop leakage of confidential data and the propagation of network threats. A regular expression database search representing various patterns for IM protocols to be filtered is applied. A syslog is generated if the flow is not recognized. You can inspect Yahoo! Messenger or MSN Messenger traffic.

Related Topics

•Guidelines for Managing Objects

•Understanding Inspection Map Objects

•Creating Class Map Objects

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > Policy Maps > IM Maps (ASA 7.2+/PIX 7.2+).

The IM Maps (ASA 7.2+/PIX 7.2+) page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add IM Map dialog box appears (see Add and Edit IM Map Dialog Boxes (for ASA 7.2+/PIX 7.2+), page F-91).

Step 4 Enter the name of the object and optionally a description.

Step 5 Configure the values for match criterion.

a. Right-click inside the table, then select Add Row.

The Add Match Condition and Action dialog box appears.

b. Select the match type from the list.

•If you select Use Specified Values as your match type, you can select a criterion from the list and configure the related fields. The dialog box values vary based on your criterion selection. For a description of the available criteria, see IM Class and Policy Map (ASA 7.2+/PIX 7.2+) Add or Edit Match Condition (and Action) Dialog Boxes, page F-92.

•If you select Use Values in Class Map as your match type, enter the name of the class map or click Select, which opens the class map selector from which to make your selection.

c. Select the action to be performed when the criteria are met.

d. Click OK to save your changes and close the dialog box.

Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 7 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 8 Click OK to save the object.

Creating IM Map Objects for IOS Devices

You can create Instant Messenger inspection map objects for use on IOS devices. An IM map lets you change the default configuration values used for IM application inspection.

Instant Messaging causes concern due to its use of clear text when conducting business and the potential for network attacks and the spreading of viruses. Thus, you might want to block certain types of instant messages from occurring, while allowing others.

IM application inspection provides detailed access control to control network usage. It also helps stop leakage of confidential data and the propagation of network threats. The scope can be limited by using an access list to specify any traffic streams to be inspected. For UDP messages, a corresponding UDP port number is also configurable. Inspection of Yahoo! Messenger, MSN Messenger, and AOL instant messages are supported.

Related Topics

•Guidelines for Managing Objects

•Understanding Inspection Map Objects

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select Inspect Maps > Policy Maps > IM Maps (IOS) from the Object Type selector. The IM Maps (IOS) page opens, displaying a list of the existing IM Map for IOS objects.

Step 3 Right-click inside the work area, then select New Object.

The Add IM Map (IOS) dialog box appears (see Add or Edit IM Map (IOS) Dialog Boxes, page F-94).

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Select the appropriate options for each service provider that you want to configure. The fields for each provider are identical, but you must configure each service separately. Typically, you want to determine whether you want to allow, deny, or log the various services provided by these IM applications. You can also permit or deny specific servers, which can help you block known sources of unwanted traffic.

Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 7 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 8 Click OK to save the object.

Creating IPSec Pass Through Map Objects

An IPsec Pass Through policy map lets you change the default configuration values used for IPsec Pass Through inspection.

The IPSec Pass Through inspection engine lets the security appliance pass ESP (IP protocol 50) and AH (IP protocol 51) traffic that is formed between two hosts because of successful IKE (UDP port 500) negotiation without the requirement of specific ESP or AH access lists.

The inspection engine works on IKE UDP port 500 to create the control flow. The inspect ipsec-pass-thru command is attached to a UDP flow as defined in the MPF framework. When an ESP or AH packet between the two peers arrives at the device, or a UDP packet with either source or destination port equal to 500, the packet is sent to the inspect module.

The ESP or AH traffic is permitted by the inspection engine with the configured idle timeout if there is an existing control flow and it is within the connection limit defined in the MPF framework. A new control flow is created for IKE UDP port 500 traffic with the configured UDP idle timeout if there is not one, or it uses the existing flow.

To ensure that the packet arrives into the inspection engine, a hole is punched for all such traffic (ESP and AH). This inspect is attached to the control flow. The control flow is present as long as there is at least one data flow (ESP or AH) established, but the traffic always flows on the same connection. Because this IKE connection is kept open as long as data flows, a rekey would always succeed. The flows are created irrespective of whether NAT is being used. However, PAT is not supported.

Related Topics

•Understanding Inspection Map Objects

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > Policy Maps > IPSec Pass Through Maps.

The IPSec Pass Through Maps page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add IPSec Pass Through Map dialog box appears (see Add or Edit IPsec Pass Through Map Dialog Boxes, page F-95).

Step 4 Enter the name of the object and optionally a description.

Step 5 Select whether to allow ESP or AH traffic, or both, and configure the allowable tunnel and timeout values.

Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 7 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 8 Click OK to save the object.

Creating NetBIOS Map Objects

A NetBIOS policy map lets you change the default configuration values used for NetBIOS inspection.

The NetBIOS inspection engine translates IP addresses in the NetBIOS name service (NBNS) packets according to the security appliance NAT configuration.

Related Topics

•Understanding Inspection Map Objects

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > Policy Maps > NetBIOS Maps.

The NetBIOS Maps page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add NetBIOS Map dialog box appears (see Add or Edit NetBIOS Map Dialog Boxes, page F-96).

Step 4 Enter the name of the object and optionally a description.

Step 5 Select Check for Protocol Violations if you want to specify an action to take if violations occur, and select the desired action.

Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 7 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 8 Click OK to save the object.

Creating SIP Map Objects

A SIP policy inspection map lets you change the default configuration values used for SIP application inspection.

SIP is a widely used protocol for Internet conferencing, telephony, presence, events notification, and instant messaging. Partially because of its text-based nature and partially because of its flexibility, SIP networks are subject to a large number of security threats.

SIP application inspection provides address translation in message header and body, dynamic opening of ports and basic sanity checks. It also supports application security and protocol conformance, which enforce the sanity of the SIP messages, as well as detect SIP-based attacks.

Related Topics

•Guidelines for Managing Objects

•Understanding Inspection Map Objects

•Creating Class Map Objects

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > Policy Maps > SIP Maps.

The SIP Maps page appears.

Step 3 Right-click inside the work area, then click New Object.

The Add SIP Map dialog box appears.

Step 4 Enter the name of the object and optionally a description.

Step 5 Select the settings you want to use on the Parameters tab. For an explanation of the options, see Add or Edit SIP Map Dialog Boxes, page F-97.

Step 6 Click the Match Condition and Action tab to configure the values for match criterion.

a. Right-click inside the table, then select Add Row.

The Add Match Condition and Action dialog box appears.

b. Select the match type from the list.

•If you select Use Specified Values as your match type, you can select a criterion from the list and configure the related fields. The dialog box values vary based on your criterion selection. For a description of the available criteria, see SIP Class and Policy Maps Add or Edit Match Condition (and Action) Dialog Boxes, page F-99.

•If you select Use Values in Class Map as your match type, enter the name of the class map or click Select, which opens the class map selector from which to make your selection.

c. Select the action to be performed when the criteria are met.

d. Click OK to save your changes and close the dialog box.

Step 7 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 8 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 9 Click OK to save the object.

Creating Skinny Map Objects

A Skinny policy map lets you change the default configuration values used for Skinny inspection.

Skinny (SCCP) is a simplified protocol used in VoIP networks. Cisco IP Phones using SCCP can coexist in an H.323 environment. When used with Cisco CallManager, the SCCP client can interoperate with H.323 compliant terminals. Application layer functions in the security appliance recognize SCCP version 3.3. There are 5 versions of the SCCP protocol: 2.4, 3.0.4, 3.1.1, 3.2, and 3.3.2.

The security appliance supports all versions through 3.3.2. The security appliance supports PAT and NAT for SCCP. PAT is necessary if you have more IP phones than global IP addresses for the IP phones to use. By supporting NAT and PAT of SCCP Signaling packets, Skinny application inspection ensures that all SCCP signaling and media packets can traverse the security appliance.

Normal traffic between Cisco CallManager and Cisco IP Phones uses SCCP and is handled by SCCP inspection without any special configuration. The security appliance also supports DHCP options 150 and 66, which it accomplishes by sending the location of a TFTP server to Cisco IP Phones and other DHCP clients. Cisco IP Phones might also include DHCP option 3 in their requests, which sets the default route.

Related Topics

•Understanding Inspection Map Objects

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > Policy Maps > Skinny Maps.

The Skinny Maps page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add Skinny Map dialog box appears.

Step 4 Enter the name of the object and optionally a description.

Step 5 Select the settings you want to use on the Parameters tab. For an explanation of the options, see Add or Edit Skinny Map Dialog Boxes, page F-101.

Step 6 Click the Match Condition and Action tab to configure the values for match criterion.

a. Right-click inside the table, then select Add Row.

The Add Match Condition and Action dialog box appears.

b. Select the criterion to use as your match type and configure the related fields. For a description of the available criteria, see Skinny Policy Maps Add or Edit Match Condition and Action Dialog Boxes, page F-103.

c. Click OK to save your changes and close the dialog box.

Step 7 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 8 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 9 Click OK to save the object.

Creating SNMP Map Objects

An SNMP policy map lets you change the default configuration values used for SNMP application inspection.

SNMP application inspection lets you restrict SNMP traffic to a specific version of SNMP. Earlier versions of SNMP are less secure; therefore, denying certain SNMP versions may be required by your security policy. The security appliance can deny SNMP versions 1, 2, 2c, or 3. You control the versions permitted by creating an SNMP map. You then apply the SNMP map when you enable SNMP inspection.

Related Topics

•Understanding Inspection Map Objects

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > Policy Maps > SNMP Maps.

The SNMP Maps page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add SNMP Map dialog box appears (see Add and Edit SNMP Map Dialog Boxes, page F-103).

Step 4 Enter the name of the object and optionally a description.

Step 5 Select the SNMP versions you want to prohibit.

Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 7 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 8 Click OK to save the object.

Creating Regular Expression Group Objects

A Regular Expression Group object groups regular expressions together. The objects can be used by inspection class maps and inspection policy maps.

Related Topics

•Guidelines for Managing Objects

•Creating Regular Expression Objects

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > Regular Expression Groups.

The Regular Expression Groups page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add Regular Expression Group dialog box appears (see Add and Edit Regular Expression Group Dialog Boxes, page F-104).

Step 4 Enter the name of the object and optionally a description.

Step 5 Enter the names of the Regular Expression objects to include in the group in the Regular Expressions field. Click Select to select the objects from a list or to create new objects.

Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 7 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 8 Click OK to save the object.

Creating Regular Expression Objects

A regular expression matches text strings either literally as an exact string or by using metacharacters so you can match multiple variants of a text string. You can use regular expressions in various type of class and policy inspection maps to match various target items, for example, the content of certain application traffic such as the body text inside an HTTP packet.

Related Topics

•Guidelines for Managing Objects

•Metacharacters Used to Build Regular Expressions

•Creating Regular Expression Group Objects

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > Regular Expressions.

The Regular Expressions page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add Regular Expression dialog box appears (see Add and Edit Regular Expression Dialog Boxes, page F-105).

Step 4 Enter the name of the object and optionally a description.

Step 5 Enter the regular expressions in the Value field. For information on the metacharacters you can use to build regular expressions, see Metacharacters Used to Build Regular Expressions.

Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 7 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 8 Click OK to save the object.

Metacharacters Used to Build Regular Expressions

Table 9-7 explains the metacharacters you can use to build regular expressions. Keep the following tips in mind when creating regular expressions:

•If you enter any metacharacters in your text string that you want to be used literally, add the backslash (\) escape character before them. For example, "example\.com".

•If you want to match upper and lower case characters, enter text in both upper- and lowercase. For example, "cats" is entered as "[cC][aA][tT][sS]".

Table 9-7 Metacharacters Used to Build Regular Expressions

Character

Description

Notes

.

Dot

Matches any single character. For example, d.g matches dog, dag, dtg, and any word that contains those characters, such as doggonnit.

(exp)

Subexpression

A subexpression segregates characters from surrounding characters, so that you can use other metacharacters on the subexpression. For example, d(o|a)g matches dog and dag, but do|ag matches do and ag. A subexpression can also be used with repeat quantifiers to differentiate the characters meant for repetition. For example, ab(xy){3}z matches abxyxyxyz.

|

Alternation

Matches either expression it separates. For example, dog|cat matches dog or cat.

?

Question mark

A quantifier that indicates that there are 0 or 1 of the previous expression. For example, lo?se matches lse or lose.

*

Asterisk

A quantifier that indicates that there are 0, 1 or any number of the previous expression. For example, lo*se matches lse, lose, loose, etc.

+

Plus

A quantifier that indicates that there is at least 1 of the previous expression. For example, lo+se matches lose and loose, but not lse.

{x}

Repeat Quantifier

Repeat exactly x times. For example, ab(xy){3}z matches abxyxyxyz.

Minimum repeat quantifier

Repeat at least x times. For example, ab(xy){2,}z matches abxyxyz, abxyxyxyz, etc.

[abc]

Character class

Matches any character in the brackets. For example, [abc] matches a, b, or c.

[^abc]

Negated character class

Matches a single character that is not contained within the brackets. For example, [^abc] matches any character other than a, b, or c. [^A-Z] matches any single character that is not an uppercase letter.

[a-c]

Character range class

Matches any character in the range. [a-z] matches any lowercase letter. You can mix characters and ranges: [abcq-z] matches a, b, c, q, r, s, t, u, v, w, x, y, z, and so does [a-cq-z].

The dash (-) character is literal only if it is the last or the first character within the brackets: [abc-] or [-abc].

""

Quotation marks

Preserves trailing or leading spaces in the string. For example, " test" preserves the leading space when it looks for a match.

^

Caret

Specifies the beginning of a line.

\

Escape character

When used with a metacharacter, matches a literal character. For example, \[ matches the left square bracket.

char

Character

When character is not a metacharacter, matches the literal character.

\r

Carriage return

Matches a carriage return 0x0d.

\n

Newline

Matches a new line 0x0a.

\t

Tab

Matches a tab 0x09.

\f

Formfeed

Matches a form feed 0x0c.

\xNN

Escaped hexadecimal number

Matches an ASCII character using hexadecimal (exactly two digits).

\NNN

Escaped octal number

Matches an ASCII character as octal (exactly three digits). For example, the character 040 represents a space.

Related Topics

•Creating Regular Expression Objects

•Creating Regular Expression Group Objects

Creating TCP Map Objects

The TCP Maps object lets you customize inspection on TCP flow for both through and to box traffic.

Related Topics

•Guidelines for Managing Objects

•Understanding Inspection Map Objects

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the Object Type selector, select Inspect Maps > TCP Maps.

The TCP Maps page appears.

Step 3 Right-click inside the work area, then select New Object.

The Add TCP Map dialog box appears.

Step 4 Enter the name of the object and optionally a description.

Step 5 Select from the settings you want to configure for the map, including TCP option ranges and how to handle reserved bits. For a complete explanation of the options, see Add and Edit TCP Map Dialog Boxes, page F-106.

Step 6 (Optional) Select a color from the Category list to help you readily identify the object when it appears in the object or rules tables. For more information, see Using Category Objects.

Step 7 Click OK to save the object.

Understanding Interface Role Objects

Interface role objects enable you to apply policies to specific interfaces on multiple devices without having to manually define the name of each interface. Because most devices follow a standard naming convention for their interfaces, you can define a naming pattern that describes a particular interface type and then assign a policy to all interfaces matching that pattern.

For example, you might define an interface role with a naming pattern of DMZ*. When you include this interface role in a policy, the policy is applied to all interfaces whose name begins with "DMZ" on the selected devices. As a result, you can, for example, assign a policy that enables anti-spoof checking on all DMZ interfaces to all relevant device interfaces with a single action. Interface roles can refer to any of the actual interfaces on the device, including physical interfaces, subinterfaces, and virtual interfaces, such as loopback interfaces.

Interface roles serve as an indirection entity between interfaces on the one hand and policies on the other. This enables you to apply policies to particular device interfaces based on the assigned role. Additionally, if you change the naming convention used for a particular interface type, you do not need to determine which policies are affected by the change. All you do is edit the interface role. Interface roles are especially useful when applying policies to new devices. As long as the devices you are adding share the same interface naming scheme as existing devices, the relevant policies can be extended to them without the need to make additional assignments.

Security Manager includes the following predefined interface roles:

•All-Interfaces

•Internal

•External

The following topics describe how to work with interface role objects:

•Creating Interface Role Objects

•Specifying Interfaces During Policy Definition

•Exceptional Cases When Using Interface Roles

Related Topics

•Policy Object Manager Window, page F-1

•Creating Objects

Creating Interface Role Objects

You can create interface role objects that represent one or more interfaces on devices. These interface roles can then be used when you define policies that require interfaces. When you create an interface role object, you must define the naming pattern of the device interfaces to include in the object. Interface roles can refer to any of the actual interfaces on the device, including physical interfaces, subinterfaces, and virtual interfaces.

Objects are defined at the global level, which means that they are applied identically to every object and policy that references them. However, you can override interface role object definitions at the device level, which enables you to associate the role with specific interfaces on a particular device. For more information, see Managing Object Overrides.

This procedure describes how to create interface role objects.

Tip You can also create interface role objects when you define policies or objects that use this object type. For more information, see Selecting Objects for Policies.

Before You Begin

•Read and understand Guidelines for Managing Objects.

Related Topics

•Specifying Interfaces During Policy Definition

•Understanding Interface Role Objects

•Exceptional Cases When Using Interface Roles

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select Interface Roles from the Object Type selector.

Step 3 Right-click in the work area, then select New Object.

The Interface Role dialog box appears.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Enter one or more naming patterns for the interface role object. This pattern defines the device interfaces to include in the definition of the interface role. Separate multiple patterns with commas.

Two wildcards are available:

•You can use a period (.) as a wildcard to represent a single character.

•You can use an asterisk (*) as a wildcard at the end of a pattern to represent multiple interfaces with similar names. (An asterisk can also be used on its own to indicate all interfaces.)

If the pattern does not include a wildcard, it must match the exact name of the interface. For example, the pattern "FastEthernet" will not match FastEthernet0/1 unless you include an asterisk at the end of the pattern.

Note When the pattern defines a subinterface, enter a backslash (\) before the period. Otherwise, Security Manager treats the period as a wildcard.

Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 7 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 8 Click OK to save the object.

Specifying Interfaces During Policy Definition

Security Manager provides you with several options for specifying an interface when defining a policy:

•Entering the name of an interface manually. (To manually enter a subinterface, see Specifying Interfaces During Policy Definition.)

•Entering the name of an interface role manually. See Understanding Interface Role Objects.

•Selecting an interface or interface role from a list. For more information, see Selecting Objects for Policies.

When the policy allows multiple interfaces, each entry must be separated by a comma.

Defining Subinterfaces

If you manually define a subinterface as part of a policy definition, be sure to enter a backslash (\) before the period. If you enter the period without the backslash, Security Manager treats the period as a wildcard for a single character.

For example, if you want to define Ethernet1/1.0 as part of an access rule, you need to enter Ethernet1/1\.0 in the Interfaces field. If you enter Ethernet1/1.0 instead, the interface role will match interfaces named Ethernet1/1.0 and Ethernet1/1/0, since the period on its own is treated as a wildcard.

Note Subinterfaces always appear with a backslash in object selectors.

Distinguishing Interfaces from Interface Roles

When using the selector, be aware that there may be interfaces and interface roles with the same name. They can be distinguished by the icon displayed next to the name, as shown in Table 9-8.

Table 9-8 Icons for Interfaces and Interface Roles

Type

Icon

Interface

Interface role

Related Topics

•Basic Interface Settings on Cisco IOS Routers, page 14-14

•Configuring Firewall Device Interfaces, page 15-2

•Understanding Interface Role Objects

•Creating Interface Role Objects

•Exceptional Cases When Using Interface Roles

Exceptional Cases When Using Interface Roles

This section describes exceptional cases than can occur when defining interface roles in policies.

One Interface Role Assigned to Multiple Interfaces

When using interface roles, you might define a role that applies to more than one interface on a device. For example, the All-Ethernets interface role might be assigned to two different Ethernet interfaces on the device. If you then define a policy requiring a single interface definition that includes the All-Ethernets interface role, a warning message tells you that Security Manager will use the first interface on the device it finds with that role. Any other interfaces assigned the same role are ignored.

Interfaces and Interface Roles with the Same Name

Under normal circumstances, you can configure an interface role that has the same name as an actual interface on the device. If you use object selectors when defining policies (see Selecting Objects for Policies), both the interface and the interface role are listed as available choices, enabling you to select either option. If you type in this common name when you define a policy, Security Manager automatically associates the interface role with the policy, not the interface.

However, a naming conflict can occur under the following circumstances:

1. You type the name of an interface when defining a policy.

2. You later create an interface role that has the same name.

3. You type this name again when defining a policy.

4. You click Select to display the object selector, or Save to save the policy.

When this sequence of events occurs, the Interface Name Conflict Dialog Box, page F-109 is displayed. From here, you can select whether to include the interface or the interface role in the policy.

Related Topics

•Specifying Interfaces During Policy Definition

•Understanding Interface Role Objects

•Creating Interface Role Objects

Understanding IPsec Transform Set Objects

A transform set comprises a combination of security protocols, algorithms and other settings that specify exactly how the data in the IPsec tunnel will be encrypted and authenticated. During IPsec security association negotiation, the peers agree to use a particular transform set when protecting a particular data flow. When defining a transform set, you can make use of the AH (authentication header) protocol, the ESP (encapsulation security protocol) protocol, or both. When using ESP, you can specify whether to use ESP encryption only, or ESP encryption together with ESP authentication. Additionally, you can use the transform set to specify whether to compress the traffic being carried over the IPsec tunnel.

Note We recommend using both encryption and authentication on IPsec tunnels.

IPsec transform set objects are used when defining IPsec proposal policies for VPNs. For more information, see Configuring IPsec Proposals, page 10-53.

To create an IPsec transform set object, see Creating IPsec Transform Set Objects.

Related Topics

•IPsec Protocols

•IPsec Modes

•Policy Object Manager Window, page F-1

•Creating Objects

IPsec Protocols

Two different security protocols are included within the IPsec standard:

•Encapsulating Security Protocol (ESP)—Provides authentication, encryption, and anti-replay services. ESP is IP protocol type 50.

•Authentication Header (AH)—Provides authentication and anti-replay services. AH does not provide encryption and has largely been superseded by ESP. AH is IP protocol type 51.

When using ESP, you can choose from several encryption options, including:

•Data Encryption Standard (DES)

•3DES (requires 3DES license)

•Advanced Encryption Standard (AES—128-bit, 192-bit, and 256-bit)

ESP and AH perform authentication through the use of a hash algorithm, which creates a message to ensure message integrity. Both ESP and AH offer the following authentication options:

•Message Digest 5 (MD5)—Produces a 128-bit digest. MD5 uses less processing time than SHA, but is less secure.

•Secure Hash Algorithm (SHA)—Produces a 160-bit digest. SHA is more resistant to brute-force attacks than MD5, but requires more processing time.

Related Topics

•IPsec Modes

•Creating IPsec Transform Set Objects

•Understanding IPsec Transform Set Objects

IPsec Modes

IPsec can operate in the following modes:

•Tunnel Mode—Tunnel mode encapsulates the entire IP packet. The IPsec header is added between the original IP header and a new IP header. Tunnel mode is used when the firewall is protecting traffic to and from hosts positioned behind the firewall. Tunnel mode is the normal way regular IPsec is implemented between two firewalls (or other security gateways) that are connected over an untrusted network, such as the Internet.

•Transport Mode—Transport mode encapsulates only the upper-layer protocols of an IP packet. The IPsec header is inserted between the IP header and the upper-layer protocol header (such as TCP). Transport mode requires that both the source and destination hosts support IPsec, and can only be used when the destination peer of the tunnel is the final destination of the IP packet. Transport mode is generally used only when protecting a Layer 2 or Layer 3 tunneling protocol such as GRE, L2TP, and DLSW.

Related Topics

•IPsec Protocols

•Creating IPsec Transform Set Objects

•Understanding IPsec Transform Set Objects

Creating IPsec Transform Set Objects

You can create IPsec transform set objects for use in IPsec proposals when defining site-to-site and remote access VPNs. When you create an IPsec transform set object, you must select the mode in which IPsec should operate, as well as define the required encryption and authentication types. Additionally, you can select whether to include compression in the transform set.

This procedure describes how to create IPsec transform set objects.

Tip You can also create IPsec transform set objects when defining policies or objects that use this object type. For more information, see Selecting Objects for Policies.

Before You Begin

•Read and understand Guidelines for Managing Objects.

Related Topics

•Understanding IPsec Transform Set Objects

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select IPsec Transform Sets from the Object Type selector.

Step 3 Right-click in the work area, then select New Object.

The IPsec Transform Set dialog box appears.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Select the required IPsec mode—tunnel or transport. For more information, see IPsec Modes.

Step 6 (Optional) Select the type of ESP encryption and authentication to use in the transform set. If the AH protocol is being used instead of ESP, leave this field blank, then select the type of AH authentication to use. For more information, see IPsec Protocols.

Step 7 (Optional) Select the Compression check box to compress the data in the IPsec tunnel.

Step 8 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 9 Click OK to save the object.

Understanding LDAP Attribute Map Objects

Use the LDAP Attribute Map page to create and name an attribute map for mapping custom (user-defined) attribute names to Cisco LDAP attribute names. If you are introducing a security appliance to an existing LDAP directory, your existing custom LDAP attribute names and values are probably different from the Cisco attribute names and values. Rather than renaming your existing attributes, you can create LDAP attribute maps that map your custom attribute names and values to Cisco attribute names and values. By using simple string substitution, the security appliance then presents you with only your own custom names and values. You can then bind these attribute maps to LDAP servers or remove them as needed. You can also delete entire attribute maps or remove individual name and value entries.

For more information regarding AAA Support on ASA devices, see LDAP.

Related Topics

•Creating LDAP Attribute Map Objects

Creating LDAP Attribute Map Objects

Use the Add and Edit LDAP Attribute Map dialog boxes to add or edit an existing LDAP attribute map.

Before You Begin

•Read and understand Guidelines for Managing Objects.

Related Topics

•Understanding LDAP Attribute Map Objects

•Overriding Global Objects for Individual Devices

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select LDAP Attribute Maps from the Object Type selector.

Step 3 Right-click inside the work area, then select New Object.

The Add LDAP Attribute Map dialog box appears. For a description of the GUI elements, see Table F-80 on page F-112.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Right-click inside the table, then select Add Row.

The Add LDAP Attribute Map Value dialog box appears. For a description of the GUI elements, see Table F-81 on page F-113.

Step 6 Enter the name of the custom map.

Step 7 Select the Cisco map name from the list.

Step 8 Right-click inside the table, then select Add Row.

The Add Map Value dialog box appears. For a description of the GUI elements, see Table F-82 on page F-114.

Step 9 Enter the Custom Map Value.

Step 10 Enter the Cisco Map Value.

Step 11 Click OK to save your changes.

The Add Map Value dialog box closes and you return to the Add LDAP Attribute Map Value dialog box. The new values are displayed in the table.

Step 12 Click OK to save your changes.

The Add LDAP Attribute Map Value dialog box closes and you return to the LDAP Attribute Maps page. The new object is shown in the table.

Step 13 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 14 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 15 Click OK to save the object.

Understanding Network/Host Objects

Network/host objects are logical collections of IP addresses that represent networks, hosts, or both. They can contain one or more network or host IP addresses, as well as other network/host objects. You can reference network/host objects when defining a variety of policies, instead of specifying each network or host individually. By collecting multiple objects in a network/host object, you can refer to all objects in the group as a single item.

Network/host objects can contain the following:

•Networks or subnets, specified by IP addresses and subnet masks.

•Individual hosts, specified by IP addresses.

•Other network/host objects, specified by selecting from a list of existing objects.

Network/host objects make it easier to manage scalable policies. By using the associative capabilities of network/host objects, you can expand your policies along with your network. For example, when you make changes to the list of addresses contained in a network/host object, the changes propagate to all other network/host objects and to policies that refer to that network/host object.

The following topics describe how to work with network/host objects:

•Creating Network/Host Objects

•Using Unspecified Network/Host Objects

•Supported IP Address Formats

•Contiguous and Discontiguous Network Masks

•Specifying IP Addresses During Policy Definition

Related Topics

•How Network/Host Objects are Provisioned as PIX/ASA Object Groups

•Policy Object Manager Window, page F-1

•Creating Objects

Supported IP Address Formats

When defining network/host objects, you can use any of the following formats:

•Host address: x.x.x.x (where x is a value between 0-255)

Example: 192.0.2.252

•Network IP address: x.x.x.x/y (where x is a value between 0-255, and y is a value between 1-32)

Example: 192.0.2.0/24

•Network IP address: x.x.x.x/x.x.x.x (where x is a value between 0-255)

Example: 192.0.2.0/255.255.255.0

•IP address range: x.x.x.x—x.x.x.x

Examples: 192.0.2.14—192.0.2.112

Notes

•IP address ranges can span more than one subnet.

•You cannot define an IP address range with a network mask when defining a network/host object. You can, however, add the network mask when entering the address range directly in a policy. See Specifying IP Addresses During Policy Definition.

•For more information about how Security Manager works with network masks, see Contiguous and Discontiguous Network Masks.

Network/Host Object Optimization

Security Manager optimizes the addresses that you define in network/host objects by removing redundant entries and combining adjacent entries. For example, 192.168.1.0 and 192.168.1.1 are combined as 192.168.1.0/31. Optimization reduces the size of your configuration and provides better performance and memory usage.

To perform optimization, the adjacent addresses must be located on the same subnet boundary (as defined by the CIDR notation). For example, take the following addresses:

•10.1.1.228 (00001010 00000001 00000001 11100100 in binary)

•10.1.1.229 (00001010 00000001 00000001 11100101)

These two addresses can be optimized as 10.1.1.228/31. However, in the case of these two addresses:

•10.1.1.227 (00001010 00000001 00000001 11100011)

•10.1.1.228 (00001010 00000001 00000001 11100100)

Security Manager cannot optimize these addresses because these is no way to define a subnet boundary without including additional addresses.

In addition, optimization cannot be performed in the following circumstances:

•On ACLs.

•On nested network/host objects, which are objects that refer to other objects as part of their definition.

Note IP addresses that you enter directly when you define a policy (for example, in the Source and Destination fields of an access rule) are not optimized.

Related Topics

•Specifying IP Addresses During Policy Definition

•Creating Network/Host Objects

•Using Unspecified Network/Host Objects

•Policy Object Manager Window, page F-1

•Understanding Network/Host Objects

Contiguous and Discontiguous Network Masks

A network mask determines which portion of an IP address identifies the network and which portion identifies the host. Like the IP address, the mask is represented by four octets. (An octet is an 8-bit binary number equivalent to a decimal number in the range 0-255.) If a given bit of the mask is 1, the corresponding bit of the IP address is in the network portion of the address, and if a given bit of the mask is 0, the corresponding bit of the IP address is in the host portion.

Standard, or contiguous, network masks start with zero or more 1s followed by zero or more 0s, as described by the regular expression, 1 x 0 (32-x). This kind of network mask is considered contiguous because it represents a network that consists of a contiguous IP address range. For example, the network 192.168.1.0/255.255.255.0 contains all the IP addresses ranging from 192.168.1.0 to 192.168.1.255.

Table 9-9 shows different methods of representing commonly used standard network masks:

Table 9-9 Standard Network Masks

Dotted Decimal Notation

Classless Inter-Domain Routing (CIDR) Notation

255.0.0.0

/8

255.255.0.0

/16

255.255.255.0

/24

255.255.255.255

/32

For example, 255.255.255.0 indicates that the first three octets of the IP address (24 bits or /24 in CIDR notation) are made up of ones and identify the network; the last octet is made up of zeros and identifies the host.

Discontiguous Network Masks

Nonstandard, or discontiguous, network masks are masks that do not conform to the format of 1 x 0 (32-x). Although discontiguous network masks are not typically used for network configurations, they are sometimes used for certain commands, such as filtering commands when defining access control lists (ACLs). Security Manager supports the use of nonstandard network masks in the policies whose CLI commands support them. An error is displayed if you try to define a discontiguous network mask in a policy that does not support them.

Network Masks and Discovery

During discovery, Security Manager attempts to match network/host objects with existing equivalent objects defined in the Policy Object Manager:

•For contiguous network masks—Two network/host objects containing only standard networks are considered equivalent if they consist of the same set of IP addresses.

•For discontiguous network masks—Two network/host objects are considered equivalent only if the standard networks consist of the same set of IP addresses and the nonstandard networks are syntactically equivalent.

How Network Masks are Displayed

Although you can enter both contiguous and discontiguous network masks using dotted decimal notation, all contiguous network masks are converted to CIDR notation. This makes it easier to distinguish them from discontiguous network masks, which are displayed in dotted decimal notation only.

Related Topics

•Supported IP Address Formats

•Creating Network/Host Objects

•Specifying IP Addresses During Policy Definition

•Using Unspecified Network/Host Objects

•Understanding Network/Host Objects

Creating Network/Host Objects

You can create network/host objects to represent networks or individual hosts. When you create a network/host object, you can include one or more IP addresses and address ranges in IPv4 format. Additionally, you can include existing network/host objects in a new network/host object. For example, you can create a network/host object that comprises two existing network/host objects, a range of IP addresses, and two additional IP addresses.

Objects are defined at the global level, which means that they are applied identically to every object and policy that references them. However, you can override network/host object definitions at the device level, which enables you to associate the object with a specific IP address used by a particular device. For more information, see Overriding Global Objects for Individual Devices.

This procedure describes how to create network/host objects.

Tip You can create network/host objects when defining policies or objects that use this object type. For more information, see Selecting Objects for Policies.

In addition, you can right-click the source or destination defined in an access rule or AAA rule and create a network/host object directly from the contents of the cell. For more information, see Editing Access Rules, page 12-43 and Editing AAA Rules, page 12-62.

Before You Begin

•Read and understand Guidelines for Managing Objects.

Related Topics

•Supported IP Address Formats

•Contiguous and Discontiguous Network Masks

•Specifying IP Addresses During Policy Definition

•Using Unspecified Network/Host Objects

•Understanding Network/Host Objects

•How Network/Host Objects are Provisioned as PIX/ASA Object Groups

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select Networks/Hosts from the Object Type selector.

Step 3 Right-click in the work area, then select New Object.

The Network/Host dialog box appears.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Under Networks/Hosts, enter the addresses (including network masks; the /32 host mask is not required) and/or address ranges to include in the object, or click Select to display a selector (see Selecting Objects for Policies). Use a "-" to separate the first and last IP address in an address range.

If the network you want is not listed, click the Create button or the Edit button to display the Network/Host Dialog Box, page F-114. From here you can define a network/host object.

Note See Supported IP Address Formats for a complete list of supported formats.

Tip You can leave this field blank when creating a global object that will be overridden on all devices that use the object. See Using Unspecified Network/Host Objects.

Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 7 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Note You must select this option when creating a network/host object with an unspecified value.

Step 8 Click OK to save the object.

Using Unspecified Network/Host Objects

When you define network/host objects, you can leave the Networks/Hosts field blank, thereby creating a network/host object with an unspecified value. Use this feature to create global network/host objects that are overridden on every device that uses them.

The advantage of using a network/host object with an unspecified value is that Security Manager displays an error if you submit your changes without creating a device-level override on every device using the object; by contrast, when you define the global object with a placeholder value (such as, 10.10.10.10), that global value could be deployed by mistake if you fail to define an override.

The following procedure describes how to create and implement network/host objects with unspecified values.

Procedure

Step 1 Create a network/host object, making sure to:

•Leave the Networks/Hosts field blank.

•Select the Allow Value Override per Device check box.

For more information, see Creating Network/Host Objects.

Step 2 Create overrides for each device that will use the object:

a. In the Overridable column for the object on the Networks/Hosts page, double-click the green checkmark. The Policy Object Overrides window is displayed. See Policy Object Overrides Window, page F-181.

b. Select the devices on which you want to create overrides, then define a value in the Networks/Hosts field. At this point, this override value applies to all the selected devices. For more information, see Creating Object Overrides for Multiple Devices.

c. Double-click each device in the Policy Object Overrides dialog box, then modify the Networks/Hosts field for the value required by that device.

Step 3 Define the policy that requires the network/host object. You can use one of two methods:

•Define the policy on a single device in Device view, share the policy, then assign the policy to the other devices. See Sharing a Local Policy, page 7-26 and Modifying Shared Policy Assignments in Device View, page 7-34.

•Create a shared policy in Policy view, then assign the policy to the other devices using the Assignments tab. See Modifying Policy Assignments in Policy View, page 7-39.

Note You can create a network/host object that refers to a network/host object with an unspecified value. You do not have to create the device-level overrides before you assign the policy containing the object to devices.

Related Topics

•Creating Network/Host Objects

•Overriding Global Objects for Individual Devices

•Supported IP Address Formats

•Contiguous and Discontiguous Network Masks

•Specifying IP Addresses During Policy Definition

•Understanding Network/Host Objects

Specifying IP Addresses During Policy Definition

Security Manager provides you with several options for specifying an IP address when defining a policy:

•Entering the IP address manually.

•Entering an IP address range manually. You can add a network mask in CIDR or dotted decimal format, if required (for example, when defining tunnel groups or dynamic NAT policies).

Note Adding network masks to an IP address range is not supported when defining a network/host object. See Supported IP Address Formats.

•Entering the name of a network/host object that represents one or more IP addresses. See Understanding Network/Host Objects.

•Selecting a network/host object from a list. For more information, see Selecting Objects for Policies.

When you create a network/host object or define IP addresses as part of a policy, Security Manager verifies that the syntax of the address is correct and that a mask was entered where required. For example, when you define a policy that requires a host, you do not need to enter a mask. However, when you define a policy that requires a subnet, you must enter the address with the mask or select a network/host object that has a mask defined.

Notes

•For more information about the types of addresses you can enter, see Supported IP Address Formats.

•If the policy requires a specific type of IP address, such as a subnet, other types of IP addresses are not accepted.

•When the policy allows multiple addresses, you must separate each entry with a comma.

•IP addresses that you enter directly when defining a policy (for example, in the Source and Destination fields of an access rule) are not optimized. For more information, see Network/Host Object Optimization.

Related Topics

•Creating Network/Host Objects

•Contiguous and Discontiguous Network Masks

•Using Unspecified Network/Host Objects

•Policy Object Manager Window, page F-1

•Understanding Network/Host Objects

Understanding PKI Enrollment Objects

PKI (public key infrastructure) enrollment objects define the Certification Authority (CA) servers that operate within a public key infrastructure. CA servers, also known as trustpoints, manage public PKI certificate requests and issue certificates to participating IPsec network devices. CA servers provide centralized key management for the participating devices, eliminating the need for you to configure keys on each device. Instead, you enroll each participating device with a CA server, which is explicitly trusted to validate identities and create a digital certificate for that device. When peers must negotiate a secured communication session, they validate the identity of the other peer and establish an encrypted session with the public keys contained in the certificates.

CAs can also revoke certificates for devices that will no longer participate in IPsec. Revoked certificates are either managed by an Online Certificate Status Protocol (OCSP) server or are listed in a certificate revocation list (CRL) stored on an LDAP server, which each peer can check before accepting a certificate from another peer.

PKI can be set up in a hierarchical framework consisting of multiple CAs. At the top of the hierarchy is a root CA, which holds a self-signed certificate. The trust within the entire hierarchy is derived from the RSA key pair of the root CA. Subordinate CAs within the hierarchy can enroll with either the root CA or another subordinate CA. Within a hierarchical PKI, all enrolled peers can validate each other's certificates if the peers share a trusted root CA certificate or a common subordinate CA.

A PKI enrollment object identifies the name and URL of a particular CA server, specifies the revocation-checking method that server uses, and defines the parameters that devices require to enroll with that server. In addition, a PKI enrollment object can define additional information for inclusion in certificate requests. When using a hierarchical PKI framework, the PKI enrollment object specifies the trusted servers located above this server in the established hierarchy.

PKI enrollment objects are used in PKI policies. For more information, see Understanding Public Key Infrastructure Policies, page 10-60.

To create a PKI enrollment object, see Creating PKI Enrollment Objects.

Related Topics

•Policy Object Manager Window, page F-1

•Creating Objects

Creating PKI Enrollment Objects

You can create PKI enrollment objects to define the properties of a CA server used when devices exchange certificates as part of an IPsec network. When you create a PKI enrollment object, you define a name for the server and the URL for enrollment. You must specify whether the devices you wish to enroll with this server should retrieve the CA server's own certificate using the Simple Certificate Enrollment Process (SCEP) or use a certificate that you have entered manually into the device configuration. You must also select the method of support used by the CA server for revocation checking.

In addition, you can optionally define the following:

•Whether the CA server is acting as a Registration Authority (RA) server.

•Enrollment parameters, including retry settings and RSA key pair settings.

•Additional attributes to include in the certificate request.

•The list of trusted CA servers located above this server in the PKI hierarchy.

Objects are defined at the global level, which means that they are applied identically to every object and policy that references them. However, you can override PKI enrollment object definitions at the device level, which enables you to associate a specific CA server with a particular device. For more information, see Managing Object Overrides.

This procedure describes how to create a PKI enrollment object.

Tip You can also create PKI enrollment objects when defining policies or objects that use this object type. For more information, see Selecting Objects for Policies.

Before You Begin

•Read and understand Guidelines for Managing Objects.

Related Topics

•Understanding PKI Enrollment Objects

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 Select PKI Enrollments from the Object Type selector.

Step 3 Right-click in the work area, then select New Object.

The PKI Enrollment dialog box appears. For a description of the fields in this dialog box, see Table F-84 on page F-116.

Step 4 Enter a name for the object and optionally a description of the object.

Step 5 Define the properties of the PKI enrollment object, as described in the following topics:

•Defining CA Server Properties

•Defining PKI Enrollment Parameters

•Defining Additional PKI Attributes

•Defining the Trusted CA Hierarchy

Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.

Step 7 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Global Object to Be Overridden.

Step 8 Click OK to save the object.

Defining CA Server Properties

Use the CA Information tab of the PKI Enrollment dialog box to define the basic properties of the PKI enrollment object, including the name and URL of the CA server, the source for obtaining the CA server's certificate, and the type of revocation checking support.

This procedure describes how to define the properties of the CA server in a PKI enrollment object.

Naming the CA Server

When you enter a name for the CA server, bear in mind the following:

•You cannot configure two CA servers with the same name but different URLs on the same device.

•The CA name cannot match the name of a trusted CA configured as part of the same PKI enrollment object. For more information about trusted CAs, see Defining the Trusted CA Hierarchy.

•When the device is configured as part of a VPN, do not configure a device-level override that uses the same CA name as that of the CA server used by any of the peers. (This is not a problem when the device and its peers use a tiered PKI hierarchy.)

In all of these cases, deployment will succeed, but one CA definition will overwrite the other.

Related Topics

•Defining PKI Enrollment Parameters

•Defining Additional PKI Attributes

•Defining the Trusted CA Hierarchy

•Creating PKI Enrollment Objects

•Understanding PKI Enrollment Objects

Procedure

Step 1 In the PKI Enrollment dialog box, click the CA Information tab. SeeTable F-85 on page F-117 Table F-247 on page F-437 for a description of the fields on this tab.

Step 2 (Optional) Enter the name used to identify the CA server in the certification request.

Note If you leave this field blank, the domain name is used. You must leave this field blank for Verisign CAs, because they require the domain name.

Step 3 Enter the URL of the CA server. The following formats are supported:

•http://CA_name:port, where CA_name is the host DNS name or IP address of the CA. The port number is mandatory.

Note If the CA cgi-bin script location at the CA is not the default (/cgi-bin/pkiclient.exe), you must also include the nonstandard script location in the URL, in the form of http://CA_name:port/script_location, where script_location is the full path to the CA scripts.

•tftp://certserver/file_specification, when you enroll with the CA server by means of a TFTP server. This option can be used if you do not have direct access to the CA server.

•Any of the following formats: bootflash, cns, flash, ftp, null, nvram, rcp, scp, system.

Step 4 Select one of the following options for obtaining the CA server's certificate:

•Select Retrieve CA Certificate Using SCEP to have the router retrieve the certificate from the CA server. When using SCEP, you must enter the fingerprint for the CA server in hexadecimal format. If the value you enter does not match the fingerprint on the certificate, the certificate is rejected.

Tip You can obtain the CA's fingerprint by contacting the server directly, or by entering the following address in a web browser: http://URLHostName/certsrv/mscep/mscep.dll

•Select Enter Manually and then copy up to three certificates from another device and paste them into the text field (using your browser's Paste function or the Ctrl-V keyboard shortcut). Each certificate must begin with the word "certificate" and end with the word "quit". Use this option when you want the PKI enrollment object to represent predefined certificates.

Step 5 Select the level of revocation checking support provided by the PKI enrollment object. For more information, see Table F-85 on page F-117.

Step 6 (If you selected OCSP checking in Step 5) Enter the URL for the OCSP server that is providing real-time certificate status checking. This URL must start with http://.

Step 7 (If you selected CRL checking in Step 5) Enter the URL for the LDAP server containing the CRL to be downloaded and checked by the CA server. This URL must start with ldap://.

Note You must include a port number in the URL when using this AAA server on ASA devices, otherwise LDAP will fail.

Step 8 (Optional) Select the Enable Registration Authority Mode check box if the CA server represented by the enrollment object is operating in Registration Authority (RA) mode. In RA mode the server acts as a proxy for the actual CA, which means that CA operations can continue even when the CA itself is offline.

Note This option does not apply to PIX/ASA 7.0+ devices. In addition, you do not need to configure this option if the PKI enrollment object is being used by Cisco IOS routers. Cisco IOS routers configure RA mode automatically, if required.

Defining PKI Enrollment Parameters

Use the Enrollment Parameters tab of the PKI Enrollment dialog box to define the retry settings to use when the device contacts the CA server as well as the settings for generating the RSA key pair to associate with the certificate.

If the PKI enrollment object represents a Microsoft CA, you can define the challenge password required to validate the router's identity.

This procedure describes how to define enrollment parameters for a PKI enrollment object.

Related Topics

•Defining CA Server Properties

•Defining Additional PKI Attributes

•Defining the Trusted CA Hierarchy

•Creating PKI Enrollment Objects

•Understanding PKI Enrollment Objects

Procedure

Step 1 In the PKI Enrollment dialog box, click the Enrollment Parameters tab. See Table F-86 on page F-119 for a description of the fields on this tab.

Step 2 (Mandatory for PIX 6.3 devices; optional for PIX/ASA 7.0 devices and Cisco IOS routers) Enter the password used by the CA server to validate the device's identity.

Tip You can obtain the password by entering the following address in a web browser: http://URLHostName/certsrv/mscep/mscep.dll. The password is good for 60 minutes from the time you obtain it from the CA server. Therefore, it is important that you deploy the password as soon as possible after you create it.

Note Each password is valid for a single enrollment by a single device. Therefore, we do not recommend that you assign a PKI enrollment object where this field is defined to a VPN, unless you first configure a device-level override for each device in the VPN. For more information, see Overriding Global Objects for Individual Devices.

Step 3 (Optional) Modify the default retry values, as follows:

a. In the Retry Period field, specify the interval between certificate request attempts, in minutes.

b. In the Retry Count field, specify the number of times the device should resend the certificate request, if no response is received from the CA server to the first request.

Step 4 (Optional) To have the router request new certificates automatically (known as autoenrollment), enter the percentage of the current certificate's lifetime that triggers the request. For example, if you enter 70, the router requests a new certificate after 70% of the lifetime of the current certificate has been reached.

Step 5 (Optional) Select the Include Device's Serial Number check box if you want to include the serial number of the device in the certificate request.

Note The CA uses the serial number to either authenticate certificates or to later associate a certificate with a particular router. If you are in doubt, include the serial number, as it is useful for debugging purposes.

Step 6 (Optional) Define the RSA key pair to associate with the certificate:

a. In the RSA Key Pair Name field, enter the name of the key pair. If you are associating an existing key pair, enter its name. If you are generating a new key pair, it will be given the name you enter here.

Note If you do not specify an RSA key pair, the fully qualified domain name (FQDN) key pair is used instead. On PIX and ASA devices, the key pair must exist on the device before it is deployed.

b. (Cisco IOS routers only) In the Key Size field, enter the size of the key pair (modulus) in bits. Valid values range from 512 to 1024 (in multiples of 64), 1536 and 2048.

Note Keys with larger modulus values are more secure, but take longer to generate and process. For example, keys larger than 512 bits may take a minute or longer to generate.

c. (Cisco IOS routers only) In the Encryption Key Size field, define the size of the second key, which is used to request separate encryption, signature keys, and certificates.

Step 7 (Optional—for Cisco IOS routers only) In the Source Interface field, enter the name of the interface or interface role whose address should be used as the source interface for all outgoing connections to the CA or LDAP server, or click Select to display a selector (see Selecting Objects for Policies).

This option is useful when the CA or LDAP server cannot reach the address from which the connection originated (for example, due to a firewall). If you do not enter a value in this field, the address of the outgoing interface is used.

Tip If the interface role you want is not listed, click the Create button or the Edit button in the selector to open the Interface Role Dialog Box, page F-108. From here, you can define an interface role to use in the object.

Defining Additional PKI Attributes

Use the Certificate Subject Name tab of the PKI Enrollment dialog box to optionally define additional attributes to include in the certificate request. This information is placed in the certificate and can be viewed by any party who receives the certificate from the router.

This procedure describes how to define additional attributes for a PKI enrollment object.

Note You must enter all information in the LDAP X.500 format.

Related Topics

•Defining CA Server Properties

•Defining PKI Enrollment Parameters

•Defining the Trusted CA Hierarchy

•Creating PKI Enrollment Objects

•Understanding PKI Enrollment Objects

Procedure

Step 1 In the PKI Enrollment dialog box, click the Certificate Subject Name tab. See Table F-87 on page F-121 for a description of the fields on this tab.

Step 2 (Optional) Select the Include Device's FQDN check box to include the router's fully qualified domain name in the certificate.

Step 3 (Optional) Select the device interface whose IP address should be included in the certificate. Enter the name of an interface or interface role, or click Select to display a selector (see Selecting Objects for Policies).

Tip If the interface role you want is not listed, click the Create button or the Edit button in the selector to open the Interface Role Dialog Box, page F-108. From here, you can define an interface role to include in the object.

Step 4 (Optional) Specify one or more X.500 attributes.

Note If you are using digital certificates for user authentication on a Cisco EzVPN IPsec remote-access system, each EzVPN Remote component must be configured with the name of the client group to which it connects. Enter this information in the Organization Unit (OU) field. Although this information is not required for the EzVPN Server, including it does not create configuration problems. For more information about EzVPN, see Understanding Easy VPN, page 10-75.

Defining the Trusted CA Hierarchy

Use the Trusted CA Hierarchy tab of the PKI Enrollment dialog box to optionally define the CA servers that reside at a higher level in a PKI hierarchy. Within a hierarchical PKI, all enrolled peers can validate each other's certificate if the peers share a trusted root CA certificate or a common subordinate CA.

This procedure describes how to define a trusted CA hierarchy for a PKI enrollment object.

Related Topics

•Defining CA Server Properties

•Defining PKI Enrollment Parameters

•Defining Additional PKI Attributes

•Creating PKI Enrollment Objects

•Understanding PKI Enrollment Objects

Procedure

Step 1 In the PKI Enrollment dialog box, click the Trusted CA Hierarchy tab. See Table F-88 on page F-123 for a description of the fields on this tab.

Step 2 Define the trusted servers by selecting one or more PKI enrollment objects from the Available CA Servers list, then clicking >> to add them to the Selected CA Servers list.

Understanding Port Forwarding List Objects

Application port forwarding is configured for thin client access mode in SSL VPN. Port forwarding allows users to access applications (such as telnet, email, VNC, SSH, and Terminal services) inside the enterprise via an SSL VPN session. When port forwarding is enabled, the hosts file on the SSL VPN client is modified to map the application to the port number configured in the forwarding list. A Port Forwarding List object defines the mappings of port numbers on the remote client to the application's IP address and port behind the SSL VPN gateway.

To create Port Forwarding List objects, see Creating Port Forwarding List Objects.

Related Topics

•ASA User Group Dialog Box: SSL VPN Clientless Settings, page F-34

•Thin Client Access Mode

•Creating Objects

•Policy Object Manager Window, page F-1

Creating Port Forwarding List Objects

You can create port forwarding list objects to use when you are configuring the Thin Client access mode for SSL VPN. A port forwarding list object defines the mappings of port numbers on the remote client to the application's IP address and port behind the SSL VPN gateway.

Objects are defined at the global level, which means that they are applied identically to every object and policy that references them. However, you can override Port Forwarding List object definitions at the device level. For more information, see Managing Object Overrides.

Tip You can also create port forwarding list objects when defining policies or objects that use this object type. For more information, see Selecting Objects for Policies.

This procedure describes how to create port forwarding list objects.

Before You Begin

•Read and understand Guidelines for Managing Objects.

Related Topics

•Understanding Port Forwarding List Objects

•ASA User Group Dialog Box: SSL VPN Clientless Settings, page F-34

Procedure

Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).

Step 2 From the