-
User Guide for Cisco Security Manager 3.0.1
-
Preface
-
Getting to Know Security Manager
-
Performing Administrative Tasks
-
Working With the Security Manager User Interface
-
Using Map View
-
Managing Devices
-
Managing Policies
-
Managing Activities
-
Managing Objects
-
Managing Site-to-Site VPNs
-
Managing Remote Access VPNs
-
Managing Firewall Services
-
Managing Routers
-
Managing Firewall Devices
-
Using the Catalyst 6500/7600 Device Manager
-
Managing Deployment
-
Managing FlexConfigs
-
Using Tools
-
Devices User Interface Reference
-
Site-to-Site VPN User Interface Reference
-
Policy User Interface Reference
-
Map View User Interface Reference
-
Tools User Interface Reference
-
Administrative Settings User Interface Reference
-
Activities User Interface Reference
-
Deployment User Interface Reference
-
Index
-
Table Of Contents
How Access Rules Are Recognized on Devices
Important Notes About Access Rules
Enabling and Disabling Access Rules
Cutting, Copying, and Pasting Access Rules
Moving Access Rules Up and Down
Generating Policy Query Reports
Understanding Policy Query Results
Understanding Analysis Reports
Understanding Hit Count Results
Changing How Hit Count Results Are Displayed
Viewing Complete or Partial Details
Understanding Settings for Access Controls
Object Group Search (PIX/ASA/FWSM)
Enabling Object Group Search (PIX/ASA/FWSM)
Per User Downloadable ACLs (PIX/ASA/FWSM)
Enabling Per User Downloadable ACLs (PIX/ASA/FWSM)
Enabling Access List Compilation (PIX)
Configuring Settings for Access Control
Configuring Firewall ACL Settings
Understanding Inspection Rules
Configuring Default Protocol Ports
Configuring Custom Destination Ports
Configuring Destination Address and Port (IOS)
Configuring Source and Destination Address and Port (ASA, FWSM 3.x)
Enabling and Disabling Inspection Rules
Cutting, Copying, and Pasting Inspection Rules
Moving Inspection Rules Up and Down
Configuring Settings for Inspection Rules
Supported Features for Inspection
Enabling and Disabling AAA Rules
Cutting, Copying, and Pasting AAA Rules
Configuring Settings for AAA Firewall (PIX/ASA/FWSM)
Using MAC Exempt Address Lists
Adding MAC Exempt Address Lists
Editing MAC Exempt Address Lists
Deleting MAC Exempt Address Lists
Configuring Settings for AAA (IOS)
Understanding Web Filter Rules
Adding Web Filter Rules (ASA/FWSM/PIX)
Editing Web Filter Rules (ASA/FWSM/PIX)
Enabling and Disabling Web Filter Rules (ASA/FWSM/PIX)
Cutting, Copying, and Pasting Web Filter Rules (ASA/FWSM/PIX)
Moving Web Filter Rules Up and Down (ASA/FWSM/PIX)
Deleting Web Filter Rules (ASA/FWSM/PIX)
Editing Web Filter Rules (IOS)
Deleting Web Filter Rules (IOS)
Adding Exclusive Domains (IOS)
Editing Exclusive Domains (IOS)
Deleting Exclusive Domains (IOS)
Configuring Settings for Web Filter Servers
Adding Settings for Web Filter Server Configuration
Editing Settings for Web Filter Server Configuration
Deleting Settings for Web Filter Server Configuration
Working with Transparent Firewall Rules
Enabling and Disabling Transparent Rules
Cutting, Copying, and Pasting Transparent Rules
Moving Transparent Rules Up and Down
Configuring Settings for Transparent Rules
Managing Firewall Services
Firewall Services manages firewall-related policies in Security Manager that apply to the adaptive security appliance (ASA), PIX Firewall (PIX), Firewall Services Module (FWSM) installed in a Catalyst 6500/7600 device, and security routers running Cisco IOS (IOS).
Each firewall policy comprises a collection of rules. Firewall Services supports over 10,000 rules. The rules are loaded into rules tables incrementally, allowing you to scroll and view a partial rule set before the entire rule set is in memory. After rules are loaded the first time, they are retained in cache memory, so subsequent viewing of the rules tables is instantaneous. Cache memory is automatically cleared after an activity is approved or discarded, if a device is rediscovered, or when a policy is copied from another device. While rules are being loaded into tables, the action buttons on the page are grayed out until loading is complete; however, you can still make changes to the rules in the table during this process.
You can define firewall policies from "Device view," which enables you to configure local service policies on individual firewall devices and security appliances. You can then share these local policies with other devices. You can also define firewall policies from "Policy view," which enables you to define a general policy to assign to a set of devices or all devices. Policy view enables you to manage shared policies at the system level. For more information, see Chapter 1, "Managing Policies."
Firewall Services provides a uniform design for displaying firewall policy information for all supported platforms. This design is represented in the form of rules tables that are shown in the main work area. However, when configuring settings for firewall policies, the Settings selector differs depending upon the type of device selected. For example, an ASA security appliance displays pages for Access Control settings, AAA Firewall settings, Web Filter settings, and Transparent settings (if the appliance interface is configured in L2 mode), whereas an IOS device displays pages for Access Control settings, Inspection settings, AuthProxy settings, Transparent settings, and Web Filter settings.
Security Manager manages the following types of policies under Firewall Services:
•
Firewall rules—Permit or deny a packet based on source address, destination address, source interface, and service. For more information, see Working with Access Rules.
•
•
•
•
In addition to understanding the types of firewall policies that Security Manager supports, you need to understand the concept of policy inheritance. Inheritance refers to the capability of Security Manager to enforce hierarchical lists of first-match, rule-based policies such as access rules. Within the hierarchy, policies at a lower level in the hierarchy (called child policies) extend or override the properties of the policies that are directly above them in the hierarchy (called parent policies). Firewall policies can be inherited by a parent policy. Settings do not recognize inheritance. For more information, see Understanding Rule Inheritance, page 1-45.
Firewall policies have the following properties:
•
•
•
Note
•
•
•
•
Security Manager does not recognize out-of-band changes (rules and other changes entered directly to the device). If the device has several changes that you want recognized by Security Manager, you can right-click the device, then click Discover Policies on Device. Security Manager contacts the device and rediscovers the policies on it. If you are requesting to discover policies for the first time, you are prompted with a warning that all policies on the device will be overridden if you continue.
If permanent changes are entered directly to the device, you can be made aware of such changes by requesting that an error or warning is generated before you deploy updated configurations to the device.
•
•
For more information, see Deploying to a Device, page 1-11.
Note
Related Topics
•
•
•
How ACL Names Are Generated
An ACL is assigned a name, which requires no user intervention; however, user-defined ACL names can be retained in Security Manager. Note, however, that a relationship exists between name preservation, deployment time, and non-traffic interruption. For example, name preservation will have an effect on deployment time and traffic interruption. To retain user-defined ACL names, select Firewall > Settings > Access Control. For more information, see Configuring Settings for Access Control.
When the name for the ACL is generated by Firewall Services, the name is derived from the type of rule or platform being defined and certain configuration settings that make it unique. A group command is then generated that binds the defined rules to the ACL.
The naming conventions used for the rule types and platforms are:
•
–
–
Note
•
•
•
–
–
–
•
–
–
•
•
During deployment, sometimes a suffix ".n" (where n is an integer) might get added to an ACL name if the existing ACL cannot be edited in place. For example, if an ACL named acl_mdc_outside_10 already exists on the device, a new ACL with the name acl_mdc_outside_10.1 is created if you do not remove the old ACL before you deploy the new ACL.
Related Topics
Understanding Access Rules
Firewall policies rely on access rules as one method for defining network security policy; they control the traffic that flows through a firewall device and security appliance. Access rules comprise conditions and actions. A condition describes a traffic stream of packets. You define constraints on the source and destination device, the service (for example, protocols and ports), and the incoming interface. An action describes what should occur based on the conditions set. For example, if the packet stream meets all conditions as described and the action is set to permit traffic, the packets are sent to the destination device.
Access rules filter network traffic by controlling whether routed packets are forwarded or blocked at the firewall's interfaces. Each packet is examined to determine whether to forward or drop the packet based on criteria you specify.
Criteria could be the source address of the traffic, the destination address of the traffic, the upper-layer protocol, or other information. No authentication is required.
Access rules use the concept of access control lists (ACLs) to describe how an entire subnet or specific network host interacts with another to permit or deny a specific service, protocol, or both.
Access rules are grouped by the interface on which they are configured and enforced. Firewall Services sorts the rules by interface and uses the remaining information in the rule to create the access control entry (ACE) that is included in the ACL for that interface.
Access rules are recognized in the form of an ordered list, which is represented in a rules table. Rules are processed by a firewall device or security appliance from first to last, or first-match basis. When a rule matches the network traffic that a firewall device or security appliance is processing, the device or appliance uses that rule's action to decide if traffic is permitted. After finding a matching ACE, the device looks no further.
When you define an access rule, you are basically defining an ACE in an ACL. Each table row in the Access Rules table represents one ACE. An access rule can represent multiple ACEs if the definition contains multiple sources, destinations, and services. For platforms that support object grouping, each combination of source, destination, and source in a rule is mapped to a single ACE. For platforms that do not support object grouping, such as IOS devices, multiple ACEs are generated.
After you configure an ACE, you can view its command-line equivalent (access-list command) after the device configuration is generated. The access-list commands are then "bound" to an ACL using the access-group command.
Note
After you define access rules for Security Manager to manage, it is likely that the resulting ACLs will have ACEs that are either redundant or conflicting. Because a device uses the first-match method to evaluate ACLs, these extraneous entries do not cause a problem. However, to help you identify if conflicting rules exist, you can generate an analysis report from which you can determine if any ACEs should be changed. For more information, see Understanding Analysis Reports.
You might want to identify rules that use a particular policy object, or perhaps you simply want to remove extraneous entries to make your rules tables more manageable. You can compose a query that describes a set of packets. The results of the query identify all rules in the global policy that could affect the defined packets. Based on the results, you can add or delete rules as needed. For more information, see Understanding Policy Query.
You might want to know whether rules that are defined are used and how often. The Hit Count feature collects the number of times that traffic for a device is permitted or denied based on an access rule. For more information, see Understanding Hit Count.
Related Topics
•
How Access Rules Are Recognized on Devices
Devices managed by Security Manager use the Adaptive Security Algorithm (ASA, also referred to as "algorithm") to allow one-way (inside to outside) connections without an explicit configuration for each internal system and application. An example of the algorithm in action is FTP. The algorithm analyzes the contents of the FTP control channel to allow dynamic access to the correct FTP data channels. You can configure exceptions to this algorithm so that certain traffic can access your higher-security interfaces.
The algorithm is a stateful (fixed) approach to security. Every inbound packet is checked against the algorithm and against any connection-state information in memory. This approach is regarded in the industry as being far more secure than a stateless packet-screening approach.
Each interface on the device or appliance is associated with a list of ACEs that are associated with an ACL. An ACL is an ordered list of rules that describe how an entire subnet or specific network host interacts with another to permit or deny a specific service, protocol, or both.
Each ACE describes network traffic based on source IP address, destination IP address, protocol, and possibly ports. Each ACE has an action to permit or deny. When a packet arrives at the firewall device or security appliance, the device checks the ACL for the interface on which the packet has arrived. The device then evaluates the ACEs in the ACL, looking for the first one that matches the packet.
When the firewall device finds a matching ACE, the device performs the associated action either permitting the packet into the firewall device for further processing, or denying entry to the packet. After finding a matching ACE, the device looks no further. If no ACE matches the packet, the packet is denied. An exception to this rule is an IOS device, which permits inbound traffic by default. To deny traffic, an ACE must be assigned to the interface.
Related Topics
Important Notes About Access Rules
•
•
–
–
–
–
•
•
•
•
Related Topics
Working with Access Rules
When configuring access rules, you should:
1.
2.
From the Access Rules tables, you can generate reports to help you identify:
•
•
•
The following topics will help you work with access rules:
•
•
•
•
Logging Events for an ACE
Firewall Services provides the ability to log events on any specific ACE in the Access Rules tables. Statistics and logging are provided for each flow. A flow is defined by source interface, protocol, source IP address, source port, destination IP address, and destination port. The retained statistics are the number of traffic requests permitted and denied associated with a flow by an ACE over a specified period of time. You can configure the retained statistics for each ACE according to your own needs.
When you configure a rule in the Access Rules table, you can enable logging for each access rule, along with a specified syslog level and interval of time. To log events for an ACE, you must enable the ACL Syslog setting. For more information, see Adding Access Rules.
Related Topics
•
Adding Access Rules
This procedure assumes you are adding a rule from Device view. To add a rule from Policy view, see Creating a New Shared Policy, page 1-40, then complete this procedure. After you complete the procedure, you can share the global policy and assign devices to it. For more information, see Modifying Policy Assignments in Policy View, page 1-41.
Note
In the absence of an ACL:
•
•
•
•
Procedure
Step 1
Step 2
The Access Rules page appears. For a description of the GUI elements, see Access Rules Page, page A-635.
Step 3
The Add Firewall Rule dialog box appears. For a description of the GUI elements, see Add and Edit Firewall Rule Dialog Boxes, page A-639.
Step 4
Step 5
Step 6
•
The objects are moved to the selected column.
•
A popup window helps you define the object. After you complete the definition, the new object is listed in the selected column.
For more information, see:
•
•
Step 7
•
The objects are moved to the selected column.
•
A popup window helps you define the object. After you complete the definition, the new object is listed in the selected column.
For more information, see:
•
•
Step 8
•
The objects are moved to the selected column.
•
A popup window helps you define the services object. After you complete the definition, the new object is listed in the selected column.
For more information, see Working with Service Objects, page 1-181.
Step 9
•
The objects are moved to the selected column.
•
A popup window helps you define the interface role object. After you complete the definition, the new object is listed in the selected column.
For more information, see Working with Interface Role Objects, page 1-120.
Step 10
Step 11
Step 12
Step 13
a.
b.
Step 14
a.
b.
Note
Step 15
Step 16
Step 17
•
•
Step 18
•
•
A popup window helps you define the time range object. After you complete the definition, the new object is listed in the Time Range Selector.
For more information, see Working with Time Range Objects, page 1-217.
Step 19
•
•
•
Step 20
The Advanced dialog box closes and you return to the Add Access Rules dialog box.
Step 21
The Add Access Rule dialog box closes and you return to the Access Rules table with the rule information shown in the table.
Step 22
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
After you define policy settings in Device view, you can use it locally on the device, or share it with multiple devices. For more information, see Working with Shared Policies in Device View, page 1-22.
Note
Related Topics
•
•
•
•
Editing Access Rules
To facilitate the editing process, Firewall Services offers the ability to perform inline editing on access rules shown in the tables. Editing can be performed on a rule in its entirety or individual table cells.
You can edit rules in their entirety by double-clicking a rule number in the table, which opens the rule dialog box or wizard from which to make your changes. You can also right-click a rule number in the table, then select Edit Row. You can edit individual table cells by double-clicking a cell, which opens a dialog box specific to that table cell. You can also right-click a cell, then click the Edit function from the shortcut menu.
You can edit multiple rule entries by selecting multiple rules, then right-clicking a column. You can then Add or Edit a feature, which is applied to the selected column for all selected rows.
You can display a list of all source and destination addresses by clicking on a table cell or specific entry (subfield) within the table cell, then clicking one of the Show Contents options from the shortcut menu. The list shows flattened values of all levels of an address, network object, or interface role and sorts the results in ascending order on the IP address, then descending order on the mask.
You can display a list of all services and port information. The list shows flattened values of all levels of the Service and Port List objects and sorts the results on: protocol, destination port, and source port.
You can display each interface role type as a separate listing in the table if you are working from Policy view, or display actual interface names if you are working from Device view.
In addition to performing inline editing and displaying a flattened list of table cell contents, you can move rules up or down within a table; cut, copy, and paste rules from which to clone other rule entries; enable or disable defined rules; and delete rules from the table. These functions can be performed from shortcut menus or buttons located on the GUI page.
An inherited rule can be modified only inside the parent policy in which it was defined. It cannot be modified inside a child policy.
Note
•
•
•
•
This procedure assumes you are working from Device view.
Note
Procedure
Step 1
Step 2
The Access Rules page appears. For a description of GUI elements, see Access Rules Page, page A-635.
Step 3
•
The Edit Firewall Rule page appears, from which you can edit the rule in its entirety. Follow the procedure for adding an access rule.
•
•
–
–
•
–
–
•
•
•
•
•
•
Step 4
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
Related Topics
•
•
•
•
Enabling and Disabling Access Rules
This procedure assumes you are working from Device view.
Procedure
Step 1
Step 2
The Access Rules page appears. For a description of GUI elements, see Access Rules Page, page A-635.
Step 3
Step 4
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
Note
•
Related Topics
•
Generating Usage Reports
You might need to edit a policy object in the rules table. You can generate a usage report, which indicates whether objects are in use (referenced) by another object, policy, or device (in case of device override). Usage reports contain any references in your current activity, as well as references committed to the Security Manager database.
This procedure assumes you are working from Device view.
Procedure
Step 1
Step 2
The Access Rules page appears. For a description of the GUI elements, see Access Rules Page, page A-635.
Step 3
A usage report is generated for the object selected. For a description of the GUI elements, see Object Usage Window, page A-204.
Step 4
Related Topics
•
•
Cutting, Copying, and Pasting Access Rules
This procedure assumes you are working from Device view.
Procedure
Step 1
Step 2
The Access Rules page appears. For a description of GUI elements, see Access Rules Page, page A-635.
Step 3
Step 4
The rule is added to the table.
Step 5
Step 6
Step 7
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
Note
Related Topics
•
•
Moving Access Rules Up and Down
This procedure assumes you are working from Device view.
Procedure
Step 1
Step 2
The Access Rules page appears. For a description of GUI elements, see Access Rules Page, page A-635.
Step 3
The selected rule moves up or down one row within the table.
Tip
Step 4
Step 5
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
Note
Related Topics
•
Deleting Access Rules
This procedure assumes you are working from Device view.
Procedure
Step 1
Step 2
The Access Rules page appears. For a description of GUI elements, see Access Rules Page, page A-635.
Step 3
You are prompted to confirm the deletion the first time you delete a row and any additional time, unless you request not to be prompted.
Step 4
The rule is removed from the table.
Step 5
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
You can verify the deletion of the rule by viewing an audit report. To generate an audit report, select Tools > Audit Report.
Related Topics
•
•
Understanding Policy Query
You might want to know how many rules contain a particular network object or service before you create a new rule, or perhaps you want to clean up redundant rules, or identify and delete rules that have no effect on your network. You can compose a query that describes a set of packets. The results of the query identify all rules that could affect the defined packets. Based on the results, you can add or delete rules as needed.
Policy Query operates on the values of the conditions, for example, to show all rules that will impact a packet with a source in network 192.168.1.0/24. The query will return rules that have any in the source as well as a policy object (assuming the policy object contains some part of the 192.168.1.0/24 network).
The elements on which a query is based are:
•
•
•
•
•
Based on the device hierarchy, you have two approaches for determining how to base your query:
•
•
For a given table, the query is compared to each rule in the table. If an intersection between the query packet and the rule exists, the rule is added to the query results. Calculations are based on a tuplespace (source, destination, and service).
The query mechanism helps to debug how traffic is being processed by the rules. By doing a content match, you can see all rules that could have some affect on traffic. The query results are labeled by how the rule interacts with the query space.
Related Topics
•
•
Generating Policy Query Reports
You can generate a Policy Query report by clicking the Query button from any of the main firewall rules tables. The Query Report can be generated from either Device view or Policy view. This procedure assumes you are requesting a query from Device view.
Procedure
Step 1
The Querying Policy/Device dialog box appears.
Step 2
Step 3
Step 4
Step 5
•
The objects are moved to the selected column.
•
A popup window helps you define the object. After you complete the definition, the new object is listed in the selected column.
For more information, see:
•
•
Step 6
•
The objects are moved to the selected column.
•
A popup window helps you define the object. After you complete the definition, the new object is listed in the selected column.
For more information, see:
•
•
Step 7
•
The objects are moved to the selected column.
•
A popup window helps you define the object. After you complete the definition, the new object is listed in the selected column.
For more information, see Working with Interface Role Objects, page 1-120.
Step 8
•
The objects are moved to the selected column.
•
A popup window helps you define the object. After you complete the definition, the new object is listed in the selected column.
For more information, see Working with Service Objects, page 1-181.
The policy query results are displayed. For more information, see Understanding Policy Query Results.
Related Topics
•
•
Understanding Policy Query Results
Policy query results are based on the criteria of the initial query. The results are divided into sections. See Figure 1-1.
Figure 1-1 Policy Query Results
Query Parameters
The top portion of the report shows the query parameters. The left column lists the available options. The right column lists the selected options. You can edit your query by clicking Edit Query. Follow the procedure for Generating Policy Query Reports.
Results Table
The middle portion of the report shows a results table that displays query results based on the rule type selected from the list box. The results table displays the results for the rule type selected, for example, access rules. The results identify the following:
•
–
–
–
You might have two matching rules, A and B. Rule A appears in an ACL list before Rule B. Both rules have the same interface. Rule A's source address, destination address, and services are equivalent to, or contain, those of Rule B. Rule B is blocked by Rule A. Rule B has no effect.
You might have a global mandatory rule that permits a service, but the rule at the device level denies the service. Since rules are recognized on a first-match order, after discovering a match at the mandatory global scope, no other rules are checked. The conflict has no effect.
•
•
•
–
–
•
•
•
•
•
•
Details Table
The bottom portion of the report shows a details table. The details table shows greater detail for the parameters that matched the highlighted rule in the results table. If no match exists for a parameter, details remain blank. You select a folder to display details specific to a parameter.
•
–
–
–
–
Note
•
•
–
–
–
–
•
Example of Details Table Results
Consider the following:
Two Network Objects are defined in Security Manager:
•
•
You request a policy query using Network Object A as the source parameter. The results table shows rules that includes Network Object A as the source. The details table, however, will display the following:
Network Object A
contains
Network Object B [3.4.5.6]
Close the page after you view the contents.
Related Topics
•
•
Understanding Analysis Reports
The Analysis feature analyzes and reports rules that overlap or conflict with other rules. The analysis is performed using the rules defined for a selected device. Reports are provided for access rules only. For more information, see Generating Analysis Reports.
Certain conflicting rules might have no effect on a device after they are deployed; however, they create unnecessary clusters in the rules table. By detecting these rules, you can clean up the rule set and optimize performance.
Other conflicting rules, such as opposite rules, can create unwanted results to your network. By detecting these conflicting rules, you can implement your security needs as intended.
Some of the types of conflicts shown in the analysis report include:
•
•
–
–
–
–
Table 1-1 Opposite Rules
my-PC
Mail-Servers
smtp-25
Permit
my-PC
Mail-Servers
smtp-25
Deny
Table 1-2 Opposite Rules
my-PC
any
smtp-25
Permit
my-PC
1.2.3.4
smtp-25
Deny
Table 1-3 Lower Rule Never Used
PC-subnet (192.168.101.0/24
Print-Server
lpr-515
Permit
my-PC (192.168.101.50)
Print-Server
lpr-515
Deny
Table 1-4 First Rule Contained In Second Rule
PC-subnet (192.168.101.0/24
Web-Proxy1
80
Permit
Trusted-Nets (192.168.0.0/16)
Web-Proxy1
80
Permit
The analysis report is displayed in three window panes (Figure 1-2).
•
•
•
Figure 1-2 Example of Analysis Report Layout
Related Topics
Generating Analysis Reports
The Analysis feature analyzes and reports rules that overlap or conflict with other rules. The analysis is performed using the rules defined for a selected device group. For more information, see Understanding Analysis Reports.
Procedure
Step 1
Step 2
The Access Rules page appears. For a description of the GUI elements, see Access Rules Page, page A-635.
Step 3
Note
The Analysis Report appears. For a description of the GUI elements, see Analysis Reports Page, page A-802.
Step 4
Step 5
Figure 1-3 shows an Analysis Report query from the Access Rules page.
Figure 1-3 Analysis Report Query
Figure 1-4 shows the results to that query. The report in this example shows that the rules conflict.
Figure 1-4 Analysis Report Results
Related Topics
•
•
Understanding Hit Count
The Hit Count feature collects the number of times that traffic for a device is permitted or denied based on an access rule. Report results are displayed in two forms:
•
•
From Hit Count reports, you can:
•
•
–
–
–
–
–
–
–
•
ACL hit count information is a critical component for debugging your security system. You can display this information directly from the Access Rules tables. Hit count information is provided for all device platforms supported by Firewall Services.
Note
Note
Related Topics
•
•
Generating Hit Count Reports
You can generate a Hit Count report from Device view or Policy view.
•
•
Note
This procedure assumes you are working from Device view.
Before You Begin
•
•
Procedure
Step 1
Step 2
The Access Rules page appears. For a description of the GUI elements, see Access Rules Page, page A-635.
Step 3
Note
The Hit Count report appears. For a description of the GUI elements, see Hit Count Page, page A-818.
Step 4
After the refresh, the Expanded table adds a Delta column that displays the new data retrieved.
Step 5
Related Topics
•
•
Understanding Hit Count Results
The Hit Count report displays ACL hit count information for the rules selected from the Access Rules tables. If no rules are selected, the Hit Count report includes information for all access rules on the device. The report includes policy objects that are used to define the rules selected. If object grouping is enabled, the report displays the hit count for all ACEs in the object group. (See Figure 1-5.)
Note
Report results are displayed in two forms:
•
•
For a description of the GUI elements, see Hit Count Page, page A-818.
If you inadvertently define a duplicate rule in a table, for example, access rule 1 in the mandatory table is the same as rule 5, the report displays the hit count for the first rule (mandatory_1 hit count = 1000) and the duplicate rule displays the hit count as zero (mandatory_5 hit count = 0).
Tip
Note
Related Topics
•
Changing How Hit Count Results Are Displayed
In addition to viewing Hit Count report information from the Expanded table and the Raw ACE table, you can customize report results based on more specific needs.
To change how report information is displayed, see:
•
Filtering Columns
This procedures describes how to filter hit count result information.
Procedure
Step 1
Step 2
You can only select one heading at a time.
Step 3
The report results are displayed based on your selections.
Step 4
Related Topics
•
Sorting Columns
From the Expanded table, you can sort column information in ascending or descending order.
This procedure describes how to sort columns in the Expanded table.
Note
Tip
Procedure
Step 1
Step 2
The information is changed in ascending or descending order.
Step 3
Step 4
Related Topics
•
Viewing Complete or Partial Details
From the Expanded table, you can view partial rule information (default). You can also view detailed results that expand the columns to display complete rule information.
This procedure describes how to change views from the Expanded table.
Procedure
Step 1
Step 2
The table expands to display all information for the selected rule.
Step 3
Step 4
Related Topics
•
Figure 1-5 Hit Count Results Table
Figure 1-6 Expanded Table
Figure 1-7 Raw ACE Table
Related Topics
•
Understanding Settings for Access Controls
By configuring settings for access control, you can:
•
•
•
Related Topics
•
•
•
Object Group Search (PIX/ASA/FWSM)
Object Group Search is a feature that you access from the Access Rules table. Object Group Search enables you to decide whether the ACL should be expanded or not for packet processing. If object-groups are huge, you can instruct the device to search within an object-group instead of expanding the ACL.
When enabled, the feature reduces the memory requirement on the device to hold large ACLs; however it impacts performance by making ACL processing slower for each packet. When enabled, the access-list <acl_name> object-group-search command is generated.
When Object Group Search is enabled on the device, the device performs the traffic match based on an ACL; it searches on object-group. Less memory is needed, but performance is slower.
When Object Group Search is disabled on the device, the device flattens all object groups used in the ACL and stores the ACEs in memory. Performance is improved, but more memory is required.
Consider the following:
host 1.1.1.1
host 3.3.3.3
host 2.2.2.2
host 4.4.4.4
Access-list test-acl permit ip object-group net1 object-group net2.In the example above, IP traffic is permitted from source net1 to destination net2 (where net1 and net2 are object groups).
When Object Group Search is disabled on the device, an input packet is filtered using the flattened object groups. Internally, the device expands the ACL as follows:
Permit ip host 1.1.1.1 host 3.3.3.3Permit ip host 1.1.1.1 host 4.4.4.4Permit ip host 2.2.2.2 host 3.3.3.3Permit ip host 2.2.2.2 host 4.4.4.4
Note
To access this feature, select Firewall > Settings > Access Control. Right-click inside the table, then click Add Row, or right-click a row, then click Edit Row.
Related Topics
•
•
•
Enabling Object Group Search (PIX/ASA/FWSM)
The Object Group Search feature reduces the memory requirement on the device to hold large ACLs. For more information, see Object Group Search (PIX/ASA/FWSM).
Procedure
Step 1
Step 2
The Access Control page appears. For a description of the GUI elements, see Access Control Page, page A-776.
Step 3
The Firewall ACL Setting dialog box appears. For a description of the GUI elements, see Firewall ACL Setting Dialog Box, page A-779.
Step 4
•
The objects are moved to the selected column.
•
A popup window helps you define the object. After you complete the definition, the new object is listed in the selected column.
Note
For more information, see Working with Interface Role Objects, page 1-120.
Step 5
Step 6
Step 7
Step 8
The dialog box closes and you return to the main page. True is displayed in the Object Group Search column.
Step 9
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
Related Topics
Access Control Page, page A-776
Per User Downloadable ACLs (PIX/ASA/FWSM)
The access list is applied to traffic inbound to an interface. The access-group command binds an access list to an interface. If traffic is permitted through the interface, the firewall device continues to process the packet. If traffic is denied, the device discards the packet and generates a syslog message.
The per-user downloadable ACLs option allows downloaded access lists to override the access list applied to the interface. If the per-user downloadable ACLs setting is not present, the firewall device preserves the existing filtering behavior. If per-user downloadable ACLs is present, the firewall device allows the permit or deny status from the per-user access-list (if one is downloaded) associated to a user to override the permit or deny status from the access-group command associated access list. Additionally, the following rules are observed:
•
•
•
Related Topics
•
•
Enabling Per User Downloadable ACLs (PIX/ASA/FWSM)
The Per User Downloadable ACLs feature permits downloaded access lists to override an access list applied to an interface role.
This procedure assumes you are working from Device view.
Procedure
Step 1
Step 2
The Access Control page appears.
Step 3
The Firewall ACL Setting dialog box appears.
Step 4
•
The objects are moved to the selected column.
•
A popup window helps you define the object. After you complete the definition, the new object is listed in the selected column.
Note
For more information, see Working with Interface Role Objects, page 1-120.
Step 5
Step 6
Step 7
Step 8
The dialog box closes and you return to the main page. True is displayed in the Object Group Search column.
Step 9
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
Related Topics
•
•
•
Access List Compilation (PIX)
An access list typically consists of multiple access list entries, organized internally by a firewall device as a linked list. When a packet is subjected to access list control, the device searches this linked list linearly to find a matching element. The matching element is then examined to determine if the packet is to be transmitted or dropped. With a linear search, the average search time increases in proportion to the size of the list.
Access List Compilation is designed to improve the average search time of access control lists containing a large number of entries. The feature causes the firewall device to compile tables for ACLs, which improves the searching of long ACLs.
Note
When Security Manager deploys the Access List Compilation commands to the firewall device, Security Manager cannot detect if the ACLs were compiled successfully. If the ACLs were not compiled successfully, the firewall device disables the Access List Compilation feature. You can turn the feature on or off at the global level. For more information, see Enabling Access List Compilation (PIX).
The Access List Compilation feature requires significant amounts of memory and is most appropriate for high-end PIX Firewall models, such as the PIX 525 or PIX 535, and security appliances. The minimum memory required is 2.1 MB, and approximately 1 MB of memory is required for every 2,000 ACL elements.
Note
Related Topics
•
•
•
Enabling Access List Compilation (PIX)
The Access List Compilation feature improves the average search time of access control lists containing a large number of entries.
This procedure assumes you are working from Device view.
Procedure
Step 1
Step 2
The Access Control page appears.
Step 3
The Firewall ACL Setting dialog box appears.
Step 4
Step 5
•
The objects are moved to the selected column.
•
A popup window helps you define the object. After you complete the definition, the new object is listed in the selected column.
Note
For more information, see Working with Interface Role Objects, page 1-120.
Step 6
Step 7
Step 8
The dialog box closes and you return to the Access Control page. True is displayed in the Access List Compilation column.
Step 9
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
Related Topics
•
•
•
Configuring Settings for Access Control
Procedure
Step 1
Step 2
The Access Control page appears.
Step 3
•
•
•
Note
Step 4
Note
Step 5
Step 6
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
To configure additional firewall ACL settings, see Configuring Firewall ACL Settings.
Related Topics
•
•
Configuring Firewall ACL Settings
Procedure
Step 1
Step 2
The Access Control page appears.
Step 3
The Firewall ACL Setting dialog box appears.
Step 4
•
The objects are moved to the selected column.
•
A popup window helps you define the object. After you complete the definition, the new object is listed in the selected column.
Note
For more information, see Working with Interface Role Objects, page 1-120.
Step 5
Step 6
Step 7
•
•
•
Step 8
Step 9
Step 10
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
Related Topics
Firewall ACL Setting Dialog Box, page A-779
Understanding Inspection Rules
Inspection rules provide an informational list of services, protocols, and port numbers to which a firewall device applies the Adaptive Security Algorithm (ASA). The default ports or those you specify are the ports at which the device listens for each service.
The default configuration of the firewall device includes a set of application inspection entries that associate supported protocols with specific TCP or UDP port numbers and that identify any special handling required. The inspection function does not support NAT or PAT for certain applications because of the constraints imposed by the applications. You can change the port assignments for some applications, but other applications have fixed port assignments that you cannot change.
You can extend the HTTP inspection capabilities to select which HTTP methods defined in the RFC to permit in HTTP traffic. If the device encounters an HTTP method not permitted, it drops the packet and closes the connection to prevent any subsequent data from traversing the security appliance.
Inspection rules are based on Context-Based Access Control (CBAC) to intelligently filter TCP and UDP packets based on application-layer protocol session information. You can configure CBAC to permit specified TCP and UDP traffic through a firewall only when the connection is initiated from within the network you want to protect. CBAC can inspect traffic for sessions that originate from either side of the firewall, and CBAC can be used for intranet, extranet, and Internet perimeters of your network.
When configuring inspection rules, you should:
1.
2.
From the Inspection Rules tables, you can generate Policy Query reports to help you identify all rules in the global policy that could affect the defined packets. For more information, see Understanding Policy Query.
Related Topics
•
•
Working with Inspection Rules
Note
•
•
The following topics will help you work with inspection rules:
•
•
•
•
•
•
Adding Inspection Rules
When adding an inspection rule, you can perform packet inspection globally or on a per-interface basis and identify traffic direction. You can constrain the inspection further based on other criteria that differs depending on the platform for which the rule inspected.
A branching wizard is used to help you configure inspection rules. Basically, the steps in the wizard are the same for all platforms; however, the dialog boxes in the wizard will vary depending on your selections.
This procedure assumes you are adding a rule from Device view. To add a rule from Policy view, see Creating a New Shared Policy, page 1-40, then complete this procedure. After you complete the procedure, you can share the global policy and assign devices to it. For more information, see Modifying Policy Assignments in Policy View, page 1-41.
Procedure
Step 1
Step 2
The Inspection Rules page appears.
Step 3
The Add Inspection Rule page appears. For a description of the GUI elements, see Add and Edit Inspection Rule Dialog Boxes, page A-664.
Step 4
Step 5
•
•
–
–
•
•
Step 6
Step 7
•
The objects are moved to the selected column.
•
A popup window helps you define the object. After you complete the definition, the new object is listed in the selected column.
For more information, see Working with Interface Role Objects, page 1-120.
Step 8
•
•
•
•
Note
Step 9
Step 10
Step 11
The appropriate wizard guides you through the configuration.
Related Topics
•
•
•
•
•
Configuring Default Protocol Ports
This procedure assumes you selected Default Protocol Ports as the type of traffic matched for inspection rules. This option configures default inspection traffic.
Procedure
Step 1
The wizard page listing protocols appears.
Step 2
Step 3
The dialog box closes and you return to the Inspection Rules table with the new information displayed.
Step 4
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
After you define policy settings in Device view, you can use it locally on the device, or share it with multiple devices. For more information, see Working with Shared Policies in Device View, page 1-22.
Note
Related Topics
•
•
•
Configuring Custom Destination Ports
This procedure assumes you selected Custom Destination Ports as the type of traffic matched for inspection rules (IOS). This option configures TCP and UDP.
Procedure
Step 1
Step 2
Step 3
The page listing protocols appears.
Step 4
Step 5
Step 6
•
•
Step 7
Step 8
The dialog box closes, and you return to the Inspection Rules table with the new rule information displayed.
Step 9
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
After you define policy settings in Device view, you can use it locally on the device, or share it with multiple devices. For more information, see Working with Shared Policies in Device View, page 1-22.
Note
Related Topics
•
•
•
Configuring Destination Address and Port (IOS)
This procedure assumes you selected Destination IP Address (IOS) as the type of traffic matched for inspection rules.
Procedure
Step 1
•
The objects are moved to the selected column.
•
A popup window helps you define the object. After you complete the definition, the new object is listed in the selected column.
For more information, see:
•
•
Step 2
Step 3
Step 4
The page listing protocols appears.
Step 5
Step 6
The dialog box closes and you return to the Inspection Rules table with the new information displayed.
Step 7
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
After you define policy settings in Device view, you can use it locally on the device, or share it with multiple devices. For more information, see Working with Shared Policies in Device View, page 1-22.
Note
Related Topics
•
•
•
Configuring Source and Destination Address and Port (ASA, FWSM 3.x)
This procedure assumes you selected Source and Destination Address and Port (ASA, FWSM 3.x) as the type of traffic matched for inspection rules.
Procedure
Step 1
Step 2
•
The objects are moved to the selected column.
•
A popup window helps you define the object. After you complete the definition, the new object is listed in the selected column.
For more information, see:
•
•
Step 3
•
The objects are moved to the selected column.
•
A popup window helps you define the object. After you complete the definition, the new object is listed in the selected column.
For more information, see:
•
•
Step 4
•
The objects are moved to the selected column.
•
A popup window helps you define the object. After you complete the definition, the new object is listed in the selected column.
For more information, see Working with Service Objects, page 1-181.
Step 5
Step 6
The page listing protocols appears.
Step 7
Step 8
The dialog box closes and you return to the Inspection Rules table with the new information displayed.
Step 9
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
After you define policy settings in Device view, you can use it locally on the device, or share it with multiple devices. For more information, see Working with Shared Policies in Device View, page 1-22.
Note
Related Topics
•
•
•
•
•
•
Editing Inspection Rules
To facilitate the editing process, Firewall Services offers the ability to perform inline editing on inspection rules shown in the tables. Editing can be performed on a rule in its entirety or individual table cells.
You can edit rules in their entirety by right-clicking a rule number in the table, which opens the rule dialog box or wizard from which to make your changes. You can also edit individual table cells by right-clicking a cell, then using the shortcut menu, which opens a dialog box specific to that table cell.
Right-click operations are restricted in certain circumstances:
•
•
•
•
You can edit multiple rule entries by selecting multiple rules, then right-clicking a column. You can then Add or Edit a feature, which is applied to the selected column for all selected rows.
You can display a list of all source and destination addresses by clicking on a table cell or specific entry (subfield) within the table cell, then clicking one of the Show Contents options from the shortcut menu. The list shows flattened values of all levels of an address, network object, or interface role and sorts the results in ascending order on the IP address, then descending order on the mask.
In addition to performing inline editing, you can move rules up or down within a table; cut, copy, and paste rules from which to clone other rule entries; enable or disable defined rules; and delete rules from the table. These functions can be performed from shortcut menus or buttons located on the GUI page.
An inherited rule can be modified only inside the parent policy in which it was defined. It cannot be modified inside a child policy.
Note
•
•
•
•
This procedure assumes you are working from Device view.
Note
Note
Procedure
Step 1
Step 2
The Inspection Rules page appears.
Step 3
•
The Edit Inspection Rule page appears, from which you can edit the rule in its entirety. Follow the procedure for adding an inspection rule. For more information, see Adding Inspection Rules.
•
•
–
–
•
–
–
•
•
•
•
•
•
•
Step 4
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
Related Topics
•
•
•
•
•
Enabling and Disabling Inspection Rules
This procedure assumes you are working from Device view.
Procedure
Step 1
Step 2
The Inspection Rules page appears.
Step 3
Step 4
Step 5
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
Note
•
Related Topics
Inspection Rules Page, page A-661
Generating Usage Reports
You might need to edit a policy object in the rules table. You can generate a usage report, which indicates whether objects are in use (referenced) by another object, policy, or device (in case of device override). Usage reports contain any references in your current activity, as well as references committed to the Security Manager database.
This procedure assumes you are working from Device view.
Procedure
Step 1
Step 2
The Inspection Rules page appears. For a description of the GUI elements, see Inspection Rules Page, page A-661.
Step 3
A usage report is generated for the object selected. For a description of the GUI elements, see Object Usage Window, page A-204.
Note
Step 4
Related Topics
•
•
•
•
Cutting, Copying, and Pasting Inspection Rules
This procedure assumes you are working from Device view.
Procedure
Step 1
Step 2
The Inspection Rules page appears.
Step 3
Step 4
Step 5
The rule is added to the table.
Step 6
Step 7
Step 8
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
Related Topics
•
•
Moving Inspection Rules Up and Down
This procedure assumes you are working from Device view.
Procedure
Step 1
Step 2
The Inspection Rules page appears.
Step 3
Step 4
The selected rule moves up or down one row within the table.
Tip
Step 5
Step 6
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
Related Topics
Inspection Rules Page, page A-661
Deleting Inspection Rules
This procedure assumes you are working from Device view.
Procedure
Step 1
Step 2
The Inspection Rules page appears.
Step 3
You are prompted to confirm the deletion the first time you delete a row and any additional time, unless you request not to be prompted.
Step 4
The rule is removed from the table.
Step 5
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
You can verify the deletion of the rule by viewing an audit report. To generate an audit report, select Tools > Audit Report.
Related Topics
Understanding Audit Reports, page 1-6
Configuring Settings for Inspection Rules
Configure settings for inspection rules for deeper packet inspection for IOS devices.
This procedure assumes you are working from Device view.
Procedure
Step 1
Step 2
The Inspection page appears.
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
Step 12
Step 13
Step 14
Step 15
Step 16
Step 17
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
Related Topics
•
Supported Features for Inspection
Table 0-5 shows how platforms managed by Security Manager support inspection and fixup.
·
Related Topics
•
•
Working with AAA Rules
Access control is the way to control who is allowed access to the network server and what services they are allowed to use once they have access. Authentication, authorization, and accounting (AAA) network security services provide the primary framework through which you set up access control on your firewall device or security appliance.
AAA rules control authentication (who the user is), authorization (what the user is allowed to do), and accounting (what the user did) for traffic.
When configuring AAA rules, you should:
1.
2.
a.
b.
From the AAA Rules tables, you can generate Policy Query reports to help you identify all rules in the global policy that could affect the defined packets. For more information, see Understanding Policy Query.
Topics to help you work with AAA Rules are:
•
•
Topics to help you work with Settings for AAA Rules are:
•
•
•
•
•
Adding AAA Rules
This procedure assumes you are adding a rule from Device view. To add a rule from Policy view, see Creating a New Shared Policy, page 1-40, then complete this procedure. After you complete the procedure, you can share the global policy and assign devices to it. For more information, see Modifying Policy Assignments in Policy View, page 1-41.
Procedure
Step 1
Step 2
The AAA Rule page appears.
Step 3
The Add AAA Rule page appears. For a description of the GUI elements, see Add and Edit AAA Rules Dialog Boxes, page A-711.
Step 4
Step 5
•
•
•
Step 6
Step 7
•
The objects are moved to the selected column.
•
A popup window helps you define the object. After you complete the definition, the new object is listed in the selected column.
For more information, see:
•
•
Step 8
•
The objects are moved to the selected column.
•
A popup window helps you define the object. After you complete the definition, the new object is listed in the selected column.
For more information, see:
•
•
Step 9
•
The objects are moved to the selected column.
•
A popup window helps you define the object. After you complete the definition, the new object is listed in the selected column.
For more information, see Working with Service Objects, page 1-181.
Step 10
•
The objects are moved to the selected column.
•
A popup window helps you define the object. After you complete the definition, the new object is listed in the selected column.
For more information, see Working with AAA Server Group Objects, page 1-6.
Step 11
•
The objects are moved to the selected column.
•
A popup window helps you define the object. After you complete the definition, the new object is listed in the selected column.
For more information, see Working with Interface Role Objects, page 1-120.
Step 12
Step 13
Step 14
Step 15
The page closes and you return to the AAA table. The rule information is shown in the table.
Step 16
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
After you define policy settings in Device view, you can use it locally on the device, or share it with multiple devices. For more information, see Working with Shared Policies in Device View, page 1-22.
Note
Related Topics
•
•
•
Editing AAA Rules
To facilitate the editing process, Firewall Services offers the ability to perform inline editing on AAA rules shown in the tables. Editing can performed on a rule in its entirety or individual table cells.
You can edit rules in their entirety by double-clicking a rule number in the table, which opens the rule dialog box or wizard from which to make your changes. You can also right-click a rule number in the table, then select Edit Row. You can edit individual table cells by double-clicking a cell, which opens a dialog box specific to that table cell. You can also right-click a cell, then click the Edit function from the shortcut menu.
You can edit multiple rule entries by selecting multiple rules, then right-clicking a column. You can then Add or Edit a feature, which is applied to the selected column for all selected rows.
You can display a list of all source and destination addresses by clicking on a table cell or specific entry (subfield) within the table cell, then clicking one of the Show Contents options from the shortcut menu. The list shows flattened values of all levels of an address, network object, or interface role and sorts the results in ascending order on the IP address, then descending order on the mask.
You can display a list of all services and port information. The list shows flattened values of all levels of the Service and Port List objects and sorts the results on: protocol, destination port, and source port.
You can display each interface role type as a separate listing in the table if you are working from Policy view, or display actual interface names if you are working from Device view.
In addition to performing inline editing and displaying a flattened list of table cell contents, you can move rules up or down within a table; cut, copy, and paste rules from which to clone other rule entries; enable or disable defined rules; and delete rules from the table. These functions can be performed from shortcut menus or buttons located on the GUI page.
An inherited rule can be modified only inside the parent policy in which it was defined. It cannot be modified inside a child policy.
Note
•
•
•
•
This procedure assumes you are working from Device view.
Note
Procedure
Step 1
Step 2
The AAA Rule page appears.
Step 3
•
The Edit AAA Rule page appears, from which you can edit the rule in its entirety. Follow the procedure for adding an access rule. For more information, see Adding AAA Rules.
•
•
–
–
•
–
–
•
•
•
•
•
•
•
Step 4
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
Related Topics
Enabling and Disabling AAA Rules
This procedure assumes you are working from Device view.
Procedure
Step 1
Step 2
The AAA Rules page appears. For a description of the GUI elements, see AAA Rules Page, page A-708.
Step 3
Step 4
Step 5
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
Note
•
Related Topics
Generating Usage Reports
You might need to edit a policy object in the rules table. You can generate a usage report, which indicates whether objects are in use (referenced) by another object, policy, or device (in case of device override). Usage reports contain any references in your current activity, as well as references committed to the Security Manager database.
This procedure assumes you are working from Device view.
Procedure
Step 1
Step 2
The AAA Rules page appears. For a description of the GUI elements, see AAA Rules Page, page A-708.
Step 3
A usage report is generated for the object selected. For a description of the GUI elements, see Object Usage Window, page A-204.
Step 4
Related Topics
•
Cutting, Copying, and Pasting AAA Rules
This procedure assumes you are working from Device view.
Procedure
Step 1
Step 2
The AAA Rules page appears. For a description of the GUI elements, see AAA Rules Page, page A-708.
Step 3
Step 4
Step 5
The rule is added to the table.
Step 6
Step 7
Step 8
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
Related Topics
Moving AAA Rules Up and Down
Procedure
Step 1
Step 2
The AAA Rules page appears. For a description of the GUI elements, see AAA Rules Page, page A-708.
Step 3
Step 4
The selected rule moves up or down one row within the table.
Tip
Step 5
Step 6
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
Related Topics
Deleting AAA Rules
This procedure assumes you are working from Device view.
Procedure
Step 1
Step 2
The AAA Rules page appears. For a description of the GUI elements, see AAA Rules Page, page A-708.
Step 3
You are prompted to confirm the deletion the first time you delete a row and any additional time, unless you request not to be prompted.
Step 4
The rule is removed from the table.
Step 5
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
You can verify the deletion of the rule by viewing an audit report. To generate an audit report, select Tools > Audit Report.
Related Topics
•
Configuring Settings for AAA
Configuring settings for AAA enables you to configure added granularity when you are using AAA servers.
•
–
–
•
Configuring Settings for AAA Firewall (PIX/ASA/FWSM)
Before You Begin
Configure a AAA rule for the device or device group. For more information, see Adding AAA Rules.
Procedure
Step 1
Step 2
The AAA Firewall page appears.
Step 3
Step 4
Step 5
•
•
•
•
If you disable challenge authentication for a particular protocol, traffic using that protocol is allowed only if the traffic belongs to a session previously authenticated. This authentication can be accomplished by traffic using a protocol whose authentication challenge remains enabled. For example, if you disable challenge authentication for FTP, the FWSM denies new sessions using FTP if the traffic is included in an authentication rule. If you establish the session with a protocol whose authentication challenge is enabled (such as HTTP), FTP traffic is allowed.
Step 6
Step 7
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
Related Topics
•
•
Using MAC Exempt Address Lists
The security appliance can exempt from authentication and authorization any traffic from specific MAC addresses.
For example, if the security appliance authenticates TCP traffic originating on a particular network but you want to allow unauthenticated TCP connections from a specific server, you would create a MAC rule permitting traffic from the MAC address of the server. This generates a mac-list command. You would then exempt from authentication and authorization any traffic from the server specified by the MAC list. This generates a aaa mac-exempt command.
Conversely, if traffic from a particular computer should never be permitted regardless of authentication, you can use the MAC address of the computer that denies traffic from the MAC address. Traffic is disallowed from the computer even though authentication rules would otherwise permit the traffic.
Related Topics
Adding MAC Exempt Address Lists
Adding MAC Exempt Address Lists
This procedure assumes you are working from Device view.
Note
Procedure
Step 1
Step 2
The AAA Firewall page appears. For a description of the GUI elements, see AAA Firewall Page, page A-784.
Step 3
Step 4
The Firewall AAA MAC Exempt Setting dialog box appears. For a description of the GUI elements, see Firewall AAA MAC Exempt Setting Dialog Box, page A-786.
Step 5
Step 6
Step 7
The dialog box closes are you return to the MAC-exempt Address table. The rule information is shown in the table.
Step 8
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
Related Topics
•
•
•
•
Editing MAC Exempt Address Lists
Unlike many of the policy rule tables, the MAC-exempt Address List table does not enable editing on a per-table cell basis.
Procedure
Step 1
Step 2
The AAA Firewall page appears. For a description of the GUI elements, see AAA Firewall Page, page A-784.
Step 3
The Firewall AAA MAC Exempt Setting dialog box appears. For a description of the GUI elements, see Firewall AAA MAC Exempt Setting Dialog Box, page A-786.
Step 4
Step 5
Step 6
The dialog box closes are you return to the MAC-exempt Address table. The rule information is shown in the table.
Step 7
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
Related Topics
•
•
Deleting MAC Exempt Address Lists
Procedure
Step 1
Step 2
The AAA Firewall page appears.
Step 3
You are prompted to confirm the deletion the first time you delete a row and any additional time, unless you request not to be prompted.
Step 4
The rule is removed from the table.
Related Topics
•
•
•
Configuring Settings for AAA (IOS)
AuthProxy provides information about all authenticated-proxy user events for IOS devices.
Before You Begin
Configure a AAA rule for the device or device group. For more information, see Adding AAA Rules.
This procedure assumes you are working from Device view.
Procedure
Step 1
Step 2
The AuthProxy page appears with the General tab displayed.
Step 3
•
The objects are moved to the selected column.
•
A popup window helps you define the object. After you complete the definition, the new object is listed in the selected column.
For more information, see Working with AAA Server Group Objects, page 1-6.
Step 4
•
The objects are moved to the selected column.
•
A popup window helps you define the object. After you complete the definition, the new object is listed in the selected column.
For more information, see Working with AAA Server Group Objects, page 1-6.
Step 5
•
The objects are moved to the selected column.
•
A popup window helps you define the object. After you complete the definition, the new object is listed in the selected column.
For more information, see Working with AAA Server Group Objects, page 1-6.
Step 6
Step 7
•
•
•
Step 8
Step 9
•
–
–
–
•
–
–
–
•
–
–
–
•
Step 10
Step 11
Step 12
Step 13
The Firewall AAA IOS Timeout Value Setting dialog box appears.
Step 14
•
The objects are moved to the selected column.
•
A popup window helps you define the object. After you complete the definition, the new object is listed in the selected column.
For more information, see Working with Interface Role Objects, page 1-120.
Step 15
Step 16
Step 17
Step 18
The dialog box closes and you return to the AuthProxy page. The rule information is shown in the table.
Step 19
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
Related Topics
•
Understanding Web Filter Rules
Web filter rules are rules that specify filter URLs using a filtering server such as Websense. You define the rules in the Web Filter Rules table and determine whether to permit or deny traffic if the filter server is unavailable.
Java inspection enables Java applet filtering at the firewall. Java applet filtering distinguishes between trusted and untrusted applets by relying on a list of external sites that you designate as friendly. If an applet is from a friendly site, the firewall device allows the applet through. If the applet is not from a friendly site, the applet is blocked. Alternately, you could permit applets from all sites except sites specifically designated as hostile.
From the Web Filter Rules tables, you can generate Policy Query reports to help you identify all rules in the global policy that could affect the defined packets. For more information, see Understanding Policy Query.
Related Topics
Working with Web Filter Rules
When configuring Web Filter rules, you should:
1.
Note
2.
The Web Filter policy for IOS devices contains two subpolicies: IOS Web Filter rules and Exclusive Domains. Under IOS Web Filter rules, you can create rules for enabling Web filtering and Java applet scanning on traffic flows. Under Exclusive Domains, you can specify a set of domain names that will be permitted or denied by the IOS firewall device without having to consult the external URL server.
Topics that support Web Filter Rules for ASA, FWSM, and PIX devices are:
•
•
•
•
•
•
•
Topics that support Web Filter Rules for IOS devices are:
•
•
•
•
•
•
•
Topics that support Settings for Web Filter Rules are:
•
•
•
•
Adding Web Filter Rules (ASA/FWSM/PIX)
This procedure assumes you are adding a rule from Device view. To add a rule from Policy view, see Creating a New Shared Policy, page 1-40, then complete this procedure. After you complete the procedure, you can share the global policy and assign devices to it. For more information, see Modifying Policy Assignments in Policy View, page 1-41.
Procedure
Step 1
Step 2
The Web Filter Rules page appears. For a description of the GUI elements, see Web Filter Rules Page (ASA/FWSM/PIX), page A-733.
Step 3
The PIX/ASA Web Filter Rule dialog box appears. For a description of the GUI elements, see PIX/FWSM/ASA Rules Dialog Box, page A-735.
Step 4
Step 5
•
•
Step 6
Step 7
•
The objects are moved to the selected column.
•
A popup window helps you define the object. After you complete the definition, the new object is listed in the selected column.
For more information, see:
•
•
Step 8
•
The objects are moved to the selected column.
•
A popup window helps you define the object. After you complete the definition, the new object is listed in the selected column.
For more information, see:
•
•
Step 9
•
The objects are moved to the selected column.
•
A popup window helps you define the object. After you complete the definition, the new object is listed in the selected column.
For more information, see Working with Service Objects, page 1-181.
Note
Step 10
Step 11
Step 12
Step 13
Step 14
•
•
•
Step 15
Step 16
Step 17
The PIX/ASA dialog box closes and you return to the Web Filter Rules page. The rule information is shown in the table.
Step 18
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
After you define policy settings in Device view, you can use it locally on the device, or share it with multiple devices. For more information, see Working with Shared Policies in Device View, page 1-22.
Note
Related Topics
•
•
•
•
•
Editing Web Filter Rules (ASA/FWSM/PIX)
To facilitate the editing process, Firewall Services offers the ability to perform inline editing on Web Filter rules shown in the tables. Editing can be performed on a rule in its entirety or individual table cells.
You can edit rules in their entirety by double-clicking a rule number in the table, which opens the rule dialog box or wizard from which to make your changes. You can also right-click a rule number in the table, then select Edit Row. You can edit individual table cells by double-clicking a cell, which opens a dialog box specific to that table cell. You can also right-click a cell, then click the Edit function from the shortcut menu.
You can edit multiple rule entries by selecting multiple rules, then right-clicking a column. You can then Add or Edit a feature, which is applied to the selected column for all selected rows.
You can display a list of all source and destination addresses. The list shows flattened values of all levels of an address, network object, or interface role object and sorts the results in ascending order on the IP address, then descending order on the mask.
You can display a list of all services and port information. The list shows flattened values of all levels of the Service and Port List objects and sorts the results on: protocol, destination port, and source port.
In addition to performing inline editing and displaying a flattened list of table cell contents, you can move rules up or down within a table; cut, copy, and paste rules from which to clone other rule entries; enable or disable defined rules; and delete rules from the table. These functions can be performed from shortcut menus or buttons located on the GUI page.
An inherited rule can be modified only inside the parent policy in which it was defined. It cannot be modified inside a child policy.
Note
•
•
•
•
This procedure assumes you are working from Device view.
Note
Procedure
Step 1
Step 2
The Web Filter Rules page appears. For a description of the GUI elements, see Web Filter Rules Page (ASA/FWSM/PIX), page A-733.
Step 3
•
The PIX/ASA Web Filter Rule dialog box appears, from which you can edit the rule in its entirety. Follow the procedure for adding a Web Filter rule. For a description of the GUI elements, see Adding Web Filter Rules (ASA/FWSM/PIX).
•
–
–
•
–
–
•
Note
•
•
•
•
Step 4
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
Related Topics
•
•
•
Enabling and Disabling Web Filter Rules (ASA/FWSM/PIX)
This procedure assumes you are working from Device view.
Procedure
Step 1
Step 2
The Web Filter Rules page appears. For a description of the GUI elements, see Web Filter Rules Page (ASA/FWSM/PIX), page A-733.
Step 3
Step 4
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
Note
•
Related Topics
•
•
•
Cutting, Copying, and Pasting Web Filter Rules (ASA/FWSM/PIX)
Procedure
Step 1
Step 2
The Web Filter Rules page appears. For a description of the GUI elements, see Web Filter Rules Page (ASA/FWSM/PIX), page A-733.
Step 3
Step 4
Step 5
The rule is added to the table.
Step 6
Step 7
Step 8
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
Related Topics
•
•
•
•
Moving Web Filter Rules Up and Down (ASA/FWSM/PIX)
Procedure
Step 1
Step 2
The Web Filter Rules page appears. For a description of the GUI elements, see Web Filter Rules Page (ASA/FWSM/PIX), page A-733.
Step 3
Step 4
The selected rule moves up or down one row within the table.
Tip
Step 5
Step 6
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
Related Topics
•
•
•
Deleting Web Filter Rules (ASA/FWSM/PIX)
This procedure assumes you are working from Device view.
Procedure
Step 1
Step 2
The Web Filter Rules page appears. For a description of the GUI elements, see Web Filter Rules Page (ASA/FWSM/PIX), page A-733.
Step 3
You are prompted to confirm the deletion the first time you delete a row and any additional time, unless you request not to be prompted.
Step 4
The rule is removed from the table.
Step 5
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
You can verify the deletion of the rule by viewing an audit report. To generate an audit report, select Tools > Audit Report.
Related Topics
•
•
•
•
Adding Web Filter Rules (IOS)
This procedure assumes you are adding a rule from Device view. To add a rule from Policy view, see Creating a New Shared Policy, page 1-40, then complete this procedure. After you complete the procedure, you can share the global policy and assign devices to it. For more information, see Modifying Policy Assignments in Policy View, page 1-41.
Procedure
Step 1
Step 2
The IOS Web Filter Rules page appears. The Web Filter Rules tab opens by default. For a description of the GUI elements, see Web Filter Rules Page (IOS), page A-755.
Step 3
The IOS Web Filter Rule and Applet Scanner dialog box appears. For a description of the GUI elements, see IOS Web Filter Rule and Applet Scanner Dialog Box, page A-760.
Step 4
Step 5
•
•
For more information, see Working with Interface Role Objects, page 1-120.
Step 6
Step 7
Step 8
Step 9
•
The objects are moved to the selected column.
•
A popup window helps you define the object. After you complete the definition, the new object is listed in the selected column.
The object selector dialog box closes and you return to the IOS Web Filter Rule and Applet Scanner dialog box. For more information, see Working with Network/Host Objects, page 1-142.
Step 10
The dialog box closes and you return to the Web Filter Rules page. The rule information is shown in the table.
Step 11
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
After you define policy settings in Device view, you can use it locally on the device, or share it with multiple devices. For more information, see Working with Shared Policies in Device View, page 1-22.
Note
Related Topics
•
•
•
•
•
Editing Web Filter Rules (IOS)
Unlike many of the rules tables, the IOS Web Filter Rules table does not enable editing on a per-table cell basis. The basic procedure for editing Web Filter Rules for IOS devices is the same as adding rules.
An inherited rule can be modified only inside the parent policy in which it was defined. It cannot be modified inside a child policy.
This procedure assumes you are working from Device view.
Procedure
Step 1
Step 2
The IOS Web Filter Rules page appears. For a description of the GUI elements, see Web Filter Rules Page (IOS), page A-755.
Step 3
The IOS Web Filter Rule and Applet Scanner dialog box appears. For a description of the GUI elements, see IOS Web Filter Rule and Applet Scanner Dialog Box, page A-760.
Step 4
Step 5
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
Related Topics
•
•
•
•
•
Deleting Web Filter Rules (IOS)
This procedure assumes you are working from Device view.
Step 1
Step 2
The IOS Web Filter Rules page appears. For a description of the GUI elements, see Web Filter Rules Page (IOS), page A-755.
Step 3
You are prompted to confirm the deletion the first time you delete a row and any additional time, unless you request not to be prompted.
Step 4
The rule is removed from the table.
Step 5
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
You can verify the deletion of the rule by viewing an audit report. To generate an audit report, select Tools > Audit Report.
Related Topics
•
•
•
•
Adding Exclusive Domains (IOS)
This procedure assumes you are adding a rule from Device view. To add a rule from Policy view, see Creating a New Shared Policy, page 1-40, then complete this procedure. After you complete the procedure, you can share the global policy and assign devices to it. For more information, see Modifying Policy Assignments in Policy View, page 1-41.
Exclusive Domain policies enable you to specify a list of domain names (exclusive domains) eliminating the need for the firewall to create a lookup request for HTTP traffic destined for one of the domains in the exclusive list. Thus, you can avoid sending look-up requests to the web server for HTTP traffic that is destined for a host allowed to all users. You can enter the complete domain name or a partial domain name.
Before You Begin
You must configure a Web Filter Server in order for exclusive domains to be recognized. For more information, see Configuring Settings for Web Filter Servers.
Procedure
Step 1
Step 2
The IOS Web Filter Rules page appears. For a description of the GUI elements, see Web Filter Rules Page (IOS), page A-755.
Step 3
Step 4
The IOS Web Filter Exclusive Domain Name dialog box appears. For a description of the GUI elements, see Exclusive Domain Name Dialog Box, page A-763.
Step 5
Step 6
•
•
Step 7
The dialog box closes and you return to the Exclusive Domain table. The rule information is shown in the table.
Step 8
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
After you define policy settings in Device view, you can use it locally on the device, or share it with multiple devices. For more information, see Working with Shared Policies in Device View, page 1-22.
Note
Related Topics
•
•
•
•
Editing Exclusive Domains (IOS)
Unlike many of the rules tables, the Exclusive Domains table does not enable editing on a per-table cell basis. The basic procedure for editing Web Filter Settings for IOS Rules is the same as adding settings.
An inherited rule can be modified only inside the parent policy in which it was defined. It cannot be modified inside a child policy.
This procedure assumes you are working from Device view.
Procedure
Step 1
Step 2
The IOS Web Filter Rules page appears. For a description of the GUI elements, see Web Filter Rules Page (IOS), page A-755.
Step 3
Step 4
The IOS Web Filter Exclusive Domain Name dialog box appears. For a description of the GUI elements, see Exclusive Domain Name Dialog Box, page A-763.
Step 5
Step 6
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
Related Topics
•
•
•
•
Deleting Exclusive Domains (IOS)
This procedure assumes you are working from Device view.
Procedure
Step 1
Step 2
The IOS Web Filter Rules page appears. For a description of the GUI elements, see Web Filter Rules Page (IOS), page A-755.
Step 3
Step 4
You are prompted to confirm the deletion the first time you delete a row and any additional time, unless you request not to be prompted.
Step 5
The rule is removed from the table.
Step 6
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
You can verify the deletion of the rule by viewing an audit report. To generate an audit report, select Tools > Audit Report.
Related Topics
•
•
•
•
Configuring Settings for Web Filter Servers
Procedure
Step 1
Step 2
The Web Filter page appears. For a description of the GUI elements, see Web Filter Page, page A-796.
Step 3
Step 4
•
•
For IOS Settings:
Step 5
•
•
•
•
Step 6
Step 7
Step 8
For PIX, ASA, and FWSM Settings:
Step 9
Step 10
Step 11
Step 12
Step 13
Step 14
Changes must be submitted and approved before they are committed to the database, which enables all other users to view the changes. For more information, see Chapter 1, "Managing Activities."
Changes are applied to the assigned device configuration files when they are generated. The configuration files are then downloaded to the devices at deployment. For more information, see Chapter 1, "Managing Deployment."
Related Topics
•
