Table Of Contents
Configuring Access Rules
Defining Access Rules
Types of Access Rules
Understanding How Access Rule Are Generated
Understanding How Firewall Devices Store Access Rules
Understanding the Access Rules Table
Using the Filter Feature
Using the Highlight Feature
Using Categories, Color Coding, and Filtering
Using the Conflict Detection Feature
Important Notes About Access Rules
Logging Events for an ACE
Configuring Access Rule Tables
Inserting or Editing a Firewall Rule
Inserting or Editing an AAA Rule
Inserting or Editing a Web Filter Rule
Inserting or Editing an Ethertype Rule
Cutting, Copying, or Pasting an Access Rule
Deleting an Access Rule
Optimizing Your Policy Rules and Performance
Using Group Discovery
Using Turbo ACLs
Configuring Access Rules
Access rules are used to define your network security policy; they control the traffic that flows through a firewall device. Access rules are recognized in the form of an ordered list, which is represented in Firewall MC as a table. Rules are processed by a firewall device from first to last. When a rule matches the network traffic that a firewall device is processing, the firewall device uses that rule's action to decide if traffic is permitted. To access this feature, select Configuration > Access Rules.
Before setting up and deploying access rules, you should understand these topics:
•
Defining Access Rules
•
Types of Access Rules
•
Understanding How Access Rule Are Generated
•
Understanding How Firewall Devices Store Access Rules
•
Understanding the Access Rules Table
•
Configuring Access Rule Tables
•
Optimizing Your Policy Rules and Performance
Defining Access Rules
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 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. Each access rule defined in Firewall MC will eventually correspond to a single entry in the ACL for an interface on a particular firewall device.
Access rules can be applied to the Global group, its subgroups, or individual devices. Access rules are grouped by the interface on which they are configured and enforced.
Firewall MC sorts the rules by interface and uses the remaining information in the rule to create the access control entry (ACE) that will be included in the ACL for that interface.
Types of Access Rules
Firewall MC divides access rules into four categories:
•
Firewall rules—Rules that permit or deny a packet based on source address, destination address, source interface, and service. For more information on firewall rules, see Inserting or Editing a Firewall Rule.
•
AAA rules—Rules that control authentication, authorization, or accounting for traffic.
To define AAA rules, you must first define the rule on the firewall device in the firewall rules table. The firewall rule defines the traffic between the source and destination, and identifies the services for which the rule applies.
After you identify the source and destination for which traffic is permitted, you must define the rules in the AAA Rules table and identify the AAA control type. For more information on AAA rules, see Inserting or Editing an AAA Rule.
•
Filter rules—Rules that specify filter URLs using a filtering server such as Websense.
To define filter rules, you must first define the rule on the firewall device in the firewall rules table. The firewall rule defines the traffic between the source and destination, and identifies the services for which the rule applies. After you identify the source and destination for which traffic is permitted, you must define the rules in the Web Filter Rules table and determine whether to permit or deny traffic if the filter server is unavailable. For more information on filter rules, see Inserting or Editing a Web Filter Rule.
•
Ethertype rules— Ethertype rules are used to configure non-IP related traffic policies through the firewall when operating in transparent mode. In transparent mode, you can apply both extended and ethertype access rules to an interface. For more information on ethertype rules, see Inserting or Editing an Ethertype Rule.
Understanding How Access Rule Are Generated
Firewall MC is based on a hierarchical list of device groups containing firewall devices. Rules defined at each group (also referred to as a scope) can be designated as either mandatory or default, as shown in the Firewall MC GUI; rules defined at the device scope are designated as default only. The mandatory and default access rules generate a block of ACEs. These ACEs are concatenated to form the ACL for an interface on the firewall device. Within each group, access rules are evaluated in the same order as you configure them. This is the default method used to permit or block traffic. The order of concatenation is:
1.
Mandatory access rules defined at each group level.
2.
Device access rules defined directly at the device level.
3.
Default access rules defined at each group level.
Note
To determine which rules apply to a device, you identify the mandatory rules for each enclosing group before rules set at the device level, then identify the default rules for each enclosing group after rules set at the device level.
The ACEs from the mandatory rules are ordered from the highest group (Global) down to the group that directly contains the device that cannot be overridden. The ACEs from the Default rules are ordered in the opposite direction and can be overridden.
It is likely that the resulting ACL will have ACEs that are either redundant or conflicting. Because a firewall device uses the first-match method to evaluate ACLs, these extraneous entries do not cause a problem. Mandatory rules are listed first, so they take precedence over any rules that come later. The device rules take effect only if no relevant mandatory rules apply. Finally, the default rules apply if no mandatory or device-specific rules apply.
When you select Configuration > Access Rules, the page opens to display the default firewall rules for the scope selected. If no scope is selected, the Global scope is displayed.
Note
Access rules defined at the device level must be defined from Firewall MC in order to be displayed in the access rules tables.
Rules and other changes entered directly to the device are not recognized by Firewall MC. If the device has several changes that you want recognized by Firewall MC, you must delete the device, then reimport it; however, doing so results in the loss of any previous hierarchical structure, as all settings will be defined at the device scope.
If permanent changes are entered directly to the device, you can be made aware of such changes by requesting that Firewall MC generate an error or warning before you deploy updated configurations to the device. To access this feature, select Configuration > MC Settings > Management.
•
A warning permits the deployment to continue and a message appears in the deploy status window.
•
An error denies the deployment.
For more information, see Configuring Management Controls, page 3-13.
Understanding How Firewall Devices Store Access Rules
A firewall device uses the Adaptive Security Algorithm (ASA) to allow one-way (inside to outside) connections without an explicit configuration for each internal system and application. An example of ASA in action is FTP. The ASA 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 ASA is a stateful approach to security. Every inbound packet is checked against the ASA 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 firewall device is associated with a list of access control entries (ACEs), called access control lists (ACLs). 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. You can also define authentication, authorization, and accounting (AAA), and web filtering.
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, 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.
Understanding the Access Rules Table
Figure 11-1 shows the user interface for setting color coding, highlighting, and filtering features in the rule tables.
Figure 11-1 Rule Table User Interface for Color Coding, Highlighting,
and Filtering

|
Reference
|
Element
|
Description
|
1
|
Column list
|
Displays all rule table column headings.
Note Column headings vary depending on the table you are viewing.
|
2
|
Text field
|
Allows you to specify an element based on your selection in the column list.
|
3
|
Filter icon
|
Displays all rules based on the filtering selection.
|
4
|
Highlight icon
|
Highlights all rules associated with the selected category.
|
5
|
Color list
|
Displays color selections.
• None—(Default). No color coding is used.
• Rules—All rules associated with the selected category are color coded.
• Building Blocks—All building blocks associated with the selected category are color coded.
Note Figure 11-1 shows color coding being used to display rules in the table.
|
6
|
Popup icon
|
Opens an expanded popup window.
|
7
|
Action buttons
|
Provide the ability to manage access rule tables.
Note You can right-click inside the rule table to open a menu of available action buttons, which simulates the act of clicking the button.
|
8
|
Remove Filter icon
|
Removes filtering query results and displays rule table in its entirety.
Note The Remove Filtering icon is visible only after you request Filtering.
|
9
|
Filter field
|
Displays initial filtering query request. Allows you to make a nested filter query request based on initial filtering query request results.
Note The Filter field is visible only after you request Filtering.
|
Table 11-1 defines the action buttons used to configure access rules.
Table 11-1 Access Rule Tables Action Buttons
Action Button
|
Description
|
Insert
|
Adds a row in an ordered table.
|
Edit
|
Edits an existing row in a table.
|
View
|
Shows information in read-only mode.
|
Copy
|
Copies a row in a table.
|
Cut
|
Removes a row in a table.
|
Paste
|
Pastes a row that was copied or cut from a table.
|
Delete
|
Removes a row from a table.
|
Discover Groups
|
Analyzes and restructures ACLs into groups to facilitate maintenance and offer greater ease-of-use when you view rule tables. See Using Group Discovery.
|
Detect Conflicts
|
Analyzes and displays rules that overlap or conflict with other rules. The analysis is performed using the rules defined at the current scope and the mandatory and default rules defined in their parent scope in the hierarchy. See Using the Conflict Detection Feature.
|
View All
|
Displays all rules (mandatory and default) defined from Global down to the current scope.
For Web Filter Rules, displays all rules in one table because these rules are no longer divided into mandatory and default. The Scope of the rule is shown in the Scope column and device rules are listed before parent groups.
|
Using the Filter Feature
The rule table can be filtered according to a particular value in a column, making it easier for you to reduce the number of visible rows and maintain objects in the rule tables.
Step 1
Select the column to filter from the column list, for example, Service.
Step 2
Enter an element to filter based on your selection in the column list, for example, TCP. Text is not case-sensitive.
Step 3
Click the Filter icon.
The table displays a subset of the total rows that include your selected filter criteria.
Step 4
To use color coding, select from the Color list whether to color rules in the table (colors the entire row) or building blocks (colors building block objects) contained within rules in the table.
Step 5
After you view the results, you can do either of the following:
•
Remove the filter by clicking the Remove Filtering icon.
•
Make another filter request based on the initial filter results (nested filtering).
Using the Highlight Feature
The Highlight feature allows you to search for a particular value in the table without trimming the displayed data. When you highlight a row, the appearance of the row number changes to a display a white foreground and black background.
Step 1
Select the column to filter from the column list, for example, Service.
Step 2
Enter an element to filter based on your selection in the column list, for example, TCP. Text is not case-sensitive.
Step 3
Click the Highlight icon.
The table highlights all rows based on your selected highlight criteria.
Step 4
To remove highlighting, click the Highlight icon again.
Using Categories, Color Coding, and Filtering
The Categories feature is designed to provide an intermediate level of detail to objects to help you categorize and readily identify rules and building blocks in access rule tables. You can assign a category to a rule or building block when you create the rule, or you can edit the rule or building block to include category information later.
Each category is assigned a background and foreground color that is displayed in the access rule tables. Depending on your specific needs, you can use color to display rules based on the rule category, building block objects based on the building block category, or both. You can also choose to use no color coding at all. Default categories and color combinations are provided; however, you can create your own categories and assign different background and foreground color combinations to them.
Before you can use the categories feature in a rule table, you must define the categories. To access the Categories feature, select Configuration > Building Blocks > Categories. For information on how to configure categories, see Using Categories and Color-Coding, page 10-5.
After you define your categories in building blocks, the next step is to assign a category to an access rule. You can select a category from a list when you insert or edit a rule. The list contains all categories that you previously defined in building blocks.
The following are some examples of associating color coding with access rules:
•
An e-commerce customer implemented a B2B network. This customer recently had to shut down the site for more than 1 day because partner connectivity was disrupted and no sales orders could be taken. The diagnosis revealed that certain ACLs for the B2B partners were inadvertently deleted.
This e-commerce customer needs the capability to associate a color (for example, red) with all access rules that are vital for the B2B network. All security admins and network admins at the company require written permission from the CIO before they can modify or delete any red rules.
•
The economic downturn forced a start-up company to create nonfinancial incentives to retain its employees. The CTO would like to allow MP3 files to be downloaded in the test lab so engineers can listen to music while they work. This is a contentious issue for the managers and lab administrators at other development sites.
The start-up company would like the capability to associate a color (for example, green) with all rules that relate to downloading MP3 files to the engineering labs. This would allow each development site to readily change the rules depending on the decision of each site.
•
A service provider must reduce costs by 50 percent or go out of business. After a lengthy investigation, the company discovered it could reduce the security budget by 50 percent by "re-using" existing firewalls for multiple customers. The company wants to explore the possibility of hosting 10 customers on a single firewall. The ability to set up virtual firewalls is not an option since capital expenditures were cut for new purchases until calendar year 2004.
The service provider needs to associate rules belonging to each customer in a single rule table, and to associate a color for each customer's rules to allow for easy debugging of specific customer problems. The service provider estimates more than 5,000 rules for the 10 customers and needs the capability to find all rules for each customer.
•
The security operations staff of an Enterprise 100 company estimates that they spend 20 percent of their time dealing with complaints from the Finance department. The Finance department is quick to report any delays in accessing their applications and has learned they can blame network outages as an excuse for not delivering financial reports on time.
The Enterprise 100 company wants to identify any rule that will affect the Finance department's access to key applications. The rules that affect the Finance department should be displayed with a color so that the Security Operations department can maintain these rules and verify how often the Finance department is trying to access their applications.
Using the Conflict Detection Feature
The Conflict Detection feature analyzes and reports rules that overlap or conflict with other rules.
The analysis is performed using the rules defined at the current scope and the mandatory and default rules defined in their parent scope in the hierarchy. The analysis does not include rules defined at the child scope. For example, a system administrator has set up the following group hierarchy:
Global > East Coast > New York > PIX-1
If a rule conflict analysis is performed with the current scope set at New York, these the rule sets would be analyzed in the following order:
1.
Mandatory rules (Global)
2.
Mandatory rules (East Coast)
3.
Current rules (New York)
4.
Default rules (East Coast)
5.
Default rules (Global)
Some of the types of conflicts that the Conflict Detection feature reports include:
•
Exact match ( Table 11-2).
•
Opposite rules ( Table 11-3).
•
A lower rule that will never be used ( Table 11-4).
•
The first rule contained in a second rule ( Table 11-5).
Table 11-2 Exact Match
Source
|
Target
|
Protocol
|
Allow/Deny
|
my-PC
|
Mail-Servers
|
smtp-25
|
Allow
|
my-PC
|
Mail-Servers
|
smtp-25
|
Allow
|
Table 11-3 Opposite Rules
Source
|
Target
|
Protocol
|
Allow/Deny
|
my-PC
|
Mail-Servers
|
smtp-25
|
Allow
|
my-PC
|
Mail-Servers
|
smtp-25
|
Deny
|
Table 11-4 Lower Rule Never Used
Source
|
Target
|
Protocol
|
Allow/Deny
|
PC-subnet (192.168.101.0/24
|
Print-Server
|
lpr-515
|
Allow
|
my-PC (192.168.101.50)
|
Print-Server
|
lpr-515
|
Deny
|
Table 11-5 First Rule Contained In Second Rule
Source
|
Target
|
Protocol
|
Allow/Deny
|
PC-subnet (192.168.101.0/24
|
Web-Proxy1
|
80
|
Allow
|
Trusted-Nets (192.168.0.0/16)
|
Web-Proxy1
|
80
|
Allow
|
To perform an analysis of conflicting rules, follow these steps:
Step 1
Using the Object Selector, select the scope (if not already selected) to identify the device or device group in which the rules to be analyzed reside.
Note
The Object bar displays the last scope that was selected under the Configuration tab.
Step 2
Select Configuration > Access Rules > (Rules type) > [Mandatory or Default] (for example, Configuration > Access Rules > Firewall Rules > Mandatory).
Step 3
Click Detect Conflicts.
The Firewall Rule Conflict Report appears. The report contains two types of tables: the summary table and the detailed table.
The summary table lists higher-priority rules that conflict with other, lower-priority rules within its group hierarchy. Each row contains information about the higher-priority rule, with the last column in the row (the Conflict No. column) providing the number of conflicts with other, lower-priority rules.
The detailed table provides information about the lower-priority rules conflicting with the higher-priority rules listed in the summary table. First the higher priority rule is listed; then all lower-priority rules conflicting with the higher-priority rule are listed.
See Table 11-6 for descriptions of the report.
Table 11-6 Firewall Rule Conflict Report
Column
|
Description
|
Scope
|
Scope of the rule shown in the row.
|
Type
|
Type of rule—mandatory or default.
|
Rule No.
|
Index of the rule in its rule table.
For example, if the first rule at the Global Mandatory level conflicts with lower priority rules, and the first rule at the East Coast Mandatory level conflicts with lower priority rules, then both will appear in the summary table, and both will be numbered 1.
Click a the rule number to see conflict details.
|
Permit
|
Describes what should occur depending on conditions set.
• Permit—Allows traffic.
• Deny—Denies traffic.
|
Source Address
|
Source network object1 names or addresses of hosts that are subject to filtering for the given rule.
|
Destination Address
|
Destination network object 1 names or addresses of hosts that are subject to filtering for the given rule.
|
Service
|
Name of one or more services2 for the given rule.
|
Interface
|
Name of interface to which the rule is assigned.
• Inside—Connects to your internal network.
• Outside—Connects to an external network or public Internet.
|
Conflict No.
|
Number of lower priority rules that conflict with the rule shown in the row.
|
Important Notes About Access Rules
•
Access rules are listed sequentially and are applied in the order in which they appear in the Access Rules table. An unwritten rule denies all traffic that is not explicitly permitted.
•
Access rules are grouped by the interface on which they are configured and enforced. Within each group, access rules are evaluated in the same order as you configure them. This is the default method for permitting or blocking traffic.
•
On the outside interface, all hosts are visible to hosts on all other interfaces. Hosts on a medium security interface are, by default, visible to hosts on higher security interfaces, but not visible to hosts on lower security interfaces unless the appropriate NAT rules have been created.
•
Rules can be applied at the global level, a group level, or to individual devices. The action can pertain to any of the following:
–
Approval (permit or deny)
–
AAA requirements
–
Passing traffic through a URL filter
•
When rules are shown at the device scope, the table is labeled as default. No mandatory setting exists at the device scope.
•
A firewall device configured from Firewall MC uses access control lists (ACLs). ACLs allows you to specify whether your firewall device should permit or block a connection from a network or host on one interface to a network or host on a different interface.
–
A PIX Firewall permits traffic from inside to outside (default) unless specifically denied in an ACL.
–
A Firewall Services Module (FWSM) denies inbound and outbound traffic (default) unless specifically permitted in an ACL.
•
Firewall MC generates only configuration files with ACLs. Conduits and outbound lists are not supported. Therefore, you must use the conversion tool on configurations with conduits and outbound lists before they can be deployed.
•
We recommend that you define translation rules and building blocks before you define rules (for example, network groups, service groups, and AAA server groups). If you are using auto-identity NAT, you do not need to define translation rules first.
Logging Events for an ACE
Firewall MC provides the ability to log events on any specific ACE in the Firewall Rule 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 Firewall Rule 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 first enable the ACL Syslog setting. To access the ACL Syslog setting, select Configuration > Device Settings > Logging > ACL Syslog. For more information, see Generating Enhanced Audit Data for Firewall Rules, page 16-19.
Configuring Access Rule Tables
Topics to be discussed are:
•
Inserting or Editing a Firewall Rule
•
Inserting or Editing an AAA Rule
•
Inserting or Editing a Web Filter Rule
•
Inserting or Editing an Ethertype Rule
Inserting or Editing a Firewall Rule
Note
Use the same procedure to configure mandatory and default firewall rules for all scopes.
Before You Begin
Recommended but not required: Define a network object identifying each host or server for which a rule applies. To do this, select Configuration > Building Blocks > Network Objects.
Step 1
Select Configuration > Access Rules > Firewall Rules > [Mandatory or Default].
The Firewall Rules page appears.
Step 2
Using the Object Selector, select the scope (if not already selected) to identify the device or device group to which the rules will apply.
Note
The Object bar displays the last scope that was selected under the Configuration tab.
Step 3
Do one of the following:
•
To insert the first row in the table, click Insert.
•
To add another row, select the check box above which to add a new row, then click Insert.
•
To paste a row that was cut or copied to the clipboard, select the row above which to add a new row, then click Paste.
Note
Because rules are applied to an interface, make sure the interface specified in a rule exists on the device to which you are pasting the rule.
•
To edit a row, select the appropriate check box, then click Edit.
•
To analyze and display rules that overlap or conflict with other rules, click Detect Conflict. The analysis is performed using the rules defined at the current scope and the mandatory and default rules defined in their parent scope in the hierarchy. See Using the Conflict Detection Feature.
•
To view all firewall rules tables (mandatory and default) from Global down to the current scope, click View All.
A page appears from which you can print the tables.
Note
You can right-click in the table to select the buttons shown at the bottom of the table. This simulates the act of clicking the button.
Step 4
Verify that the Enable rule check box is selected.
Step 5
To permit or deny traffic for the rule being defined, click the appropriate radio button.
Step 6
Enter the source addresses or click Select to display a list of defined objects.
Step 7
Do any of the following:
•
Select the available objects, then click Select =>.
The objects are moved to the Selected Objects column.
•
To create a new network object to use as a source address, click Add Network Object.
A popup window helps you define the network object. When you complete the definition, the new object is listed in the Selected Objects column. For more information, see Adding or Editing a Network Object, page 10-21.
Step 8
Click OK.
Step 9
Enter the destination addresses or click Select to display a list of defined objects.
Step 10
Do any of the following:
•
Select the available objects, then click Select =>.
The objects are moved to the Selected Objects column.
•
To create a new network object to use as a destination address, click Add Network Object.
A popup window helps you define the network object. When you complete the definition, the new object is listed in the Selected Objects column. For more information, see Defining Network Objects, page 10-9.
Step 11
Click OK.
Step 12
To enter the services, click Select to display a list of services.
Step 13
Do any of the following:
•
Select the available services, then click Select =>.
The objects are moved to the Selected Services column.
•
To create a service definition, click Add Service.
A popup window helps you define the service definition. When you complete the definition, the new building block is listed in the Selected Services column. For more information, see Configuring Service Definitions, page 10-24.
•
To create a service group and define services for that group, click Add Service Group.
A popup window helps you define the building block. When you complete the definition, the new building block is listed in the Selected Services column. For more information, see Defining Service Groups, page 10-28.
Step 14
Click OK.
Step 15
Select the source interface from the list. The list contains all interfaces defined at the current scope.
Step 16
Select the logging level from the list.
Step 17
Enter the logging interval.
Step 18
Select the category from the list. The list contains all categories defined as building blocks.
Step 19
Enter an optional description.
Step 20
Click OK.
Changes are applied to the assigned firewall device configuration files when they are generated. The configuration files are then downloaded to the firewall devices at deployment.
If you are using AAA authentication, you must also define the rule in the AAA Rules table and select the AAA control types that apply. See Inserting or Editing an AAA Rule.
If you are using web filtering, you must also define the rule in the Web Filter Rules table and determine whether to permit or deny traffic if the web server fails. See Inserting or Editing a Web Filter Rule.
If you want to configure access rules to control packets with non-IP ether type packets, you must also define the rule in the Ethertype table. See Inserting or Editing an Ethertype Rule.
Table 11-7 describes the elements on the Firewall Rules page.
Table 11-7 Firewall Rules
Element
|
Description
|
Enable Rule check box
|
Enables access rules.
Note If you select the Enable rule check box when you are configuring a rule, the rule is shown as true in the rule table under the Enabled column.
|
Action
|
Describes what should occur based on conditions set.
• Permit—Allows traffic.
• Deny—Denies traffic.
|
Source Addresses
|
Source network object1 names or addresses of hosts that are subject to filtering. Multiple entries are separated by commas.
Note If you are configuring a rule, you can click Select to open a popup window from which to make your selection.
|
Destination Addresses
|
Destination network object 1 names or addresses of hosts that are subject to filtering. Multiple entries are separated by commas.
Note If you are configuring a rule, you can click Select to open a popup window from which to make your selection.
|
Services
|
Name of one or more service definitions.2 Multiple entries are separated by commas.
Note If you are configuring a rule, you can click Select to open a popup window from which to make your selection.
|
Source Interface
|
Name of interface to which the generated ACL is assigned.
• Inside—Connects to your internal network.
• Outside—Connects to an external network or public Internet.
|
Syslog Level
|
Type of syslog used to log events for an ACE.
Note If you are configuring a rule, the logging level you select is displayed in the rule table in the Syslog Level column.
|
Logging Level list
|
Enables syslog for an ACE.
• Default (level 6).3 —The ACL logging behavior before PIX 6.3 is restored, (for example, if a packet is denied, message 106023 is generated.
• Emergencies (level 0)—System unusable. Generates messages that identify system instabilities.
• Alerts (level 1)—Immediate action needed. Generates messages that identify system integrity problems that require immediate administrative action.
• Critical (level 2)—Critical condition. Generates messages that identify critical system problems.
• Errors (level 3)—Error condition. Generates messages that identify system errors during operation.
• Warnings (level 4)—Warning condition. Generates messages that identify system warnings, for example, the device might be configured incorrectly.
• Notifications (level 5)—Normal but significant condition. Generates messages that identify normal operations that are usually considered significant events.
• Informational (level 6)—Informational message only. Generates messages that identify system information that is typical of day-to-day activity, such as network session records.
This setting directly affects the level of reports you can generate about network activity for this firewall device. We recommend that you select Informational to ensure that all report data is available.
|
Logging Level list (cont)
|
• Debugging (level 7)—Appears during debugging only. Generates messages that assist you in debugging. Also generates logs that identify the commands issued during FTP sessions and the URLs requested during HTTP sessions.
• Disabled—No logging. 3
Note If you are configuring a rule, the logging level you select is displayed in the rule table in the Syslog Level column.
|
Logging Interval
|
Interval of time, in seconds, used to generate logging messages. Default is 300 seconds. You must select a logging level from the list for the logging interval value to be recognized. If you selected Disabled or Default as your logging level, this field is grayed-out.
Note If you select Default as the logging level, the default logging interval value is used.
|
Category4
|
Element defined in Building Blocks to provide an intermediate level of detail to objects. This helps you categorize and readily identify rules and building blocks.
|
Description
|
Optional user-defined description that identifies the access rule.
|
Inserting or Editing an AAA Rule
Note
Use the same procedure to configure mandatory and default AAA rules for all scopes.
Before You Begin
•
Recommended but not required: Define a network object identifying each host or server for which a rule applies. To do this, select Configuration > Building Blocks > Network Objects.
•
Before defining rules that use AAA, you must identify the AAA server. To do this, select Configuration > Building Blocks > AAA Server Group.
Step 1
Select Configuration > Access Rules > AAA Rules > [Mandatory or Default].
The AAA Rules page appears.
Step 2
Using the Object Selector, select the scope (if not already selected) to identify the device or device group to which the rules will apply.
Note
The Object bar displays the last scope that was selected under the Configuration tab.
Step 3
Do one of the following:
•
To insert the first row in the table, click Insert.
•
To add another row, select the check box above which to add a new row, then click Insert.
•
To paste a row that has been cut or copied to the clipboard, select the check box above which to add a new row, then click Paste.
Note
Because rules are applied to an interface, make sure the interface specified in a rule exists on the device to which you are pasting the rule.
•
To edit a row, select the appropriate row, then click Edit.
•
To analyze and display rules that overlap or conflict with other rules, click Detect Conflict. The analysis is performed using the rules defined at the current scope and the mandatory and default rules defined in their parent scope in the hierarchy. See Using the Conflict Detection Feature.
•
To view all AAA rules tables (mandatory and default) from Global down to the current scope, click View All.
A page appears from which you can print the table.
Note
You can right-click in the table to select the buttons shown at the bottom of the table. This simulates the act of clicking the button.
Step 4
Select the Enable Rule check box.
Step 5
To permit or deny an action for the rule being defined, click the appropriate radio button.
Step 6
Based on your selection in Step 5, select the authentication, authorization, or accounting check boxes to which the action applies.
Step 7
Enter the source addresses or click Select to display a list of defined objects.
Step 8
Do any of the following:
•
Select the available objects, then click Select =>.
The objects are moved to the Selected Objects column.
•
To create a new network object to use as a source address, click Add Network Object.
A popup window helps you define the network object. When you complete the definition, the new object is listed in the Selected Objects column. For more information, see Adding or Editing a Network Object, page 10-21.
Step 9
Click OK.
Step 10
Enter the destination addresses or click Select to display a list of defined objects.
Step 11
Do any of the following:
•
Select the available objects, then click Select =>.
The objects are moved to the Selected Objects column.
•
To create a new network object to use as a destination address, click Add Network Object.
A popup window helps you define the network object. When you complete the definition, the new object is listed in the Selected Objects column. For more information, see Defining Network Objects, page 10-9.
Step 12
Click OK.
Step 13
To enter the services, click Select to display a list of services.
Step 14
Do any of the following:
•
Select the available services, then click Select =>.
The objects are moved to the Selected Services column.
•
To create a service definition, click Add Service.
A popup window helps you define the service definition. When you complete the definition, the new building block is listed in the Selected Services column. For more information, see Configuring Service Definitions, page 10-24.
•
To create a service group and define services for that group, click Add Service Group.
A popup window helps you define the building block. When you complete the definition, the new building block is listed in the Selected Services column. For more information, see Defining Service Groups, page 10-28.
Step 15
Click OK.
Step 16
Select the source interface from the list. The list contains all interfaces defined at the current scope.
Step 17
Select the AAA server group from the list.
Note
AAA server groups are user-defined. If you have not already done so, you can define a server group by selecting Configuration > Building Blocks > AAA Server Group.
Step 18
Enter an optional description in the field provided.
Step 19
Enter the category from the list.
Step 20
Click OK.
Changes are applied to the assigned firewall device configuration files when they are generated. The configuration files are then downloaded to the firewall devices at deployment.
If you defined AAA rules to permit FTP, HTTP, or Telnet services, you must enable FTP, HTTP, or Telnet traffic to allow authentication to occur. To do this, select Configuration > Device Settings > Firewall Device Administration > AAA Admin Authentication.
Table 11-8 describes the elements on the AAA Rules page.
Table 11-8 AAA Rules
Element
|
Description
|
Enable Rule check box
|
Enables AAA rule.
If the Enable rule check box is selected when you are configuring a rule, the rule is shown as true in the rules table in the Enabled column.
|
Actions radio buttons and check boxes
|
Permits or denies traffic.
• Authentication.
• Authorization—Used for TACACS only.
• Accounting.
If traffic is permitted, select the desired AAA control type using the corresponding check boxes.
If the action information is selected when you are configuring a rule, the results are displayed in the rules table in the Action column.
|
Source Addresses
|
Source network object1 names or addresses of hosts that are subject to filtering. Multiple entries are separated by commas.
Note If you are configuring a rule, you can click Select to open a popup window from which to make your selection.
|
Destination Addresses
|
Destination network object 1 names or addresses of hosts that are subject to filtering. Multiple entries are separated by commas.
Note If you are configuring a rule, you can click Select to open a popup window from which to make your selection.
|
Services
|
Name of one or more services.2 Multiple entries are separated by commas.
Note If you are configuring a rule, you can click Select to open a popup window from which to make your selection.
|
Source Interface
|
Name of interface to which the generated ACL is assigned.
• Inside—Connects to your internal network.
• Outside—Connects to an external network or public Internet.
|
Description
|
Optional user-defined description that identifies AAA rule.
|
AAA Server Group
|
AAA server groups defined in Building Blocks at current scope and above. Selected group is used to service corresponding AAA rules.
|
Category3
|
Element defined in Building Blocks to provide an intermediate level of detail to objects to help you categorize and readily identify rules and building blocks.
|
Inserting or Editing a Web Filter Rule
Before You Begin
•
Recommended but not required: Define a network object identifying each host or server for which a rule applies. To do this, select Configuration > Building Blocks > Network Objects.
•
Before you can define rules that use Web filtering, you must identify the Web filter server definitions. To do this, select Configuration > Device Settings > Servers and Services > URL Filter Server.
Note
Filter FTP and Filter HTTPS actions will only work with a Websense URL server. Filter URL, Filter URL Except, Filter Java, and Filter ActiveX actions will work with either a Websense or an N2H2 URL server.
Note
As of Firewall MC 1.3, web filter rules are no longer divided into mandatory and default tables.
Step 1
Select Configuration > Access Rules > Web Filter Rules.
The Web Filter Rules page appears.
Step 2
Using the Object Selector, select the scope (if not already selected) to identify the device or device groups to which the rules will apply.
Note
The Object bar displays the last scope that was selected under the Configuration tab.
Step 3
Do one of the following:
•
To insert the first row in the table, click Insert.
•
To add another row, select the check box above which to add a new row, then click Insert.
•
To paste a row that has been cut or copied to the clipboard, select the check box above which to add a new row, then click Paste.
Note
Because rules are applied to an interface, make sure the interface specified in a rule exists on the device to which you are pasting the rule.
•
To edit a row, select the appropriate check box, then click Edit.
•
To analyze and display rules that overlap or conflict with other rules, click Detect Conflict. The analysis is performed using the rules defined at the current scope and the mandatory and default rules defined in their parent scope in the hierarchy. See Using the Conflict Detection Feature.
•
To view all Web Filter Rules tables from Global down to the current scope, click View All.
A page appears from which you can print the table.
Note
You can right-click in the table to select the buttons shown at the bottom of the table. This simulates the act of clicking the button.
Step 4
Select the Enable rule check box.
Step 5
Select the action to be taken depending on the conditions set.
Step 6
Enter the source addresses or click Select to display a list of defined objects.
a.
Select the available objects, then click Select =>.
The objects are moved to the Selected Objects column.
b.
To create a new network object to use as a source address, click Add Network Object.
A popup window helps you define the network object. When you complete the definition, the new object is listed in the Selected Objects column. For more information, see Adding or Editing a Network Object, page 10-21.
c.
Click OK.
Step 7
Enter the destination addresses or click Select to display a list of defined objects.
a.
Select the available objects, then click Select =>.
The objects are moved to the Selected Objects column.
b.
To create a new network object to use as a destination address, click Add Network Object.
A popup window helps you define the network object. When you complete the definition, the new object is listed in the Selected Objects column. For more information, see Defining Network Objects, page 10-9.
c.
Click OK.
Step 8
To enter the services, click Select to display a list of services.
Step 9
Do any of the following:
•
Select the available services, then click Select =>.
The objects are moved to the Selected Services column.
•
To create a service definition, click Add Service.
A popup window helps you define the service definition. When you complete the definition, the new building block is listed in the Selected Services column. For more information, see Configuring Service Definitions, page 10-24.
•
To create a service group and define services for that group, click Add Service Group.
A popup window helps you define the building block. When you complete the definition, the new building block is listed in the Selected Services column. For more information, see Defining Service Groups, page 10-28.
Step 10
Click OK.
Step 11
Enter an optional description.
Step 12
Select a category from the list.
Step 13
To permit or deny traffic if the filter server is unavailable, click the corresponding check box.
Step 14
To block the connection to an HTTP proxy server, click the corresponding check box.
Step 15
To truncate CGI requests by removing the CGI parameters, click the corresponding check box.
Step 16
To block outbound traffic if the absolute FTP path is not provided, click the corresponding check box.
Step 17
Configure the action to be taken if the URL exceeds the maximum size (1159 characters).
Step 18
Click OK.
Changes are applied to the assigned firewall device configuration files when they are generated. The configuration files are then downloaded to the firewall devices at deployment.
Table 11-9 describes the elements on the Web Filter Rules page.
Table 11-9 Web Filter Rules
Element
|
Description
|
Enable rule check box
|
When you are configuring a rule, enables the filter rule. When enabled, set to true.
|
Action
|
Displays the action of the rules listed in the rules table. Valid actions for Web filter rules are Filter URL, Filter Java, Filter FTP, Filter ActiveX, Filter HTTPS, Filter URL Except.
Filter FTP and Filter HTTPS actions will only work with a Websense URL server. Filter URL, Filter URL Except, Filter Java, and Filter ActiveX actions will work with either a Websense or an N2H2 URL server.
Filter URL Except rules are ordered before any of the other filter commands. Firewall MC places the Filter URL Except rules in the same Web Filter Rules table as the other filer rules; however the Filter URL Except rules appear on top.
Your selection activates the applicable check boxes at the bottom of the page.
Note You can define the Filter URL, Filter HTTPS, and Filter FTP actions on the same device with the same port number, IP address, and netmask. However, if you try to add the Filter Java and Filter ActiveX actions to the same device with the same port number, IP address, and netmasks defined, the firewall produces an error message. For the deployment to succeed, Firewall MC ignores this error message, and the conflicting filter commands are not deployed.
|
Source Addresses
|
Source network object1 names or addresses of hosts that are subject to filtering. Multiple entries are separated by commas.
Note If you are configuring a rule, you can click Select to open a popup window from which to make your selection.
|
Destination Addresses
|
Destination network object 1 names or addresses of hosts that are subject to filtering. Multiple entries are separated by commas.
Note If you are configuring a rule, you can click Select to open a popup window from which to make your selection.
|
Services
|
Name of one or more services.2 Multiple entries are separated by commas.
You can also specify a specific port or range of ports.3
Note If you are configuring a rule, you can click Select to open a popup window from which to make your selection.
|
Description
|
Optional user-defined comment that identifies an access rule.
|
Category4
|
Element defined in Building Blocks to provide an intermediate level of detail to objects to help you categorize and readily identify rules and building blocks.
|
Allow traffic if filter server unavailable check box
|
When selected, allows traffic when the web server fails. Selection is displayed in the Options column in the Web Filter Rules table.
|
Block connection to an HTTP proxy server check.box
|
When selected, blocks traffic to an HTTP proxy server. Selection is displayed in the Options column in the Web Filter Rules table.
|
Truncate CGI requests by removing the CGI parameters check box
|
When selected, sends a CGI script as an URL.
|
Block outbound traffic if absolute FTP path is not provided check box
|
When selected, prevents users from connecting to the FTP server through an interactive FTP program.
|
Long URL
|
Click the radio button corresponding to the desired handling of a long URL:
• Drop—Discards the URL request.
• Truncate—Sends only the originating hostname or IP address to the Websense server if the URL is over the URL buffer limit.
• Deny—Denies the URL request if the URL is over the URL buffer-size limit or the URL buffer is not available.
|
Inserting or Editing an Ethertype Rule
Note
Use the same procedure to configure mandatory and default Ethertype rules for all scopes.
Step 1
Select Configuration > Access Rules > Ethertype Rules > [Mandatory or Default].
The Ethertype Rules page appears.
Step 2
Using the Object Selector, select the scope (if not already selected) to identify the device or device group to which the rules will apply.
Note
The Object bar displays the last scope that was selected under the Configuration tab.
Step 3
Do one of the following:
•
To insert the first row in the table, click Insert.
•
To add another row, select the check box above which to add a new row, then click Insert.
•
To paste a row that has been cut or copied to the clipboard, select the check box above which to add a new row, then click Paste.
Note
Because rules are applied to an interface, make sure the interface specified in a rule exists on the device to which you are pasting the rule.
•
To edit a row, select the appropriate check box, then click Edit.
•
To analyze and display rules that overlap or conflict with other rules, click Detect Conflict. The analysis is performed using the rules defined at the current scope and the mandatory and default rules defined in their parent scope in the hierarchy. See Using the Conflict Detection Feature.
•
To view all firewall rules tables (mandatory and default) from Global down to the current scope, click View All.
A page appears from which you can print the tables.
Note
You can right-click in the table to select the buttons shown at the bottom of the table. This simulates the act of clicking the button.
Step 4
Verify that the Enable rule check box is selected.
Step 5
To permit or deny traffic for the rule being defined, click the appropriate radio button.
Step 6
Select the interface to which the rule is bound from the Interface list.
Step 7
Click the appropriate radio button to define the Ether value.
Step 8
Select a category from the list.
Step 9
Enter an optional description.
Step 10
Click OK.
Changes are applied to the assigned firewall device configuration files when they are generated. The configuration files are then downloaded to the firewall devices at deployment.
Table 11-10 describes the elements on the Ethertype Rules page.
Table 11-10 Ethertype Rules
Element
|
Description
|
Enable Rule check box
|
Enables access rules.
Note If you select the Enable rule check box when you are configuring a rule, the rule is shown as true in the rule table under the Enabled column.
|
Action
|
Describes what should occur based on conditions set.
• Permit—Allows traffic.
• Deny—Denies traffic.
|
Source Interface
|
Name of interface to which the generated ACL is assigned.
• Inside—Connects to your internal network.
• Outside—Connects to an external network or public Internet.
|
Ether Value
|
• IPX
• BPDU
• MPLS-UNICAST
• MPLS-MULTICAST
• Other—Any valid hex value greater than 0x600.
|
Category1
|
Element defined in Building Blocks to provide an intermediate level of detail to objects. Helps you categorize and identify rules and building blocks.
|
Description
|
Optional user-defined description that identifies the access rule.
|
Cutting, Copying, or Pasting an Access Rule
When configuring access rules tables, you might be able to use shortcuts to help you define them:
•
Cut allows you to cut a rule from the table.
•
Copy allows you to copy a rule in the table and paste it elsewhere.
•
Paste allows you to paste a rule that was copied or cut from a table.
Note
•
Because rules are applied to an interface, make sure the interface specified in a rule exists on the device to which you are pasting the rule. If the interface is not found on the device, an error results when the device configuration is generated.
•
You cannot paste a rule before or after a rule created from an outbound rule. Outbound rules are sorted in the order that a firewall device applies them to traffic.
Step 1
Select Configuration > Access Rules > (Rules type) > [Mandatory or Default] (for example, Configuration > Access Rules > Firewall Rules > Mandatory).
Note
As of Firewall MC 1.3, web filter rules are no longer divided into mandatory and default tables.
The access rules table for the selected rules type appears.
Step 2
Using the Object Selector, select the scope (if not already selected) for the device or device groups to which the rules will apply.
Note
The Object bar displays the last scope that was selected under the Configuration tab.
Step 3
Do one of the following:
•
To copy a row in the table, select the check box for the row, then click Copy.
•
To cut a row, select the appropriate check box, then click Cut.
•
To paste a row, select the check box above which to paste the rule, then click Paste.
•
To view all rules tables (mandatory and default) for a single access rule type from Global down to the current scope, click View All.
Note
Web Filter Rules are displayed in one table because these rules are no longer divided into mandatory and default.
A page appears from which you can print the table.
Note
You can right-click in the table to select the buttons shown at the bottom of the table. This simulates the act of clicking the button.
Deleting an Access Rule
Step 1
Select Configuration > Access Rules > (Rules type) > [Mandatory or Default] (for example, Configuration > Access Rules > Firewall Rules > Mandatory).
Note
As of Firewall MC 1.3, web filter rules are no longer divided into mandatory and default tables.
The access rules table for the selected rules type appears.
Step 2
Using the Object Selector, select the scope to identify the device or device groups to which the rules will apply.
Note
The Object bar displays the last scope that was selected under the Configuration tab.
Step 3
Select the appropriate check box, then click Delete.
You are prompted to confirm the delete request.
Step 4
Click Yes.
The row is removed from the table.
Optimizing Your Policy Rules and Performance
Topics to be discussed are:
•
Using Group Discovery
•
Using Turbo ACLs
Using Group Discovery
Group Discovery is a feature that you access from the access rule tables, whereby an algorithm identifies rules that can be grouped together. The algorithm analyzes the mandatory or default rules at the current scope. You must select at least one rule on which to perform the algorithm. To access this feature, click Discover Groups, which is located at the bottom of the rule tables.
The results are displayed in a popup window that displays the discovered network, service groups, and their contents. It also lists the original number of rules and the new number of rules if the changes are accepted. You have the option to continue the replacing of rules or cancel the request. If you choose to continue, the access rule table is updated to display the new rule information.
Functionally, Group Discovery is equivalent to defining new building blocks, creating new rules to reference the building blocks, then deleting the old rules.
As a result of Group Discovery, you can create new building blocks to represent the discovered groups. Firewall MC reuses existing building blocks if it finds them. Otherwise it creates its own service groups and network objects. The newly created groups will have the names MC-SGroup (for a service group) and MC-NGroup (for a network object). After you accept the changes, you can rename the groups.
Tip
You can create building blocks before performing Group Discovery. Firewall MC will use the building blocks if they are a good match.
The rules in the access rule table are rewritten to refer to the building blocks instead of the original addresses (or smaller building blocks). The resulting list of rules is shortened, making the rules in the table more manageable.
An access list command can refer to five possible groups: source network, destination network, protocol, source service ports, and destination service, which can be service ports or ICMP types. A command must have a source network or group and a destination network or group.
•
For source network, destination network, and protocol, the command can refer to a group or an individual item.
•
For source service ports and destination service, the command can refer to a group or individual item, or is not used.
Note
During conversion, the networks are converted first, followed by services.
An access rule can apply to the following types of objects:
•
Client host—Makes HTTP, Telnet, FTP, VoIP, and other service requests.
•
Server host—Responds to service requests.
•
Service type—Services are assigned to well-known, dynamically assigned, or secondary channel TCP or UDP ports.
•
Subnet—The network address of internal or external subnetworks where server or client hosts are located.
•
ICMP types—Such as ECHO-REPLY.
An access rule allows or denies traffic matching a specific combination of these objects. For example, an access rule might cause the PIX Firewall to allow a designated client to access a particular server host for a specific service. When there is only one client, one host, and one service, only one access rule is needed. However, as the number of clients, servers, and services increases, the number of rules required might increase exponentially.
Object Grouping 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:
•
My Services—Includes the TCP/UDP port numbers of the service requests that are allowed access to the internal network.
•
Trusted Hosts—Includes the host and network addresses allowed access to the greatest range of services and servers.
•
Public Servers—Includes the host addresses of servers to which the greatest access is provided.
After creating these groups, you can use a single access rule to allow trusted hosts to make specific service requests to a group of public servers. Object groups can also contain other object groups or be contained by other object groups.
Object Grouping 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.
Policies are sorted by their sources, so policies with the same source are placed together.
2.
Same-source policies are sorted by destination, so policies with the same source and destination are placed together.
3.
Same-source and same-destination policies are combined into a single policy, and the services are combined into an object group.
4.
Adjacent policies are checked to see if they have the same source and service. If so, they are combined into a single policy, and the destinations are combined into an object group.
5.
Adjacent policies are checked to see if they have the same destination and service. If so, they are combined into a single policy, and the sources are combined into an object group.
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:Permit
Rule 2: Src:1.1.1.1 Dst:3.3.3.3 Svc:CMD Interface:inside Action Permit
The two rules can be combined to form a new rule:
New Rule: Src:1.1.1.1 Dst:MC-NGroup1234 Svc:CMD Interface:inside
Action:Permit
Where MC-NGroup1234 contains Dst 2.2.2.2 and 3.3.3.3.
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.
Note
For versions of PIX Firewalls that do not support object grouping, the groups are always lost on generation and cannot exist on import.
Using Turbo ACLs
An access list typically consists of multiple access list entries, organized internally by a PIX Firewall as a linked list. When a packet is subjected to access list control, the PIX Firewall searches this linked list linearly to find a matching element. The matching element is then examined to determine if the packet is to be transmitted or dropped. With a linear search, the average search time increases in proportion to the size of the list.
The Turbo ACLs feature is designed to improve the average search time of access control lists containing a large number of entries. The Turbo ACL feature causes the PIX Firewall to compile tables for ACLs, which improves the searching of long ACLs.
When Firewall MC deploys the Turbo ACL commands to the firewall device, Firewall MC cannot detect if the ACLs were compiled successfully. If the ACLs were not compiled successfully, the firewall device turns off the Turbo ACL feature. You can turn the Turbo ACLs feature on or off at the global level. To access this feature, select Configuration > Device Settings > Advanced Security > Turbo ACLs.
The Turbo ACLs feature requires significant amounts of memory and is most appropriate for high-end PIX Firewall models, such as the PIX 525 or PIX 535. The minimum memory required for Turbo ACLs is 2.1 MB, and approximately 1 MB of memory is required for every 2,000 ACL elements.
Note
Firewall MC currently does not support Turbo ACLs per ACL.
Enabling Turbo ACLs
Step 1
Select Configuration > Device Settings > Advanced Security > Turbo ACLs.
The Turbo ACLs page appears.
Step 2
Select the Enable Turbo Access Rules Searches check box to speed up the processing of large access rules.
Note
This feature requires a minimum of 2.1 MB of memory for the device. Additional memory might be required.
Step 3
Click Apply.
Changes are applied to the assigned firewall device configuration files when the files are generated. The configuration files are then downloaded to firewall devices at deployment. See "Managing Activities."
Table 11-11 describes the elements on the Turbo ACLs page.
Table 11-11 Turbo ACLs
Element
|
Description
|
Inherit settings check box
|
When selected, the subgroup or devices inherit the settings of the enclosing group to current scope. You can override a default setting by deselecting the check box and specifying other values. (See What Is Inheritance?.)
Note A grayed-out check box disallows changes at the current scope.
|
Enforce/Mandate settings for children check box
|
When selected, settings are at a group level and are inherited by the enclosed subgroups and devices. Mandatory settings cannot be changed by a subgroup or device. (See What Is Inheritance?.)
Note A grayed-out check box disallows changes at the current scope.
|
Enable Turbo Access Rule Searches check box
|
Speeds up processing of large access rules tables.
Note If you enable Turbo Access Rule Searches, additional memory might be required for the device.
|