Filter
Top Products
16-2
User Guide for Cisco Security Manager 4.4
OL-28826-01
Chapter 16 Managing Firewall Access Rules
Understanding Access Rules
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.
Tip For ASA 8.3+ devices, you can augment interface-specific access rules with global access rules. For
more information, see Understanding Global Access Rules, page 16-3.
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 automatic conflict detection and policy
query tools. For more information, see Using Automatic Conflict Detection, page 16-25 and Generating
Policy Query Reports, page 12-28.
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, page 12-22.
• 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 Viewing Hit Count Details, page 16-33.
• 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, page 69-28.
For more conceptual information on access rules, see the following topics:
• Understanding Global Access Rules, page 16-3
• Understanding Device Specific Access Rule Behavior, page 16-4
• Understanding Access Rule Address Requirements and How Rules Are Deployed, page 16-5
Related Topics
• Configuring Access Rules, page 16-7
• Configuring Expiration Dates for Access Rules, page 16-19