Filter
Top Products
66-49
User Guide for Cisco Security Manager 4.4
OL-28826-01
Chapter 66 Viewing Events
Using Event Viewer
The main reason you would want to perform policy lookup is to adjust a policy based on the events that
it is generating. For example, an access rule might be dropping traffic that you actually want to allow.
Because you are looking at the event, you know there is a policy that is causing the event, so with a few
clicks, you can get from that event to the policy that you need to reconfigure.
You can look up policies from the following types of events:
• Firewall events—You can look up policies for the following syslog messages:
–
106023—Denied IP packet.
–
106100—Permit/Denied by ACL.
–
302013—Built TCP (started a TCP session).
–
302015—Built UDP (started a UDP session).
• IPS alert events—All IPS events that have valid signature and sub-signature identifiers.
Tips and Caveats
• You cannot look up firewall policies for events that contain IPv6 addresses. You can look up IPS
policies for IPv6 addresses, however.
• When a policy that is based on IP address alone and not on a user name triggers an event, the device
looks up the IP address in the Active Directory and if a user name is associated with that IP address,
the user name is added to the syslog. Hence, even if a policy does not contain a user name, the
resulting syslog might contain it. Policies cannot be created with a destination user and, as a result,
this field will not be used during policy lookup.
• If an event is generated for a policy that is configured based on source/destination FQDN, the
resulting syslog will not contain the FQDN because of a device defect. In such cases, policy lookup
will not work.
• If an event is generated for a policy that is based on user groups, the syslog will contain the specific
user name that triggered the event and not the user group. In such cases, policy lookup will not work.
• Hash codes are required for successful policy lookups from syslog 106023 and 106100 events. These
hash codes are available only if you deployed the configuration using Security Manager. If policy
lookup fails, try deploying the configuration (either to the device or to a file), then try the policy
lookup again.
• If you had applied a filter to the device’s policy table, and the rule or signature that generated an
event is filtered from the current view, Security Manager cannot highlight it. Clear the filter and try
again.
• If the event is caused by an implicit rule, such as the implicit deny any at the end of access rules,
Security Manager cannot highlight the rule. It is considered good practice to create an explicit deny
any rule at the end of access lists.
• The target policy is always found in Device view, even if the device uses a shared policy. Device
view is opened if necessary to highlight the policy.
• For IPS signatures, you might not be able to edit the signature if it is a default signature.
• For access rules, the selected rule is the best match for the event. It is possible that more than one
rule would generate the same event if you have overlapping or redundant rules. In these cases,
editing the selected rule might not completely eliminate the event, because a subsequent rule might
perform the same action. Use the access rules tools to analyze and combine overlapping rules.
• For access rules, multiple rules might permit a packet during session creation, but the first rule only
is highlighted.