-
null
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Policy 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 MyServers network/host object to send and receive traffic for the services defined in the service object. If a change is made to these servers, you need only update the network/host or service object and redeploy, instead of trying to locate and edit each rule in which the servers are used.
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 Understanding Policy Object Overrides for Individual Devices.
This chapter contains the following topics:
•Selecting Objects for Policies
•Working with Policy Objects—Basic Procedures
•Understanding AAA Server and Server Group Objects
•Creating Access Control List Objects
•Creating ASA User Group Objects
•Creating IKE Proposal Objects
•Understanding Interface Role Objects
•Creating IPSec Transform Set Objects
•Creating LDAP Attribute Map Objects
•Understanding Network/Host Objects
•Creating PKI Enrollment Objects
•Creating Port Forwarding List Objects
•Creating Cisco Secure Desktop Configuration Objects
•Understanding and Specifying Services and Service and Port List Objects
•Configuring Single Sign-On Server Objects
•Monitoring Service Level Agreements (SLAs) To Maintain Connectivity
•Customizing Clientless SSL VPN Portals
•Creating SSL VPN Gateway Objects
•Creating Traffic Flow Objects
•How Policy Objects are Provisioned as ASA/PIX/FWSM Object Groups
When creating a policy, you often need to select one or more objects to include in the policy definition. For example, firewall policies make use of network/host objects, interface role objects, and service objects.
To include objects in policies, you can manually enter the object name or click the Select button to display an object selector dialog box. Object selectors make it easy for you to select which objects to include in a particular policy.
Additionally, object selectors enable you to create and edit objects of that type on the fly. This makes it easy to work with objects without leaving the policy you are defining to open the Policy Object Manager. For example, if when creating a dynamic NAT rule you discover that the ACL object you require does not exist, you can click the Create button to open the dialog box for creating an ACL object. When you finish creating the object, you are returned to the object selector with the new object selected and ready for inclusion in the policy.
When you create an object by opening the object editor from within a selector, the new object must conform to the requirements of the field from which the selector was opened. For example, if you open a selector from a field requiring a host and then decide to create a network/host object for that field, you must define the network/host object as a host.
There are two types of objects selectors—a simple list selector for policies that require you to select a single object, and a dual selector for policies that allow you to select multiple objects of a certain type.
Note When using an object selector to select interfaces, 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. For more information, see Specifying Interfaces During Policy Definition.
Step 1 When configuring a policy that allows or requires a policy object for a given field, click Select next to the field.
An object selector for the required object type is displayed. See Table F-149 on page F-206 for a description of object selectors.
In certain cases, the object selector is prefiltered to display only the objects that are applicable to the policy you are configuring. For example, when configuring a policy that requires a subnet, the object selector displays only those network/host objects that represent subnets, not network/host objects that represent single hosts.
Step 2 In a limited number of fields, you can select more than one type of policy object. For example, some policies allow both network/host objects and interface role objects for source or destination addresses. Other policies allow the selection of either a standard or extended ACL object. If the object selector includes a Type field above the available objects list, select the type of object you want to select.
Tip In some policies, if you select more than one type of object, they are displayed on different tabs within the field.
Step 3 Select the objects to include in the policy definition by doing one of the following:
•In single-object selectors—Click the object you want to select from the displayed list. The name of the object appears in the field at the bottom of the selector.
•In multiple-object selectors—Click the objects you want to select from the Available list (standard multiple-selection shortcuts are supported), then click >> to move your selections to the Selected list on the right. You can return objects from the Selected list to the Available list by selecting them, then clicking <<.
Tip You can also move objects between lists by double-clicking them or by selecting them and pressing Enter. To quickly find a particular object, start typing its name. The selector jumps to the nearest match.
Step 4 For a limited number of object types, order matters. If the selector includes Move Up and Move Down buttons, arrange the objects in priority order. For example, when defining a method list for AAA, use the arrows to determine the order in which different types of AAA server groups are used.
Step 5 Click OK. The objects you selected are added to the policy definition.
The following topics describe the actions that you can perform on policy objects. Some tasks are limited to certain types of objects. For example, not all types of object are overridable, you cannot edit predefined objects, and you cannot import or export all objects.
This section contains the following topics:
•Generating Object Usage Reports
•Importing and Exporting Policy Objects
Security Manager provides predefined policy 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. This is frequently the best method to use, because during policy creation you are prompted for the specific type of object that applies to the situation, and you are more aware of the settings you need for the policy. See Selecting Objects for Policies.
Tip 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 (select 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-35.
Related Topics
•Chapter 8 "Managing Policy Objects"
•Working with Policy Objects—Basic Procedures
Step 1 Do one of the following:
•Select Tools > Policy Object Manager to open the Policy Object Manager Window, page F-1. Select the type of object you want to create from the table of contents, right-click in the table and select New Object.
•While configuring a rule, click Select next to a field that allows or requires a policy object. In the object selector, click the Create button below the available objects list.
The dialog box for adding the selected type of object opens. For more information about the individual types of objects, see the following topics:
•Understanding AAA Server and Server Group Objects
•Creating Access Control List Objects
•Creating ASA User Group Objects
•Understanding FlexConfig Policies and Policy Objects, page 18-1 and Creating FlexConfig Policy Objects, page 18-26 (in Chapter 18, "Managing FlexConfigs")
•Creating IKE Proposal Objects
•Understanding Interface Role Objects
•Creating IPSec Transform Set Objects
•Creating LDAP Attribute Map Objects
•Understanding Network/Host Objects
•Creating PKI Enrollment Objects
•Creating Port Forwarding List Objects
•Creating Cisco Secure Desktop Configuration Objects
•Understanding and Specifying Services and Service and Port List Objects
•Configuring Single Sign-On Server Objects
•Monitoring Service Level Agreements (SLAs) To Maintain Connectivity
•Configuring SSL VPN Bookmark Lists for ASA and IOS Devices
•Configuring ASA Portal Appearance Using SSL VPN Customization Objects
•Creating SSL VPN Gateway Objects
•Configuring SSL VPN Smart Tunnels for ASA Devices
•Creating Traffic Flow Objects
•Configuring WINS/NetBIOS Name Service (NBNS) Servers To Enable File System Access in SSL VPNs
Step 2 Enter a name for the object and optionally a description of the object.
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, maps, network/host 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.
Step 3 Configure the settings specific to the type of object. Refer to the online help page for the dialog box.
Step 4 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.
Step 5 (Optional) If the object type provides the option, select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Policy Object to Be Overridden.
Step 6 Click OK to save the object.
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. However, if an override for the object is already defined for a device, your edits are not reflected in the object used on those devices.
You cannot edit predefined objects, but you can copy them to create new objects. 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
Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager Window, page F-1.
Step 2 Select the object type from the table of contents.
Step 3 Right-click the object you want to edit and 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. Click the Help button for information specific to the type of object.
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.
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-43).
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.
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. 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.
Related Topics
•Working with Policy Objects—Basic Procedures
Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager Window, page F-1.
Step 2 Select the object type from the table of contents.
Step 3 Right-click the object you want to duplicate and 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. Click the Help button for information specific to that type of object.
Step 5 Click OK to save your changes.
You can view contents of an object 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.
Related Topics
•Working with Policy Objects—Basic Procedures
Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager Window, page F-1.
Step 2 Select the object type from the table of contents.
Step 3 Right-click the object and select View Object.
The dialog box for that object appears in read-only mode.
Before you make any changes to a policy 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 database.
You can use either of these methods to generate usage reports:
•Policy Object Manager—Select Tools > Policy Object Manager to open the Policy Object Manager Window, page F-1. Select the type of object from the table of contents, right-click the object and select Find Usage.
•Firewall rules policies—Left-click an object in a firewall rules table, then right-click and select Find Usage.
The usage information is displayed in the Object Usage Dialog Box, page F-206. You can select or deselect the check boxes below the table to view only devices, policies, or other objects that use the selected object.
You can delete user-defined objects only when they are not being used by policies or other objects. You cannot delete predefined objects. If you delete an object for which device-level overrides are defined, all overrides are also deleted.
Tip You might be prevented from deleting an unused 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 unused objects in the database, because they will not affect your policies.
Before You Begin
Determine if the object is currently being used and which policies, objects, and devices would be affected by the deletion. You need to remove all references to the object before you can delete it. You can generate a usage report for this purpose. See Generating Object Usage Reports.
Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager Window, page F-1.
Step 2 Select the object type from the table of contents.
Step 3 Right-click the object you want to delete and select Delete Object, or select the object and click the Delete Object button. You are asked to confirm the deletion.
When you create a policy object, you can elect to allow the object to be overridden. This makes it possible to create a generic object to enable you to create general policies. For individual devices, you override the policy object definition to make the policy apply correctly to the device.
From the Policy Object Manager Window, page F-1, you can select a policy object that can be overridden and generate a table of device-level overrides that are defined for that global object. Right-click the object and select Edit Device Overrides to generate the table (see Policy Object Overrides Window, page F-207).
You can create device-level overrides in two places:
•In the Device Properties window of a selected device, which allows you to create and manage overrides for the selected device only. For more information, see Creating or Editing Object Overrides for a Single Device.
•In the Policy Object Manager window, which allows you to create and manage overrides for more than one device at a time. For more information, see Creating or Editing Object Overrides for Multiple Devices At A Time.
Tip If you override any part of the object definition at the device level, any subsequent changes made to the policy definition at the global level do not affect the device on which the object was overridden.
The following topics explain policy object overrides in more detail:
•Understanding Policy Object Overrides for Individual Devices
•Allowing a Policy Object to Be Overridden
•Creating or Editing Object Overrides for a Single Device
•Creating or Editing Object Overrides for Multiple Devices At A Time
•Deleting Device-Level Object Overrides
For many types of policy objects, you can elect to allow an object to be overridden for a particular device. Thus, you can create an object whose definition works for most devices, and then create modifications to the object for the few devices that need slightly different definitions. Or, you can create an object that needs to be overridden for all devices, but which allows you to create a single policy for all devices. Object overrides make it possible for you to create a smaller set of shared policies for use across your devices without giving up the ability to alter policies when needed for individual devices.
For example, you might want to deny ICMP traffic to the different departments in your company, each of which is connected to a different network. You can do this by defining an access rule firewall policy with a rule that includes a network/host object called Departmental Network. By allowing device override for this object, you can then create overrides on each relevant device that specify the actual network to which that device is connected.
Device-level object overrides are especially important when the global object is included in the definition of a VPN policy, which applies to every device in the VPN topology. For example, you select a PKI enrollment object when defining a PKI policy on a site-to-site VPN. If the hub of your VPN uses a different CA server than the spokes, you must use device-level overrides to specify the CA server used by the hub. Although the PKI policy references a single PKI enrollment object, the actual CA server represented by this object will differ for the hub, based on the device-level override you define.
You can quickly tell if an object can be overridden by looking for the Overridable column in the objects table in the Policy Object Manager Window, page F-1. A green checkmark indicates that you can create overrides for the object; the presence of the column indicates the object type allows overrides.
Related Topics
•Allowing a Policy Object to Be Overridden
•Creating or Editing Object Overrides for a Single Device
•Creating or Editing Object Overrides for Multiple Devices At A Time
•Deleting Device-Level Object Overrides
To create overrides for an object, the object must allow overrides. Not all object types allow overrides.
For those that do allow overrides, you define the object as allowing overrides by selecting Allow Value Override per Device when defining the object. After selecting this option, you must click OK to save the object before you can define any overrides. For more information on creating objects, see Creating Policy Objects.
You can also configure Security Manager to create device-level overrides for existing objects when you discover policies on devices that you add to the inventory. During discovery, if Security Manager determines that an existing object applies to a discovered policy, but that it is not a perfect fit, the object is used but a device-level override is created to account for the difference. For example, if you run policy discovery on a device that has an ACL with the same name as an ACL policy object in Security Manager, the name of the discovered policy object is reused, but a device-level override is created for the object. If you do not allow device-level overrides during discovery, a new policy object is created with a number appended to the name; this is the default.
To configure Security Manager to allow device overrides during discovery, select Tools > Security Manager Administration > Discovery and select Allow Device Override for Discovered Policy Objects.
Related Topics
•Understanding Policy Object Overrides for Individual Devices
•Creating or Editing Object Overrides for a Single Device
•Creating or Editing Object Overrides for Multiple Devices At A Time
•Deleting Device-Level Object Overrides
You can create or edit device-level object overrides from the Device Properties window.
An override specifies a definition for a global object that affects only the selected device. For example, you can override the definition of a AAA server group object so that the object represents a different group of AAA servers for one device than the group it represents for other devices.
Related Topics
•Understanding Policy Object Overrides for Individual Devices
•Allowing a Policy Object to Be Overridden
•Creating or Editing Object Overrides for Multiple Devices At A Time
•Deleting Device-Level Object Overrides
Step 1 (Device view) Right-click a device in the Device selector and select Device Properties.
Step 2 Select the object type you want to override from the Policy Object Overrides folder.
The table displays all objects of the selected type that can be overridden at the device level. If an object has an override already defined for the device, the Value Overridden? column contains a check mark.
Step 3 Select the object whose override you want to change and do one of the following:
•Click the Create Override button, or right-click and select Create Override.
•Click the Edit Override button, or right-click and select Edit Override.
The dialog box for defining that type of object is displayed with the current properties (either the global properties or the local override).
Step 4 Modify the definition of the object and click OK to save the device-level override. In the Device Properties window, a green check mark appears in the Value Overridden? column.
You can create or edit device-level object overrides from the Policy Object Manager window.
This method enables you to create overrides on multiple devices at the same time, which is especially useful when creating overrides for several devices that participate in the same VPN topology. For example, if the spokes located in one part of the VPN use a different CA server than the spokes located in a different part of the VPN, you can override the PKI enrollment object that defines the server for these devices. This is a more convenient method than selecting each device individually from Device view and defining the override from the Device Properties window.
Related Topics
•Understanding Policy Object Overrides for Individual Devices
•Allowing a Policy Object to Be Overridden
•Creating or Editing Object Overrides for a Single Device
•Deleting Device-Level Object Overrides
Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager Window, page F-1.
Step 2 Select the object type you want to override from the table of contents, and then select the object to override.
Tip Not all types of object allow overrides, and not all objects are defined as overridable. Look for a green check mark in the Overridable column. If the object type allows overrides, but this object does not have a check mark, edit the object to enable object override (see Allowing a Policy Object to Be Overridden).
Step 3 Double-click the checkmark, or right-click the object and select Edit Device Overrides, to open the Policy Object Overrides Window, page F-207. The window contains a table listing each device for which an override is defined for the object.
Tip You can also edit the overridable object and click Edit next to the Overrides field.
Step 4 Do one of the following:
•To add an override, click the Create Override button, select the devices to which you want to apply the override, and define the override.
The dialog boxes for creating and editing the override are the same ones used to create the object; click the Help button for information specific to the type of object.
The override you create applies to all policies on the device that use the object; you cannot override the object for one policy but not for another policy.
•To edit an override, select it and click the Edit Override button.
Deleting a device-level override restores the global definition of the object to the selected device. You can delete overrides from the Device Properties window or from the Policy Object Manager window:
•Deleting overrides from Device view—Right-click the device and select Device Properties, then select the object type from the Policy Object Overrides folder. Select the override you want to delete and click Delete Override.
•Deleting overrides from the Policy Object Manager—Select the object type from the table of contents, then right-click the object and select Edit Device Overrides. Select the override you want to delete and click Delete Override.
Related Topics
•Understanding Policy Object Overrides for Individual Devices
•Allowing a Policy Object to Be Overridden
•Device Properties Page, page C-28
•Policy Object Override Pages, page C-34
•Policy Object Overrides Window, page F-207
Security Manager includes a Perl script that you can use to export network/host, service, and port list policy objects so that you can import them into another Security Manager server. The information includes device-level overrides for policy objects that have them.
The Perl command is located in $NMSROOT\bin, which is typically C:\Program Files\CSCSpx\bin. The syntax of the command is:
perl [path]PolicyObjectImportExport.pl-u username -p password -o {import | export} [-a activity] -t object_type -f filename [-c {true | false}] [-d {true | false}] [-h]
Syntax
perl [path] CSMgrDeviceExport.pl |
The Perl script command. Include the path to the PolicyObjectImportExport.pl file if the path is not defined in the system path variable. |
-u username |
A Security Manager username. The data exported is limited by the permissions assigned to this user. The user must have Modify Objects permission for the import or export of policy objects, and additionally the Modify Devices permission for the import or export of device-level overrides. If you are importing objects in non-Workflow mode, you must also have Submit and Approve privileges. |
-p password |
The user's password. |
|
The type of operation you are performing, either to import policy objects from an existing file, or to export policy objects to a CSV file. Only committed objects are exported. |
-a activity |
(Optional.) The name of a Workflow activity. If you do not specify a name, a new activity is created with the name username_time. |
-t object_type |
Object type, one of the following: •network—For network/host objects. •service—For service objects. •portlist—For port list objects. |
-f filename |
The name of the CSV file. When exporting, if the file exists, it is overwritten. |
|
(Optional.) When importing objects, whether to enable policy object conflict detection. •false—An object is imported even if an existing object has the same content. •true—If an existing object has the same content as an imported object, the imported object is skipped. You must also select Enforce for the When Redundant Objects Detected option on the Policy Objects Page, page A-35. |
|
(Optional.) How to handle device-level policy object overrides during either an import or export operation: •true—Include all globally-defined objects and all device-level overrides of the objects. •false—Include only the global definitions of the policy objects. Do not include any device-level policy object override information. This is the default. |
|
(Optional.) Display the command line help. If you include this option, all other options are ignored. |
Importing Policy Objects
When you are importing objects, if an object refers to another object, that object must already be defined in Security Manager, or it must be defined in the same CSV file that you are importing. If the object is in the same CSV file, it must come before the object that refers to it. (Security Manager automatically sorts objects as required when exporting them.)
If Security Manager already has a policy object of the same name as one you are importing, the object is skipped and not imported. The name conflict can even occur if another user has created an object but not yet committed it for public viewing, so you might not be able to see the conflicting object. Security Manager creates only new objects, it does not update existing objects. Use the -c option to specify whether new objects can be created that have the same content as existing objects.
When you run the command, if there are any errors in the file, only the affected objects are not imported. Error messages indicate these problems as they occur, and Security Manager continues evaluating all records in the file. All correctly defined policy objects are imported, and the objects with errors are skipped. The total count and the names of the policy objects that are not imported are shown in the output screen.
After the import command completes, additional actions depend on the Workflow mode you are using:
•Workflow mode—You must log into Security Manager using the same username and password and submit the activity you specified during the import. The activity must be submitted and approved for the changes to take effect.
•Non-Workflow mode—The imported objects are automatically submitted and approved without action on your part. However, you will receive an error if the username you supplied does not have Submit and Approve privileges, and the import operation will fail.
CSV File Format
All objects in a single file are of the same policy object type. The file is in standard comma-separated values (CSV) format. The first line has column headings. Each row represents a single policy object. The columns, left to right, are:
•Name—(Mandatory.) The name of the object.
•Node—The display name of the device on which an override of the policy object is defined. If the policy object is defined on the global level, the field is empty. When importing objects, if the display name does not match a device already in the Security Manager inventory, the object is skipped and not imported.
•Description—The description of the object, if any.
•Category—The category identifier of the object, if any. The category ID is from 10 to 19.
•Allow Override—Whether the object can be overridden. True if the policy object can be overridden on device level, False (or an empty field) if not.
•Group—The names of other policy objects with the same type referenced by this policy object. If there is more than one object, they are separated by commas. For example, network building block Net1 references network building block Net2 and Net3. The Group field of Net1 would have "Net2,Net3" as its value.
•Data—The content of the object.
If there is no value for a particular field, that field is blank in the output. If there are multiple values for a field, the field is enclosed in double quotation marks.
You use AAA server objects to identify the AAA servers used in your network. 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, 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 access rules (ACLs) alone. For example, you can create an access rule allowing all outside users to attempt to use Telnet on a server on the DMZ network. If you want only some users to actually reach the server (and you might not always know the IP addresses of these users, making it impossible to configure simple access rules), you can enable AAA to allow only authenticated or authorized users to make it through the network device (for example, the ASA or router). Thus, users must authenticate before reaching the Telnet server, where Telnet can also require a separate login.
AAA server objects are collected into AAA server group objects. 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.
The following topics describe how to work with AAA server objects:
•Additional AAA Support on ASA, PIX, and FWSM Devices
•Predefined AAA Authentication Server Groups
•Default AAA Server Groups and IOS Devices
•Creating AAA Server Group Objects
You can use AAA servers that use the following protocols with all devices. For ASA, PIX, and FWSM devices, you can also use the protocols described in Additional AAA Support on ASA, PIX, and FWSM Devices
•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.
You can use RADIUS 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 independently.
Related Topics
•Additional AAA Support on ASA, PIX, and FWSM Devices
•Understanding AAA Server and Server Group Objects
In addition to supporting RADIUS and TACACS+, ASA, PIX 7.0+, and FWSM 3.1+ devices can support AAA servers running the following protocols. For more information, see the explanation of AAA usage in the configuration guides for the device type and operating system version that interests you.
•Kerberos—These devices can use Kerberos servers for VPN authentication. When a user attempts to establish VPN access through the 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—These 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 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, you must specify whether the server is version 5.0 or an earlier version.
•LDAP—These devices can use Lightweight Directory Access Protocol (LDAP) servers for VPN authorization. These 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 one of these devices using one of these other servers for authentication and their password has expired, the 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, PIX, or FWSM device) to an LDAP server. These devices and LDAP servers can support multiple mechanisms. If both mechanisms (MD5 and Kerberos) are available, the ASA, PIX, or FWSM 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, PIX, or FWSM device queries the LDAP server and applies the authorizations it receives to the VPN session.
•HTTP-Form—These devices 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 8-1 describes the AAA services that are supported by each protocol:
|
|
|||||||
---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
||||||||
VPN users |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes1 |
Firewall sessions |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
No |
Administrators |
Yes |
Yes |
Yes |
Yes2 |
Yes |
Yes |
Yes |
No |
|
||||||||
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 |
|
||||||||
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. |
Related Topics
•Understanding AAA Server and Server Group Objects
There are 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 8-2 describes the predefined AAA authentication server groups.
|
|
---|---|
Enable |
Uses the enable password defined on the device for authentication. |
KRB5 KRB5-Telnet |
Uses Kerberos 5 for authentication. Use KRB5-Telnet when using Telnet to connect. For Cisco IOS routers, you can use 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). |
If-Authenticated |
Uses the if-authenticated method, which allows the user to access the requested function if the user is authenticated. |
Line |
Uses the line password defined on the device for authentication. |
Local Local-case |
Uses the local username database (defined on the device) for authentication. Use Local-case if you want the login to be case-sensitive. |
None |
Uses no authentication. |
RADIUS TACACS+ |
Use RADIUS or TACACS+ authentication. (Does not apply to Cisco IOS routers.) These AAA server groups do not contain any AAA servers. To use one of them 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 or Editing Object Overrides for a Single Device. |
Related Topics
•Creating AAA Server Group Objects
•Default AAA Server Groups and IOS Devices
•Understanding AAA Server and Server Group Objects
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.
You can also create your own default group. 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 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.
Related Topics
•Predefined AAA Authentication Server Groups
•Creating AAA Server Group Objects
•Understanding AAA Server and Server Group Objects
You can create AAA server objects to populate the AAA server group objects that are referenced by policies such as AAA rules, 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.
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.
Related Topics
•Additional AAA Support on ASA, PIX, and FWSM Devices
•Understanding AAA Server and Server Group Objects
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 to open the Add or Edit AAA Server Dialog Box, page F-8.
Step 4 Enter a name for the object and optionally a description of the object.
Step 5 Identify the AAA server:
•In the Host field, enter the IP address or (for ASA or PIX 7.2+ devices) host name of the AAA server. You can also enter the name of a network/host object that contains the host IP address, or click Select to select the object.
•Optionally, in the Interfaces field, enter the name of an interface or an interface role (which must resolve to a single interface name on the device) whose IP address should be used for all outgoing RADIUS or TACACS+ packets.
•Optionally, enter the amount of time to wait until a AAA server is considered unresponsive.
Step 6 Select the protocol used by the AAA server and configure protocol-specific properties. You can use RADIUS and TACACS+ with all device types. You can use the Kerberos, LDAP, NT, SDI, and HTTP-FORM protocols only with ASA, PIX 7.x+, and FWSM 3.1+ devices.
For details about the properties, see the following topics:
•RADIUS—See AAA Server Dialog Box—RADIUS Settings, page F-10.
•TACACS+—See AAA Server Dialog Box—TACACS+ Settings, page F-12.
•Kerberos—See AAA Server Dialog Box—Kerberos Settings, page F-13.
•LDAP—See AAA Server Dialog Box—LDAP Settings, page F-14.
•NT—See AAA Server Dialog Box—NT Settings, page F-16.
•SDI—See AAA Server Dialog Box—SDI Settings, page F-16.
•HTTP-FORM—See AAA Server Dialog Box—HTTP-FORM Settings, page F-17.
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.
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.
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.
Related Topics
•Predefined AAA Authentication Server Groups
•Default AAA Server Groups and IOS Devices
•Understanding AAA Server and Server Group Objects
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 to open the AAA Server Group Dialog Box, 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 ASA, PIX, or FWSM 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 Select the protocol to be used by the servers in the group.
Step 6 Enter the names of the AAA server policy objects that define the AAA servers to include in the group. Click Select to select the objects from a list filtered by the protocol you selected. You can also create new AAA server objects from the selection list. Separate multiple objects with commas.
Step 7 Configure the additional options that you want:
•Make this Group the Default AAA Server Group—For IOS devices only, whether you are using this group as the default group. Use this option if you intend to have a single global server group for this protocol for all policies requiring AAA. For more information, see Default AAA Server Groups and IOS Devices.
•ASA, PIX, FWSM devices—Select options for how to handle AAA servers that stop responding, and for how to send accounting messages. For more information, see AAA Server Group Dialog Box, page F-6.
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 Policy Object to Be Overridden.
Step 10 Click OK to save the object.
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.
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 8-3:
Related Topics
•Creating Access Control List Objects
•Understanding Access Rule Address Requirements and How Rules Are Deployed, page 11-19
•Understanding Network/Host Objects
•Understanding and Specifying Services and Service and Port List Objects
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.
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
•Creating Access Control List Objects
•Understanding Access Rule Address Requirements and How Rules Are Deployed, page 11-19
•Understanding Network/Host Objects
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.
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 8-4 shows examples of Web VPN ACLs.
Uses:
•As a filter ACL in an ASA User Group policy object (under SSL VPN > Clientless).
Related Topics
•Creating Access Control List Objects
•Understanding Access Rule Address Requirements and How Rules Are Deployed, page 11-19
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.
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.
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.
Related Topics
•Configuring a Tunnel Group Policy for Easy VPN, page 9-78
•Policy Object Manager Window, page F-1
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 ASA Group Policies Dialog Box, page F-25.
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 these settings, see ASA Group Policies 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 these settings, see ASA Group Policies 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 these settings, see ASA Group Policies 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 these settings, see ASA Group Policies IPSec Settings, page F-31.
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 these settings, see ASA Group Policies SSL VPN Clientless Settings, page F-33.
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 these settings, see ASA Group Policies 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 these settings, see ASA Group Policies 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 these settings, see ASA Group Policies DNS/WINS Settings, page F-40.
b. Select Split Tunneling to allow a remote client to conditionally direct encrypted packets through a secure tunnel to the central site and simultaneously allow clear text tunnels to the Internet through a network interface. For a description of these settings, see ASA Group Policies Split Tunneling Settings, 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 these settings, see ASA Group Policies Connection Settings, page F-42.
Step 10 Click OK to save the object.
You can create credential objects to use for IKE Extended Authentication (Xauth) in Easy VPN configurations. 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.
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.
Related Topics
•Easy VPN and IKE Extended Authentication (Xauth)
•Policy Object Manager Window, page F-1
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 Credentials Dialog Box, page F-46.
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 Policy Object to Be Overridden.
Step 10 Click OK to save the object.
File objects represent files that are used in device configurations, typically for remote access VPN policies and policy objects. Such files include Anyconnect client profile and image files, image (graphic) files, plug-in jar files, and Cisco Secure Desktop package files.
When you create a file object, Security Manager makes a copy of the file in its storage system. These files are backed up whenever you create a backup of the Security Manager database, and they are restored if you restore the database. When you deploy configurations that specify a file object, the associated file is download to the device in the appropriate directory.
After you create a file object, you typically should not edit it. If you need to replace the file, edit the file object to select the new file, or create a new file object. If the file is editable, you can edit the file object to identify the file's location in the file repository, and use the desired editor to open and edit the file outside of Security Manager. The file repository is the CSCOpx\MDC\FileRepository folder in the installation directory (typically, C:\Program Files). The files are organized in subfolders named for the file type.
When you delete a file object, the associated file is not deleted from the file repository.
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
Copy the files to the Security Manager server. You cannot select files from a network server or your workstation. Do not copy the file directly to the file repository.
Related Topics
•Selecting or Specifying a File or Directory on the Server File System, page 2-19
•Policy Object Manager Window, page F-1
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 (see Add and Edit File Object Dialog Boxes, 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 you are selecting, and click Browse to select the file.
If desired, you can enter a different name for the file in the File Name on Device field. This is the name that is used when copying the file to the device when you deploy the configuration.
Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.
Step 7 Click OK to save the object.
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 9-45.
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.
Tip You can also create IKE proposal objects when defining policies that use this object type. For more information, see Selecting Objects for Policies.
Related Topics
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.
Step 4 Enter a name for the object and optionally a description of the object.
Step 5 Configure the options you want to use for this IKE proposal. The options are described in Add or Edit IKE Proposal Dialog Box, page F-53 and in these topics:
•Deciding Which Encryption Algorithm to Use, page 9-45
•Deciding Which Hash Algorithm to Use, page 9-46
•Deciding Which Diffie-Hellman Group to Use, page 9-46
•Deciding Which Authentication Method to Use, page 9-47
Step 6 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.
Step 7 Click OK to save the object.
Interface Role objects have the following uses:
•Specifying multiple interfaces— Interface role objects allow you to apply policies to specific interfaces on multiple devices without having to manually define the names 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.
•Zones—You use interface role objects to define the zones in a zone-based firewall rules policy.
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 you apply 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—Includes every interface defined on a device.
•Internal—Includes only specific interfaces that are meant to be on the inside of a network. See the object definition for a list.
•External—Includes only specific interfaces that are meant to be on the outside of a network. See the object definition for a list.
•Self—Does not include any interfaces. The Self interface role is specific to zone-based firewall rules policies. The Self zone is the router itself. You can use it to identify traffic originating from the router, or traffic directed to the router. It does not include traffic passing through the router.
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
You can create interface role objects that represent one or more interfaces on devices. You can then use these roles when you define policies that require interfaces or zones. 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.
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.
Related Topics
•Specifying Interfaces During Policy Definition
•Understanding Interface Role Objects
•Exceptional Cases When Using Interface Roles
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.
You can use these wildcards to create name patterns that apply to multiple interfaces:
•Use a period (.) as a wildcard for a single character.
To use a period as part of the pattern itself (for example, when defining subinterfaces), enter a backslash (\) before the period.
•Use an asterisk (*) as a wildcard for one or more characters at the end of the interface pattern. For example, FastEthernet* would include interfaces named FastEthernet0 and FastEthernet1.
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.
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 Policy Object to Be Overridden.
Step 8 Click OK to save the object.
When you configure policies that require you to identify an interface, you have several options for specifying the interface:
•Enter the name of the interface manually, for example, Ethernet0.
To manually specify a subinterface as part of a policy definition, you must enter a backslash (\) before the period. For example, Ethernet0\.1.
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. If you enter Ethernet1/1.0 instead, the name matches interfaces named Ethernet1/1.0 and Ethernet1/1/0, because the period on its own is treated as a wildcard.
•Enter the name of an interface role manually. For more information about interface roles, see Understanding Interface Role Objects.
•Select an interface or interface role from a list. By clicking Select next to the Interfaces field, you are prompted with a list of valid interface names and interface roles. Subinterfaces appear with a backslash before the period in their names.
By selecting from a list, you can ensure that your entry is valid. For more information, see Selecting Objects for Policies.
When a policy allows multiple interfaces, separate entries with commas.
In policies and object selectors, icons distinguish between interfaces and interface roles. If you create interface roles with the same name as interfaces, be careful to select exactly what you want. Table 8-5 explains the icons.
|
|
---|---|
Interface |
|
Interface role If you can edit the role, a pencil image overlays the icon. |
|
Related Topics
•Basic Interface Settings on Cisco IOS Routers, page 13-13
•Configuring Firewall Device Interfaces, page 14-2
•Understanding Interface Role Objects
•Creating Interface Role Objects
•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, or in some cases, OK to update the policy.
When this sequence of events occurs, the Interface Name Conflict Dialog Box, page F-57 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
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.
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.
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.
Related Topics
Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager Window, page F-1.
Step 2 Select IPSec Transform Sets from the table of contents.
Step 3 Right-click in the work area and select New Object.
The IPSec Transform Set dialog box appears (see Add or Edit IPSec Transform Set Dialog Box, page F-57).
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:
•Use tunnel mode 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 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.
Step 6 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 Add or Edit IPSec Transform Set Dialog Box, page F-57.
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.
Use LDAP Attribute Map objects to map 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 Additional AAA Support on ASA, PIX, and FWSM Devices.
Related Topics
•Understanding Policy Object Overrides for Individual Devices
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 Add and Edit LDAP Attribute Map Dialog Boxes, page F-59.
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 Add and Edit LDAP Attribute Map Value Dialog Boxes, page F-60.
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 Add and Edit Map Value Dialog Boxes, page F-61.
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 Policy Object to Be Overridden.
Step 15 Click OK to save the object.
The objects in the Maps folder in the Policy Object Manager allow you to configure class, parameter, and policy maps for inspection rules or zone-based firewall rules policies. The types of maps you can use with these policies depends on the operating system running on the device as well as the specific version number, so typically it is best to configure the maps when you are configuring the policies.
Tip Devices enforce unique names for all configured maps. For example, you cannot use the same name for an FTP and DNS class map on the same device. If you select maps with the same name for a device, Security Manager automatically adds a numerical suffix to the duplicate names, for example, dnsmap_1.
The Maps folder contains the following folders. Subfolders organize the maps based on whether they are used for inspection or web content filtering.
•Class Maps—Layer 7 class maps used for identifying traffic that you want to act on.
•Parameter Maps—Parameter maps that configure settings used in zone-based firewall rules policies or other maps.
•Policy Maps—Layer 7 policy maps used for identifying the action to take on selected traffic.
Also included in the Maps folder are entries for TCP Map objects (a Layer 4 object), Regular Expression objects, and Regular Expression Group objects.
The following sections describe the different types of maps in more detail.
Class Maps
Class maps are subordinate to policy maps. You cannot specify a class map directly in a device policy. Instead, you create a policy map to incorporate the class map. The class map itself defines the match conditions for the traffic that you want to target in an inspection rule or zone-based firewall rule.
•ASA/PIX 7.2 and higher, and FWSM devices—You can create class maps for the inspection of DNS, FTP, HTTP, IM, and SIP traffic. You also have the option of defining the traffic match directly in the policy map object, but if you create separate class maps, you can reuse them in more than one policy map.
•IOS 12.4(6)T and higher devices—You can create class maps for the inspection of IM applications (AOL, ICQ, MSN Messenger, Windows Messenger, and Yahoo Messenger), P2P applications (eDonkey, FastTrack, Gnutella, Kazaa2), H.323, HTTP, IMAP, POP3, SIP, SMTP, Sun RPC. You can also create class maps for filtering web content using the Local, N2H2, Trend, and Websense objects.
Unlike the class maps used for ASA/PIX/FWSM, you must create separate class maps and refer to them from the related policy maps. You can use these policy maps in zone-based firewall inspection or content filtering rules. For more information, see these topics:
–Configuring Maps for Inspection in Zone-Based Firewall Rules Policies
–Configuring Maps for Content Filtering in Zone-Based Firewall Rules Policies
To create class maps, see Creating Class Map Objects.
To create the regular expressions and regular expression groups that you can use in class, parameter, and policy maps, see these topics:
•Creating Regular Expression Group Objects
•Creating Regular Expression Objects
Parameter Maps
Parameter maps define settings that you can use in zone-based firewall inspection or content filtering rules, or in other policy map objects.
•Inspection—You can create Inspection Parameter maps for general zone-based firewall rule parameters, or Protocol Info Parameter maps for use with IM application inspection.
•Content Filtering—You can create the following parameter maps to define web content filtering: Local, N2H2, Trend, URL Filter, URLF Glob, Websense.
Policy Maps
You can configure policy maps to alter the default actions of inspection or to configure web content filtering in zone-based firewall settings policies. Policy maps typically apply to applications that require special handling, perhaps due to embedded IP address information or the fact that the traffic opens secondary channels on dynamically assigned ports.
The policy map identifies the action to take on traffic that matches the conditions identified in the map. For most policy maps, you can specify traffic match conditions by referring to a class map. However, some policy maps require that you specify the match criteria within the policy map.
You can configure these types of policy maps:
•Inspection Rules—When configuring inspection rules, you can use Security Manager to create policy map objects for the following applications: DCE/RPC, DNS, ESMTP, FTP, GTP, H.323, HTTP, IM, IPsec, NetBIOS, SIP, Skinny, and SNMP. See the following topics for more information:
–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
You can also create TCP Maps, which are a Layer 4 policy map, as described in Creating TCP Map Objects.
•Zone-Based Firewall Inspection Rules—When configuring zone-based firewall inspection rules, you can use Security Manager to create policy map objects for the following applications: H.323, HTTP, IM (includes AOL, ICQ, MSN Messenger, Windows Messenger, and Yahoo Messenger), IMAP, P2P (includes eDonkey, FastTrack, Gnutella, Kazaa2), POP3, SIP, SMTP, Sun RPC. For more information, see Configuring Maps for Inspection in Zone-Based Firewall Rules Policies.
•Zone-Based Firewall Content Filtering Rules—When configuring zone-based firewall content filtering rules, you can use Security Manager to create Web Filter policy maps. You can also configure HTTP policy maps to inspect HTTP traffic. For more information, see Configuring Maps for Content Filtering in Zone-Based Firewall Rules Policies.
You can create class maps as independent policy objects and then assign them to specific policy inspection map objects. For class maps used with ASA or PIX devices, you can create class maps directly in a policy map object, but by creating them separately, you can reuse the class maps in multiple policy objects. For class maps used with IOS devices, you must create the class map separately from the policy map.
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
•Configuring Maps for Inspection in Zone-Based Firewall Rules Policies
•Configuring Maps for Content Filtering in Zone-Based Firewall Rules Policies
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 folders in the 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-61).
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, complete the dialog box with appropriate values, and select whether you are matching or not matching the specified settings. The available criteria differ depending on the type of class map you are creating.
For ASA and PIX devices, see the following topics for information on match criteria:
•DNS Class and Policy Maps Add or Edit Match Condition (and Action) Dialog Boxes, page F-90
•FTP Class and Policy Maps Add or Edit Match Condition (and Action) Dialog Boxes, page F-97
•H.323 Class and Policy Maps Add or Edit Match Condition (and Action) Dialog Boxes, page F-106
•SIP Class and Policy Maps Add or Edit Match Condition (and Action) Dialog Boxes, page F-129
For IOS devices, see the following topics for information on match criteria:
•Zone-Based Firewall IM Application Class Maps Add or Edit Match Condition Dialog Boxes, page F-64
•Zone-Based Firewall P2P Application Class Maps Add or Edit Match Condition Dialog Boxes, page F-64
•H.323 (IOS) Class Maps Add or Edit Match Criterion Dialog Boxes, page F-65
•HTTP (IOS) Class Add or Edit Match Criterion Dialog Boxes, page F-65
•IMAP and POP3 Class Maps Add or Edit Match Criterion Dialog Boxes, page F-67
•SIP (IOS) Class Add or Edit Match Criterion Dialog Boxes, page F-68
•SMTP Class Maps Add or Edit Match Criterion Dialog Boxes, page F-69
•Sun RPC Class Maps Add or Edit Match Criterion Dialog Boxes, page F-72
•Local Web Filter Class Add or Edit Match Criterion Dialog Boxes, page F-72
•N2H2 and Websense Class Add or Edit Match Criterion Dialog Boxes, page F-73
•Trend class map criteria are described in Add or Edit Class Maps Dialog Boxes, page F-61
Step 7 Click OK.
The Add Match Criterion dialog box closes and you return to the Add Class Map dialog box.
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 Policy Object to Be Overridden.
Step 10 Click OK to save the object.
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
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 Maps > Policy Maps > Inspect > 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-86.
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 Policy Object to Be Overridden.
Step 8 Click OK to save the object.
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 to 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
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 Maps > Policy Maps > Inspect > 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-87).
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-88.
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-89.
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-87.
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-90.
•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 Policy Object to Be Overridden.
Step 11 Click OK to save the object.
An ESMTP policy map lets you change the default configuration values used for ESMTP inspection.
ESMTP inspection detects attacks, including spam, phishing, 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
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 Maps > Policy Maps > Inspect > 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-92.
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-94.
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 Policy Object to Be Overridden.
Step 9 Click OK to save the object.
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
Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).
Step 2 Select Maps > Policy Maps > Inspect > 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-95).
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-97).
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-97.
•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 Policy 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.
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
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 Maps > Policy Maps > Inspect > 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-99).
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-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 GTP Policy Maps Add or Edit Match Condition and Action Dialog Boxes, page F-101.
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 Policy 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.
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
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 Maps > Policy Maps > Inspect > H.323 Maps (ASA/PIX/FWSM).
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-103.
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-106.
•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 Policy Object to Be Overridden.
Step 9 Click OK to save the object.
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+)
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
•Configuring HTTP Policy Map Objects
•Creating HTTP Map Objects (ASA 7.2+/PIX 7.2+)
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 Maps > Policy Maps > Inspect > 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-107).
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-108.
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-109.
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-111.
•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-112.
•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-113.
•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-114.
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 Policy Object to Be Overridden.
Step 10 Click OK to save the object.
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
•Configuring HTTP Policy Map Objects
•Creating HTTP Map Objects (ASA 7.1.x/PIX 7.1.x/FWSM 3.x/IOS)
Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).
Step 2 Select Maps > Policy Maps > Inspect > 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-115).
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-115.
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-117.
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-117.
•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 Policy Object to Be Overridden.
Step 9 Click OK to save the object.
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
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 Maps > Policy Maps > Inspect >
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-121).
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-122.
•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 Policy Object to Be Overridden.
Step 8 Click OK to save the object.
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
Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).
Step 2 Select Maps > Policy Maps > Inspect > 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-124).
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 Policy Object to Be Overridden.
Step 8 Click OK to save the object.
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
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 Maps > Policy Maps > Inspect > 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-125).
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 Policy Object to Be Overridden.
Step 8 Click OK to save the object.
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
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 Maps > Policy Maps > Inspect > 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-126).
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 Policy Object to Be Overridden.
Step 8 Click OK to save the object.
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
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 Maps > Policy Maps > Inspect > SIP Maps (ASA/PIX/FWSM).
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-127.
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-129.
•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 Policy Object to Be Overridden.
Step 9 Click OK to save the object.
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
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 Maps > Policy Maps > Inspect > 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-131.
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-133.
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 Policy Object to Be Overridden.
Step 9 Click OK to save the object.
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
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 Maps > Policy Maps > Inspect > 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-133).
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 Policy Object to Be Overridden.
Step 8 Click OK to save the object.
When you configure Zone-Based Firewall Rules policies for a router, you can configure rules to inspect traffic by selecting Inspect as the action for the rule. You can then select the protocols to inspect.
For some protocols, you can select policy maps to perform deep inspection on packets that match your criteria. You can configure these maps from the policy object selector dialog box while configuring the policy, or from the Policy Object Manager window (select Tools > Policy Object Manager). In addition to policy maps, there are some parameter maps you can configure for inspection.
For protocols that allow deep inspection, you select the related policy maps, which in turn incorporate class maps that define the match conditions for the targeted traffic. To create these policy maps in the Policy Object Manager, select one of the maps listed in Table 8-6 in the Maps > Policy Maps > Inspect folder and review the detailed usage information in Add or Edit Policy Maps Dialog Boxes for Zone-Based Firewall Policies, page F-134. For information on creating class maps, which are in the Maps > Class Maps > Inspect folder, see the references to the match criterion dialog boxes and Add or Edit Class Maps Dialog Boxes, page F-61.
Besides the maps used to configure deep inspection, you can also configure an Inspect Parameters map on in the Adding and Editing Zone-based Firewall Rules. Zone-based firewall inspection includes several general settings, all of which have default values that are appropriate for most networks. If you want to adjust any setting, you can create an Inspect Parameters map. In the Policy Object Manager, select Maps > Parameter Maps > Inspect > Inspect Parameters and review the detailed usage information in Add or Edit Inspect Parameter Map Dialog Boxes, page F-74.
|
|
|
|
|
|
---|---|---|---|---|---|
Internet Messaging: AOL, ICQ, MSN Messenger, Windows Messenger, Yahoo Messenger |
12.4(9)T |
IM (Zone based IOS) |
AOL ICQ MSN Messenger Windows Messenger Yahoo Messenger |
Protocol Info Parameters |
Inspect traffic based on the type of service (chat or any other). See Zone-Based Firewall IM Application Class Maps Add or Edit Match Condition Dialog Boxes, page F-64. You must also select a Protocol Info parameter map to define the DNS servers used by the traffic you are inspecting. See Add or Edit Protocol Info Parameter Map Dialog Boxes, page F-76. |
Person-to-Person (P2P): eDonkey, FastTrack, Gnutella, Kazaa2 |
12.4(9)T |
P2P |
eDonkey FastTrack Gnutella Kazaa2 |
None |
Inspect traffic based on file name. See Zone-Based Firewall P2P Application Class Maps Add or Edit Match Condition Dialog Boxes, page F-64. |
H.323 |
12.4(6)T |
H.323 (IOS) |
H.323 (IOS) |
None |
Inspect traffic based on the H.323 message type. See H.323 (IOS) Class Maps Add or Edit Match Criterion Dialog Boxes, page F-65. |
HTTP |
12.4(6)T |
HTTP (Zone Based IOS) |
HTTP (IOS) |
None |
Inspect traffic based on a wide variety of criteria including the content of the header or body, port misuse, and whether the traffic includes a Java applet. See HTTP (IOS) Class Add or Edit Match Criterion Dialog Boxes, page F-65. |
IMAP (Internet Message Access Protocol) POP3 (Post Office Protocol 3) |
12.4(6)T |
IMAP POP3 |
IMAP POP3 |
None |
Inspect traffic based on invalid commands or clear text logins. See IMAP and POP3 Class Maps Add or Edit Match Criterion Dialog Boxes, page F-67. |
SIP |
12.4(6)T |
SIP (IOS) |
SIP (IOS) |
None |
Inspect traffic based on a wide variety of criteria. See SIP (IOS) Class Add or Edit Match Criterion Dialog Boxes, page F-68. |
SMTP |
12.4(6)T |
SMTP |
SMTP |
None |
Inspect traffic based on data length. See SMTP Class Maps Add or Edit Match Criterion Dialog Boxes, page F-69. |
Stun-ice |
12.4(9)T |
None |
None |
Protocol Info Parameters |
You must select a Protocol Info parameter map to define the DNS servers used by the traffic you are inspecting. See Add or Edit Protocol Info Parameter Map Dialog Boxes, page F-76. |
Sun RPC (Remote Procedure Call) |
12.4(6)T |
Sun RPC |
Sun RPC |
None |
Inspect traffic based on the RPC protocol number. See Sun RPC Class Maps Add or Edit Match Criterion Dialog Boxes, page F-72. |
Related Topics
•Understanding the Zone-based Firewall Rules, page 11-62
•Zone-based Firewall Rules Page, page I-54
When you configure Zone-Based Firewall policies for a router, you can configure rules to filter web content by selecting Content Filter as the action for the rule. To filter web content, you must configure a variety of map policy objects, which you can do from the policy object selector dialog box while configuring the policy, or from the Policy Object Manager window (select Tools >
Policy Object Manager).
The type of maps required depends on the technique you are using to filter content and on the Cisco IOS Software version you are using. You can filter content based on URL lists defined locally on the device, or you can use external filtering servers such as SmartFilter (N2H2), Websense, or Trend Micro.
Tip If you use an external server, you must have set up and configured the server appropriately based on the documentation for the type of server you select. If you use Trend Micro servers, configure the Zone-Based Firewall Settings policy to specify the server details and to register the product and download certificates. For more information, see Zone Based Firewall Page, page I-87.
The following are the configuration requirements for map objects when configuring zone-based content filtering:
•For devices running releases below 12.4(20)T, you must create a URL Filter parameter map object. In the Policy Object Manager, select Maps > Parameter Maps > Web Filter > URL Filter and review the detailed usage information in Add or Edit URL Filter Parameter Map Dialog Boxes, page F-82.
–To do local filtering using lists of allowed (whitelisted) and denied (blacklisted) hosts defined on the device, create the lists on the Local Filtering tab. Any web access attempts are first compared to these lists before the request is sent on to an external web filtering server, if you configure one. These lists contain either a complete domain name (such as www.cisco.com) or a partial name (such as cisco.com), but they do not include paths or page names, and you cannot use wildcards.
–To use a SmartFilter (N2H2) or Websense server, configure the type of server you are using and its address information on the External Filter tab. You can also configure other settings that control communication with the server. You cannot configure a Trend Micro server using the URL Filter parameter map.
•For devices running release 12.4(20)T and higher, the preferred configuration is to use a Web Filter policy map object. Although Web Filter policy maps are more complex, they provide added flexibility and allow you to use Trend Micro filtering servers. In the Policy Object Manager, select Maps > Policy Maps > Web Filter > Web Filter and review the detailed usage information in Add and Edit Web Filter Map Dialog Boxes, page F-136.
A Web Filter policy map points to other types of maps. To create the object, you must create these other types of maps:
–Parameter maps—On the Parameters tab, you can select parameter maps for the various types of web filtering if you do not want to use the default settings. If you are using SmartFilter (N2H2) or Websense, you need to select a parameter map because the map identifies those servers. For local and Trend Micro filtering, parameter maps configure some general settings, the most interesting of which is whether to display a message or web page when you block a URL. In the Policy Object Manager, you can find parameter maps for Local, N2H2, Trend, and Websense in the Maps > Parameter Maps > Web Filter folder. For detailed usage information, see Add or Edit Local Web Filter Parameter Map Dialog Boxes, page F-77, Add or Edit N2H2 or WebSense Parameter Map Dialog Boxes, page F-78, or Add or Edit Trend Parameter Map Dialog Boxes, page F-81.
Note You configure Trend Micro server information in the Firewall > Settings > Zone Based Firewall policy rather than in a policy object or in the Zone Based Firewall Rules policy.
–Class maps for match conditions and actions—Class maps define the type of traffic you are targeting for filtering. You select the type of filtering you want to do, then select the class map that identifies the targeted traffic and set the action to take for that traffic. In the Policy Object Manager, you can find class maps for Local, N2H2, Trend, and Websense in the Maps > Class Maps > Web Filter folder.
The configurations depend on the type of filtering:
Local Filtering—The Local Web Filter class map uses URLF Glob parameter maps to define either domain names or URL keywords that you want to target. A URL keyword is any text string that occurs between / characters in a URL. These class maps help you define allowed (whitelisted) and denied (blacklisted) URL lists; create separate maps for each list. For detailed usage information, see Add or Edit Class Maps Dialog Boxes, page F-61, Local Web Filter Class Add or Edit Match Criterion Dialog Boxes, page F-72, and Add or Edit URLF Glob Parameter Map Dialog Boxes, page F-84.
SmartFilter (N2H2) or Websense Filtering—The class maps for N2H2 and Websense define any server response as the matching criterion. For detailed usage information, see Add or Edit Class Maps Dialog Boxes, page F-61.
Trend Micro Filtering—The Trend class map defines the various web traffic categories and security classifications, as defined by Trend Micro, that you want to target. For detailed usage information, see Add or Edit Class Maps Dialog Boxes, page F-61.
Besides the maps used to define content filtering, you can also configure the following maps for content filter rules:
•Inspect Parameters maps—Zone-based firewall inspection includes several general settings, all of which have default values that are appropriate for most networks. If you want to adjust any setting, you can create an Inspect Parameters map. In the Policy Object Manager, select Maps > Parameter Maps > Inspect > Inspect Parameters and review the detailed usage information in Add or Edit Inspect Parameter Map Dialog Boxes, page F-74.
•HTTP policy map—If you want to use deep inspection on the individual HTTP packets in addition to web filtering, you can configure an HTTP policy map by clicking Configure next to the Protocol field in the Action group on the Adding and Editing Zone-based Firewall Rules, page I-57. The HTTP policy map incorporates HTTP class maps that define the type of traffic you want to match and then defines the action to take. For example, you can target traffic that includes Java applets. In the Policy Object Manager, select Maps > Policy Maps > Inspect > HTTP (Zone Based IOS) and review the detailed usage information in Add or Edit Policy Maps Dialog Boxes for Zone-Based Firewall Policies, page F-134, HTTP (IOS) Class Add or Edit Match Criterion Dialog Boxes, page F-65, and Add or Edit Class Maps Dialog Boxes, page F-61.
Related Topics
•Understanding the Zone-based Firewall Rules, page 11-62
•Zone-based Firewall Rules Page, page I-54
A Regular Expression Group object groups regular expressions together. The objects can be used by inspection class maps and inspection policy maps.
Related Topics
•Creating Regular Expression Objects
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 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-138).
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 Policy Object to Be Overridden.
Step 8 Click OK to save the object.
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
•Metacharacters Used to Build Regular Expressions
•Creating Regular Expression Group Objects
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 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-138).
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 Policy Object to Be Overridden.
Step 8 Click OK to save the object.
Table 8-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]".
Related Topics
•Creating Regular Expression Objects
•Creating Regular Expression Group Objects
The TCP Maps object lets you customize inspection on TCP flow for both through and to box traffic.
Related Topics
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 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-139.
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.
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.
•Ranges of network addresses.
•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
•Contiguous and Discontiguous Network Masks
•Specifying IP Addresses During Policy Definition
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. 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 8-8 shows different methods of representing commonly used standard network masks:
|
|
---|---|
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 contiguous format. For example, 10.0.1.1/255.0.255.255 indicates that you want to match an address that matches octets 1, 3, and 4 exactly, but any value in octet 2 is accepted.
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
•Creating Network/Host Objects
•Specifying IP Addresses During Policy Definition
•Using Unspecified Network/Host Objects
•Understanding 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 other network/host objects in a 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.
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.
Related Topics
•Contiguous and Discontiguous Network Masks
•Specifying IP Addresses During Policy Definition
•Using Unspecified Network/Host Objects
•Understanding Network/Host Objects
Step 1 Select Tools > Policy Object Manager to open the 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 to open the Add or Edit Network/Host Dialog Box, page F-141.
Step 4 Enter a name for the object and optionally a description of the object.
Step 5 In the Networks/Hosts field, enter the desired host or network addresses, address ranges, or other network/host objects. For specific information on the address formats allowed, see Specifying IP Addresses During Policy Definition.
Tip You can leave this field blank if you want to create an object that must be overridden for every device that uses it. You must also select Allow Value Override per Device. For more information, 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 Policy Object to Be Overridden.
Step 8 Click OK to save the object.
When you define network/host objects, you can leave the Networks/Hosts field blank, thereby creating a network/host object with an unspecified value. Network/host objects with unspecified values require that you create overrides for 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.
Related Topics
•Creating Network/Host Objects
•Understanding Policy Object Overrides for Individual Devices
•Contiguous and Discontiguous Network Masks
•Specifying IP Addresses During Policy Definition
•Understanding Network/Host Objects
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 to open the Policy Object Overrides Window, page F-207.
b. Click the Create Override button and 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 or Editing Object Overrides for Multiple Devices At A Time.
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 6-27 and Modifying Shared Policy Assignments in Device View, page 6-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 6-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.
Many policies and policy objects require that you enter an IP address for a host or network. For some policies or objects, you must enter just a host, or just a network. For other policies or objects, you can enter some combination of hosts and networks. You are prevented from entering or selecting addresses that are not appropriate for the circumstances.
The following is a description of all acceptable formats that you can use, although a particular policy or object might not allow specific formats (for example, interface roles are allowed as address designations in only a very limited number of policies). If the policy or object allows it, you can enter multiple addresses by separating them with commas.
•Network/host object. Enter the name of the object or click Select to select it from a list. You can also create new network/host objects from the selection list.
•Host IP address, for example, 10.10.10.100.
•Network address, including subnet mask, in either the format 10.10.10.0/24 or 10.10.10.0/255.255.255.0.
•A range of IP addresses, for example, 10.10.10.100-10.10.10.200. Separate the beginning and ending addresses with a hyphen. The range does not need to be within a single subnet unless the policy requires it.
You can also include a subnet mask: 10.10.10.100-10.10.10.200/24.
•An IP address pattern in the format 10.10.0.10/255.255.0.255, where the mask is a discontiguous bit mask (see Contiguous and Discontiguous Network Masks).
•Interface role object (in rare cases). Enter the name of the object or click Select to select it from a list (you must select Interface Role as the object type). When you use an interface role, the rule behaves as if you supplied the IP address of the selected interface. This is useful for interfaces that get their address through DHCP, because you do not know what IP address will be assigned to the device. For more information, see Understanding Interface Role Objects.
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 when 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.
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
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.
Note You do not have to define enrollment parameters in order to create or import a trustpoint in Security Manager.
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.
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.
Related Topics
•Understanding Public Key Infrastructure Policies, page 9-57
•Configuring Public Key Infrastructure Policies, page 10-32 (remote access VPN)
•Prerequisites for Successful PKI Enrollment, page 9-59
•Configuring Public Key Infrastructure Policies, page 9-61 (site-to-site VPN)
•Policy Object Manager Window, page F-1
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 (see PKI Enrollment Dialog Box, page F-142).
Step 4 Enter a name for the object and optionally a description of the object.
Step 5 Click the CA Properties tab and 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. Keep the following in mind when filling in the tab:
•The URL enrollment method is the only method where Security Manager will complete the enrollment for you. If you select another method, you must use your own methods for completing the enrollment.
•If you leave the CA Server Nickname field blank, the domain name is used. You must leave this field blank for Verisign CAs, because they require the domain name.
For specific information on the fields on this tab, see PKI Enrollment Dialog Box—CA Information Tab, page F-144.
Step 6 Click the Enrollment Parameters tab and 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.
For specific information on the fields on this tab, see PKI Enrollment Dialog Box—Enrollment Parameters Tab, page F-148.
Step 7 Click the Certificate Subject Name tab and 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.
For specific information on the fields on this tab, see PKI Enrollment Dialog Box—Certificate Subject Name Tab, page F-150.
Step 8 Click the Trusted CA Hierarchy tab to define the trusted CA servers within a hierarchical PKI framework. Within this framework, all enrolled peers can validate each other's certificates if they share a trusted root CA certificate or a common subordinate CA.
Select the CA servers (as defined as PKI enrollment objects) to include in the hierarchy in the Available Servers list and click >> to move them to the selected list. You can do the reverse to remove servers.
If the PKI enrollment object you need is not yet defined, click the Create button beneath the available servers list to create the object. You can also select an object and click the Edit button to change its definition, if needed.
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 Policy Object to Be Overridden.
Step 11 Click OK to save the object.
You can create port forwarding list objects to use when you are configuring the thin client access mode for SSL VPN.
Port forwarding allows users to access applications (such as Telnet, e-mail, VNC, SSH, and Terminal services) inside the enterprise through 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.
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.
Related Topics
•ASA Group Policies SSL VPN Clientless Settings, page F-33
•Policy Object Manager Window, page F-1
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 Port Forwarding List.
The Port Forwarding List page opens, displaying the defined port forwarding list objects.
Step 3 Right-click in the work area, then select New Object.
The Port Forwarding List dialog box opens, displaying a table of any port forwarding entries that are defined for the object. For a description of the elements in this dialog box, see Table F-102 on page F-152.
Step 4 Enter a name for the object and optionally a description of the object.
Step 5 To create a new port forwarding entry or modify the properties of an existing one, click Create below the Port Forwarding List table, or select an entry in the table and click Edit. The Add/Edit Port Forwarding Entry dialog box opens. For a description of the elements on this dialog box, see Table F-103 on page F-152.
a. Specify the port number to which the local application is mapped.
b. Specify the IP address or fully qualified domain name of the remote server.
c. Specify the port number of the application for which port forwarding is configured.
d. Enter any additional information about the port forwarding entry (mandatory on IOS routers).
e. Click OK to save the changes, and close the Add/Edit Port Forwarding Entry dialog box. The entry appears in the table in the Port Forwarding List dialog box.
Step 6 In the Include Port Forwarding Lists field, specify the names of other Port Forwarding List objects that you want to include in this Port Forwarding List object. You can click Select to open the Port Forwarding List selector from which you can make your selection.
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 Policy Object to Be Overridden.
Step 9 Click OK to save the object.
You can create port list objects for use in defining service objects (see Understanding and Specifying Services and Service and Port List Objects). Each port list object can contain one or more port ranges (for example, 1-1000 and 2000-2500). Additionally, a port list object can include other port list objects.
Security Manager contains a predefined port list object that includes either all ports (1-65535) or all secure ports (1024-65535), depending on the setting you select in the Security Manager Administration window (select Tools > Security Manager Administration > Policy Objects and see Policy Objects Page, page A-35).
Tip You can also create port list objects when defining service objects. For more information, see Selecting Objects for Policies.
Related Topics
•Policy Object Manager Window, page F-1
Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).
Step 2 Select Services > Port Lists from the Object Type selector.
Step 3 Right-click inside the work area, then select New Object.
The Add Port List dialog box appears. For a description of the fields in this dialog box, see Table F-104 on page F-153.
Step 4 Enter a name for the object and optionally a description of the object.
Step 5 Define the contents of the port list object by doing one or both of the following:
•In the Ports field, enter one or more ports and port ranges. Use hyphens to separate the first and last port number in the range, for example, 100-999. Separate multiple entries with commas. You can also use the following operators:
–gt—greater than
–lt—less than
–eq—equals
–neq—does not equal
Note You cannot combine a port range containing the neq operator with additional ranges.
•Enter the names of existing port list objects, or click Select to display a selector (see Selecting Objects for Policies).
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 Policy Object to Be Overridden.
Step 8 Click OK to save the object.
Cisco Secure Desktop (CSD) Configuration objects define the settings you want to use if you enable Secure Desktop in an SSL VPN policy for an IOS device (see Configuring Cisco Secure Desktop Software on IOS Devices, page 10-26). For ASA devices, the feature is set up as part of the Dynamic Access Policy (see Understanding Dynamic Access Policies, page 10-17).
Cisco Secure Desktop (CSD) provides a reliable means of eliminating all traces of sensitive data by providing a single, secure location for session activity and removal on the client system. CSD provides a session-based interface where sensitive data is shared only for the duration of an SSL VPN session. All session information is encrypted, and all traces of the session data are removed from the remote client when the session is terminated, even if the connection terminates abruptly. For more information about Cisco Secure Desktop, see Understanding Secure Desktop Manager Policies, page 10-24.
About Windows Locations
Windows locations let you determine how clients connect to your virtual private network, and protect it accordingly. For example, clients connecting from within a workplace LAN on a 10.x.x.x network behind a NAT device are an unlikely risk for exposing confidential information. For these clients, you might set up a CSD Windows Location named Work that is specified by IP addresses on the 10.x.x.x network, and disable both the Cache Cleaner and the Secure Desktop function for this location.
In contrast, users' home PCs might be considered more at risk to viruses due to their mixed use. For these clients, you might set up a location named Home that is specified by a corporate-supplied certificate that employees install on their home PCs. This location would require the presence of antivirus software and specific, supported operating systems to grant full access to the network.
Alternatively, for untrusted locations such as Internet cafes, you might set up a location named "Insecure" that has no matching criteria (thus making it the default for clients that do not match other locations). This location would require full Secure Desktop functions, and include a short timeout period to prevent access by unauthorized users. If you create a location and do not specify criteria, make sure it is the last entry in the Locations list.
Related Topics
•Cisco Secure Desktop on IOS Configuration Example Using SDM, http://www.cisco.com/en/US/products/ps6496/products_configuration_example09186a008072aa7b.shtml
•Setting Up CSD for Microsoft Windows Clients, http://www.cisco.com/en/US/docs/security/csd/csd311/csd_for_vpn3k_cat6k/configuration/guide/CSDwin.html
•Configuring the Secure Desktop Software for an IOS SSL VPN Policy, page 10-61
Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).
Step 2 Select Cisco Secure Desktop Configuration from the Object Type selector.
Step 3 Right-click in the work area and select New Object to open the Add or Edit Secure Desktop Configuration Dialog Box, page F-44.
Step 4 Enter a name for the object and optionally a description of the object.
Step 5 Select Windows Location Settings to create locations (such as Work, Home, or Insecure), and define the location-based settings (also called adaptive policies) for CSD.
a. For each location you want to configure, enter its name in the Location to Add field and click Add to move it to the Locations field. You can reorder the locations using the Move Up and Move Down buttons. When users connect, these locations are evaluated in order and the first one that matches is used to define the policies for the user.
When you add a location, a folder for the location is added to the table of contents. The folder and its subfolders define the policies for the location.
b. If you want all the open browser windows to close after the Secure Desktop installation, make sure to select the corresponding check box.
c. Select the required check boxes to configure a VPN Feature policy that enables web browsing, file access, port forwarding, and full tunneling, if installation or location matching fails.
Step 6 Select the folders and subfolders for the Windows locations you added and configure their settings. For detailed information about these settings, see Setting Up CSD for Microsoft Windows Clients at http://www.cisco.com/en/US/docs/security/csd/csd311/csd_for_vpn3k_cat6k/configuration/guide/CSDwin.html.
Step 7 Select Windows CE to configure a VPN feature policy to enable or restrict web browsing and remote server file access for remote clients running Microsoft Windows CE.
Step 8 Select Mac and Linux Cache Cleaner to configure the Cache Cleaner and a VPN Feature Policy for these clients, such as enabling or restricting web browsing, remote server file access, and port forwarding.
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.
Many policies in Security Manager require that you identify a service to which the policy applies. A service is a protocol and port definition that identifies a particular type of traffic. In many cases, you can specify the service directly in the policy. You can also select service policy objects that define the required services, or use a combination of service objects and policy-specific service designations.
When configuring a policy that requires that you identify a service, you can select or create service objects by clicking the Select button next to the Services field. To create a new service from the selection dialog box, click the Add button beneath the service list. You can also create services from the Policy Object Manager Window by selecting Services > Services from the table of contents and clicking the Add Object button. For information on the specific fields available when creating a service object, see Add and Edit Service Dialog Boxes, page F-154.
Service objects are convenient because you can create service objects to represent the composition of a particular application, or you can model them after the logical organizations that exist on your network, such as a development team or corporate department.
Security Manager includes a comprehensive collection of predefined service objects, including ICMP messages and objects for commonly used services such as HTTP, Syslog, POP3, Telnet, and SNMP. Before using a predefined service object, you should review the object definition to verify that it conforms to your network implementation. If the predefined object does not meet your needs (for example, if you require different destination ports), you can create a new service object from scratch or based on a copy of an existing object. For more information, see Duplicating Objects.
Whether you are creating a service object or specifying services directly in a policy, you can specify services using the following formats. As you type, Security Manager might prompt you with text-completion options related to your entry. You can select a value from the list and press Enter or Tab. You can enter more than one service by separating services with commas.
•protocol, where the protocol is 1-255 or a well known protocol name such as tcp, udp, gre, icmp, and so forth. If you enter a number, Security Manager might convert it to the associated name.
•icmp/message_type, where the message type is 1-255 or a well-known message type name such as echo.
•{tcp | udp | tcp&udp}/{destination_port_number | port_list_object} where the destination port number is 1-65535 or the name of a port list object. You can enter a range of ports using a hyphen, for example, 10-20. The source port number is the Default Range port list object. The Default Range object includes either all ports (1-65535) or all secure ports (1024-65535), depending on the setting you select in the Policy Objects Page, page A-35 (select Tools > Security Manager Administration > Policy Objects).
For example, defining a service as tcp/10 means that 10 is the destination port and no source port is defined.
Tip To create port list objects, select Services > Port Lists in the Policy Object Manager Window and click the Add Object button. For more information, see Add or Edit Port List Dialog Box, page F-153.
•{tcp | udp | tcp&udp}/{source_port_number | port_list_object}/ {destination_port_number | port_list_object}, where the source and destination port numbers are 1-65535 or the name of a port list object. You can enter a range of ports using a hyphen, for example, 10-20.
For example, defining a service as tcp/10/20 means that 10 is the source port and 20 is the destination port. If you do not want to specify a destination port, use the Default Range port list object, for example, tcp/10/Default Range.
•service_object_name, which is the name of another existing service object. Specifying other objects lets you nest object definitions. Click Select to select a service object or to create a new object.
Related Topics
•Selecting Objects for Policies
•How Service Objects are Provisioned as ASA/PIX/FWSM Object Groups
•Allowing a Policy Object to Be Overridden
Single sign-on (SSO) lets SSL VPN users enter a username and password once and be able to access multiple protected services and web servers without logging into each one. If you want to configure SSO for an SSL VPN group, you must also configure a AAA server, such as a RADIUS or LDAP server.
The SSO mechanism starts as part of the AAA process or just after successful user authentication to an AAA server. The SSL VPN server running on the security appliance acts as a proxy for the user to the authenticating server. When a user logs in, the SSL VPN server sends an SSO authentication request, including username and password, to the authenticating server. If the server approves the authentication request, it returns an SSO authentication cookie to the SSL VPN server. The security appliance keeps this cookie on behalf of the user and uses it to authenticate the user to secure web sites within the domain protected by the SSO server.
You can use either a Computer Associates SiteMinder SSO server or a Security Assertion Markup Language (SAML) Browser Post Profile version 1.1 server. Create a single sign on server policy object to identify the URL and other properties of the server you are using. Select Single Sign On Servers in the Policy Object Manager Window, page F-1, then right-click inside the work area and select New Object or right-click a row and select Edit Object. You can also create the object when configuring an ASA user group object for SSL VPN (see ASA Group Policies Dialog Box, page F-25).
For detailed information about the properties that you must configure in a single sign on server object, see Add or Edit Single Sign On Server Dialog Boxes, page F-156.
Note The SAML Browser Artifact profile method of exchanging assertions is not supported.
Related Topics
•Policy Object Manager Window, page F-1
•Add or Edit Single Sign On Server Dialog Boxes, page F-156
You can configure ASA or PIX devices that run version 7.2 or higher to perform route tracking by monitoring service level agreements. By monitoring the connectivity to a device on another network, you can track the availability of a primary route and install a backup route if the primary route fails. For example, you can define a default route to an Internet service provider (ISP) gateway and a backup default route to a secondary ISP in case the primary ISP becomes unavailable. This technique, called Dual ISP, provides security appliances with a form of high availability, which is a vital part of providing customers with the services to which they are entitled.
Without route tracking, there is no inherent mechanism for determining if the route is up or down. A static route remains in the routing table even if the next hop gateway becomes unavailable, and is removed only if the associated interface on the security appliance goes down.
The security appliance performs route tracking by associating a route with a monitoring target that you define in an SLA monitor policy object. It monitors the target using ICMP echo requests, according to the parameters configured in the object. If an echo reply is not received within a specified time period, the SLA monitor is considered down and the associated route is removed from the routing table. A previously configured backup route is used in place of the removed route.
SLA monitoring jobs start immediately after deployment and continue to run unless you remove the SLA monitor from the device configuration (that is, they do not age out).
The following procedure explains how to configure SLA monitor objects and associate them with routes and interfaces in an ASA or PIX configuration.
Related Topics
•Configuring Static Routes, page 14-75
•Configuring Firewall Device Interfaces, page 14-2
Step 1 Create the SLA monitor policy object:
a. Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1) and select SLA Monitors from the table of contents.
Tip You can also create SLA monitor objects when defining policies that use this object type. For more information, see Selecting Objects for Policies.
b. Right-click in the work area and select New Object to open the Add or Edit SLA Monitor Dialog Box, page F-158.
c. The monitoring options are appropriate for most connections, so you need only configure the following:
•Name—The name of the object.
•SLA Monitor ID—An identifying number for the monitoring process. The number must be unique within a device configuration.
•Monitored Address—The address that you are monitoring. When you select a monitoring target, make sure that it can respond to ICMP echo requests (pings). The target can be any network address that you choose, but consider the use of:
•The ISP gateway address.
•The next hop gateway address (if you are concerned about the availability of the ISP gateway).
•A server on the target network, such as an AAA server, with which the security appliance needs to communicate.
•A persistent network device on the destination network. (A desktop or notebook computer that gets shut down at night is not a good choice.)
•Interface—The interface name, or interface role that identifies an interface, that will be the source of the ICMP messages. The device pings the monitored address from this interface's IP address.
d. Click OK to save the object.
Step 2 Configure ASA/PIX policies to use the object to monitor routes. You can configure the following policies to monitor SLAs:
•Platform > Routing > Static Route—When you define a static route, you can select an SLA monitor object to do route tracking for the route. For more information, see Static Route Page, page K-184 and Add/Edit Static Route Dialog Box, page K-185.
•Interfaces—When you define an interface that uses DHCP or PPPoE, you can configure the DHCP or PPPoE learned default routes to be tracked. For more information, see Device Interface: IP Type (PIX/ASA), page 14-10.
You can customize the web site and its contents that you use for the portal page for a browser-based clientless SSL VPN. ASA devices allow much more customization than IOS devices. You can create several policy objects that define the look of the web pages the user sees when logging into or out of the VPN and the home page for the portal, as well as the bookmarks and smart tunnels available to the user.
This section contains the following topics:
•Configuring ASA Portal Appearance Using SSL VPN Customization Objects
•Localizing SSL VPN Web Pages for ASA Devices
•Creating Your Own SSL VPN Logon Page for ASA Devices
•Configuring SSL VPN Bookmark Lists for ASA and IOS Devices
•Using the Post URL Method and Macro Substitutions in SSL VPN Bookmarks
•Configuring SSL VPN Smart Tunnels for ASA Devices
•Configuring WINS/NetBIOS Name Service (NBNS) Servers To Enable File System Access in SSL VPNs
An SSL VPN Customization object describes the appearance of browser-based clientless SSL VPN web pages displayed to users. This includes the Logon page displayed when they connect to the ASA security appliance, the Home page displayed after authentication, and the Logout page displayed when users log out of the SSL VPN service.
You use SSL VPN Customization objects when defining ASA group objects or Remote Access VPN Connection policies for ASA devices. You can create several customization objects and define multiple ASA group or connection profiles so that each user group sees web pages designed specifically for their use. Customization can include localizing the web pages in the languages appropriate for each group. For more information about localization, see Localizing SSL VPN Web Pages for ASA Devices.
Initially, when a user first connects, the default customization object identified in the connection profile determines how the logon screen appears. If the user selects a different group from the connection profile list on the logon page, and that group has its own customization, the screen changes to reflect the customization object for the selected group. After the remote user is authenticated, the screen appearance is determined by the customization object that has been assigned to the group policy.
After you create the SSL VPN customization object as described in this procedure, you can use the object to specify the portal characteristics in these policies:
•On the SSL VPN > Settings page in an ASA group policy object (see ASA Group Policies SSL VPN Settings, page F-37), which you then select in one of these policies:
–Remote Access VPN > Group Policies
–Remote Access VPN > Connection Profiles on the General tab
•In the Remote Access VPN > Connection Profiles policy, you can also specify the SSL VPN customization object on the SSL tab (see SSL Tab (ASA), page H-32).
Related Topics
•Localizing SSL VPN Web Pages for ASA Devices
•Add and Edit SSL VPN Customization Dialog Boxes, page F-163
Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).
Tip You can also create SSL VPN Customization objects when defining policies or objects that use this object type. For more information, see Selecting Objects for Policies.
Step 2 Select SSL VPN Customization from the Object Type selector. The SSL VPN Customization page opens, displaying a list of the existing SSL VPN Customization objects.
Step 3 Right-click in the work area and select New Object.
The Add SSL VPN Customization dialog box appears (see Add and Edit SSL VPN Customization Dialog Boxes, page F-163).
Step 4 Enter a name for the object and optionally a description of the object.
Step 5 Before you configure settings for the various pages, use the Preview button to view the default settings. Clicking Preview opens a browser window to display the current settings for the Logon page, Portal page, or Logout page, whichever one is selected in the table of contents (selecting a page within one of these folders is the same as selecting the parent folder).
Tip Click Preview after making any changes to settings to verify that the changes are what you desire.
Step 6 Configure the settings for the Logon page. This web page is the one users see first when connecting to the SSL VPN portal. It is used for logging into the VPN. Select the following items in the Logon Page folder in the table of contents on the left of the dialog box to view and change the settings:
•Logon Page—Specify the title of the web page, which is displayed in the browser's title bar.
•Title Panel—Determine whether the Logon page will have a title displayed in the web page itself. If you enable the title panel, you can specify the title, font, font size and weight, styles, and colors used. You can also select a File object that identifies a logo graphic. For more information about the settings, see SSL VPN Customization Dialog Box—Title Panel, page F-165.
•Language—If you want to configure translation tables for other languages on the ASA device and use them, you can configure the supported languages and allow users to choose their language. For information about translation tables and localization support, see Localizing SSL VPN Web Pages for ASA Devices. For more information about the settings, see SSL VPN Customization Dialog Box—Language, page F-166.
•Logon Form—Configure the labels and colors used in the form that accepts user logon information. For more information about the settings, see SSL VPN Customization Dialog Box—Logon Form, page F-168.
•Informational Panel—If you want to provide extra information to the user, you can enable an informational panel and add text and a logo graphic. For more information about the settings, see SSL VPN Customization Dialog Box—Informational Panel, page F-169.
•Copyright Panel—If you want to include copyright information on the logon page, you can enable the copyright panel and enter your copyright statement. For more information about the settings, see SSL VPN Customization Dialog Box—Copyright Panel, page F-170.
•Full Customization—If you do not want to use the security appliance's built-in logon page, even customized, you can instead enable full customization and supply your own web page. For information on creating the required file, see Creating Your Own SSL VPN Logon Page for ASA Devices. For more information about the settings, see SSL VPN Customization Dialog Box—Full Customization, page F-170.
Step 7 Configure the settings for the Portal page. This is the home page for the SSL VPN portal, and is displayed after the users log in. Select the following items in the Portal Page folder in the table of contents on the left of the dialog box to view and change the settings:
•Portal Page—Specify the title of the web page, which is displayed in the browser's title bar.
•Title Panel—Determine whether the Portal page will have a title displayed in the web page itself. If you enable the title panel, you can specify the title, font, font size and weight, styles, and colors used. You can also select a File object that identifies a logo graphic. For more information about the settings, see SSL VPN Customization Dialog Box—Title Panel, page F-165.
•Toolbar—Determine whether the Portal page will have a toolbar, which contains a field for entering a URL to browse. For more information about the settings, see SSL VPN Customization Dialog Box—Toolbar, page F-171.
•Applications—Determine which application buttons will appear on the page. For more information about the settings, see SSL VPN Customization Dialog Box—Applications, page F-172.
•Custom Panes—Determine how you want to organize the body of the Portal page. The default is a single column with no internal panes. You can create a multiple-column layout, create internal panes that display text or references to URLs, and determine in which column and row to place the panes. For more information about the settings, see SSL VPN Customization Dialog Box—Custom Panes, page F-172.
•Home Page—Determine how and whether to display URL lists on the home page, and whether to use your own web page for the main body of the Portal page. For more information about the settings, see SSL VPN Customization Dialog Box—Home Page, page F-174.
Step 8 Select Logout Page to configure the settings of the page displayed when a user logs out of the SSL VPN. You can configure the title, message text, fonts, and colors. For more information about the settings, see SSL VPN Customization Dialog Box—Logout Page, page F-175.
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 Policy Object to Be Overridden.
Step 11 Click OK to save the object.
Localization is the process of providing text in a language that is appropriate for the target users. When you create an SSL VPN Customization object for defining the look of browser-based clientless SSL VPN web pages hosted on an ASA device, you can configure the pages to use the desired language.
To see localized web pages correctly, users must configure their browsers to use UTF-8 encoding (for example, in Internet Explorer, select View > Encoding > Unicode (UTF-8). They also must install the required fonts or language support files for their language using the Regional and Language Options control panel. On the Languages tab, click Details to install the desired languages, and select the appropriate supplemental language settings for East Asian, complex scripting, and right-left languages. On the Advanced tab, select the desired code page conversion tables. If users do not configure the browser correctly, they might see boxes instead of characters.
There are two techniques you can use to localize SSL VPN web pages that are hosted on an ASA device. These techniques are not mutually exclusive; you can use both of them. These are the techniques:
•Configure the SSL VPN Customization object using the desired language—When you create the SSL VPN Customization object, you can enter text for labels and messages in non-English, non-ASCII languages in UTF-8 encoding. To enter non-ASCII languages in UTF-8 encoding, you must configure Windows with the correct locale setting and have the required fonts installed. Use the Regional and Language Options control panel to configure your system and install files required for complex script or East Asian languages. If you want to type in text directly, you also need to install an appropriate keyboard; otherwise, you can use a text editor that supports the language's characters and copy and paste text from a document that contains the text you want to use.
You can also enter non-ASCII languages into SSL VPN Bookmarks objects.
•Configure translation tables on the ASA device to support the languages you want to make available—To enable the security appliance to provide language translation for the portal and screens displayed to users, you must define the necessary languages in a translation table and import the table into the security appliance. The software image package for the security appliance includes a translation table template. Every language you list in an SSL VPN Customization object must have a corresponding translation table on the device. Conversely, translation tables for languages that are not listed in the SSL VPN Customization object are ignored.
If you use this technique, you must use the ASA CLI or ASDM to configure and upload the translation tables. You cannot manage the translation tables with Security Manager. However, the SSL VPN Customization object includes settings that allow you to configure automatic browser language selection and to enable users to select their desired language. Thus, if you install translation tables for ten languages, the pages defined in the SSL VPN Customization object will be available to users in all of those languages. For more information on these settings, see SSL VPN Customization Dialog Box—Language, page F-166.
Although both of the following features require translation tables, they are separate and complementary:
–Automatic Browser Language Selection—Automatic browser language selection attempts to select the appropriate language based on the user's browser settings. This technique does not ask for user input. In the SSL VPN Customization object, you create a list of languages that will be used in the negotiation with the browser. During a connection, the security appliance receives a list of languages (and their priorities) from the browser, and looks through your list of languages top to bottom until a match is found. If there is no match, then the language you defined in the list as the default language is used. If you do not specify a default language, English is used.
The languages on the security appliance are labels for the translation tables. The languages must mirror those of the browser, and can consist of groups of up to 8 alphanumeric characters (starting from alpha characters), separated by hyphens. For example, fr-FR-paris-univ8. However, when you add a language to the list in Security Manager, only the first two characters are available.
When looking for a match, the security appliance starts with the longest language name, and if it does not match, it discards the rightmost group of the name. For example, if the preferred language on the browser is fr-FR-paris-univ8, and the security appliance supports fr-FR-paris-univ8, fr-FR-paris, fr-FR, and fr, it matches fr-FR-paris-univ8 and uses the translated strings from that translation table. If fr is the only language on the security appliance, the security appliance considers it a match also, and uses that translation table.
For more information about setting up translation tables, see the user documentation for the ASA device and operating system or the ASDM online help.
–Language Selector—By enabling the language selector, you provide the user with the ability to actively select the desired language from a list of languages that you support. This technique does not rely on the browser language settings being configured correctly. The language selector is displayed on the logon page.
Related Topics
•Configuring ASA Portal Appearance Using SSL VPN Customization Objects
•Add and Edit SSL VPN Customization Dialog Boxes, page F-163
You can create your own custom SSL VPN Logon page rather than use the page provided by the security appliance for browser-based clientless SSL VPNs. This is called full customization, and replaces the settings you can configure in the SSL VPN Customization policy object.
To provide your own Logon page, you must create the page, copy it to the Security Manager server, and identify the page on the Full Customization page of the SSL VPN Customization object dialog box. For information on creating SSL VPN Customization objects, see Configuring ASA Portal Appearance Using SSL VPN Customization Objects.
When you enable full customization, all other settings for the Logon page configured in the policy object are ignored. When you deploy your configuration to the ASA device, Security Manager copies your custom page to the device.
The Logon page you create must include all of the HTML code required to present the page correctly, and include special Cisco HTML code that provides the functions for the login form and the Language Selector drop-down list. Keep the following in mind when you create the HTML file:
•The file extension must be .inc.
•All images in the custom Logon page must be present on the security appliance. Replace the file path with the keyword /+CSCOU+/, which is an internal directory on the ASA device. When you upload an image to the device, it is saved in this directory.
•Use the csco_ShowLoginForm('lform') Javascript function to add the login form to the page. This form prompts for the username, passwords, and group information. You must include this function somewhere on the page.
•Use the csco_ShowLanguageSelector('selector') Javascript function to add the Language Selector drop-down list to the page. You do not have to use this function if you are not supporting the use of more than one language.
Related Topics
•Configuring ASA Portal Appearance Using SSL VPN Customization Objects
•Add and Edit SSL VPN Customization Dialog Boxes, page F-163
•SSL VPN Customization Dialog Box—Full Customization, page F-170
When you configure a browser-based clientless SSL VPN, you can define a list of bookmarks, or URLS, to include on the SSL VPN portal page. Use SSL VPN bookmarks policy objects to define bookmark lists.
You can create SSL VPN bookmark objects for SSL VPNs hosted on IOS devices or ASA devices. However, these device types allow different bookmark configurations, the ASA device allowing more configuration options than IOS devices. Besides allowing more configuration options, you can also create bookmarks for ASA devices in non-English, non-ASCII languages. For more information on localizing the bookmarks and portal for ASA devices, see Localizing SSL VPN Web Pages for ASA Devices.
After you create the SSL VPN bookmark object as described in this procedure, you can use the object to specify the bookmark object in the Portal Web Pages or Bookmarks fields in these policies:
•ASA devices—On the SSL VPN > Clientless page in an ASA group policy object (see ASA Group Policies SSL VPN Clientless Settings, page F-33), which you then select in one of these policies:
–Remote Access VPN > Group Policies
–Remote Access VPN > Connection Profiles on the General tab
•ASA devices—In the Remote Access VPN > Dynamic Access policy, you can specify the SSL VPN bookmark object on the Main > Bookmarks tab (see Main Tab, page H-39).
•IOS devices—On the Clientless page in a user group policy object configured for SSL VPN (see User Group Dialog Box—Clientless Settings, page F-197), which you then select in the Remote Access VPN > SSL VPN policy on the General tab.
Related Topics
•Creating Group Policies (ASA), page 10-30
•Configuring Dynamic Access Policies, page 10-18
•Understanding Connection Profiles (ASA), page 10-16
•Configuring an SSL VPN Policy (IOS), page 10-58
•Policy Object Manager Window, page F-1
Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).
Tip You can also create SSL VPN bookmark objects when you define policies or objects that use this object type. For more information, see Selecting Objects for Policies.
Step 2 Select SSL VPN Bookmarks from the Object Type selector. The SSL VPN Bookmarks page opens, displaying a list of the existing SSL VPN bookmark objects.
Step 3 Right-click in the work area, then select New Object.
The Add SSL VPN Bookmark dialog box appears (see Add or Edit Bookmarks Dialog Boxes, page F-159).
Step 4 Enter a name for the object and optionally a description of the object.
Step 5 If you are creating the object for an SSL VPN hosted on an IOS device, you can enter a name for the heading that is displayed above the bookmarks list in the Bookmarks Heading (IOS) field.
Step 6 The Bookmarks table displays any URLs that are defined for the object. To add a bookmark, click the Add Row button below the table; to edit an existing bookmark, select it and click the Edit Row button.
The Add/Edit SSL VPN Bookmark Entry dialog box opens. For more information about the fields on this dialog box, see Add and Edit Bookmark Entry Dialog Boxes, page F-161.
•In the Bookmark Option field, select whether you are defining a bookmark (Enter Bookmark) or adding bookmarks from another SSL VPN bookmark object (Include Existing Bookmarks). If you are including an existing object, enter the object's name or click Select to select it from a list of existing objects.
•If you are creating the object for use on an IOS device, enter the title of the bookmark, which is displayed to users, and the URL. Be careful to select the correct protocol for the URL. Click OK to add the bookmark to the table of bookmarks.
•If you are creating the object for use on an ASA device, you have many more options. Besides the title and the URL, you can define a subtitle and image icon for the bookmark plus other options.
Tip If you choose the protocols RDP, SSH, Telnet, VNC, or ICA, you must configure the plug-in for the protocol in the Remote Access VPN > SSL VPN > Other Settings policy (see SSL VPN Other Settings Page, page H-97).
You can also configure the bookmark to use the Post method rather than the Get method. If you use Post, you must configure the post parameters by clicking Add Row beneath the Post Parameters table. For more information on Post parameters, see these topics:
–Using the Post URL Method and Macro Substitutions in SSL VPN Bookmarks
–Add and Edit Post Parameter Dialog Boxes, page F-162
Click OK to add the bookmark to the table of bookmarks.
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 Policy Object to Be Overridden.
Step 9 Click OK to save the object.
One of the options you have for configuring bookmarks on an SSL VPN hosted on an ASA device is the method used by a URL, either Get or Post. The Get method is the standard method; a user clicks the URL and is taken to the web page. The Post method is useful when processing the data might involve changes to it, for example, storing or updating data, ordering a product, or sending e-mail.
If you choose the Post URL method, you must configure Post parameters for bookmark entries. Because these are often personalized resources that contain the user ID and password or other input parameters, you might need to define clientless SSL VPN macro substitutions.
Clientless SSL VPN macro substitutions let you configure users for access to personalized resources that contain the user ID and password or other input parameters. Examples of such resources include bookmark entries, URL lists, and file shares.
Note For security reasons, password substitutions are disabled for file access URLs (cifs://). Also for security reasons, use caution when introducing password substitutions for web links, especially for non-SSL instances.
You can use the following macro substitutions:
•Logon Information Substitutions— The security appliance obtains values for these substitutions from the SSL VPN Logon page. It recognizes these strings in user requests, and replaces them with the value specific to the user before it passes the request on to a remote server.
These are the available macro substitutions:
–CSCO_WEBVPN_USERNAME
The username used to log into the SSL VPN.
–CSCO_WEBVPN_PASSWORD
The password used to log into the SSL VPN.
–CSCO_WEBVPN_INTERNAL_PASSWORD
The internal resource password entered when logging into the SSL VPN.
–CSCO_WEBVPN_CONNECTION_PROFILE
The connection profile associated with the user group selected when logging into the SSL VPN.
For example, if a URL list contains the link http://someserver/homepage/CSCO_WEBVPN_USERNAME.html, the security appliance translates it to the following unique links:
–For USER1 the link becomes http://someserver/homepage/USER1.html
–For USER2 the link is http://someserver/homepage/USER2.html
In the following example, cifs://server/users/CSCO_WEBVPN_USERNAME lets the security appliance map a file drive to specific users:
–For USER1 the link becomes cifs://server/users/USER1
–For USER2 the link is cifs://server/users/USER2
•RADIUS/LDAP Vendor-Specific Attributes (VSAs)—These substitutions let you set substitutions configured on either a RADIUS or an LDAP server. These are the available macro substitutions:
–CSCO_WEBVPN_MACRO1
–CSCO_WEBVPN_MACRO2
For information on configuring bookmarks, see Configuring SSL VPN Bookmark Lists for ASA and IOS Devices.
A smart tunnel is a connection between an application running on a user's workstation and a private site. The connection uses a clientless (browser-based) SSL VPN session with the security appliance as the pathway and proxy server. Smart tunnels do not require the user to connect the application to the local port, so the application can gain access to the network without giving the user administrative privileges, as is required for full tunnel support. If you do not otherwise configure the network to allow access to an application, you can create a smart tunnel for those applications that you want to support.
You can configure smart tunnel access to an application under the following conditions:
•The application is a Winsock 2, TCP-based application and there is a browser plug-in for the application. Cisco distributes plug-ins for some applications for use in clientless SSL VPN, including SSH (for both SSH and Telnet sessions), RDP, and VNC. You must supply or obtain plug-ins for any other applications. Configure plug-ins in the Remote Access VPN > SSL VPN > Other Settings policy on the Plug-Ins tab.
•The user's workstation is running a 32-bit version of Microsoft Windows Vista, Windows XP, or Windows 2000.
Users of Microsoft Windows Vista who use smart tunnels (or port forwarding) must add the URL of the ASA device to the Trusted Site zone. Configure the Trusted Site zone in Internet Explorer (Tools > Internet Options, Security tab).
•The user's browser must be enabled with Java, Microsoft ActiveX, or both.
•If the user's workstation requires a proxy server to reach the security appliance, the URL of the terminating end of the connection must be in the list of URLs excluded from proxy services. In this configuration, smart tunnels support only basic authentication.
Tip A stateful failover does not retain smart tunnel connections. Users must reconnect following a failover.
You configure smart tunnel access for an application by creating an SSL VPN smart tunnel list policy object and including that object in an ASA group policy object. You then assign the ASA group policy object to a device in the Remote Access VPN > Group Policies policy.
Related Topics
•Understanding Group Policies (ASA), page 10-29
•Policy Object Manager Window, page F-1
Step 1 Create an SSL VPN smart tunnel list policy object:
a. Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1), and select SSL VPN Smart Tunnel Lists from the table of contents.
Tip You can also create SSL VPN smart tunnel list objects when you create or edit the ASA group policy object. For more information, see Selecting Objects for Policies.
b. Click the Add Object button to open the Add and Edit Smart Tunnel List Dialog Boxes, page F-177.
c. Enter a name for the object, up to 64 characters.
d. Add the applications to which you are granting smart tunnel access to the table of applications (click the Add Row button to open the Add and Edit A Smart Tunnel Entry Dialog Boxes, page F-179). Consider the following:
•Enter an application name that is easy to understand and include version numbers if you support more than one version. For example, Microsoft Outlook.
•For the application path, the simplest and easiest to maintain option is to enter only the filename, for example, outlook.exe. This allows the user to install the application in any folder. Enter the full path if you want to enforce a specific installation structure.
•Hash values are optional, but you can use them to prevent spoofing. Without hash values, a user can rename an application to a supported filename; the security appliance checks only the filename and path (if specified). However, if you enter hash values, you must maintain them as users apply patches or application upgrades. For specific information on determining hash values, see Add and Edit A Smart Tunnel Entry Dialog Boxes, page F-179.
Click OK to save the entry.
e. You can also incorporate other SSL VPN smart list objects into the object. This allows you to create a core set of smart list objects that you can use repeatedly in other objects.
f. Click OK to save the object.
Step 2 Configure the ASA group policy object to use the SSL VPN smart tunnel list object:
a. Edit (or create) the ASA group policy object either from the Policy Object Manager Window, page F-1 or the Remote Access VPN > Group Policies policy. The object must be configured to support SSL VPNs. (You can also edit these objects from the Remote Access VPN > Connection Profiles policy from an individual profile, or the Connection Profiles policy for an
EasyVPN topology.)
b. Select the SSL VPN > Clientless folder from the table of contents to open ASA Group Policies SSL VPN Clientless Settings, page F-33.
c. Enter the name of the SSL VPN smart tunnel list object in the Smart Tunnel field.
d. Select Auto Start Smart Tunnel to automatically start smart tunnels for the applications when the user connects to the SSL VPN portal.
If you do not select this option, users must start smart tunnel access using the Application Access > Start Smart Tunnels button on the clientless SSL VPN portal page.
Clientless SSL VPN uses WINS and the Common Internet File System (CIFS) protocol to access or share files, printers, and other machine resources on remote systems. The ASA or IOS device uses a proxy CIFS client to provide this access transparently; users appear to have direct access to the file systems (subject to individual file and user permissions).
When users attempt a file-sharing connection to a Windows computer by using its computer name, the file server they specify corresponds to a specific WINS name that identifies a resource on the network. The security appliance queries WINS or NetBIOS name servers to map WINS names to IP addresses. SSL VPN requires NetBIOS to access or share files on remote systems.
You use WINS server list policy objects to configure the list of WINS servers that are used to resolve these Microsoft file-directory share names. The WINS server list objects define the NetBIOS Name Service (NBNS) server list on the device (using the nbns-list and nbns-server commands) for Common Internet File System (CIFS) name resolution.
After creating the WINS server list policy object, you can configure it in the following policies and policy objects, and also select the file access services that you want to allow:
•ASA devices—In the Remote Access VPN > Connection Profiles policy, specify the WINS server list object on the SSL tab (see SSL Tab (ASA), page H-32).
Select the file access options on the SSL VPN > Clientless page in an ASA group policy object (see ASA Group Policies SSL VPN Clientless Settings, page F-33), which you then select in one of these policies:
–Remote Access VPN > Group Policies
–Remote Access VPN > Connection Profiles on the General tab
•IOS devices—On the Clientless page in a user group policy object configured for SSL VPN (see User Group Dialog Box—Clientless Settings, page F-197), which you then select in the Remote Access VPN > SSL VPN policy on the General tab.
Related Topics
Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager Window, page F-1.
Tip You can also create WINS server list objects when defining policies or objects that use this object type. For more information, see Selecting Objects for Policies.
Step 2 Select WINS Server Lists from the Object Type selector.
The WINS Server List page opens, displaying the currently defined WINS server list objects.
Step 3 Right-click in the work area and select New Object to open the Add or Edit WINS Server List Dialog Box, page F-203.
Step 4 Enter a name for the object and optionally a description of the object.
Step 5 Click the Add Row button below the table, or select a server in the table and click Edit Row, to configure the WINS servers defined in the object. Configure these settings:
•Server—The IP address of the WINS server. You can select a network/host object or enter the address directly.
•Set as Master Browser—Select this option if the server is a master browser, which maintains the list of computers and shared resources.
Other fields are optional; change them if you want non-default values. For more information, see Add or Edit WINS Server Dialog Box, page F-204.
Click OK to save your changes.
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 Policy Object to Be Overridden.
Step 8 Click OK to save the object.
You can create an SSL VPN Gateway object to use when you are configuring an SSL VPN connection on your VPN gateway (server) device. For more information, see Gateway and Context Page (IOS), page H-10.
An SSL VPN gateway acts as a proxy for connections to protected resources, which are accessed through an SSL-encrypted connection between the gateway and a web-enabled browser on a remote device.
An SSL VPN gateway object includes parameters that enable the gateway to be used as a proxy for connections to the protected resources in your SSL VPN. These parameters include the gateway's IP address, the port that will carry HTTPS traffic, and the digital certificate required to establish a secure connection.
Tip You can also create SSL VPN Gateway objects when defining policies or objects that use this object type. For more information, see Selecting Objects for Policies.
Related Topics
•Gateway and Context Page (IOS), page H-10
•Policy Object Manager Window, page F-1
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 SSL VPN Gateways.
The SSL VPN Gateways page opens, displaying any currently defined SSL VPN Gateway objects.
Step 3 Right-click inside the work area, then select New Object.
The Add SSL VPN Gateway dialog box appears. For a description of the elements in this dialog box, see Add or Edit SSL VPN Gateway Dialog Box, page F-176.
Step 4 Enter a name for the object and optionally a description of the object.
Step 5 Specify the IP address used to configure the gateway object. Choose either the public static IP address of the router interface or the router's public static IP address.
Step 6 Specify the port that will carry the HTTPS traffic.
Step 7 Specify the trustpoint (digital certificate) required to establish the secure connection.
Note A self-signed certificate is generated when an SSL VPN gateway is activated.
Step 8 Select Enable Gateway to activate the SSL VPN gateway.
Step 9 Select Specify SSL Encryption Algorithms to specify the encryption algorithms that the SSL protocol uses for the SSL VPN connections. Then select up to three algorithms, in order of preference, from the lists provided.
Step 10 Select Redirect HTTP Traffic to configure the gateway to redirect HTTP traffic over secure HTTP (HTTPS), then specify the port number over which the HTTP traffic will be redirected in the field provided.
Step 11 Select whether and how to obtain the hostname.
Step 12 (Optional) Under Category, select a category to help you identify this object in the Objects table. See Using Category Objects.
Step 13 (Optional) Select Allow Value Override per Device to allow the properties of this object to be redefined on individual devices. See Allowing a Policy Object to Be Overridden.
Step 14 Click OK to save the object.
You can create a text object if you need textual data to be referenced and acted upon by another policy object that accepts text objects.
Text objects are a type of policy object variable. They are a name and value pair, where the value can be a single string, a list of strings, or a table of strings. Their flexibility allows you to enter any type of textual data to be referenced and acted upon by FlexConfigs.
Tip You can also create text objects when defining policies or objects that use this object type. For more information, see Selecting Objects for Policies.
Related Topics
•Chapter 18, "Managing FlexConfigs"
Step 1 Select Tools > Policy Object Manager to open the Policy Object Manager (see Policy Object Manager Window, page F-1).
Step 2 Select Text Objects from the Object Type selector.
Step 3 Right-click inside the work area and click New Object.
The Add Text Object dialog box appears (see Add or Edit Text Object Dialog Box, page F-181).
Step 4 Enter a name for the object and optionally a description of the object.
Step 5 Enter the object data. You can create a simple single-value variable, a list of variables (by selecting Dimension 1) or a table or variables (by selecting Dimension 2). After you create the desired grid by selecting the dimension and if applicable, the number of rows and columns, enter the data into each cell by first clicking in the cell.
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 Policy Object to Be Overridden.
Step 8 Click OK to save the object.
You can create time range objects for use when creating time-based ACLs and some firewall rules. While similar to extended ACLs in function, time-based ACLs allow for access control based on time considerations. The time range applies to specific rules, and makes those rules active for the specific time period defined in the range. For example, you can implement a rule for typical work hours to allow or prevent certain types of access.
You can also use time range objects when defining ASA user groups to restrict VPN access to specific times during the week. For more information, see Creating ASA User Group Objects.
Time range objects can rely on the device's system clock, but they work best when using Network Time Protocol (NTP) synchronization.
Tip You can also create time range objects when defining policies or objects that use this object type. For more information, see Selecting Objects for Policies.
Related Topics
Step 1 Select Tools > Policy Object Manager to open the see Policy Object Manager Window, page F-1.
Step 2 Select Time Ranges from the Object Type selector.
Step 3 Right-click in the work area, then select New Object.
The Time Range dialog box appears (see Add or Edit Time Range Dialog Box, page F-182).
Step 4 Enter a name for the object and optionally a description of the object.
Step 5 Define an overall start and end time. You can either have the time range take effect immediately upon deployment or define a specific date and time as the start time. You can either define no end date, or end the range on a specific date.
Step 6 If you want the time range to apply to a recurring time period within the overall start and end date, add the desired recurring ranges. For example, you can define the typical weekly work hours for your organization.
•To add a range, click the New Recurring Range button and fill in the Recurring Ranges Dialog Box, page F-183.
•To edit a range, select it and click the Edit Recurring Range button.
•To delete a range, select it and click the Delete Recurring Range button.
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.
Traffic flows objects map to class maps (the class map command) in the IPS, QoS and Connection Rules service policy for PIX, ASA, and FWSM devices to configure network policies on devices. Traffic flow objects are used with devices running the PIX 7.0+, ASA 7.0+, and FWSM 3.2+ operating systems. For more information on configuring the policy, see Configuring Service Policy Rules on Firewall Devices, page 14-79.
Related Topics
•Default Inspection Traffic, page F-186
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 Traffic Flow.
The Traffic Flow page appears.
Step 3 Right-click inside the work area, then select New Object.
The Add Traffic Flow dialog box appears.
Step 4 Enter a name for the object and optionally a description of the object.
Step 5 Select the traffic match type from the list, then enter the appropriate values. The dialog box values vary based on your selection. For detailed information on the fields, see Add and Edit Traffic Flow Dialog Boxes, page F-184.
The traffic match options are:
•Any traffic.
•Source and destination IP address (uses access lists). Select the desired ACL object.
•Default inspection traffic.
•Default inspection traffic with access list. Select the desired ACL object.
•TCP or UDP destination port. Enter the desired port or port range (0-65535).
•RTP range. Enter the desired port range within 2000-65535.
•Tunnel group. Enter the name of the tunnel group and decide whether to base it on the destination address.
•IP precedence bits. Select up to 4 values.
•IP DiffServe Code Points (DSCP) values. Select up to 8 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 Click OK to save the object.
User group objects are used in Easy VPN topologies, remote access VPNs, and SSL VPNs.
When you configure a remote access VPN, SSL VPN, or Easy VPN server, you can create user groups to which remote clients belong. The remote clients must be configured with the same group name as the user group on the VPN server in order to connect to the server; otherwise, no connection is established. When the remote client connects to the VPN server successfully, the group policies for that particular user group are pushed to all remote clients belonging to the user group.
For more information about user groups, see:
•Understanding User Group Policies (IOS), page 10-41
•Configuring User Group Policies, page 10-42
•Configuring a User Group Policy for Easy VPN, page 9-77
•Configuring an SSL VPN Policy (IOS), page 10-58
Note You must select the technology (Easy VPN/Remote Access VPN, or SSL VPN) for which you are creating the user group object. If you are editing an existing 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 User Group objects when defining policies or objects that use this object type. For more information, see Selecting Objects for Policies.
Related Topics
•Policy Object Manager Window, page F-1
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 User Groups.
The User Groups page opens, displaying the currently defined user group objects.
Step 3 From the work area, right-click inside the table, then select New Object.
The User Group dialog box opens, displaying a list of settings that you can configure for the user group. For a description of the elements on this dialog box, see Add or Edit User Group Dialog Box, page F-187.
Step 4 Enter a name for the object and optionally a description of the object.
Step 5 Specify a name for the user group. You should configure the same user group name within the remote client or device to ensure that the appropriate group attributes are downloaded.
Step 6 If you opened the User Group dialog box from the Policy Object Manager window, select the type of technology for which you are creating the user group object— Easy VPN/Remote Access VPN
or SSL VPN.
Note If you opened the dialog box from the Site-to-site VPN Manager, or the Remote Access VPN or SSL VPN folder in the Device View, the technology is already selected, and you cannot edit it.
Depending on the selected technology, the appropriate settings are displayed in the Settings pane for configuration, as described in the following steps.
Step 7 To configure the user group for an Easy VPN or remote access VPN, from the Settings pane:
a. Select General to configure general settings for your user group policy, including the authentication method, IP address pool information, and connection attributes for PIX Firewalls. For a description of the elements required to configure these settings, see User Group Dialog Box—General Settings, page F-189.
b. Select DNS/WINS to define the DNS and WINS servers and the domain name that should be pushed to clients associated with the user group. For a description of the elements required to configure these settings, see User Group Dialog Box—DNS/WINS Settings, page F-190.
c. Select Split Tunneling to configuring split tunneling for your user group. For a description of the elements required to configure split tunneling, see User Group Dialog Box—Split Tunneling, page F-191.
d. Select Client Settings (IOS) to define Cisco IOS specific options for your user group, including firewall settings for VPN clients. For a description of the elements required to configure these settings, see User Group Dialog Box—IOS Client Settings, page F-192.
e. Select Xauth Options (IOS) to configure IKE Extended Authentication (Xauth) user authentication and connection parameters for the user group, including the banner text. For a description of the elements required to configure these settings, see User Group Dialog Box—IOS Xauth Options, page F-194.
f. Select Client VPN Software Update (IOS) to configure, for an IOS VPN client, the platform type, VPN Client revisions, and image URL for each client VPN software package installed, for your user group. For a description of the elements required to configure these settings, see User Group Dialog Box—IOS Client VPN Software Update, page F-195.
g. Select Advanced Options (PIX) to configure options specifically for PIX Firewalls in your user group. For a description of the elements required to configure these options, see User Group Dialog Box—Advanced PIX Options, page F-196.
Step 8 To configure the user group for an SSL VPN, from the Settings pane:
a. Select Clientless to configure the Clientless mode of access to the corporate network in an SSL VPN, for your user group. For a description of the elements required to configure the Clientless mode, see User Group Dialog Box—Clientless Settings, page F-197.
b. Select Thin Client to configure the Thin Client settings that enable the Thin Client mode of access to the corporate network in an SSL VPN, for your user group. For a description of the elements required to configure the Thin Client mode, see User Group Dialog Box—Thin Client Settings, page F-198.
c. Select Settings from the Full Tunnel folder to configure Full Tunnel settings that enable the Full Tunnel mode of access to the corporate network in an SSL VPN, for your user group. For a description of the elements required to configure the Full Tunnel settings, see User Group Dialog Box—SSL VPN Full Tunnel Settings, page F-198.
d. Select DNS/WINS from the Full Tunnel folder to define the DNS and WINS servers for the user group in an SSL VPN. For a description of the elements required to configure these settings, see Table F-135 on page F-191.
e. Select Split Tunneling from the Full Tunnel folder to configure split tunneling for your user group in an SSL VPN. For a description of the elements required to configure split tunneling, see User Group Dialog Box—SSL VPN Split Tunneling, page F-200.
f. Select Browser Proxy Settings from the Full Tunnel folder to configure the browser proxy settings for your user group in an SSL VPN. For a description of the elements required to these settings, see User Group Dialog Box—Browser Proxy Settings, page F-201.
g. Select Connection Settings to configure the SSL VPN connection settings for the user group. For a description of the elements required to configure the connection settings, see User Group Dialog Box—SSL VPN Connection Settings, page F-202.
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.
Object groups are a feature of ASA, PIX, and FWSM devices that enable you reduce the size of access rules by grouping objects such as IP hosts, networks, protocols, ports, and ICMP message types. Although the functionality of object groups is similar to the functionality of policy objects in Security Manager, there are several important differences in implementation.
As a result, when deploying policies to a device, it is not always possible to create object groups that are an exact copy of the policy objects that you configured in Security Manager. To take one example, policy object names are unique per object type in Security Manager (that is, you can define a network/host object and a service object with the same name); ASA/PIX/FWSM object groups of all types, however, share a single naming scheme. Therefore, if you deploy a network/host object whose name matches an existing service object group on the device, a suffix is added to the name of the network/host object to distinguish it from the service object group.
Note For information about the options available when deploying object groups, see Deployment Page, page A-7.
Similarly, when discovering policies on a device, it is not always possible to create policy objects that are an exact copy of the object groups that are configured on the device. However, Security Manager preserves as much of the original configuration as possible.
The following sections describe the changes that are made when provisioning policy objects to ASA/PIX/FWSM object groups, or when creating the policy objects when discovering policies on these devices:
•How Service Objects are Provisioned as ASA/PIX/FWSM Object Groups
In most cases, network/host, port list, and service objects can be provisioned as object groups without changing the object name. Table 8-9 describes how object names are changed when the names cannot be converted directly to object groups on PIX/ASA devices.
Note The predefined network/host object any is not provisioned as an object group.
Related Topics
•Understanding Network/Host Objects
•Understanding and Specifying Services and Service and Port List Objects
•How Service Objects are Provisioned as ASA/PIX/FWSM Object Groups
•How Policy Objects are Provisioned as ASA/PIX/FWSM Object Groups
Table 8-10 describes how Security Manager creates object groups when deploying service objects to ASA/PIX/FWSM devices.
Related Topics
•Understanding and Specifying Services and Service and Port List Objects
•How Policy Objects are Provisioned as ASA/PIX/FWSM Object Groups