This chapter is from the book
This chapter is from the book
This chapter is from the book
Configuring Event and Session Logging
Configuring event and session logging consists of some or all of the following tasks:
- Globally enabling system logging and configuring global logging properties
- Optionally, disabling logging of specific messages
- Optionally, changing the level of specific messages
- Optionally, configuring message event filters that will govern which system messages to send to particular destinations
- Configuring event destinations and specifying message filters that apply to each of those destinations
Configuring Global Logging Properties
To globally enable system logging and set general logging properties, navigate in ASDM to Configuration > Device Management > Logging > Logging Setup. The Logging Setup pane opens, as shown in Figure 6-5. In this pane, you can set several global logging properties.
)
Figure 6-5 Setting Global Logging Parameters
In Figure 6-5, the Enable Logging check box is selected. This is necessary because, by default, all logging on the security appliance is disabled. Options within this same pane, none of which are selected in the figure, are as follows:
- Enable logging on the failover standby unit: Check this box to enable logging for a standby security appliance, if one exists. By default, if this box is not checked, only severity level 1 messages are available on the standby unit (severity level 1 messages on the standby unit are related to failover events). Failover configurations are discussed in a later chapter.
- Send debug messages as syslogs: Check this box to redirect all debug output to system logs. By default, debug output is not included in system log messages. Checking this box redirects debug messages to logs as syslog message 711001, with severity level 7.
- Send syslogs in EMBLEM format: Check this box to enable Cisco EMBLEM format for all log destinations other than syslog servers. EMBLEM format is designed to be consistent with the Cisco IOS format. Many event management solutions will not recognize EMBLEM format messages, however. It is used primarily for the CiscoWorks Resource Manager Essentials (RME) Syslog Analyzer.
In Figure 6-5, the Buffer Size setting is left at the default of 4096 bytes (valid sizes are from 4096 to 1048576 bytes). This pertains to the internal buffer, maintained in memory. When this buffer gets full, it is overwritten in circular fashion, with each new message overwriting the oldest message in the buffer. If you do not want to lose information to these overwrites, there are two options for preserving buffered log messages: sending the buffer contents to an FTP server or saving them to internal flash memory. In Figure 6-5, the check box for FTP Server is checked, and the Configure FTP Settings button has been clicked, opening the Configure FTP Settings dialog box on the right side of the figure.
To enable saving of buffer contents to an FTP server, in the Configure FTP Settings dialog box, check the Enable FTP Client check box and configure information on the FTP server address, directory path for storing buffer log contents, and a username and password used to log in to the FTP server. In Figure 6-5, a server is defined in the out-of-band (OOB) management network, at IP address 192.168.1.15; the /ASALogs directory of the FTP server is used for storage; the username is set to CiscoASA; and a password of CCNPSecurity is entered twice, the second time to verify it is entered correctly. Clicking OK would complete the FTP server definition.
If you were saving buffered log contents to internal flash memory, you would need to define two parameters: the maximum amount of flash memory to be used for storing log information, and the minimum free space to be preserved in flash memory. Selecting this option creates a directory named "syslog" on the device disk on which messages are stored.
Finally, Figure 6-5 leaves the default queue size of 100 for messages retained in the ASDM log buffer. The ASDM log buffer is a different buffer than the internal log buffer.
Once the FTP server window is completed and saved, clicking Apply in the Logging Setup pane will send the new settings to the security appliance.
The CLI commands generated by the changes made are as follows:
logging enable logging ftp-bufferwrap logging ftp-server 192.168.1.15 /ASALogs CiscoPress CCNPSecurity
If you are configuring the security appliance from the CLI, you can enter these commands directly in global configuration mode.
Two other settings that are global for syslog messages are the syslog Facility Code and whether messages carry a time stamp when sent by the security appliance. These settings are not made in the same pane in which the other settings are made.
To modify these settings, navigate to Configuration > Device Management > Logging > Syslog Setup. This pane is shown in Figure 6-6. In the Syslog Format area, at the top of the pane, you can set the Facility Code and enable/disable time stamps.
)
Figure 6-6 The Syslog Setup Pane
In Figure 6-6, the default syslog Facility Code of LOCAL4(20) is left unchanged. Syslog Facility Codes are included in messages sent to syslog servers. The codes are used by syslog servers to organize event messages as they arrive. Eight logging facilities are available, LOCAL0 to LOCAL7 (if set in decimal only, 16–23). LOCAL4(20) is the default setting for all Cisco ASA syslog events. In the figure, the check box to enable time stamps is selected. Click Apply to send the change to the security appliance.
The CLI command generated by the change is as follows:
logging timestamp
If you are configuring the security appliance from the CLI, you can enter this command directly in global configuration mode.
Altering Settings of Specific Messages
Sometimes a default system message does not contain any useful information, or the default severity assigned to a message is not suitable to a particular environment. In such cases, you can tune individual system messages by globally suppressing them or by altering their default severity. You tune these aspects in the Syslog Setup pane, also.
The Syslog ID Setup area comprises most of the Syslog Setup pane. The first option available is to change what message IDs are displayed in the main portion of this area. The default option is the display of all syslog message IDs. Other options available in the Show drop-down list are as follows:
- Disabled syslog IDs: Display only message IDs that have been explicitly suppressed.
- Syslog IDs with changed logging: Display only message IDs with severity levels that have been changed from their default values.
- Syslog IDs that are suppressed or with a changed logging level: Display all message IDs that have been modified by being suppressed or having their default level modified.
To modify a specific message ID, click the message to select it, and then click the Edit button to open the Edit Syslog ID Settings dialog box, shown in Figure 6-7. In this dialog box, you can suppress (disable) a particular message or change its configured logging level.
)
Figure 6-7 Disabling a Message ID
In Figure 6-7, message ID 113007 has been selected for editing, and the Disable Messages check box has been selected. Clicking OK will configure global suppression of this particular message. Message 113007 is generated when a locked user account is unlocked by an administrator, and in this scenario, it has been decided that this information is unimportant—what is important is to log when an account is locked for excessive incorrect password attempts.
There are also times when you may want to log a particular message ID, but alter the severity level at which it is reported. You do so from the same Edit Syslog ID Settings dialog box. Click a message to select it, and then click the Edit button. Figure 6-8 shows an example of modifying the severity level of a syslog message.
)
Figure 6-8 Modifying a Syslog Message Severity Level
In Figure 6-8, message ID 106018 has been selected for modification. As you can see in the background, the default setting for this message ID is Critical (2). This particular message is generated if an ICMP packet is denied by an outgoing access list. Because outgoing filters do not exist by default on the security appliance, this means an administrator explicitly configured the security appliance to block such packets. However, given that an internal user generating a ping that is dropped by the security appliance would generate such a message, in this scenario it has been decided to alter the level from Critical to Notifications (5). Click OK to complete the modification of this message, and then click Apply to send these changes to the security appliance.
The CLI commands generated by the changes made are as follows:
logging message 106018 level Notifications no logging message 113007
If you are configuring the security appliance from the CLI, you can enter these commands directly in global configuration mode.
Configuring Event Filters
For each logging destination, you can configure filters (known as event lists) that determine which subset of all generated messages will be forwarded to that destination. You can configure such filters based on the following:
- Event (message) severity only: For example, by specifying a maximum severity of 4 (Warnings), all messages with a severity of Warnings or higher (severity levels 0 to 4) would be forwarded to the logging destination. All messages with severities of 5 to 7 would be dropped.
- Event classes: All system messages are grouped into event classes based on the subsystem that created the messages. For example, there is an event class for the Authentication subsystem.
- A combination of event class and event severity: For example, all Authentication messages with a maximum severity of 4 (Warnings).
- The message ID: Each message has a unique message ID. Therefore, you can select individual messages for forwarding to particular logging destinations.
Event lists are reusable groups of messages, which can be selected by a combination of event class and severity, or individually by message ID. When you create an event list, you can apply that same event list to multiple logging destinations, thus simplifying the configuration of message filters.
To create an event list, navigate to Configuration > Device Management > Logging > Event Lists. Click Add to create a new event list. This opens the Add Event List dialog box, which is shown in Figure 6-9. You assign a unique name to each event list, and then configure the parameters that define your desired filter.
)
Figure 6-9 Configuring an Event List
In Figure 6-9, a name of ALERT_ADMIN_BY_EMAIL has been defined. The Add button in the Event Class/Severity Filters area was clicked to open the Add Class and Severity Filter dialog box, in which a specific class and severity can be defined. In this example, All Event Classes has been selected, and a severity level of Alerts (1) has been selected. In this scenario, it has been determined that any syslog message of severity 0 or 1 should generate an immediate email notification to an administrator (setup of the SMTP log destination is covered in the "Email" section of this chapter). This event list will accommodate such a configuration. Click OK twice to complete the configuration of the event class filter and the creation of the event list. Finally, click Apply to send the configuration to the security appliance.
The CLI command generated by the change is as follows:
logging list ALERT_ADMIN_BY_EMAIL level Alerts
If you are configuring the security appliance from the CLI, you can enter this command directly in global configuration mode.
Configuring Individual Event Destinations
After you have enabled logging globally, optionally set up global logging properties, and optionally configured event lists, you can configure the security appliance to send logging messages to one or more logging destinations. For each destination, you specify a filter that will select a subset of generated messages to be forwarded to that destination.
To configure logging destinations and filters, navigate to Configuration > Device Management > Logging > Logging Filters. In the Logging Filters pane that opens, you can activate logging to any of the eight available destinations and configure filters that determine which generated messages are forwarded to each.
Internal Buffer
The first example will be to configure the internal buffer as a logging destination. In the Logging Filters pane, select the Internal Buffer destination, and click Edit to open the Edit Logging Filters dialog box, shown in Figure 6-10.
)
Figure 6-10 Configuring the Internal Buffer Logging Filter
As you can see in Figure 6-10, you have several options for determining the logging filter for a particular log destination. To create a filter that applies to all event classes, choose one of the following radio buttons in the top, Syslogs from All Event Classes area:
- Filter on severity: Filters system log messages by their severity level, and allows you to specify the level of messages that should be forwarded to the log destination. In Figure 6-10, this choice is selected, and the filter level is set to Debugging, which sends all system messages to the destination being configured (internal buffer). Depending on traffic, this particular choice can overwhelm the destination service (especially the console) or the user attempting to analyze events. You should carefully consider the impact of your choice before applying the configuration to the security appliance. If you wish to log all messages from all severity levels, it is strongly recommended that you do so to the internal buffer, and never to the console. In fact, it is generally recommended to leave console logging disabled.
- Use event list: Filters system log messages based on a previously defined event list, and allows you to specify which event list to use, or create a new event list.
- Disable logging from all event classes: Disables all forwarding of system messages to the destination being configured.
You can also create specific logging filters in this dialog box by entering the filter criteria in the Syslogs from Specific Event Classes area. This is equivalent to creating an event list for just this specific logging destination.
Click OK to complete the configuration of a logging filter to the internal buffer logging destination. Click Apply to send the modified settings to the security appliance.
The CLI command generated by the change made is as follows:
logging buffered Debugging
If you are configuring the security appliance from the CLI, you can enter this command directly in global configuration mode.
ASDM
Cisco ASDM contains a powerful event viewer that you can use to display a real-time message feed from the security appliance. This event viewer is particularly useful when you are troubleshooting security appliance software and configuration issues, or when you are monitoring real-time activity over the security appliance.
You enable logging to the internal ASDM event viewer by configuring the ASDM logging destination and specifying a logging filter, in the same manner as for other logging destinations. Messages are forwarded to ASDM over the HTTPS session and are displayed in a log viewer window at the bottom of the ASDM Home page.
This example assumes that the ASDM logging destination has been configured to receive messages from all event classes, containing a maximum severity level of Informational. Click Apply to send the modified settings to the security appliance.
The CLI command generated by the change made is as follows:
logging asdm Informational
If you are configuring the security appliance from the CLI, you can enter this command directly in global configuration mode.
To use the full event viewer functionality, start the viewer by navigating in ASDM to Monitoring > Logging > Real-Time Log Viewer, selecting a logging level, and clicking the View button. The ASDM Real-Time Log Viewer opens in a dedicated window and starts displaying log messages as selected by the configured message filter. Figure 6-11 shows an example of the Real-Time Log Viewer.
)
Figure 6-11 Real-Time Log Viewer
In the Real-Time Log Viewer, you can set additional keyword-based filtering by entering a keyword in the Filter By field in the log viewer toolbar. Above this field are toolbar icons that can be used to pause, resume, and clear the event display, copy individual messages to the clipboard, and set message colors.
The log viewer interface also allows you to select a particular message, and invoke various options by right-clicking it. You can, for example, show or even create specific access rules based on log messages. For example, if a log message showed that a packet had been denied by an access rule, you could immediately create a rule to allow such packets in the future. Or, for all session-related messages, you could right-click the interface and select Show Access Rule to jump immediately to the table of access rules and to the exact rule permitting or denying this particular connection.
At the bottom of the Real-Time Log Viewer, a context-sensitive help window shows message descriptions, recommends actions to administrators, and offers full message details. This is the only tool in ASDM that provides an administrator with such detailed explanations of log messages. Additionally, the suggestion of remedies is an invaluable aid in rapid troubleshooting and resolution of identified problems.
You can also use ASDM to view a snapshot of the current appliance internal log buffer, by navigating to Monitor > Logging > Log Buffer, selecting a maximum severity level, and clicking View.
Syslog Server(s)
Probably the most common destination to configure for log messages is one or more syslog servers in your network. Configuring the security appliance to send logs to syslog servers enables you to easily archive logs, limited only by the available disk space on the remote syslog server. You can specify up to 16 syslog servers as log destinations. Further, the security appliance can deliver syslog messages to servers using either UDP (standard syslog) or TCP (specialized for firewall syslog) as transport protocols.
Prior to ASA software version 8.0, all syslog messages were transferred in clear text. Beginning with software version 8.0(2), support was introduced for secure logging, using a SSL/TLS transport layer between the security appliance and syslog servers. Certificate-based authentication and encrypted data transfer help mitigate security threats to the logging service when messages are crossing an untrusted network. To use secure logging, you must set up an SSL/TLS connection between the security appliance and a remote syslog server supporting SSL/TLS. Also, the SSL syslog server must be added to the ASA as a certificate trust point. Configuration of secure logging is not covered in this book, but more information can be obtained from the Cisco ASDM User Guide available at Cisco.com.
When a security appliance is configured to use TCP-based syslog to at least one syslog server, by default, the security appliance will block all traffic attempting to go through the appliance if the TCP-based syslog server is down or unable to record further messages in its logs (that is, it is out of disk space). This feature is designed to prevent traffic from traversing a security appliance that is unable to log events, a common requirement in high-security networks. Use this feature if your local security policy requires this level of risk control.
To configure (non-SSL/TLS) syslog servers as log destinations, navigate to Configuration > Device Management > Logging > Syslog Servers. In the Syslog Servers pane, click Add to define a new syslog server log destination. The Add Syslog Server dialog box opens, as shown in Figure 6-12. Here, you define which interface the security appliance uses to reach the server, the server's IP address, whether to use TCP or UDP as the transport protocol, the destination port on the server, and, optionally, the use of EMBLEM format (only if using UDP) or SSL/TLS encryption (only if using TCP).
)
Figure 6-12 Adding a Syslog Server Destination
In Figure 6-12, a syslog server is defined, reachable through the management interface (in the OOB management network), using IP address 192.168.1.7, and standard UDP-based syslog transport to port 514 (the default UDP port; the default TCP port is 1470). Click OK to complete the configuration of this server.
If you are using TCP-based syslog, you have the option to allow user traffic to traverse the ASA even when the TCP syslog server is down. To do so, in the main Syslog Servers pane, check the Allow User Traffic to Pass when TCP Syslog Server Is Down check box and then click Apply to send the new server definitions to the security appliance. Selecting this option generates the logging permit-hostdown command in the security appliance configuration.
After you have defined one or more syslog servers, you must configure a logging filter for the destination syslog servers, before the security appliance actually sends event messages to the configured servers. You do this the same way as covered previously. This example assumes that you have configured a logging filter to send all event classes, with a maximum severity of Warnings (4) to the logging destination of syslog servers.
The CLI commands generated by the changes made are as follows:
logging trap Warnings logging host management 192.168.1.7
If you are configuring the security appliance from the CLI, you can enter these commands directly in global configuration mode.
In most cases, using remote syslog servers as the primary method of reporting events to a central repository is recommended, as syslog is a widely supported and easily deployed logging protocol. Because UDP transport does not guarantee delivery, and should be used only over trusted or OOB networks, you should consider the use of TCP-based syslog when operating over a congested network subject to frequent packet loss. Also, consider the use of SSL/TLS if you are using untrusted ("sniffable") transport networks between the security appliance and the syslog server.
Sending log messages to an email system is useful, as it provides a simple way to integrate event notification with many messaging solutions, including simple email, mobile email, and SMS or pager systems, using appropriate gateways.
Configuring the security appliance to send email notifications is similar to configuring syslog servers, in that you must first define how the security appliance reaches intended recipients (sender and receiver addresses, SMTP servers, and so on), and then create a logging filter instructing the security appliance to use email as a logging destination and what events to send.
To configure email sender and recipient addresses, navigate to Configuration > Device Management > Logging > E-Mail Setup. Enter a source email address in the provided field, and then click the Add button to add recipient information. Figure 6-13 shows an example, where a source address of ASA@CiscoPress.CCNP has been entered in the Source E-Mail Address field.
)
Figure 6-13 Adding an Email Recipient
In the Add E-Mail Recipient dialog box, the Destination E-Mail Address field has been completed with Admin@CiscoPress.CCNP as the recipient. Finally, the maximum severity of event messages that should generate an email to this recipient is configured in the Syslog Severity field, as Alerts.
After you have configured recipients, you must configure the security appliance with information about the SMTP server(s) through which the security appliance will send notifications. To do this, navigate to Configuration > Device Management > Logging > SMTP. The SMTP pane, as shown in Figure 6-14, is where you configure a primary and, optionally, secondary SMTP server address for the security appliance to send email through.
)
Figure 6-14 Defining SMTP Servers
Figure 6-14 shows an example where two SMTP servers on the DMZ network—172.16.0.5 as primary and 172.16.0.6 as secondary—are configured.
After configuring sender and recipient addresses and SMTP servers, you configure email notifications just like any other logging destination. In this example, however, rather than simply set a maximum severity for all event classes, Figure 6-15 shows the configuration of a logging filter for the E-Mail destination, using the previously created event list named ALERT_ADMIN_BY_EMAIL.
)
Figure 6-15 Configuring Email Logging Filter
It is important to limit the amount of notifications sent via email, so use this destination only for exceptional events of critical importance. In this example, recall that event list ALERT_ADMIN_BY_EMAIL was defined with a maximum severity level of Alerts (1). This example might be overly restrictive, so use an appropriate level based on your local security policy.
Click OK in the Edit Logging Filters dialog box, and then click Apply in the Logging Filters pane, to complete the configuration of email as a logging destination.
The CLI commands generated by the changes made are as follows:
logging mail ALERT_ADMIN_BY_EMAIL smtp-server 172.16.0.5 172.16.0.6 logging from-address ASA@CiscoPress.CCNP logging recipient-address Admin@CiscoPress.CCNP level Alerts
If you are configuring the security appliance from the CLI, you can enter these commands directly in global configuration mode.
NetFlow
To configure NSEL in the security appliance, you must first configure NetFlow export destinations by defining the location of NetFlow collectors. To do so, navigate to Configuration > Device Management > Logging > NetFlow. In the NetFlow pane, shown in Figure 6-16, you can configure NetFlow destinations, and also some options that might impact performance with NetFlow export enabled.
)
Figure 6-16 Configuring NetFlow Settings
In Figure 6-16, a NetFlow collector has been defined through the management interface, with IP address 192.168.1.13, and the default NetFlow port of UDP 2055. Additionally, the option Delay Transmission of Flow Creation Events for Short-Lived Flows has been enabled, and the delay set to 10 seconds. Finally, because use of NetFlow makes some syslog messages redundant, the option to Disable Redundant Syslog Messages has been selected. (Neither of the preceding options is enabled by default.)
Defining flows to be exported to NetFlow collectors is unique among logging destinations. With NSEL, you can granularly select which flows through the security appliance are exported using NetFlow, based on flow properties such as IP addresses, protocols, and ports. You configure this selection using Cisco Modular Policy Framework (MPF) service policies, which are covered in a later chapter.
The CLI commands generated by the changes made are as follows:
no logging message 106015 no logging message 106023 ...output omitted... flow-export delay flow-create 10 flow-export destination management 192.168.1.13 2055
If you are configuring the security appliance from the CLI, you can enter these commands directly in global configuration mode.
Telnet or SSH Sessions
To enable the security appliance to display system event messages in Telnet or SSH sessions, you can configure a logging filter for the Telnet and SSH Sessions destination, like any other destination. This generates the logging monitor command in the security appliance's configuration file. Although these messages are sent to the Telnet or SSH session, the user must also use the terminal monitor command to see the messages displayed in their remote terminal session.