Managing Event and Session Logging
The Cisco Adaptive Security Appliance supports a full audit trail of system log messages that describe its activities and security events. The two major classifications of events are system events, such as resource depletion, and network events, such as denied sessions or packets. These messages are used to create log files, which can be filtered and sent to a number of differing destinations for storage, display, or analysis.
Figure 6-4 provides a graphical illustration of the Cisco ASA logging subsystem, showing the two major event classifications as sources, and the eight possible destinations.
)
Figure 6-4 The Cisco ASA Logging Subsystem
The security appliance supports sending log messages to the following destinations:
- Console: The security appliance console, a low-bandwidth serial connection to which messages can be sent for display on a console CLI session. This mode is useful for limited debugging, or in production environments with limited traffic or a lack of centralized management tools.
- ASDM: The ASDM graphical user interface, which provides a powerful real-time event viewer useful for troubleshooting issues or monitoring network activity.
- Monitor: Telnet or SSH administrative sessions. This mode is useful to receive real-time debugging information when troubleshooting.
- Buffered: The internal in-memory buffer on the security appliance. Although useful for storage and analysis of recent activity, the internal buffer is limited in size, and it is not persistent, by default, across appliance reboots. The buffer can optionally be archived to an external FTP server or to the security appliance's internal flash memory.
- Host: Remote syslog servers, using the standard syslog protocol. Use the logging host command in conjunction with the logging trap command to define both a destination server and a logging level.
- SNMP: Remote network management servers, using the standard Simple Network Management Protocol (SNMP) Trap to send event messages. This mode is configured with the snmp-server enable traps syslog command, rather than directly with a logging destination command.
- Mail: Remote email systems, using the standard Simple Mail Transfer Protocol (SMTP) to send event messages to a defined SMTP server, or set of SMTP servers.
- Flow-export-syslogs: Remote NetFlow collectors, using the standard NetFlow v9 protocol to send event messages to the defined collector.
NetFlow Support
Cisco NetFlow efficiently provides a key set of services for IP applications, including network traffic accounting, usage-based network billing, network planning, security, denial-of-service monitoring capabilities, and network monitoring. NetFlow provides valuable information about network users and applications, peak usage times, and traffic routing.
The basic output of NetFlow is known as a flow record. Several different formats for flow records have existed as NetFlow has evolved and matured. The current version of NetFlow formatting is known as NetFlow version 9. The Cisco ASA supports providing NetFlow Secure Event Logging (NSEL), beginning with version 8.2(1). NSEL allows specific, high-volume, traffic-related events to be exported from the security appliance in a more efficient and scalable manner than that provided by standard syslog logging. You may use any NetFlow v9–capable collector to receive ASA NetFlow data.
The ASA implementation of NSEL is a stateful, IP flow tracking method that exports only those records that indicate significant events in a flow. In stateful flow tracking, tracked flows go through a series of state changes. NSEL events are used to export data about flow status, and are triggered by the events that cause state changes. Examples of events that are tracked include flow-create, flow-teardown, and flow-denied (excluding flows that are denied by EtherType ACLs, which are discussed in Chapter 12, "Using Transparent Firewall Mode"). Each NSEL record has an event ID and an extended event ID field, which describe the flow event.
The Cisco ASA supports multiple NetFlow export destinations and can therefore store its NetFlow information on multiple NetFlow collectors.
For a detailed discussion on Cisco ASA NetFlow event generation, consult the "Cisco ASA 5500 Series Implementation Note for NetFlow Collectors, 8.2," at www.cisco.com/en/US/docs/security/asa/asa82/netflow/netflow.html.
Logging Message Format
Most Cisco ASA messages generated by the logging subsystem are simple text messages that conform to a particular message format, as demonstrated here:
Jan 5 2011 09:27:16 FIREWALL : %ASA-6-725002: Device completed SSL handshake with client management:192.168.1.8/49287
This message consists of the following:
- An optional timestamp (disabled by default)
- An optional device-id (disabled by default), which can include the interface name, IP address, hostname, context name, or a custom string up to 16 characters, if configured
- A message identifier (%ASA-6-725002 in the example), which identifies the device type (ASA), the message severity level (6, Informational), and the event message number (725002)
- The message text (Device completed SSL handshake...)
Additional data may be added to the message, depending on its destination. For example, a time stamp and hostname may be added for the syslog destination.
Message Severity
Each log message is assigned a severity level that indicates its relative importance. Lower numbers are of higher severity than higher numbers. Possible number and string values for message severity are shown in Table 6-2.
Table 6-2. Message Severity Levels
|
Numeric Level |
Equivalent String |
Definition |
|
0 |
Emergencies |
Extremely critical "system unusable" messages |
|
1 |
Alerts |
Messages that require immediate administrator action |
|
2 |
Critical |
A critical condition |
|
3 |
Errors |
An error message (also the level of many access list deny messages) |
|
4 |
Warnings |
A warning message (also the level of many other access list deny messages) |
|
5 |
Notifications |
A normal but significant condition (such as an interface coming online) |
|
6 |
Informational |
An informational message (such as a session being created or torn down) |
|
7 |
Debugging |
A debug message or very detailed accounting message |