Access rules define the rules that traffic must meet to pass through an interface. When you define rules for incoming traffic, they are applied to the traffic before any other policies are applied (with the exception of less common AAA rules). In that sense, they are your first line of defense.
Tip For some types of devices, you can configure IPv6 access rules in addition to IPv4 access rules. For information on supported device types, see IPv6 Support in Security Manager.
The following topics help you understand and work with access rules:
Access rules policies define the rules that allow or deny traffic to transit an interface. Typically, you create access rules for traffic entering an interface, because if you are going to deny specific types of packets, it is better to do it before the device spends a lot of time processing them.
There are two separate access rules policies based on the IP addressing scheme. The Firewall > Access Rules policy is for IPv4 addresses, and the Firewall > IPv6 Access Rules policy is for IPv6 addresses. Other than the addressing scheme, and the tools available for use with the policies, configuring IPv4 and IPv6 access rules is the same.
When you deploy access rules to devices, they become one or more entries (ACEs) to access control lists (ACLs) that are attached to interfaces. Typically, these rules are the first security policy applied to packets; they are your first line of defense. You use access rules to filter out undesired traffic based on service (protocol and port numbers) and source and destination addresses, either permitting the traffic or denying (dropping) it. Each packet that arrives at an interface is examined to determine whether to forward or drop the packet based on criteria you specify. If you define access rules in the out direction, packets are also analyzed before they are allowed to leave an interface.
When you permit traffic in an access rule, subsequent policies might end up dropping it. For example, inspection rules, web filter rules, and zone-based firewall rules are applied after a packet makes it through the interface’s access rules. These subsequent rules might then drop the traffic based on a deeper analysis of the traffic; for example, the packet header might not meet your inspection requirements, or the URL for a web request might be for an undesired web site.
Thus, you should carefully consider the other types of firewall rules you intend to create when you define access rules. Do not create a blanket denial in an access rule for traffic that you really want to inspect. On the other hand, if you know that you will never allow a service from or to a specific host or network, use an access rule to deny the traffic.
Keep in mind that access rules are ordered. That is, when the device compares a packet against the rules, it searches from top to bottom and applies the policy for the first rule that matches it, and ignores all subsequent rules (even if a later rule is a better match). Thus, you should place specific rules above more general rules to ensure those rules are not ignored. To help you identify cases where IPv4 rules will never be matched, and to identify redundant rules, you can use the analysis and policy query tools. For more information, see Generating Analysis Reports and Generating Policy Query Reports.
The following are additional ways in which you can evaluate your access rules:
Combine rules—You can use a tool to evaluate your IPv4 rules and combine them into a smaller number of rules that perform the same functions. This can leave you with a smaller, easier to manage list of rules. For more information, see Combining Rules.
Generate hit counts—You can use a tool to view the hit count statistics maintained by the device for IPv4 and IPv6 ACLs. This can tell you how often a rule has permitted or denied traffic. For more information, see Generating Hit Count Reports.
View events collected by CS-MARS—You can analyze real time or historical events related to an IPv4 rule using the Cisco Security Monitoring, Analysis and Response System application if you configured it to monitor the device and you configure the rule to generate syslog messages. For more information, see Viewing CS-MARS Events for an Access Rule.
For more conceptual information on access rules, see the following topics:
Traditionally, access rules (ACLs), which control which traffic can flow through a device, are applied to device interfaces. However, with ASA devices running software release 8.3+, you have the option to create global access rules for IPv4 and IPv6.
Global access rules are defined as a special ACL that is processed for every interface on the device for traffic entering the interface. Thus, although the ACL is configured once on the device, it acts like a secondary interface-specific ACL defined for the In direction. (Global rules are always for the In direction, never the Out direction.)
When traffic enters an interface on an ASA 8.3+ device, when applying ACLs, the device first applies any interface-specific access rules to the traffic. It then applies global rules. (Overall processing is explained in Understanding the Processing Order of Firewall Rules.)
Global rules are best used for rules that you want to apply to all traffic that enters a device regardless of which interface it enters. For example, there might be a specific host or subnet that you always want to deny or permit. You can create these as global rules, so they are configured once on the device instead of configured again for each interface (although functionally the same as an interface-specific rule configured for the All-Interfaces role, All-Interfaces rules are repeated for each interface rather than being configured once on the device).
Tip If you want to configure the same set of global rules for more than one device, create a shared policy and inherit it in the IPv4 or IPv6 access rules policy for each device. Ensure that all global rules are in the Default section of the shared policy. If you put any global rules in the Mandatory section, you will not be able to inherit it on devices that have local interface-specific access rules defined. For more information on shared and inherited policies, see Local Policies vs. Shared Policies and Understanding Rule Inheritance.
When you configure access rules for an ASA 8.3+ device in Security Manager, interface-specific and global rules are configured in the same policy. However, because the device always processes interface-specific rules first, Security Manager prevents you from intermixing these different types of rules. Therefore, if you configure both interface-specific and global rules on a device, keep the following in mind:
Global rules always come last in the access rules policy. All interface-specific rules come before global rules.
You cannot move rules in a way that violates the required order. For example, you cannot move an interface-specific rule below a global rule, or a global rule above an interface-specific rule.
You cannot create rules in a location that violates the required order. For example, if you select an interface-specific rule, and another interface-specific rule follows it in the table, you cannot create a global rule. If you try to create the wrong kind of rule, when you save the rule, Security Manager will ask you if the rule can be created at the nearest valid location. You must accept the suggestion or the rule will not be added to the table. You can always move the rule after creating it if the suggested location is not ideal (but without violating the rules on order).
You cannot inherit a policy if the rules in the inherited policy will violate the required order. For example, if you create global rules in the device policy, and try to inherit a shared policy that contains interface-specific rules in the Default section, Security Manager will prevent you from inheriting the policy.
After assigning or inheriting a shared policy, you cannot edit the policy in a way that will violate rule order on any device that uses the policy.
If you assign or inherit a policy that contains global rules on a device that does not support them, all global rules are ignored and not configured on the device. For example, if you permit all traffic from host 10.100.10.10 in a global rule in a shared policy, and assign that policy to an IOS device, the rule permitting 10.100.10.10 access is not configured on the IOS device, and traffic from that host is handled either by another interface-specific policy, or the default deny all policy. As a good practice, you should not assign shared policies that contain global rules to devices that do not support them, to ensure that you do not mistakenly believe the policy defined in a global rule is being configured on the unsupported device.
There are also some changes in how certain tools work with global rules:
Find/Replace—You can search for global rules by using the Global interface name. However, there is no way to convert between global and interface-specific rules. Although you can find global rules using the Global interface name, if you try to replace an interface name with the name “Global,” you are actually creating an interface-specific access rule that uses a policy object named Global.
Rule Combiner—Interface-specific and global rules are never combined.
Understanding Device Specific Access Rule Behavior
If you do not create an access rule policy, the following is the default behavior based on the type of device, and what happens when you create an access rule:
IOS devices—Permit all traffic through an interface.
When you create an access rule permitting source A to destination B without configuring TCP/UDP inspection on the inspection rule table, or configuring the established advanced option on the rule, the device permits any packet from A to B. However, for any returning packet from B to A, the packet is not allowed, unless there is a corresponding access rule permitting that packet. If you configure TCP/UDP inspection on the traffic the inspection rule table, a rule permitting B to A is not needed in the access rule, as any returning packet from B to A automatically passes the device.
ASA and PIX devices—Permit traffic from a higher-security interface to a lower-security interface. Otherwise, all traffic is denied.
If an access rule allows TCP/UDP traffic in one direction, the appliance automatically allows return traffic (you do not need to configure a corresponding rule for the return traffic), except for ICMP traffic, which does require a return rule (where you permit the reverse source and destination), or you must create an inspection rule for ICMP.
FWSM devices—Deny all traffic entering an interface, permit all traffic leaving an interface.
You must configure access rules to allow any traffic to enter the device.
If you create any rules for an interface for any type of device, the device adds an implicit deny any rule at the end of the policy. It is a good practice for you to add this rule yourself so that you remember it is there. Adding the rule also allows you to get hit count information for the rule. For more information, see Generating Hit Count Reports.
Tip When you create the access rule policy, ensure that you include a rule that will permit access to the device from the Security Manager server, or you will not be able to manage the device using the product.
Understanding Access Rule Address Requirements and How Rules Are Deployed
One of the complexities of creating IPv4 access control lists using the operating system commands on the command line interface (CLI) is the fact that different operating systems have different IP address formats for source and destination addresses.
For example, Cisco IOS Software requires that you enter addresses using wildcard masks instead of subnet masks. To create a rule for the 10.100.10.0/24 network (subnet mask 255.255.255.0), you are required to enter the address as 10.100.10.0 0.0.0.255. The 0 and 1 have the reverse meaning in a wildcard mask that they have in a subnet mask. In ASA, PIX, and FWSM software, however, you use subnet masks, so you enter 10.100.10.0 255.255.255.0.
Security Manager simplifies addressing requirements for access rules: you always use the subnet mask. You are not even allowed to enter a wildcard mask. When you deploy the access rules to a device, Security Manager considers the operating system of the device and converts subnet masks to wildcard masks automatically when needed.
This makes it possible for you to create shared rules based on logical policies and to apply those rules to all of your devices. For example, there might be a set of access rules that you want all devices to use, in which case you can create the shared policy and assign it as the inherited policy for all devices. You do not have to worry about defining rules using the “right” syntax for the device type. You can use the same network/host objects that you use in other types of policies to identify targeted hosts and networks.
The specific CLI commands generated in deployed configurations are also based on the type of device. For IOS devices, the ip access-list command is used. For ASA, PIX, FWSM devices, the access-list or ipv6 access-list command is used and the access-group command binds it to the interface. With ASA, PIX, FWSM, and IOS 12.4(20)T+ devices, if you use network/host objects to identify the source or destination addresses for a rule, the object-group command is used to create object groups for those network/host objects. Object groups are also created for service objects.
Because you can use network/host objects to identify a source or destination, and you can configure deployment optimization for rules, there is not always a one-to-one relationship between an access rule and ACEs in the CLI definition of an ACL.
All access lists created from firewall rules are extended access lists (rather than standard). Security Manager applies a system-generated name to the ACL unless you specify a name for the ACL on the Access Control Settings Page (IPv4 and IPv6). The name applies to the ACL that includes all of the rules related to the interface and direction for which the name is defined.
There are several deployment options that control how object groups are deployed. This topic describes the default behavior. On the Deployment Page (select Tools > Security Manager Administration > Deployment), you can deselect the option to create object groups from network/host objects. You can also optimize object groups during deployment (see Optimizing Network Object Groups When Deploying Firewall Rules), create new object groups from rules with multiple services or source and destination addresses, or remove unused object groups.
The deployment options also include settings that control the names of ACLs generated from access rules and how many ACLs are created. By default, Security Manager creates a unique ACL for each interface, even if this means that several duplicate ACLs are created.
If you select Enable ACL Sharing for Firewall Rules, Security Manager can create a single ACL and apply it to multiple interfaces, thus avoiding the creation of unnecessary duplicate ACLs. However, ACL sharing occurs only if it can be done while preserving your ACL naming requirements:
– If you select Reuse existing names for the Firewall Access-List Names property, the existing names are preserved (unless you override them in the access control settings policy). This means that you might end up with duplicate ACLs under different names if duplicate ACLs already exist on the device.
Tip: To maximize ACL sharing, ensure that you select Reset to CS-Manager Generated Names for the Firewall Access-List Names property, select Speed for the Optimize the Deployment of Access Rules For property, and that you do not configure ACL names in the access control settings policy.
For more detailed information about the Enable ACL Sharing for Firewall Rules property, see Deployment Page.
Access rules policies define the rules for allowing traffic to pass through an interface. There are separate policies for IPv4 and IPv6 traffic. If you do not configure an access rules policy, the device behavior differs based on device type as explained in Understanding Device Specific Access Rule Behavior.
Before you configure access rules, consider the other types of firewall rules you will configure. Access rules are processed before all other types of rules except for AAA rules. See the following topics for more information about things you should consider:
Tip If you do not select a row, the new rule is added at the end of the local scope. You can also select an existing row and edit either the entire row or specific cells. For more information, see Editing Rules. Special rules apply if you mix interface-specific and global rules in a policy; for more information, see Understanding Global Access Rules.
Service—Use the IP service to apply to any traffic (for example, if you want to deny all traffic from a specific source). Otherwise, select the more specific service, which is a protocol and port combination, that you are targeting.
Interfaces or Global—The interface or interface role for which you are configuring the rule, or Global to create global access rules on ASA 8.3+ devices (see Understanding Global Access Rules).
Advanced settings—Click Advanced to open the Advanced dialog box for configuring additional settings. You can configure the following options; for detailed information, see Advanced and Edit Options Dialog Boxes.
– Logging options. If you are using Security Manager or CS-MARS to monitor the device, ensure that you enable logging.
– The direction of traffic to which this rule should apply (in or out). The default is in. You cannot change this setting for global rules.
– The time range for the rule, which allows you to configure rules that work only for specific periods of time, such as during working hours. For more information, see Configuring Time Range Objects.
– IOS device options for fragmentation and allowing the return of traffic for established outbound sessions.
Step 5 (IPv4 only.) If you already have a large number of rules, consider analyzing and combining them before deploying the new rules:
Click the Tools button and select Analysis to analyze whether you have redundant rules or rules that will not be used. Fix problem areas. For more information, see Generating Analysis Reports.
If analysis shows that you have a lot of redundant rules, click the Tools button and select Combine Rules to combine them. You can either allow Security Manager to evaluate all rules for combination, or just the rules you select before starting the rule combiner tool. For more information, see Combining Rules.
Access Rules Page (IPv4 or IPv6)
Use the Access Rules (for IPv4) or IPv6 Access Rules pages to configure access control rules for device interfaces. Access rules policies define the rules that allow or deny traffic to transit an interface. Typically, you create access rules for traffic entering an interface, because if you are going to deny specific types of packets, it is better to do it before the device spends a lot of time processing them. Access rules are processed before other types of firewall rules.
Read the following topics before you configure access rules:
Tip Disabled rules are shown with hash marks covering the table row. When you deploy the configuration, disabled rules are removed from the device. For more information, see Enabling and Disabling Rules.
To open the Access Rules page, do one of the following:
(Device view) Select a device, then select Firewall > Access Rules (for IPv4) or Firewall > IPv6 Access Rules from the Policy selector.
(Policy view) Select Firewall > Access Rules (for IPv4) or Firewall > IPv6 Access Rules from the Policy Type selector. Create a new policy or select an existing one.
(Map view) Right-click a device and select Edit Firewall Policies > Access Rules (for IPv4) or Edit Firewall Policies > IPv6 Access Rules.
Whether a rule permits or denies traffic based on the conditions set:
Permit—Shown as a green check mark.
Deny—Shown as a red circle with slash.
The source and destination addresses for the rule. The “any” address does not restrict the rule to specific hosts, networks, or interfaces. These addresses are IPv4 or IPv6 addresses for hosts or networks, network/host objects, interfaces, or interface roles. Multiple entries are displayed as separate subfields within the table cell. See:
The interfaces or interface roles to which the rule is assigned. Interface role objects are replaced with the actual interface names when the configuration is generated for each device. Multiple entries are displayed as separate subfields within the table cell. See Understanding Interface Role Objects.
For ASA 8.3+ devices, global rules are indicated with the name Global and a special icon to distinguish them from rules that use interface or interface role names (for an explanation of the icons, see Specifying Interfaces During Policy Definition).
The direction of the traffic to which this rule applies:
Combine Rules (IPv4 only)—To improve performance and memory usage by combining similar rules. This reduces the number of rules in the policy. See Combining Rules.
Hit Count (IPv4 and IPv6)—To identify the number of times that traffic for a device is permitted or denied based on an access rule. This information is useful in debugging the deployed policies. See Generating Hit Count Reports.
Import Rules (IPv4 only)—To import rules from an ACL defined using device commands. See Importing Rules.
Query (IPv4 only)—To run policy queries, which can help you evaluate your rules and identify ineffective rules that you can delete. See Generating Policy Query Reports
Whether to enable the rule, which means the rule becomes active when you deploy the configuration to the device. Disabled rules are shown overlain with hash marks in the rule table. For more information, see Enabling and Disabling Rules.
Whether the rule permits or denies traffic based on the conditions you define.
The source or destination of the traffic. You can enter more than one value by separating the items with commas.
Interface role object. Enter the name of the object or click Select to select it from a list (you must select Interface Role as the object type). When you use an interface role, the rule behaves as if you supplied the IPv4 or IPv6 address of the selected interface. This is useful for interfaces that get their address through DHCP, because you do not know what IP address will be assigned to the device. For more information, see Understanding Interface Role Objects.
If you select an interface role as a source, the dialog box displays tabs to differentiate between hosts or networks and interface roles.
The services that define the type of traffic to act on. You can enter more than one value by separating the items with commas.
You can enter any combination of service objects and service types (which are typically a protocol and port combination). If you type in a service, you are prompted as you type with valid values. You can select a value from the list and press Enter or Tab.
Select whether you are creating an interface-specific or global rule. Global rules are available only for ASA 8.3+ devices, and are handled according to special rules (for detailed information, see Understanding Global Access Rules).
If you select Interfaces, enter the name of the interface or the interface role to which the rule is assigned, or click Select to select the interface or role from a list, or to create a new role. An interface must already be defined to appear on the list.
Interface role objects are replaced with the actual interface names when the configuration is generated for each device. See Understanding Interface Role Objects. Global rules are created as a special global ACL that is not attached to specific interfaces, but is processed for all interfaces in the In direction after interface-specific rules.
An optional description of the rule (up to 1024 characters).
The category assigned to the rule. Categories help you organize and identify rules and objects. See Using Category Objects.
Click this button to configure other settings for the rule, including logging configuration, traffic direction, time ranges, and rule expiration dates. For more information, see Advanced and Edit Options Dialog Boxes.
Advanced and Edit Options Dialog Boxes
Use the Advanced and Edit Options dialog boxes to configure additional settings for an IPv4 or IPv6 access rule. When you are in the Advanced dialog box, you have more fields available for configuration than when you edit options, which is a cell-level editing dialog box. The settings in the Advanced dialog box show up in three different cells in an access rule; direction, options, and rule expiration.
To access the Advanced dialog box, do one of the following:
Right-click the Options cell in an access rule (on the Access Rules Page (IPv4 or IPv6)) and select Edit Options. If you select multiple rows, your changes replace the options defined for all selected rules.
Whether to generate syslog messages for the rule entries, or ACEs, for PIX, ASA, and FWSM devices. You can select these additional options:
Default Logging—Use the default logging behavior. If a packet is denied, message 106023 is generated. If a packet is permitted, no syslog message is generated. The default logging interval is 300 seconds.
Per ACE Logging—Configure logging specific to this entry. Select the logging level you want to use to log events for the ACE, and the logging interval, which can be from 1-600 seconds. Syslog message 106100 is generated for the ACE.
Following are the possible logging levels:
– Emergency—(0) System is unstable
– Alert—(1) Immediate action is needed
– Critical—(2) Critical conditions
– Error—(3) Error conditions
– Warning—(4) Warning conditions
– Notification—(5) Normal but significant condition
– Informational—(6) Informational messages only
– Debugging—(7) Debugging messages
Enable Logging (IOS)
Whether to generate an informational logging message about the packet that matches the entry to be sent to the console for IOS devices.
Select Log Input to include the input interface and source MAC address or virtual circuit in the logging output.
(Advanced dialog box only)
For interface-specific access rules, the direction of the traffic to which this rule applies:
In—Packets entering an interface.
Out—Packets exiting an interface.
Global rules are always applied in the In direction, so you cannot change this setting when configuring a global rule.
The name of a time range policy object that defines the times when this rule applies. The time is based on the system clock of the device. The feature works best if you use NTP to configure the system clock.
Enter the name or click Select to select the object. If the object that you want is not listed, click the Create button to create it.
Note Time range is not supported on FWSM 2.x or PIX 6.3 devices.
Additional options for IOS devices:
Fragment—Allow fragmentation, which provides additional management of packet fragmentation and improves compatibility with NFS.
By default, a maximum of 24 fragments is accepted to reconstruct a full IP packet; however, based on your network security policy, you might want to consider configuring the device to prevent fragmented packets from traversing the firewall.
Established—Allow outbound TCP connections to return access through the device. This option works with two connections: an original connection outbound from a network protected by the device, and a return connection inbound between the same two devices on an external host.
If you configure an expiration date, you can also configure the number of days before which the rule expires to send out a notification of the pending expiration, and e-mail addresses to which to send the notifications. These fields are initially filled with the information configured on the Rule Expiration administrative settings page (select Tools > Security Manager Administration > Rule Expiration).
Expired rules are not automatically deleted. You must delete them yourself and redeploy the configuration to the device.
Edit Firewall Rule Expiration Settings Dialog Box
Use the Edit Firewall Rule Expiration Settings dialog box to edit the expiration settings for an IPv4 or IPv6 access rule.
To set an expiration date for the rule, click the calendar icon to select a date.
If you configure an expiration date, you can also configure the number of days before which the rule expires to send out a notification of the pending expiration, and e-mail addresses to which to send the notifications. These fields are initially filled with the information configured on the Rule Expiration administrative settings page (select Tools > Security Manager Administration > Rule Expiration).
Expired rules are not automatically deleted. You must delete them yourself and redeploy the configuration to the device.
Right-click the Expiration Date cell in an access rule (on the Access Rules Page (IPv4 or IPv6)) and select Edit Rule Expiration. If you select multiple rows, your changes replace the options defined for all selected rules.
Configuring Expiration Dates for Access Rules
A frequent use of access rules is to provide temporary access to a network. For example, you might configure an access rule to allow a partner access for the duration of a specific project. Ideally, you want to remove the access rule at the completion of the project. However, as access rule lists grow, it is hard to manage them and to remember which rules were meant to be temporary.
To help you deal with this problem, you can configure expiration dates for IPv4 or IPv6 access rules. By configuring an expiration date, you can project when you believe the rule will no longer be needed.
Expiration dates are not hard and fast dates; Security Manager does not delete rules that reach their expiration date. Instead, when an expiration date is reached, Security Manager displays “Expired” in bold letters in the Expiration Date column for the rule. You can filter the access rules page based on the expiration date field, for example, filtering for “expiration date has passed” to see all expired rules.
If the rule is no longer needed, you can delete it (right-click and select Delete Row), or disable it (right-click and select Disable), and then redeploy the configuration to the device. You might want to initially disable the rule, which leaves the rule in the table (overlain with hash marks), in case you discover the rule really was still needed after all, saving you the time of recreating the rule. You just need to enable the rule (right-click and select Enable) and redeploy the configuration.
When you configure an expiration date, you can also configure notification settings, specifying an e-mail address that should be notified when an expiration date is approaching. You can specify how many days before the expiration date to send the notification e-mail message to allow you time to evaluate the rule. The notification settings are initially filled with the values configured in the administration settings (select Tools > Security Manager Administration > Rule Expiration); you can enter different settings for a given rule.
To configure rule expiration:
When creating a new rule, or editing an entire rule, click the Advanced button to get to the rule expiration settings. For information on creating access rules, see Configuring Access Rules (IPv4 or IPv6).
For existing rules, you can add or edit expiration settings without editing the entire rule. Right-click the Expiration Date cell for the rule and select Edit Rule Expiration. You can select multiple rows to configure the same rule expiration settings. For more information, see Edit Firewall Rule Expiration Settings Dialog Box.
Configuring Settings for Access Control (IPv4 or IPv6)
You can configure various settings that apply to IPv4 or IPv6 access control lists. These settings work in conjunction with your IPv4 or IPv6 access rules policy. The main setting of interest is that you can configure your own ACL names for each interface/traffic direction combination, or for the global ACL on ASA 8.3+ devices. For PIX, ASA, and FWSM devices, you can also control the maximum number of IPv4 deny flows and the related syslog interval.
You can also configure an interface to allow per-user downloadable ACLs for PIX, ASA, and FWSM devices. This allows you to configure user-based ACLs in your AAA server to override the ACLs defined on a device.
There are other settings available, but they pertain to older devices and software releases and are of limited use.
(Device view) Select Firewall > Settings > Access Control (for IPv4) or Firewall > Settings > IPv6 Access Control from the Policy selector.
(Policy view) Select Firewall > Settings > Access Control (for IPv4) or Firewall > Settings > IPv6 Access Control from the Policy Type selector. Select an existing policy or create a new one.
Step 2 (IPv4 policy only.) Configure the global settings in the top part of the page. For PIX, ASA, and FWSM devices, you can define the maximum number of concurrent deny flows and the related syslog interval. For ASA 8.3+ devices, you can enable object group search to optimize ACL performance when converting from Checkpoint, but this setting is not recommended unless you have a memory-constrained device.
Note The Enable Object Group Search setting applies to both IPv4 and IPv6 access rules. Your selection in the IPv4 policy applies to all rules; there is not a separate setting for IPv6.
Step 3 For each interface on which you want to configure an ACL name, or enable per-user ACLs, add the interface to the interfaces table by clicking the Add Row button beneath the table and filling in the Firewall ACL Setting Dialog Box (IPv4 or IPv6). Keep the following in mind:
If you configure an ACL name, the name is applied to the specific interface and direction; you cannot use the same name for both IPv4 and IPv6 policies. Security Manager creates system-generated names for any interface/direction combinations that you do not specifically name.
You can also specify the name of the global ACL for ASA 8.3+ devices.
The Enable Per User Downloadable ACLs option is not confined to IPv4 or IPv6. If you select the option in either the IPv4 or IPv6 Access Control Settings policy, the option is configured for the specified interface and direction, even if you do not select it in the other access control settings policy.
You can edit existing entries in the list by selecting them and clicking Edit Row, or delete them by clicking Delete Row.
Access Control Settings Page (IPv4 and IPv6)
Use the Access Control Settings page to configure settings to use in conjunction with your access rules policy. You can control some performance and logging features, and configure ACL names for individual interfaces. There are separate policies for IPv4 and IPv6, but they are essentially the same.
Tip Many of these settings apply only to specific device types or software versions. If you configure an option and apply the policy to unsupported device types, the option is ignored for those unsupported devices.
To access the Access Control Page, do one of the following:
(Device view) Select a device, then select Firewall > Settings > Access Control (for IPv4) or Firewall > Settings > IPv6 Access Control from the Policy selector.
(Policy view) Select Firewall > Settings > Access Control (for IPv4) or Firewall > Settings > IPv6 Access Control from the Policy Type selector. Create a new policy or select an existing policy.
(Map view) Right-click a device and select Edit Firewall Settings > Access Control (for IPv4) or Edit Firewall Settings > IPv6 Access Control.
Maximum number of concurrent flows (PIX, ASA, FWSM)
The maximum number of concurrent deny flows that the device is allowed to create. Syslog message 106101 is generated when the device reaches the number. The range you should use depends on the amount of flash memory available in the device:
More than 64 MB—Values are 1-4096. The default is 4096.
More than 16 MB—Values are 1-1024. The default is 1024.
Less than or equal to 16 MB—Values are 1-256. The default is 256.
Syslog interval (PIX, ASA, FWSM)
The interval of time for generating syslog message 106101, which alerts you that the security appliance has reached a deny flow maximum. When the deny flow maximum is reached, another 106101 message is generated if the specified number of seconds has passed since the last 106101 message. Values are 1-3600 milliseconds. The default is 300.
Enable Access List Compilation (Global)
Whether to compile access lists, which speeds up the processing of large rules tables. Compilation optimizes your policy rules and performance for all ACLs, but is supported on a limited number of older platforms:
Routers (global configuration only): 7120, 7140, 7200, 7304, and 7500.
PIX 6.3 firewalls, in global mode or per interface.
An ACL is compiled only if the number of access list elements is greater than or equal to 19. The maximum recommended number of entries is 16,000.
To compile access lists, the device must have a minimum of 2.1 MB of memory. Access list compilation is also known as Turbo ACL.
Enable Object Group Search (ASA 8.3+)
(On IPv4 policy only, but applies to both IPv4 and IPv6.)
Whether to enable object group search on ASA 8.3+ devices, which optimizes ACL performance without expanding object groups. Object group search is mainly for use when migrating from Checkpoint to ASA, which can result in a large increase in the number of access rules, when you have a memory-constrained device (that is, you find during operations that memory runs low).
If you enable object group search, you cannot use the Hit Count tool to analyze your rules. In most cases, you should not enable this feature. Instead, use the rule combiner tool to simplify your access rules, and consider using global rules for rules you want to enforce on all interfaces.
(IPv4 and IPv6.)
The table lists the interfaces for which you want to configure special processing. The interface name can be a specific interface or an interface role (which can apply settings to more than one interface at a time), or Global for global ACL settings on ASA 8.3+ devices.
The main use of this table is to configure names for ACLs if you do not want Security Manager to configure system-generated names. The name applies to the IPv4 or IPv6 ACL generated for an interface in a specific direction.
You can also configure interface-level settings for per user downloadable ACLs and for IPv4, object group search and ACL compilation.
Select whether you are configuring settings for specific interfaces (or interface roles), or for global rules on ASA 8.3+ devices.
If you select Interface, specify the name of the interface or interface role for which you are configuring settings. Enter the name or click Select to select it from a list or to create a new object.
If you select Global, your only option is to specify the name of the global ACL.
The direction of the traffic through the interface, in or out. The settings you configure apply only to this direction, if direction matters.
For global ACLs on ASA 8.3+ devices, the direction is always in.
User Defined ACL Name
Whether you want to supply the name for the ACL. If you select this option, enter the name you want to use, which is applied to the ACL generated for the interface and direction combination. The name must be unique on the device.
Tip When configuring IPv6 access control settings, there is only the ACL Name edit box; there is no User Defined ACL Name check box.
Note that you cannot use the same ACL name for IPv4 and IPv6 ACLs.
If you are configuring the name for the global ACL on ASA 8.3+ devices, the option is automatically selected; simply enter the desired name.
If you do not configure a name, Security Manager generates a name for you.
Enable Per User Downloadable ACLs (PIX, ASA, FWSM)
Whether to enable the download of per-user ACLs to override the ACLs on the interface. User ACLs are configured in a AAA server; they are not configured in Security Manager. If there are no per-user ACLs, the access rules configured for the interface are applied to the traffic.
Tip This option is separately available in the access control settings policies for IPv4 and IPv6. However, the option applies to access control as a whole, and is not separately configured for IPv4 and IPv6. If you select the option in either of the access control settings policies, the option is configured on the device for the specified interface and direction.
Enable Object Group Search (PIX 6.x)
Whether to enable object group search on a PIX 6.3 interface, which reduces the memory requirement on the device to hold large ACLs. However, object group search impacts performance by making ACL processing slower for each packet.
Object group search is recommended when you have huge object groups.
Whether to compile access lists on this interface for PIX 6.x devices. This setting overrides the equivalent global setting that you configure on the Access Control Settings page.
ACL compilation speeds up the processing of large rules tables and optimizes your policy rules and performance for the interface. An ACL is compiled only if the number of access list elements is greater than or equal to 19. The maximum recommended number of entries is 16,000.
To compile access lists, the device must have a minimum of 2.1 MB of memory.
Generating Analysis Reports
You can generate analysis reports to evaluate the logic of your access rules. The report lists rules that overlap or conflict with other rules in the access rule policy. Use this information to identify rules that need to be deleted, moved, or edited.
The purpose of analyzing your access rules policy is twofold:
To identify unnecessary redundant or duplicate rules that you can delete. For example:
– Redundant Base Rule—Although not identical to the overlapping rule, the rules apply the same action to the same type of traffic, and removing the base rule would not change the ultimate result. For example, the base rule might prohibit a service during a specific time range, but the overlapping rule prohibits the service at all times. Another example is where the overlapping rule might allow any source, whereas the base rule specifies a particular network.
– Redundant Overlapping Rule—This is the reverse of a redundant base rule. In this case, the base rule will match the same traffic as the overlapping rule, meaning the overlapping rule will never be applied to any traffic (because it comes later in the access list). You can delete the overlapping rule.
– Duplicate Rule—The base rule and the overlapping rule are identical. You can delete one of them.
Conflicting Rule— To identify rules that define conflicting actions for the same traffic. With conflicting rules, the base rule and the overlapping rule specify different actions for traffic. It might not always be apparent that the rules specify different policies. However, because the base rule comes before the overlapping rule, it is the base rule that will decide what happens to the traffic. You might need to move the overlapping rules, or edit the base or overlapping rules, to implement your desired policy.
For example, the base rule might deny IP traffic, and the overlapping rule might permit FTP traffic, for a given source or destination.
By removing unnecessary rules, you can develop an easier to use and more efficient access rules policy.
Figure 14-1 shows an example of a redundant rule. In this case, the base rule permits source address 188.8.131.52 to make TFTP connections to destination 184.108.40.206. However, a subsequent rule allows any source address to make TFTP connections to that destination. The base rule is not needed, assuming you want to keep the overlapping rule.
Figure 14-1 Example Rule Analysis Report
Tip In addition to analysis, you can use the Combine Rules tool to have Security Manager evaluate your rules and find ways to combine them into more efficient rules. For more information, see Combining Rules.
Step 2 Click the Tools button and select Analysis.
The rules are analyzed and the results presented in the Rule Analysis Results window. The report has three window panes.
Left pane (Base Rules)—Lists conflicting groups of rules identified by the base rule, which is the rule with the lowest rule number.
Top right pane (Conflict Overview)—Shows the base rule selected in the left pane and all of the rules that overlap, or conflict, with it. The scope indicates whether the rule is local to a device or inherited from a shared rule (mandatory or default). The other columns are the same as the regular access rule attributes (see Access Rules Page (IPv4 or IPv6)).
Select an overlapping rule in this pane to view a detailed comparison in the lower right pane.
Bottom right pane (Overlap Details)—Shows a detailed comparison between the base rule and the overlapping rule selected in the top right pane for easier direct comparison. Conflicting elements are shown in bold text. The types of overlap are explained above.
Use the previous and next buttons to page through the details if necessary.
Generating Hit Count Reports
You can generate hit count reports to determine how often each rule in your IPv4 or IPv6 access rule policy is matched to traffic. If an access rule is deployed as multiple access control entries (ACEs), for example, when you use interface roles to define rules and the roles apply to more than one interface, you can see the separate hit count information for each ACE deployed. The hit count results do not show counts for any other type of ACL (for example, those used with class maps or AAA rules).
Use the hit count information to help you debug your access rules. The information can help you identify rules that are never hit (which might mean you do not need them, or that they are duplicates of rules higher in the ACL), and rules that are hit often (which means you might want to refine the rules).
The following figures show an example of a hit count report and how to use the information.
Figure 14-2 shows the default view. The upper table lists the rules as they exist in your access rules policy, either all rules or just the ones you selected before generating the report. When you select a rule, the ACEs created on the device for that rule are listed in the expanded table in the lower half of the window. When you initially open the report, the expanded table shows the ACEs for all policies listed in the upper table.
Hit counts in the expanded table are for each ACE, whereas the count in the rules table is the sum of the hit counts for all ACEs created by the rule. Note that the expanded table for ASA/PIX/FWSM devices, and IOS devices lower than 12.4(20)T, shows hit counts for each element within any policy objects used in the rule, whereas for IOS 12.4(20)T+ devices, the information is only provided at the object group level.
Figure 14-3 shows the same ACEs except in CLI format. These are the ACEs as they exist in the device configuration.
Step 4 Select the rules to include in the report. Select All Rules to include all local, shared, and inherited rules. If you selected rules before initiating the report, select that option.
Step 5 Click OK.
The tool obtains the ACL and hit count information from the device. You can abort the operation if you want. When the information is obtained, it is displayed in the Hit Count Summary Results Page. For information on reading the report, see Analyzing Hit Count Query Results.
You can click Refresh Hit Count while the report is open to obtain the latest information. The Delta column displays the difference in hit count since the last refresh.
Hit Count Selection Summary Dialog Box
Use the Hit Count Selection Summary dialog box to select the rules for which you want to generate hit count information. Your options are limited by the rules you selected before initiating the hit count report.
When you click OK, the hit count information is obtained from the device, which can take some time so you are given the option to abort the operation. The results are shown in the Hit Count Query Results window. For information on reading the results, see Analyzing Hit Count Query Results.
(Device view only) Select either Firewall > Access Rules, or Firewall > IPv6 Access Rules, then click the Tools button and select Hit Count. For more information, see Access Rules Page (IPv4 or IPv6).
Identifies the selected policy. If you do not select any policy, this is typically Local, which means the rules defined specifically for the device. The policy might also be a scope within a shared or inherited policy.
The indication in this field does not actually limit the scope of your hit count report.
The rules for which you want to obtain hit counts.
Select All Rules to get hit counts for all inherited, shared, and local rules. The option is not restricted to the scope indicated in the Policy Selected field.
This is the only available option if you do not select any rules before initiating the hit count report.
Select the option for your selected rules to obtain information for only those rules. You can select the rows related to the name of a scope, a section name, multiple individual rules, or create a filter and select all filtered rules. This is the default if any row is selected when you initiate the hit count report.
Analyzing Hit Count Query Results
Use Hit Count Query Results page to view information about the number of times an IPv4 or IPv6 access rule was applied to traffic. These rules are the ones that become interface ACLs on the device. The hit count results do not show counts for any other type of ACL (for example, those used with class maps or AAA rules).
Use the hit count information to help you debug your access rules. The information can help you identify rules that are never hit (which might mean you do not need them, or that they are duplicates of rules higher in the ACL), and rules that are hit often (which means you might want to refine the rules). For an example of a hit count report, see Generating Hit Count Reports.
Consider the following points when analyzing the hit count results:
You get best results if you deploy policies to the device before viewing hit counts. If you discover a device and then generate a hit count report before deployment, the results might be incomplete or hard to interpret. For example, an access rule might not have any hit count information.
Hit count statistics are based on ACL, not on interface. If you select Enable ACL Sharing for Firewall Rules on the Security Manager Administration Deployment page (see Deployment Page), any shared ACL provides statistics that are combined from all interfaces that share the ACL.
If you enable ACL optimization, as described in Optimizing Access Rules Automatically During Deployment, the hit count results might have problems matching ACEs from the device to access rules. Thus, when you select an access rule, you might not get any hit count results for it.
The device for which you are displaying hit count information.
Refresh Hit Count button
Click this button to update the hit count information. The difference between the last hit count and the updated hit count is listed in the Delta column in the expanded table (in the lower pane).The amount of time since the last refresh is shown next to the button to help you evaluate the delta count.
Obtaining refreshed information can take some time, so you are given the opportunity to abort the refresh.
Selected Access Rules table
The rules you selected for obtaining hit count information. The hit count is the sum of the hit counts for all ACEs created by the rule. The other information is the same as in the Access Rules Page (IPv4 or IPv6).
Select one or more rules in this table to see detailed information for the access control entries (ACEs) associated with the rule in the tables in the lower half of the window.
Select whether you want to see the expanded table or the raw ACE table (both explained below).
Lists the device’s access control list entries (ACEs) for the rule selected in the upper table (Selected Access Rules table). The list contains more than one ACE if the access rule generated more than one ACE when you deployed the policy to the device.
The columns in the table match those of the upper table, except they contain the specific data configured in the ACE in place of any network/host, service, or interface role objects contained in the rule, with the exception of IOS 12.4(20)T+ devices, which show data only at the object level. Also, the name of the ACL that contains the ACE is listed.
The additional Delta column contains the number of hits for the ACE since the last time you clicked the Refresh Hit Count button. The Hit Count column shows the hits for the specific ACE rather than the overall rule.
Tip You can sort on multiple columns at the same time by pressing and holding the
Ctrl key while you click the column headings. You can sort on all columns except Interface, Direction, and ACL Name.
Raw ACE table
Shows the actual CLI for the access control entry, along with the hit count. Use this information if you are more comfortable evaluating device commands.
Typically, when you add a device to Security Manager, you discover policies from the device. This action populates your access rules policy with the access control entries (ACEs) from all active ACLs on the device.
If you find there are other ACLs that have ACEs you want included in your policy, you can define them directly in Security Manager.
Another alternative, however, is to import them by copying and pasting the CLI from a device running-configuration or by typing in the desired commands. By using the Import Rules wizard, you can quickly create all of the ACEs and associated policy objects from ACLs that you know already work. You might also want to use this method if you are more comfortable using CLI to define your rules.
Step 4 Enter the CLI in running-configuration format appropriate for the type of device. Select whether you are creating an interface-specific rule (and enter the interface or interface role to which you want the rules to apply), or for ASA 8.3+ devices, a global rule (see Understanding Global Access Rules). Also, select the traffic direction with respect to the interface (the direction is always In for global rules).
The information on the Preview page is read-only. If the rules are acceptable, click Finish. If you want to make changes, you can edit them in the access rules policy.
Import Rules Wizard—Enter Parameters Page
Use the Import Rules wizard to import a set of access control entries from an ACL in device running-configuration format to your access rules policy. The command syntax you can enter is controlled by the type of device to which you are importing rules.
Beside access control rules, you should also include the CLI for the following items if they are referred to by the rules:
Time range objects (the time-range command with its subcommands).
Object groups for PIX, ASA, FWSM, and IOS 12.4(20)T devices (the object-group command with its subcommands).
For ASA 8.3+ devices, you can also include object network and object service commands. However, any object NAT configuration is not imported.
Table 14-8 Import Rules - Enter Parameters Dialog Box
The OS commands that define the rules and related objects that you want to import. These rules must be in running-configuration format, so they are best copied and pasted from a configuration (use Ctrl+V to paste into the field). You can also type in the commands; you will be prompted if they cannot be interpreted.
If you refer to an object but do not include the CLI, the rule might be created but it will not use the object.
For PIX, FWSM, ASA, and IOS 12.4(20)T+, you can include object group and name commands.
If you import an ACL that is inactive, it is shown as disabled in Security Manager. If you deploy the configuration, it is removed from the device.
You can import extended ACLs for all device types, and standard ACLs for IOS devices. However, standard ACLs are converted to extended ACLs.
Global (ASA 8.3+)
Select whether you are importing an interface-specific or global rule. Global rules are available only for ASA 8.3+ devices, and are handled according to special rules (for detailed information, see Understanding Global Access Rules).
If you select Interfaces, enter the name of the interface or the interface role for which you are defining this rule, or click Select to select the interface or role from a list, or to create a new role. An interface must already be defined to appear on the list. You can enter any combination of interface or interface role names, separated by commas.
The direction of the traffic with respect to the interface, in or out.
The category assigned to the rules. Categories help you organize and identify rules and objects. See Using Category Objects.
Import Rules Wizard—Status Page
Use the Status page of the Import Rules wizard to view information about the results of the import process.
The number of policy objects that will be created.
The warning, error, and informational messages, as indicated by the severity icon. Typical informational messages describe the policy objects created during the operation or the existing policy objects that were reused.
When you select an item, the Description box to the right describes the message in detail. The Action box to the right provides information on how you can correct the problem.
Click this button to stop the import operation.
Import Rules Wizard—Preview Page
Use the Preview page of the Import Rules wizard to view the rules and objects that will be imported if you click Finish.
This preview is read-only; you cannot edit the rules or objects. If the rules or objects are not exactly what you want, you can click Finish to add the rules and objects, and then edit them from the access rules page. For example, you cannot import rule expiration dates, because those dates have meaning only in Security Manager.
The tabs on this dialog box appear only if the data you are importing includes items to be displayed on the tab.
Tip If your CLI refers to an object that does not exist, such as a time range, the object is not included in the rule. You can either go back and add the CLI for the object, or you can click Finish, create the object yourself, and edit the rule.
This example creates a network/host object named ftp_servers and two access rules.
Example 2: Restrict web access during working hours (ASA devices)
The following example denies HTTP requests between the hours of 8 AM and 6 PM, which are typical work hours.
periodic weekdays 8:00 to 18:00
access-list 101 deny tcp any any eq www time-range no-http
This example creates a time range object named no-http and one access rule.
Example 3: Filtering on TCP and ICMP using port numbers (IOS devices)
In the following example, the first line of the extended access list named goodports permits any incoming TCP connections with destination ports greater than 1023. The second line permits incoming TCP connections to the Simple Mail Transfer Protocol (SMTP) port of host 172.28.1.2. The last line permits incoming ICMP messages for error feedback.
ip access-list extended goodports
permit tcp any 172.28.0.0 0.0.255.255 gt 1023
permit tcp any host 172.28.1.2 eq 25
permit icmp any 172.28.0.0 255.255.255.255
This example creates three access rules. Notice that the wildcard masks used in the IOS ACL syntax are converted to regular subnet masks. Security Manager automatically converts between standard network/host subnet mask designations and the wildcard masks required in IOS ACLs. Because ASA/PIX/FWSM requires the use of subnet masks in ACL commands, this makes it possible for you to create rules that can apply to all devices; Security Manager takes care of converting your rules to the correct syntax.
Example 4: Standard ACLs restricting hosts (IOS devices)
In the following example, the workstation belonging to Jones is allowed access to Ethernet interface 0 and the workstation belonging to Smith is not allowed access:
ip access-list standard workstations
remark Permit only Jones workstation through
remark Do not allow Smith workstation through
This example creates two rules, converting the standard rules to extended rules (to any destination). The remarks are saved in the description field.
For more examples of ACLs in command language format, see the following:
Optimizing Access Rules Automatically During Deployment
You can configure the system to optimize the access control lists (ACLs) that are created from your access rules policies when they are deployed to specific devices or to all devices. This optimization affects only the deployed policies, it does not make any changes to your access rules policy.
Note The optimization described in this topic applies to IPv4 ACLs only. Optimization does not work with IPv6 ACLs.
Optimization removes redundancies and conflicts and can combine multiple entries (ACEs) into single entries. Although the order of entries might change, the semantics of your policies are preserved; the optimized ACL accepts or denies the same set of packets as did its unoptimized form. Following are the basic cases where changes are made:
Ineffective ACE—Where one entry is a subset of, or equal to, another entry, the ineffective ACE is removed. Consider the following example:
access-list acl_mdc_inside_access deny ip host 10.2.1.1 any
access-list acl_mdc_inside_access deny ip 10.2.1.0 255.255.255.0 any
The first ACE is actually a subset of the second ACE. ACL optimization will deploy only the second entry.
Superset ACE—Where one entry is a superset of another and the order of the rules does not matter, the redundant rule is removed. Consider the following example:
access-list acl_mdc_inside_access permit tcp any any range 110 120
access-list acl_mdc_inside_access deny tcp any any range 115
The second ACE will never be hit. ACL optimization will remove the second ACE and deploy only the first one.
Adjacent ACEs—Where two entries are similar enough that a single entry can do the same job. There can be no intervening rules that change which packets will hit each rule. Consider the following example:
access-list myacl permit ip 220.127.116.11 255.255.255.128 any
access-list myacl permit ip 18.104.22.168 255.255.255.128 any
The two ACEs are merged into one: access-list myacl permit ip 22.214.171.124 255.255.255.0 any.
By configuring ACL deployment optimization, you can create smaller ACLs that are more efficient, which can improve performance on devices with limited, non-expandable memory, such as the FWSM, which can be shared among multiple virtual contexts.
However, there are down sides to configuring ACL deployment optimization:
Because optimization changes what would normally be deployed for your access rules, it is hard to correlate those rules to the actual deployed ACEs. This can make the results of the hit count tool unusable, and make it very difficult to correlate events in the Cisco Security Monitoring, Analysis and Response System application. If it is important to you that you can monitor your access rules using these tools, do not enable optimization. For more information, see Generating Hit Count Reports and Viewing CS-MARS Events for an Access Rule.
Optimization does not address inherent problems in your access rules policy. It is typically better to address redundancies and conflicts proactively by using the rule analysis tool (see Generating Analysis Reports). You can also use the combine rules tool to optimize your rules in the access rules policy before you deploy them (see Combining Rules).
If you decide to configure ACL deployment optimization, consider enabling it only for those devices that are memory constrained.
Step 1 Log into Windows on the Security Manager server.
Step 2 Use a text editor such as NotePad to open the C:\Program Files\CSCOpx\MDC\athena\config\csm.properties file. Locate the optimization section and read the instructions.
To turn on full optimization for all devices, enter the following:
To turn on full optimization for a specific device, replace the asterisk with the Security Manager display name for the device. For example, if the display name is west_coast.cisco.com, enter the following:
To turn on optimization but preserve the object groups used in the ACE, replace the full keyword with preserve_og. For example:
If you do not want to allow the merger of adjacent entries, enter the following:
Step 3 Save the file. The settings take effect immediately and will be applied to all subsequent deployment jobs.
You can generate optimization reports for deployment jobs by selecting Capture Discovery/Deployment Debugging Snapshots to File, which is located in Tools > Security Manager Administration > Debug Options.
The deployment results will show optimization results summarized as an informational message that includes the original number of ACEs before optimization and the number of ACEs after optimization. The results are saved to a file on the server in the C:\Program Files\CSCOpx\MDC\temp folder. A job ID is used as part of the filename.