-
User Guide for Cisco Security Manager 3.2.2
-
Preface
-
Getting Started with Security Manager
-
Managing User Accounts
-
Working with the Security Manager User Interface
-
Using Map View
-
Preparing Devices for Management
-
Managing the Device Inventory
-
Managing Policies
-
Managing Activities
-
Managing Objects
-
Managing Site-to-Site VPNs
-
Managing Remote Access VPNs
-
Managing Firewall Services
-
Managing IPS Services
-
Managing Routers
-
Managing Firewall Devices
-
Managing Cisco Catalyst Switches and Cisco 7600 Series Routers
-
Managing IPS Devices
-
Managing Deployment
-
Managing FlexConfigs
-
Managing the Security Manager Server
-
Using Monitoring, Troubleshooting, and Diagnostic Tools
-
Administrative Settings User Interface Reference
-
Map View User Interface Reference
-
Device Inventory User Interface Reference
-
Policy User Interface Reference
-
Activities User Interface Reference
-
Policy Object Manager User Interface Reference
-
Site-to-Site VPN User Interface Reference
-
Remote Access VPN User Interface Reference
-
Firewall Services User Interface Reference
-
Router Platform User Interface Reference
-
PIX/ASA/FWSM Platform User Interface Reference
-
Catalyst Platform User Interface Reference
-
IPS User Interface Reference
-
Deployment User Interface Reference
-
Index
-
Table Of Contents
Defining Combined Rules Criteria
Understanding Combined Rules Summary Results
How Regular Expressions are Supported in Find and Replace
Defining Find and Replace Criteria
Understanding Hit Count Results
Changing How Hit Count Results Are Displayed
Extended Access List: Example 1
Extended Access List: Example 2
Generating Policy Query Reports
Understanding Policy Query Results
Understanding Rule Table Sections
Notes About Rule Table Sections
Adding Rules to an Existing Table Section
Removing Rules from an Existing Table Section
Optimizing Policy Objects in Rules
Notes about Policy Object Optimization
Expanding Object Groups During Discovery
How Access Rules Are Recognized on Devices
Enabling and Disabling Access Rules
Cutting, Copying, and Pasting Access Rules
Moving Access Rules Up and Down
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
Enabling and Disabling AAA Rules
Cutting, Copying, and Pasting AAA Rules
Understanding Web Filter Rules
Adding Web Filter Rules (PIX/ASA)
Editing Web Filter Rules (PIX/ASA)
Enabling and Disabling Web Filter Rules (PIX/ASA)
Cutting, Copying, and Pasting Web Filter Rules (PIX/ASA)
Moving Web Filter Rules Up and Down (PIX/ASA)
Deleting Web Filter Rules (PIX/ASA)
Editing Web Filter Rules (IOS)
Deleting Web Filter Rules (IOS)
Adding Exclusive Domains (IOS)
Editing Exclusive Domains (IOS)
Deleting Exclusive Domains (IOS)
Working with Transparent Firewall Rules
Enabling and Disabling Transparent Rules
Cutting, Copying, and Pasting Transparent Rules
Moving Transparent Rules Up and Down
Understanding Firewall Settings
Understanding Settings for Access Controls
Configuring Settings for Access Control
Configuring Firewall ACL Settings
Configuring Settings for Inspection Rules
Supported Features for Inspection
Configuring Settings for AAA Firewall (PIX/ASA/FWSM)
Understanding MAC Exempt Address Lists
Configuring Settings for AAA (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
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 Series or Cisco 7600 Router Series devices, and security routers running Cisco IOS (IOS).
Each firewall policy comprises a collection of 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 7, "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. The options listed in the Firewall selector are based on the type of device for which rules are being created.
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-based policies do not recognize inheritance, but settings-based policies can be shared and assigned to other devices. For more information, see the following:
•
•
To better understand the difference between policy inheritance and policy assignment, see Inheritance vs. Assignment, page 7-6.
It is important to understand how Security Manager recognizes names for access control lists. During deployment, the ACL names can be automatically generated by Security Manager or preserved as defined by users. For more information, see:
•
•
•
•
•
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 Directly to a Device, page 18-10.
Note
Related Topics
•
•
•
•
Managing Your Rules Tables
To help you administer your rules tables, Security Manager provides you with the ability to perform a variety of functions. You can:
•
•
•
•
•
•
•
•
•
•
•
Using Rule Expiration
Access control lists and policies are beneficial in controlling traffic on networks and managing traffic inspection. Many policies are created for the purpose of granting access for some limited period of time. The rule expiration feature is designed to help you control and maintain policies that are defined over time. Using the Security Manager GUI interface, you can automatically remove policies that are no longer needed, which helps you to better administer your policy rules.
You can set rule expiration parameters from the Access Rules table at the same time that you define a policy rule. For more information, see Adding Access Rules. You can also edit rule expiration parameters inline. For more information, see Editing Access Rules.
The Access Rules table includes a column with expiration date information. For non-expired rules, the expiration date is displayed in the column in plain text. For expired rules, the expiration date information is in bolded text.
You can filter ACEs in rules tables using the Expiration Date option, which can list rules that have already expired or rules that will expire on a specific date or time period. You can notify users of expired rules by configuring email settings. Such notifications can be configured "x" number of days prior to the expiration date, whereby "x" is a value from 0 up to one day prior to the expiration date. Email notifications are generally set using the Admin menu; however, you can override email settings for particular rules using the rule expiration GUI.
When setting rule expiration dates, you have the option of entering a date in the field provided by clicking the calendar icon (for example, 02-Feb-2008) or by specifying the number of days until the expiration date (for example, 30 days), which then configures the calendar expiration date for you.
Related Topics
•
Using Analysis
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.
The Analysis feature supports discontiguous masks. For more information, see Contiguous and Discontiguous Network Masks, page 9-70.
Some of the types of conflicts shown in the analysis report include:
•
•
–
–
–
–
Table 12-1 Opposite Rules
my-PC
Mail-Servers
smtp-25
Permit
my-PC
Mail-Servers
smtp-25
Deny
Table 12-2 Opposite Rules
my-PC
any
smtp-25
Permit
my-PC
1.2.3.4
smtp-25
Deny
Table 12-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 12-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 12-1).
•
•
•
Figure 12-1 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 Figure 12-1.
Figure 12-2 shows an Analysis Report query from the Access Rules page.
Figure 12-2 Analysis Report Query
Figure 12-3 shows the results to that query. The report in this example shows that the rules conflict.
Figure 12-3 Analysis Report Results
Related Topics
•
•
Procedure
Step 1
Step 2
The Access Rules page appears. For a description of the GUI elements, see Table I-1 on page I-2.
Step 3
Note
The Analysis Report appears. For a description of the GUI elements, see Table I-93 on page I-125.
Step 4
Step 5
Combining Rules
Your organization might dictate the need for using a large number of ACLs. A large number of ACLs can affect performance and memory usage in Security Manager and on the device. To help you manage your ACLs, you can combine rules, thus facilitating your ability to maintain them.
Combining rules provides a way to group objects of a similar type so that a single access rule can apply to all objects in the group. For example, consider the following three object groups:
•
•
•
After combining these objects, you can use a single access rule to allow trusted hosts to make specific service requests to a group of public servers.
Note
Combining rules dramatically compresses the number of access rules required to implement a particular security policy. For example, a customer policy that required 3,300 access rules might only require 40 rules after hosts and services are properly grouped.
To achieve this, multidimensional sorting is performed. For example:
1.
2.
3.
4.
5.
Sorting is repeated based on destination and service in place of source.
For example, you might have two rules:
Rule 1: Src:1.1.1.1 Dst:2.2.2.2 Svc:CMD Interface:inside Action:PermitRule 2: Src:1.1.1.1 Dst:3.3.3.3 Svc:CMD Interface:inside Action:PermitThe two rules can be combined to form a new rule:
New Rule: Src:1.1.1.1 Dst:2.2.2.2, 3.3.3.3 Svc:CMD Interface:inside Action:Permit
Tip
You can elect to automatically create network objects to replace the comma-separated values in a rule table cell that resulted when multiple rules were combined. The network objects are created during deployment. To set this feature, select Tools > Security Manager Administration > Deployment. From the Deployment page, select Create Object Groups for Multiple Sources, Destinations, or Services in a Rule.
Each object in the source domain must have a unique name so that policies can be sorted alphabetically. The same requirement is true for destinations and services. Sorting can also be based on IP addresses or port numbers.
Related Topics
•
•
•
Combined Rules Criteria Notes
When combining rules, note the following:
•
–
–
–
–
–
–
–
•
–
–
–
–
–
–
•
•
•
•
•
Related Topics
•
•
Defining Combined Rules Criteria
Related Topics
•
•
Procedure
Step 1
Step 2
The appropriate table appears based on your selection.
Step 3
Step 4
The Combine Rules Selection Summary dialog box appears.
Step 5
Step 6
The Results Summary is displayed after the rules table has been analyzed. For more information, see Understanding Combined Rules Summary Results.
Step 7
Step 8
Step 9
Understanding Combined Rules Summary Results
The combined rules summary is divided into two tables (Figure 12-4). The top table shows the new rules that have been generated. A table cell with a red border identifies the changes that were made to the cell content, enabling the rules to be combined. The bottom table shows the original rules in the table before they were combined and indicates the rules' original row numbers.
Tip
You can make changes directly to the results shown in the Description column. You an also create a network or service object from the Source, Destination, or Service columns.
Clicking OK updates the rules table with the combined rules; however, you must click Save to save your changes to the server.
Note
From this report, you can click Detailed Report, which opens a text description of combined rule information and displays table cell contents in its entirety. The report is in HTML, which you can print and save using Internet Explorer toolbar options.
Figure 12-4 Combined Rule Summary
Related Topics
•
•
Using Find and Replace
The Find and Replace feature is a convenient method by which you can search for values in rules tables, such as IP addresses and policy object names, to facilitate locating and making changes to rules in tables. The feature is similar to the find and replace feature in Microsoft Windows applications. You access this feature by clicking the Find and Replace icon (shown as a binoculars icon), which is located below the rules tables.
Note
Currently you can search for data in Source, Destination, Service, Interface, and Description table columns. When you begin to identify your search operation, you choose a data type on which to search using a list box. The available values used in the search will vary based on your selection. Find and Replace works on a table-by-table basis.
Table 12-5 identifies the data on which a search can be performed. For other values listed in tables, you can perform similar functionality using a combination of filtering and multiple rule editing features.
Related Topics
•
•
•
Find and Replace Notes
When defining your find and replace criteria, be aware of the following:
•
Note
•
•
•
Note
•
•
•
•
•
Related Topics
•
•
•
How Regular Expressions are Supported in Find and Replace
When the Allow Wildcards check box is selected, the Find and Replace fields use a proprietary regular expression syntax (in essence, Sun's Java RegEx syntax) with the exceptions that are shown in Table 12-6.
Examples of wildcard-enabled searches:
•
•
•
•
•
Examples of wildcard-enabled replacements:
•
•
•
•
Related Topics
•
•
Defining Find and Replace Criteria
Related Topics
•
•
Procedure
Step 1
The Find and Replace dialog box appears. For a description of the GUI elements, see Table I-92 on page I-123.
Note
Step 2
Step 3
Step 4
Step 5
Note
Step 6
Step 7
Step 8
Note
Step 9
•
•
•
Step 10
Using 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
Note
Related Topics
•
•
Generating Hit Count Reports
You can generate a Hit Count report from Device view only. Select the rules from the table to include in the report.
Note
Before You Begin
•
•
Related Topics
•
•
•
Procedure
Step 1
Step 2
The Access Rules page appears. For a description of the GUI elements, see Table I-1 on page I-2.
Step 3
Step 4
Note
The Hit Count report appears. For a description of the GUI elements, see Table I-106 on page I-146.
Step 5
After the refresh, the Expanded table adds a Delta column that displays the new data retrieved.
Step 6
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 12-5.)
Note
Figure 12-5 Hit Count Results Table
Report results are displayed in two forms:
•
•
Figure 12-6 Expanded Table
Figure 12-7 Raw ACE Table
For a description of the report GUI elements, see Table I-106 on page I-146.
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.
Related Topics
•
•
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
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
Related Topics
•
•
Procedure
Step 1
Step 2
The information is changed in ascending or descending order.
Step 3
Step 4
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.
Related Topics
•
Procedure
Step 1
Step 2
The table expands to display all information for the selected rule.
Step 3
Step 4
Importing Rules
The Import Rules feature acts as an accelerator for adding rules to rules tables. You can import rules (ACEs) by pasting them from an external application to the access rule table in Security Manager. You can import rules from Device view and only to Local rules.
Related Topics
•
•
•
•
Notes
•
•
•
•
•
•
•
–
–
•
Related Topics
•
•
•
Extended Access List: Example 1
In the following example, the first line permits any incoming TCP connections with destination ports greater than 1023. The second line permits incoming TCP connections to the Simple Mail Transfer Protocol (SMTP) port of host 128.88.1.2. The last line permits incoming ICMP messages for error feedback.
access-list 102 permit tcp 0.0.0.0 255.255.255.255 128.88.0.0 0.0.255.255 gt 1023access-list 102 permit tcp 0.0.0.0 255.255.255.255 128.88.1.2 0.0.0.0 eq 25access-list 102 permit icmp 0.0.0.0 255.255.255.255 128.88.0.0 255.255.255.255Related Topics
Extended Access List: Example 2
Suppose you have a network connected to the Internet, and you want any host on an Ethernet to be able to form TCP connections to any host on the Internet. However, you do not want IP hosts to be able to form TCP connections to hosts on the Ethernet except to the mail (SMTP) port of a dedicated mail host.
SMTP uses TCP port 25 on one end of the connection and a random port number on the other end. The same two port numbers are used throughout the life of the connection. Mail packets coming in from the Internet will have a destination port of 25. Outbound packets will have the port numbers reversed. The fact that the secure system behind the router always will be accepting mail connections on port 25 is what makes possible separate control of incoming and outgoing services. The access list can be configured on either the outbound or inbound interface.
In the following example, the Ethernet network is a Class B network with the address 128.88.0.0, and the address of the mail host is 128.88.1.2. The established keyword is used only for the TCP protocol to indicate an established connection. A match occurs if the TCP datagram has the ACK or RST bits set, which indicate that the packet belongs to an existing connection.
access-list 102 permit tcp 0.0.0.0 255.255.255.255 128.88.0.0 0.0.255.255 establishedaccess-list 102 permit tcp 0.0.0.0 255.255.255.255 128.88.1.2 0.0.0.0 eq 25Related Topics
Standard Access List: Example
The following configuration creates a standard access list named Internet_filter and an extended access list named marketing_group:
ip access-list standard Internet_filterpermit 1.2.3.4deny anyip access-list extended marketing_grouppermit tcp any 171.69.0.0 0.0.255.255 eq telnetdeny tcp any anypermit icmp any anydeny udp any 171.69.0.0 0.0.255.255 lt 1024deny ip any any logRelated Topics
How to Import Rules
Related Topics
•
Procedure
Step 1
The Access Rules table appears.
Step 2
Step 3
•
•
Step 4
•
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 Understanding Interface Role Objects, page 9-61.
Step 5
Step 6
Step 7
Errors are shown in red. You must correct any errors before you may continue. Errors include:
•
•
•
•
•
If no errors, the Import Rules - Status page appears.
Step 8
The Import Rules - Preview page appears.
Step 9
The status page closes and you return to the Access Rules table. The imported rules are displayed in the table.
Using 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:
•
Discontiguous masks are supported. For more information, see Contiguous and Discontiguous Network Masks, page 9-70.
•
•
•
•
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 Tools button located below any of the main firewall rules tables, then selecting Query. The Query Report can be generated from either Device view or Policy view. This procedure assumes you are requesting a query from Device view.
Related Topics
•
•
Procedure
Step 1
The Querying <Policy | Device > dialog box appears. For a description of the GUI elements, see Table I-103 on page I-136.
Step 2
Step 3
The policy query results are displayed. For more information, see Understanding Policy Query Results.
Understanding Policy Query Results
Policy query results are based on the criteria of the initial query. The results are divided into sections. See Figure 12-8.
Figure 12-8 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:
•
–
–
Note the following: If you have a rule defined with a source address of 1.1.1.1, a destination address of 2.2.2.2 and a service of IP, if your query is to search for a source of 1.1.1.1, the match status is shown as a partial match (not a complete match) because the query results represent only a portion of the rule's definition.
Similarly, if your query is to search for a source of 1.1.1.1 and the destination and service fields are left blank in the query dialog, the same results will occur. This is because a blank source or destination in the query dialog means "any"; a blank service field means "IP"; and a blank interface field means "all interfaces".
–
You might have two matching rules, A and B. Rule A appears in an ACL Details Table 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.
•
•
•
–
–
•
•
•
•
•
•
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:
Sources
Network Object A
contains
Network Object B [3.4.5.6]
Close the page after you view the contents.
Related Topics
•
•
Understanding Rule Table Sections
Rule table sections provide a convenient way to group multiple contiguous rules into sections. This can be particularly helpful when your rules tables contain large rule sets. You can collapse or expand a section to hide or view rules contained within it. Sections can be moved up or down within a rules table. Sections can also be deleted to ungroup the rules.
Related Topics
•
•
•
•
Notes About Rule Table Sections
•
•
•
•
•
•
•
•
•
•
Related Topics
•
•
•
Adding Rule Table Sections
Before You Begin
Make sure you have at least one rule defined in the rules table.
Related Topics
•
•
•
This procedure assumes you have added a rule to the Local scope.
Procedure
Step 1
Note
The Add Rule Section dialog box appear. For a description of the GUI elements, see Table I-91 on page I-122.
Step 2
The dialog box closes and you return to the main rules table. The new section name is highlighted and the section is shown in a collapsed state. Also shown are the number of rules currently contained within the new section and any description that was added.
Adding Rules to an Existing Table Section
You can add rules to an existing table section using a variety of methods.
•
•
•
Related Topics
•
Removing Rules from an Existing Table Section
To remove rules from an existing table section, right-click the rows, then select Remove From Section <Section Name>.
The rules previously contained in the section are relocated to the Local scope.
Related Topics
•
Editing a Rule Table Section
Related Topics
•
Procedure
Step 1
The Edit Rule Section dialog box appears. For a description of the GUI elements, see Table I-91 on page I-122.
Step 2
The dialog box closes and you return to the main rules table with the new section information displayed.
Removing a Rule Table Section
Related Topics
•
Procedure
Step 1
Step 2
The section is removed and the rules previously contained in the section are relocated to the Local scope.
Optimizing ACLs in Rules
You can choose to have Security Manager optimize access control lists (ACLs) to remove redundancies and conflicts that are common in real world firewall ACLs. Optimization can also combine several access control entries (ACEs) into a single ACE, making the ACL more concise.
Firewall memory consumption can become a problem, especially on devices with limited, non-expandable memory, such as the FWSM, which can be shared among multiple virtual contexts. ACL optimization, which is done during deployment, reduces the ACL size by removing redundant or conflicting ACEs or merging multiple ACEs into one, if possible. Consider the following examples:
Example 1
access-list acl_mdc_inside_access deny ip host 10.2.1.1 any
access-list acl_mdc_inside_access deny ip 10.2.1.0 255.255.255.0 any
The first ACE is actually a subset of the second ACE. When you deploy the configuration to the device and ACL optimization is turned on, only one ACE is generated: access-list acl_mdc_inside_access deny ip 10.2.1.0 255.255.255.0 any
Example 2
access-list acl_mdc_inside_access permit tcp any any range 110 120
access-list acl_mdc_inside_access deny tcp any any range 115
The second ACE will never be hit. ACL optimization will remove the second ACE and deploy only the first one.
Example 3
access-list myacl permit ip 1.1.1.0 255.255.255.128 any
access-list myacl permit ip 1.1.1.128 255.255.255.128 any
The two ACEs are merged into one: access-list myacl permit ip 1.1.1.0 255.255.255.0 any
You can turn on ACL optimization through a property file, which is located at: <CSCOpx>\MDC\athena\config\csm.properties.
Modification to the property file regarding ACL optimization takes effect during the next deployment. You do not need to restart the Daemon Manager.
You can also specify the optimization level in the property file. Each property matches to one device. The key of the property is OPTIMIZE.<Device name displayed in CS_Manager>.The value of the property is the optimization type. Three types are supported:
•
•
•
The following is sample CLI found in the property file:
OPTIMIZE.C514583-FWSM3.net.xyz.net=full
OPTIMIZE.C513967-FWSM3.net.xyz.net=preserve_og
In the deployment summary dialog, optimization results are summarized as an informational message that includes the original number of ACEs before optimization and the number of ACEs after optimization. Results are saved to a file on the server at <CSCOpx>\MDC\temp. A job ID is used as part of the filename.
To view the optimization report, turn on Advanced Debugging, which is located in Tools > Security Manager Administration > Deployment. The optimizer takes a policy and tries to reduce the number of ACEs without changing the semantics of the policy, so the "function" of an optimized ACL remains unchanged. That is, the optimized ACL accepts or denies the same set of packets as did its unoptimized form. Four basic cases for optimization are considered. Note that in these cases, ACE[x] is listed before ACE[y].
•
•
Note
•
Note
•
Notes about ACL Optimization
•
•
•
•
–
–
•
•
•
•
•
•
•
Caveats To ACL Optimization
•
•
If no rules are selected when you initialize a hit count report, a results window might appear, but no corresponding ACEs are listed for a selected rule in the report rules table.
•
Related Topics
Optimizing Policy Objects in Rules
You can elect to have Security Manager optimize network policy objects when you generate configurations for PIX, FWSM, and ASA devices for deployment. Optimization merges adjacent networks and removes redundant network entries.
Optimization helps reduce the size of the runtime access-list data structures on the device and the literal configuration size (to a lesser extent). A reduced runtime memory usage consumed by access-lists is particularly beneficial for FWSM devices, where the network processor memory is tight, and PIX devices that use Turbo ACLs.
Consider the following example for a network policy object named Test that contains the following sources and destinations:
192.168.1.0/24192.168.1.2310.1.1.010.1.1.110.1.1.2/31When optimization is on, the following CLIs are generated:
object-group network testnetwork-object 192.168.1.0 255.255.255.0network-object 10.1.1.0 255.255.255.252To turn optimization on, select Tools > Security Manager Administration, then select Deployment. Select Optimize Network Object Groups During Deployment (PIX, ASA, FWSM).
Related Topics
•
Notes about Policy Object Optimization
•
•
•
•
•
Related Topics
•
Expanding Object Groups During Discovery
You can elect to expand object groups when you import devices. During the discovery process, Security Manager imports the CLI comprising the object group as separate rules.
During device import, you can elect to expand an object group as separate rules instead of importing the object group name. To access this feature, select Tools > Security Manager Administration > Discovery.
Consider the example where CSM_INLINE_55 contains 1.1.1.1, 2.2.2.2, 5.5.5.5. During import, CSM_INLINE_55 will be expanded to one rule in the rule table that will identify 1.1.1.1, 2.2.2.2, and 5.5.5.5 as a source.
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 Using Analysis.
Your organization might dictate the need for using a large number of ACLs, which can affect performance and memory usage in Security Manager and on the device. As a result, you might want to combine rules and group objects of a similar type, thus facilitating your ability to maintain them. For more information, see Combining Rules.
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 Using Hit Count.
You might want to import ACEs by pasting them from an external application to the access rule table, or by importing them from a file. For more information, see Importing Rules.
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 Using Policy Query.
To help you manage the thousands of rules that might be listed in your rules tables, you can search for policy objects and text references that are used to define the rules, thus facilitating your ability to locate rules. For more information, see Adding Access Rules.
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
•
Notes About Access Rules
•
•
•
–
–
–
–
•
•
•
Related Topics
•
Working with Access Rules
When configuring access rules, you should:
1.
2.
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 7-39, 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 7-39.
Note
In the absence of an ACL:
•
•
•
•
Related Topics
•
•
•
•
Procedure
Step 1
Step 2
The Access Rules page appears. For a description of the GUI elements, see Table I-1 on page I-2.
Step 3
The Add Firewall Rule dialog box appears. For a description of the GUI elements, see Table I-2 on page I-5.
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 Understanding Service Objects, page 9-86.
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 Understanding Interface Role Objects, page 9-61.
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 Understanding Time Range Objects, page 9-108.
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. The new rule information is displayed.
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 7, "Managing Policies".
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 18, "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 7-24.
Note
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 or using the shortcut key (Ctrl+E), 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 create network/host policy objects from source and destination cell contents using the shortcut menu. Right-click an entry in the table cell, then select Create Network Object from Cell Contents. For more information, see Understanding Network/Host Objects, page 9-68.
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.
You can use the table filter to filter the information displayed in the table. Click the arrow to display the filtering bar, which enables you to set filtering parameters. See Filtering Tables, page 3-17.
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
Related Topics
•
•
•
•
Note
Procedure
Step 1
Step 2
The Access Rules page appears. For a description of the GUI elements, see Table I-1 on page I-2.
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 7, "Managing Policies".
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 18, "Managing Deployment".
Enabling and Disabling Access Rules
This procedure assumes you are working from Device view.
Notes
•
•
Related Topics
Procedure
Step 1
Step 2
The Access Rules page appears. For a description of the GUI elements, see Table I-1 on page I-2.
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 7, "Managing Policies".
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 18, "Managing Deployment".
Cutting, Copying, and Pasting Access Rules
This procedure assumes you are working from Device view.
Related Topics
•
•
Procedure
Step 1
Step 2
The Access Rules page appears. For a description of the GUI elements, see Table I-1 on page I-2.
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 7, "Managing Policies".
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 18, "Managing Deployment".
Note
Moving Access Rules Up and Down
This procedure assumes you are working from Device view.
Related Topics
•
Procedure
Step 1
Step 2
The Access Rules page appears. For a description of the GUI elements, see Table I-1 on page I-2.
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 7, "Managing Policies".
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 18, "Managing Deployment".
Note
Deleting Access Rules
This procedure assumes you are working from Device view.
Related Topics
•
Procedure
Step 1
Step 2
The Access Rules page appears. For a description of the GUI elements, see Table I-1 on page I-2.
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 7, "Managing Policies".
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 18, "Managing Deployment".
You can verify the deletion of the rule by viewing an audit report. To generate an audit report, select Tools > Audit Report.
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 Using Policy Query.
Related Topics
•
•
Working with Inspection Rules
When you configure inspection rules on appliances running ASA/PIX 7.0, access-list, policy-map/class-map commands are generated.
When you configure inspection rules on FWSMs and PIX 6.3 devices, fixup commands are generated.
When you configure inspection rules on routers running IOS 12.3 and later,ip-inspect commands are generated.
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 7-39, 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 7-39.
The following procedure describes how to add an inspection rule.
Related Topics
•
•
•
•
•
Procedure
Step 1
Step 2
The Inspection Rules page appears. For a description of the GUI elements, see Table I-15 on page I-21.
Step 3
The Add Inspection Rule page appears. For a description of the GUI elements, see Table I-16 on page I-24.
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 Understanding Interface Role Objects, page 9-61.
Step 8
•
•
•
•
Note
Step 9
Step 10
Step 11
The appropriate wizard guides you through the configuration.
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.
Related Topics
•
•
•
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 7, "Managing Policies".
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 18, "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 7-24.
Note
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.
Related Topics
•
•
•
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 7, "Managing Policies".
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 18, "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 7-24.
Note
Configuring Destination Address and Port (IOS)
This procedure assumes you selected Destination IP Address (IOS) as the type of traffic matched for inspection rules.
Related Topics
•
•
•
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 7, "Managing Policies".
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 18, "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 7-24.
Note
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.
Related Topics
•
•
•
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 Understanding Service Objects, page 9-86.
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 7, "Managing Policies".
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 18, "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 7-24.
Note
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 double-clicking a rule number in the table or using the shortcut key (Ctrl+E), 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.
You can use the table filter to filter the information displayed in the table. Click the arrow to display the filtering bar, which enables you to set filtering parameters. See Filtering Tables, page 3-17.
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
Note
Related Topics
•
•
•
•
•
Note
Procedure
Step 1
Step 2
The Inspection Rules page appears. For a description of the GUI elements, see Table I-15 on page I-21.
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 7, "Managing Policies".
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 18, "Managing Deployment"
Enabling and Disabling Inspection Rules
This procedure assumes you are working from Device view.
Notes
•
•
Related Topics
•
Procedure
Step 1
Step 2
The Inspection Rules page appears. For a description of the GUI elements, see Table I-15 on page I-21.
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 7, "Managing Policies".
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 18, "Managing Deployment"
Cutting, Copying, and Pasting Inspection Rules
This procedure assumes you are working from Device view.
Related Topics
•
•
Procedure
Step 1
Step 2
The Inspection Rules page appears. For a description of the GUI elements, see Table I-15 on page I-21.
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 7, "Managing Policies".
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 18, "Managing Deployment"
Moving Inspection Rules Up and Down
This procedure assumes you are working from Device view.
Related Topics
•
Procedure
Step 1
Step 2
The Inspection Rules page appears. For a description of the GUI elements, see Table I-15 on page I-21.
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 7, "Managing Policies".
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 18, "Managing Deployment"
Deleting Inspection Rules
This procedure assumes you are working from Device view.
Related Topics
•
Procedure
Step 1
Step 2
The Inspection Rules page appears. For a description of the GUI elements, see Table I-15 on page I-21.
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 7, "Managing Policies".
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 18, "Managing Deployment".
You can verify the deletion of the rule by viewing an audit report. To generate an audit report, select Tools > Audit Report.
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 Using 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 7-39, 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 7-39.
Related Topics
•
•
•
Procedure
Step 1
Step 2
The AAA Rule page appears. For a description of the GUI elements, see Table I-42 on page I-54.
Step 3
The Add AAA Rule page appears. For a description of the GUI elements, see Table I-43 on page I-57.
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 Understanding Service Objects, page 9-86.
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 Understanding AAA Server Group Objects, page 9-10.
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 Understanding Interface Role Objects, page 9-61.
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 7, "Managing Policies".
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 18, "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 7-24.
Note
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 or using the shortcut key (Ctrl+E), 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 create network/host policy objects from Source and Destination cell contents using the shortcut menu. Right-click an entry in the table cell, then select Create Network Object from Cell Contents. A network object is created that comprises all sources and destinations identified in the table cell.
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.
You can use the table filter to filter the information displayed in the table. Click the arrow to display the filtering bar, which enables you to set filtering parameters. See Filtering Tables, page 3-17.
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
To edit AAA rules information, follow the procedure for Adding AAA Rules or use any of the methods described above.
The following procedure assumes you are working from Device view.
Related Topics
Procedure
Step 1
Step 2
The AAA Rules page appears. For a description of the GUI elements, see Table I-42 on page I-54.
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 7, "Managing Policies".
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 18, "Managing Deployment"
Enabling and Disabling AAA Rules
This procedure assumes you are working from Device view.
Notes
•
•
Related Topics
Procedure
Step 1
Step 2
The AAA Rules page appears. For a description of the GUI elements, see Table I-42 on page I-54.
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 7, "Managing Policies".
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 18, "Managing Deployment"
Cutting, Copying, and Pasting AAA Rules
This procedure assumes you are working from Device view.
Related Topics
Procedure
Step 1
Step 2
The AAA Rules page appears. For a description of the GUI elements, see Table I-42 on page I-54.
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 7, "Managing Policies".
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 18, "Managing Deployment".
Moving AAA Rules Up and Down
Related Topics
Procedure
Step 1
Step 2
The AAA Rules page appears. For a description of the GUI elements, see Table I-42 on page I-54.
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 7, "Managing Policies".
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 18, "Managing Deployment"
Deleting AAA Rules
This procedure assumes you are working from Device view.
Related Topics
•
Procedure
Step 1
Step 2
The AAA Rules page appears. For a description of the GUI elements, see Table I-42 on page I-54.
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 7, "Managing Policies".
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 18, "Managing Deployment".
You can verify the deletion of the rule by viewing an audit report. To generate an audit report, select Tools > Audit Report.
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 Using 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 (PIX/ASA)
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 7-39, 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 7-39.
Related Topics
•
•
•
•
•
Procedure
Step 1
Step 2
The Web Filter Rules page appears. For a description of the GUI elements, see Authentication Tab, page K-59.
Step 3
The Add PIX/ASA Web Filter Rule dialog box appears. For a description of the GUI elements, see Table I-57 on page I-74.
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 Understanding Service Objects, page 9-86.
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 7, "Managing Policies".
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 18, "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 7-24.
Note
Editing Web Filter Rules (PIX/ASA)
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 or using the shortcut key (Ctrl+E), 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.
You can use the table filter to filter the information displayed in the table. Click the arrow to display the filtering bar, which enables you to set filtering parameters. See Filtering Tables, page 3-17.
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
Related Topics
•
•
•
Procedure
Step 1
Step 2
The Web Filter Rules page appears. For a description of the GUI elements, see Authentication Tab, page K-59.
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 7, "Managing Policies".
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 18, "Managing Deployment".
Enabling and Disabling Web Filter Rules (PIX/ASA)
This procedure assumes you are working from Device view.
Notes
•
•
Related Topics
•
•
•
Procedure
Step 1
Step 2
The Web Filter Rules page appears. For a description of the GUI elements, see Authentication Tab, page K-59.
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 7, "Managing Policies".
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 18, "Managing Deployment".
Cutting, Copying, and Pasting Web Filter Rules (PIX/ASA)
Related Topics
•
•
•
•
Procedure
Step 1
Step 2
The Web Filter Rules page appears. For a description of the GUI elements, see Authentication Tab, page K-59.
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 7, "Managing Policies".
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 18, "Managing Deployment".
Moving Web Filter Rules Up and Down (PIX/ASA)
Related Topics
•
•
•
Procedure
Step 1
Step 2
The Web Filter Rules page appears. For a description of the GUI elements, see Authentication Tab, page K-59.
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 7, "Managing Policies".
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 18, "Managing Deployment".
Deleting Web Filter Rules (PIX/ASA)
This procedure assumes you are working from Device view.
Related Topics
•
•
•
•
Procedure
Step 1
Step 2
The Web Filter Rules page appears. For a description of the GUI elements, see Authentication Tab, page K-59.
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 7, "Managing Policies".
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 18, "Managing Deployment".
You can verify the deletion of the rule by viewing an audit report. To generate an audit report, select Tools > Audit Report.
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 7-39, 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 7-39.
Related Topics
•
•
•
•
•
•
Procedure
Step 1
Step 2
The Web Filter Rules page for IOS devices appears. The Web Filter Rules tab opens by default the first time the page is accessed. For a description of the GUI elements, see Table I-67 on page I-88.
Step 3
The IOS Web Filter Rule and Applet Scanner dialog box appears. For a description of the GUI elements, see Table I-70 on page I-92.
Step 4
Step 5
•
•
For more information, see Understanding Interface Role Objects, page 9-61.
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 Understanding Network/Host Objects, page 9-68.
Step 10
The IOS Web Filter Rule and Applet Scanner dialog box closes and you return to the Web Filter Rules page. The rule information is shown in the table.
Step 11
•
•
Step 12
The IOS Web Filter Exclusive Domain Name dialog box appears. For a description of the GUI elements, see Table I-71 on page I-94.
Step 13
Step 14
Step 15
The IOS Web Filter Exclusive Domain Name dialog box closes and you return to the Web Filter Rules page. The new 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 7, "Managing Policies".
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 18, "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 7-24.
Note
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.
Related Topics
•
•
•
•
•
Procedure
Step 1
Step 2
The Web Filter Rules page for IOS devices appears. For a description of the GUI elements, see Table I-67 on page I-88.
Step 3
The IOS Web Filter Rule and Applet Scanner dialog box appears. For a description of the GUI elements, see Table I-70 on page I-92.
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 7, "Managing Policies".
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 18, "Managing Deployment".
Deleting Web Filter Rules (IOS)
Related Topics
•
•
•
•
This procedure assumes you are working from Device view.
Procedure
Step 1
Step 2
The Web Filter Rules page for IOS devices appears. For a description of the GUI elements, see Table I-67 on page I-88.
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 7, "Managing Policies".
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 18, "Managing Deployment".
You can verify the deletion of the rule by viewing an audit report. To generate an audit report, select Tools > Audit Report.
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 7-39, 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 7-39.
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.
Related Topics
•
•
•
•
Procedure
Step 1
Step 2
The Web Filter Rules page for IOS devices appears. For a description of the GUI elements, see Table I-67 on page I-88.
Step 3
Step 4
The IOS Web Filter Exclusive Domain Name dialog box appears. For a description of the GUI elements, see Table I-71 on page I-94.
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 7, "Managing Policies".
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 18, "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 7-24.
Note
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.
Related Topics
•
•
•
•
Procedure
Step 1
Step 2
The Web Filter Rules page for IOS devices appears. For a description of the GUI elements, see Table I-67 on page I-88.
Step 3
Step 4
The IOS Web Filter Exclusive Domain Name dialog box appears. For a description of the GUI elements, see Table I-71 on page I-94.
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 7, "Managing Policies".
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 18, "Managing Deployment"
Deleting Exclusive Domains (IOS)
This procedure assumes you are working from Device view.
Related Topics
•
•
•
•
Procedure
Step 1
Step 2
The Web Filter Rules page for IOS devices appears. For a description of the GUI elements, see Table I-67 on page I-88.
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 7, "Managing Policies".
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 18, "Managing Deployment".
You can verify the deletion of the rule by viewing an audit report. To generate an audit report, select Tools > Audit Report.
Working with Transparent Firewall Rules
Transparent Firewall is a feature that enables you to add a transparent firewall device into an existing network without having to reconfigure statically defined devices. Thus, the tedious and costly overhead that is required to renumber devices on the trusted network is eliminated.
Transparent firewall rules enable you to specify VLAN-based Layer 2 (L2) interfaces. Use of firewall devices is within the same subnet. Only EtherType rules are configured as firewall policies. To configure other types of transparent firewall features, selectPlatform > Bridging.
Transparent Firewall includes the following features:
•
–
–
•
•
•
•
•
•
•
When configuring EtherType rules, you should:
1.
2.
3.
From the Transparent 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 Using Policy Query.
The following topics will help you work with transparent rules:
•
•
•
•
Adding Transparent 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 7-39, 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 7-39.
Related Topics
•
•
•
•
•
Procedure
Step 1
Step 2
The Transparent Rules page appears. For a description of the GUI elements, see Table I-72 on page I-94.
Step 3
The Add Transparent Firewall Rule dialog box appears. For a description of the GUI elements, see Table I-73 on page I-96.
Step 4
Step 5
Step 6
If you are using the Object Selector dialog box, do one of the following, then click OK:
•
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 Understanding Interface Role Objects, page 9-61.
Step 7
Step 8
Step 9
Step 10
Step 11
For PIX/FWSM/ASA, the description is mapped to access-list remark.
Step 12
The dialog box closes and you return to the Transparent Rules page.
Step 13
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 7, "Managing Policies".
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 18, "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 7-24.
Note
Editing Transparent Rules
To facilitate the editing process, Firewall Services offers the ability to perform inline editing on transparent 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 or using the shortcut key (Ctrl+E), 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.
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 use the table filter to filter the information displayed in the table. Click the arrow to display the filtering bar, which enables you to set filtering parameters. See Filtering Tables, page 3-17.
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
Related Topics
•
•
•
Procedure
Step 1
Step 2
The Transparent Rules page appears. For a description of the GUI elements, see Table I-72 on page I-94.
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 7, "Managing Policies".
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 18, "Managing Deployment"
Enabling and Disabling Transparent Rules
This procedure assumes you are working from Device view.
Notes
•
•
Related Topics
•
•
Procedure
Step 1
Step 2
The Transparent Rules page appears. For a description of the GUI elements, see Table I-72 on page I-94.
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 7, "Managing Policies".
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 18, "Managing Deployment"
Cutting, Copying, and Pasting Transparent Rules
This procedure assumes you are working from Device view.
Related Topics
•
•
•
Procedure
Step 1
Step 2
The Transparent Rules page appears. For a description of the GUI elements, see Table I-72 on page I-94.
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 7, "Managing Policies".
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 18, "Managing Deployment"
Moving Transparent Rules Up and Down
This procedure assumes you are working from Device view.
Related Topics
•
•
Procedure
Step 1
Step 2
The Transparent Rules page appears. For a description of the GUI elements, see Table I-72 on page I-94.
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 7, "Managing Policies".
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 18, "Managing Deployment"
Deleting Transparent Rules
This procedure assumes you are working from Device view.
Related Topics
•
•
•
Procedure
Step 1
