Section 9-3. Fine-Tuning Logging Message Generation

9-3. Fine-Tuning Logging Message Generation

After you have chosen and configured severity levels for logging destinations, you should make sure you are receiving only necessary messages. In other words, don't choose a severity level that can produce an abundance of messages that will be ignored. Always keep in mind that a Syslog server must receive and archive every message sent to it. Storage space is at a premium, especially when logs continuously grow over time.

Here are rules of thumb to follow when choosing a severity level:

• If only firewall error conditions should be recorded and no one will regularly view the message logs, choose severity level 3 (errors).

• If you are primarily interested in seeing how traffic is being filtered by the firewall access lists, choose severity level 4 (warnings).

• If you need an audit trail of firewall users and their activity, choose severity level 5 (notifications).

• If you will be using a firewall log analysis application, you should choose severity level 6 (informational). This is the only level that produces messages about connections that are created, as well as the time and data volume usage.

• If you need to use any debug command to troubleshoot something on the firewall, choose a destination with severity level 7 (debugging). You can use the logging debug-trace command to force debug output to be sent to a logging destination for later review. All Syslog messages containing debug output use message ID 711001 at a default severity level of 7.

Pruning Messages

If you find that a severity level meets your needs but generates some unnecessary messages, you can "prune" those messages and keep them from being generated at all. Locate the message from an actual Syslog capture, from the lists of messages in this section, or from the message listing in Appendix B, "Security Appliance Logging Messages". Next, disable the message based on its six-digit message number with the following configuration command:

 Firewall(config)# no logging message message-number 

You can see a listing of all the disabled logging messages with the following EXEC command:

 Firewall# show logging message 

To re-enable a disabled message, you can use the logging message message-number configuration command. In PIX 7.x, to return all messages to their default levels, you can use the clear configure logging disabled configuration command.

Changing the Message Severity Level

Recall that each logging message has a default severity level associated with it. You can change that default behavior so that a message is sent based on a configurable severity level instead. This might be useful if you choose a severity level for a logging destination that includes most (but not all) of the messages that are interesting to you. For the messages that have a higher default level and that will not be sent, you can reconfigure their level to a lower value.

To change a message's severity level, use the following configuration command:

 Firewall(config)# logging message message-number [level level] 

Here, the message is identified by its six-digit message-number or Syslog ID and is assigned a new severity level (0 to 7). To see a message's current severity level, you can use the following EXEC command:

 Firewall# show logging message {message-number | all} 

The all keyword causes the state of all known or supported logging messages to be listed. Otherwise, you can specify the six-digit message-number to see the state of a specific message. The output shows the default severity level, the newly configured severity level (if any), and whether the message is enabled.

For example, suppose a firewall administrator wants to completely disable Syslog message 111008 while changing the severity of message 111009 from its default (debugging) to notifications. You could use the following commands to accomplish and verify this:

 Firewall/admin(config)# logging message 111009 level notifications Firewall/admin(config)# no logging message 111008 Firewall/admin(config)# exit Firewall/admin# show logging message syslog 111009: default-level debugging, current-level notifications (enabled) syslog 111008: default-level notifications (disabled) Firewall/admin# 

Access List Activity Logging

By default, logging message 106023 (default severity level 4, warnings) is generated when a deny access list entry is matched with a traffic flow. Only the overall ACL is listed in the message, with no reference to the actual denying ACL entry, as in the following example:

 %PIX-4-106023: Deny tcp src outside:220.163.33.180/18909 dst inside:   10.10.95.23/8039 by access-group "acl_outside" 

You can log messages when specific access control entries (ACEs, or individual permit/deny statements within an ACL) permit or deny a traffic flow by adding the log keyword to an ACE.

You can also log the rate at which traffic flows match specific access list entries. This can be useful to gauge the volume of attacks or exploits that are occurring over time.

After a traffic flow triggers an ACE configured for logging, the firewall keeps the flow in a cached list. If the reporting interval completes and there are no additional occurrences of the same flow, the cached entry is deleted, and the flow's hit count becomes 0.

You can set the logging severity level on a per-ACE basis if needed. Otherwise, severity level 6 is the default.

TIP

ACE logging generates logging message 106100 (default severity level 6), which has the following format:

 %PIX-6-106100: access-list acl_ID {permitted | denied | est-allowed}   protocol interface_name/source_address(source_port) ->   interface_name/dest_address(dest_port) hit-cnt number ({first hit |   number-second interval}) 

The ACL name acl_ID is shown to have permitted or denied a traffic flow. The specific traffic flow is defined as a protocol (UDP or TCP, for example), from the source (firewall interface name, IP address, and port) to the destination (firewall interface name, IP address, and port).

If this is the first packet in a flow, the hit count is 1, followed by the "first hit" flag. If the traffic flow has already been seen and is being tracked, this logging message appears at intervals defined along with the ACE log keyword. The hit count reflects how many times the same flow has been attempted, and the hit count interval is shown as a number of seconds. Using the hit count and interval timing values allows you to calculate the flow rate that is occurring.

1.

Configure logging on specific access list entries:

FWSM 2.x	Firewall(config)# access-list acl_name [extended] {permit | deny} ... log [level] [interval seconds]
PIX 6.x	Firewall(config)# access-list acl_name {permit | deny} ... log [level] [interval seconds]
PIX 7.x	Firewall(config)# access-list acl_name [extended] {permit | deny} ... log [level] [interval seconds]

Enter the access list entry normally, but add the log keyword at the end. If you want to log activity on this entry at a severity level other than 6, specify the level (1 to 7) too.

As soon as a traffic flow triggers this ACE, the hit count begins to increment with each new occurrence of the same flow. Nonzero hit counts are reported with a logging message at intervals of seconds (1 to 600; the default is 300 seconds or 5 minutes).

TIP

If you already have an access list configured and in place on a firewall, you can safely add the logging capability to any number of ACEs within it. In other words, when log and its associated fields are added to an existing ACE, the ACE remains in its current location in the list sequence; it isn't moved to the end of the list. In addition, you don't have to remove the ACE before configuring the log options. Simply re-enter the existing ACE and add the log keyword and options.

In the following example, an existing ACL called acl_out is being used on a production firewall. The third ACE needs to have logging added to it at severity level 4. Notice that after the ACE command is re-entered with log 4 added, it stays in the third ACE position and becomes active immediately.

 Firewall# show running-config [output omitted] access-list acl_out permit icmp any any access-list acl_out permit tcp any host 192.168.199.100 eq telnet access-list acl_out permit tcp any host 192.168.199.100 eq www access-list acl_out permit icmp any host 192.168.199.100 [output omitted] Firewall(config)# access-list acl_out permit tcp any host 192.168.199.100   eq www log 4 Firewall# show running-config [output omitted] access-list acl_out permit icmp any any access-list acl_out permit tcp any host 192.168.199.100 eq telnet access-list acl_out permit tcp any host 192.168.199.100 eq www log 4 access-list acl_out permit icmp any host 192.168.199.100 [output omitted] 

To disable message ID 106100 logging on an ACE, re-enter the command with the log default keywords appended. For example, the preceding shaded command would be re-entered as

 Firewall(config)# access-list acl_out permit tcp any host 192.168.199.100   eq www log default 

You can also re-enter the ACE with the log disable keywords to completely disable all ACE logging (both message IDs 106100 and 106023). In this case, the sample command would be re-entered as

 Firewall(config)# access-list acl_out permit tcp any host 192.168.199.100   eq www log disable 

2.

Limit the volume of deny messages.

1. Limit the number of deny flows that are tracked:

    Firewall(config)# access-list deny-flow-max n 

   
   

   Each unique traffic flow that is denied by an ACE configured for logging is added to a cached list of tracked flows. This usually isn't a problem unless something like a denial-of-service attack causes a very large number of flows to be denied and tracked.

   The firewall limits the maximum number of denied flows it tracks. By default, the maximum number is based on the available firewall memory: 4096 (64 MB or more), 1024 (16 MB or more), or 256 (less than 16 MB).

   You can change this to a lower maximum number of flows by specifying n (1 to the default maximum).

2. (Optional) Send an alert when the number of tracked flows is too high:

    Firewall(config)# access-list alert-interval seconds 

   
   

   When the maximum number of tracked flows is reached, the firewall generates logging message 106101. By default, this message is limited to appearing only every 300 seconds (5 minutes). You can change the alert interval to seconds (1 to 3600 seconds).