![]() |
Using Management Center for Firewalls 1.2
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Configuring Access Rules
![]() |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Table of ContentsConfiguring Access RulesHow a Firewall Device Stores Access Rules What's New Using Categories, Color-Coding, and Filtering Examples of Associating Color-Coding with Access Rules
Configuring Access Rule TablesUnderstanding the Rule Table User Interface Using the Filter Feature Using the Highlight Feature Important Notes About Access Rules Logging Events for an ACE Optimizing Your Policy Rules and Performance Configuring Access RulesAccess 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. 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 lists 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 ACE that will be included in the ACL for that interface. Firewall MC is based on a hierarchical list of device groups containing firewall devices. Each group (also referred to as a scope) has two sets of access rules (mandatory and default); each device has one set of access rules (default). The mandatory and default access rule sets 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:
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 will take precedence over any rules that come later. The device rules will take effect only if no relevant mandatory rules apply. Finally, the default rules will apply if no mandatory or device-specific rules apply. In addition to the mandatory and default scope settings, Firewall MC divides access rules into three categories:
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. 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. 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.
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. For more information, see Configuring Management Controls. Before you can understand how Firewall MC generates the access rules list from its settings, you must understand how a firewall device stores access rules and how those rules are used. Topics for discussion include: How a Firewall Device Stores Access RulesA 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. What's NewIf you are a previous user of Firewall MC and you upgraded to Firewall MC release 1.2, you will notice design enhancements to the access rules tables:
Using Categories, Color-Coding, and FilteringThe 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. 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. Topics for discussion include: Examples of Associating Color-Coding with Access RulesThis 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 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.
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 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 the Security Operations department can maintain these rules and verify how often the Finance department is trying to access their applications. Understanding the Rule Table User InterfaceFigure 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
Table 11-1 defines the action buttons used to configure access rules. Table 11-1 Access Rule Tables Action Buttons
Using the Filter FeatureThe rule table can be filtered based on 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: Using the Highlight FeatureThe Highlight feature allows you to search for a particular value in the table without trimming the data displayed. 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 numbers based upon your selected highlight criteria. Step 4 To remove highlighting, click the Highlight icon again. Important Notes About Access Rules
Logging Events for an ACEFirewall 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 statistics retained 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 statistics retained 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. Configuring Access Rule TablesTopics for discussion include: Inserting or Editing a Firewall Rule
Before You BeginRecommended 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] (for example, Configuration > Access Rules > Firewall Rules > Mandatory). 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. Step 3 Do one of the following: The Firewall Rule page appears. The Firewall Rule page appears.
The Firewall Rule page appears. A page appears from which you can print the tables.
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 address(es) or click Select to open a window to display a list of defined objects. The objects are moved to the Selected Objects column. You are returned to the Firewall Rule page. Step 7 Enter the destination address(es) or click Select to open a window that displays a list of defined objects. The objects are moved to the Selected Objects column. You are returned to the Firewall Rule page. Step 8 To enter the services, click Select, which opens a window to display a list of services. The objects are moved to the Selected Objects column. You are returned to the Firewall Rule page. Step 9 Select the source interface from the list. The list contains all interfaces defined at the current scope. Step 10 Select the logging level from the list. Step 11 Enter the logging interval. Step 12 Select the category from the list. The list contains all categories defined as building blocks. Step 13 Enter an optional description. Step 14 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 should the web server go down. See Inserting or Editing a Web Filter Rule. Firewall Rule Field-Level Elements and Descriptions
Inserting or Editing an AAA Rule
Before You Begin
Step 1 Select Configuration > Access Rules > AAA Rules > [Mandatory or Default] (for example, Configuration > Access Rules > AAA Rules > Mandatory). 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. Step 3 Do one of the following:
A page appears from which you can print the table.
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 address(es) or click Select, which opens a window to display a list of defined objects. The objects are moved to the Selected Objects column. You are returned to the AAA Rule page. Step 8 Enter the destination addresses or click Select, which opens a window to display a list of defined objects. The objects are moved to the Selected Objects column. You are returned to the AAA Rule page. Step 9 Enter the services by clicking Select, which opens a window to display a list of services. The objects are moved to the Selected Objects column. You are returned to the AAA Rule page. Step 10 Select the source interface from the list. The list contains all interfaces defined at the current scope. Step 11 Select the AAA server group from the list.
Step 12 Enter an optional description in the field provided. Step 13 Enter the category from the list. Step 14 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. AAA Rule Field-Level Elements and Descriptions
Inserting or Editing a Web Filter Rule
Before You Begin
Step 1 Select Configuration > Access Rules > Web Filter Rules > [Mandatory or Default] (for example, Configuration > Access Rules > Web Filter Rules > Mandatory). 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. Step 3 Do one of the following: The Web Filter Rule page appears. The Web Filter Rule page appears.
The Web Filter Rule page appears. A page appears from which you can print the table.
Step 4 Select the Enable rule check box. Step 5 Enter the source address(es) or click Select, which opens a window to display a list of defined objects. The objects are moved to the Selected Objects column. You are returned to the Web Filter Rule page. Step 6 Enter the destination address(es) or click Select, which opens a window to display a list of defined objects. The objects are moved to the Selected Objects column. You are returned to the Web Filter Rule page. Step 7 Enter the services by clicking Select, which opens a window to display a list of services. a. Select the available services, then click Select =>. The service selected must be a TCP service and cannot contain a port range. The objects are moved to the Selected Objects column. You are returned to the Web Filter Rule page. Step 8 Enter an optional description. Step 9 Select a category from the list. Step 10 To permit or deny traffic if the filter server is unavailable, click the respective radio button. Step 11 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. Filter Rule Field-Level Elements and Descriptions
|
|
| 1 Network objects are defined in Building Blocks. Select Configuration > Building Blocks > Network Objects. See Defining Network Objects. 2 Services are defined in Building Blocks. Select Configuration > Building Blocks > Service Definitions. See Defining Service Definitions. 3 Categories are defined in Building Blocks. Select Configuration > Building Blocks > Categories. See Using Categories and Color-Coding. |
When configuring access rules tables, you might be able to use shortcuts to help you define your access rules tables:
![]() |
Note |
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.
Step 3 Do one of the following:
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. |
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.
Step 3 Select the check box for the row in the table, then click Delete.
You are prompted to confirm the delete request.
Step 4 Click Yes.
The row is removed from the table.
Topics for discussion include:
Group Discovery is a feature that is accessed 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 with the replacement of rules or cancel the request. If you choose to continue, the access rule table is updated to display the new rule information.
As a result of Group Discovery, new building blocks can be created to represent the discovered groups. Firewall MC reuses existing building blocks if it finds them. Otherwise it will create 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.
![]() |
Note Functionally, Group Discovery is equivalent to defining new building blocks, creating new rules to reference the building blocks, then deleting the old rules. |
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.
![]() |
Note During conversion, the networks are converted first, followed by services. |
An access rule can apply to the following types of objects:
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:
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, multi-dimensional 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:
The two rules can be combined to form a new rule:
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. |
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 proportional 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. |
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."
|