- Managing the Firewall Clock
- Generating Logging Messages
- Fine-Tuning Logging Message Generation
- Analyzing Firewall Logs
This chapter is from the book
This chapter is from the book
This chapter is from the book
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.
%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})
- 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).
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]
Firewall(config)# access-list acl_out permit tcp any host 192.168.199.100 eq www log default
Firewall(config)# access-list acl_out permit tcp any host 192.168.199.100 eq www log disable
- Limit the volume of deny messages.
- 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).
- (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).