Logging

This chapter describes how to log system messages and use them for troubleshooting.

About Logging

System logging is a method of collecting messages from devices to a server running a syslog daemon. Logging to a central syslog server helps in aggregation of logs and alerts. Cisco devices can send their log messages to a UNIX-style syslog service. A syslog service accepts messages and stores them in files, or prints them according to a simple configuration file. This form of logging provides protected long-term storage for logs. Logs are useful both in routine troubleshooting and in incident handling.

The ASA system logs provide you with information for monitoring and troubleshooting the ASA. With the logging feature, you can do the following:

  • Specify which syslog messages should be logged.

  • Disable or change the severity level of a syslog message.

  • Specify one or more locations where syslog messages should be sent, including:

    • An internal buffer

    • One or more syslog servers

    • ASDM

    • An SNMP management station

    • Specified e-mail addresses

    • Console

    • Telnet and SSH sessions.

  • Configure and manage syslog messages in groups, such as by severity level or class of message.

  • Specify whether or not a rate-limit is applied to syslog generation.

  • Specify what happens to the contents of the internal log buffer when it becomes full: overwrite the buffer, send the buffer contents to an FTP server, or save the contents to internal flash memory.

  • Filter syslog messages by locations, severity level, class, or a custom message list.

Logging in Multiple Context Mode

Each security context includes its own logging configuration and generates its own messages. If you log in to the system or admin context, and then change to another context, messages you view in your session are only those messages that are related to the current context.

Syslog messages that are generated in the system execution space, including failover messages, are viewed in the admin context along with messages generated in the admin context. You cannot configure logging or view any logging information in the system execution space.

You can configure the ASA to include the context name with each message, which helps you differentiate context messages that are sent to a single syslog server. This feature also helps you to determine which messages are from the admin context and which are from the system; messages that originate in the system execution space use a device ID of system, and messages that originate in the admin context use the name of the admin context as the device ID.

Syslog Message Analysis

The following are some examples of the type of information you can obtain from a review of various syslog messages:

  • Connections that are allowed by ASA security policies. These messages help you spot holes that remain open in your security policies.

  • Connections that are denied by ASA security policies. These messages show what types of activity are being directed toward your secured inside network.

  • Using the ACE deny rate logging feature shows attacks that are occurring on your ASA.

  • IDS activity messages can show attacks that have occurred.

  • User authentication and command usage provide an audit trail of security policy changes.

  • Bandwidth usage messages show each connection that was built and torn down as well as the duration and traffic volume used.

  • Protocol usage messages show the protocols and port numbers used for each connection.

  • Address translation audit trail messages record NAT or PAT connections being built or torn down, which are useful if you receive a report of malicious activity coming from inside your network to the outside world.

Syslog Message Format

Syslog messages are structured as follows:

[<PRI>] [Timestamp] [Device-ID] : %ASA-Class-Level-Message_number: Message_text

Field descriptions are as follows:

<PRI> Priority value. When the logging EMBLEM is enabled, this value is displayed in the syslog message. Logging EMBLEM is compatible with UDP and not with TCP.
Timestamp Date and time of the event is displayed. When logging of timestamps is enabled, and if the timestamp is configured to be in the RFC 5424 format, all timestamp in syslog messages display the time in UTC, as indicated by the RFC 5424 standard.
Device-ID The device identifier string that was configured while enabling the logging device-id option through the user interface. If enabled, the device ID does not appear in EMBLEM-formatted syslog messages.
Class

The syslog message class provides a method of categorizing syslog messages by type, equivalent to a feature or function of the device. For example, the vpnc class denotes VPN Client.

ASA

The syslog message facility code for messages that are generated by the ASA. This value is always ASA.

Level

0 through 7. The level reflects the severity of the condition described by the syslog message—the lower the number, the more severe the condition.

Message_number

A unique six-digit number that identifies the syslog message. All messages are documented in the Cisco Secure Firewall ASA Series Syslog Messages guide.

Message_text

A text string that describes the condition. This portion of the syslog message sometimes includes IP addresses, port numbers, or usernames.

Example of a syslog message with logging EMBLEM, logging timestamp rfc5424, and device-id enabled.

<166>2018-06-27T12:17:46Z: %ASA-6-110002: Failed to locate egress interface for protocol from src interface :src IP/src port to dest IP/dest port

Example of a syslog message with logging timestamp rfc5424 and device-id enabled.

2018-06-27T12:17:46Z asa : %ASA-6-110002: Failed to locate egress interface for protocol from src interface :src IP/src port to dest IP/dest port

Syslog messages are structured as follows:

[<PRI>] [Timestamp] [Device-ID] : %ASA-Level-Message_number: Message_text

Field descriptions are as follows:

<PRI> Priority value. When the logging EMBLEM is enabled, this value is displayed in the syslog message. Logging EMBLEM is compatible with UDP and not with TCP.
Timestamp Date and time of the event is displayed. When logging of timestamps is enabled, and if the timestamp is configured to be in the RFC 5424 format, all timestamp in syslog messages display the time in UTC, as indicated by the RFC 5424 standard.
Device-ID The device identifier string that was configured while enabling the logging device-id option through the user interface. If enabled, the device ID does not appear in EMBLEM-formatted syslog messages.
ASA

The syslog message facility code for messages that are generated by the ASA. This value is always ASA.

Level

0 through 7. The level reflects the severity of the condition described by the syslog message—the lower the number, the more severe the condition.

Message_number

A unique six-digit number that identifies the syslog message.

Message_text

A text string that describes the condition. This portion of the syslog message sometimes includes IP addresses, port numbers, or usernames.

All syslog messages that are generated by the device are documented in the Cisco Secure Firewall ASA Series Syslog Messages guide.

Example of a syslog message with logging EMBLEM, logging timestamp rfc5424, and device-id enabled.

<166>2018-06-27T12:17:46Z: %ASA-6-110002: Failed to locate egress interface for protocol from src interface :src IP/src port to dest IP/dest port

Example of a syslog message with logging timestamp rfc5424 and device-id enabled.

2018-06-27T12:17:46Z asa : %ASA-6-110002: Failed to locate egress interface for protocol from src interface :src IP/src port to dest IP/dest port

Severity Levels

The following table lists the syslog message severity levels. You can assign custom colors to each of the severity levels to make it easier to distinguish them in the ASDM log viewers. To configure syslog message color settings, either choose the Tools > Preferences > Syslog tab or, in the log viewer itself, click Color Settings on the toolbar.

Table 1. Syslog Message Severity Levels

Level Number

Severity Level

Description

0

emergencies

System is unusable.

1

alert

Immediate action is needed.

2

critical

Critical conditions.

3

error

Error conditions.

4

warning

Warning conditions.

5

notification

Normal but significant conditions.

6

informational

Informational messages only.

7

debugging

Debugging messages only.

Log at this level only temporarily, when debugging issues. This log level can potentially generate so many messages that system performance can be affected.


Note


ASA and do not generate syslog messages with a severity level of zero (emergencies).


Syslog Message Filtering

You can filter generated syslog messages so that only certain syslog messages are sent to a particular output destination. For example, you could configure the ASA to send all syslog messages to one output destination and to send a subset of those syslog messages to a different output destination.

Specifically, you can direct syslog messages to an output destination according to the following criteria:

  • Syslog message ID number

  • Syslog message severity level

  • Syslog message class (equivalent to a functional area)

You customize these criteria by creating a message list that you can specify when you set the output destination. Alternatively, you can configure the ASA to send a particular message class to each type of output destination independently of the message list.

Syslog Message Classes

You can use syslog message classes in two ways:

  • Specify an output location for an entire category of syslog messages. Use the logging class command.

  • Create a message list that specifies the message class. Use the logging list command.

The syslog message class provides a method of categorizing syslog messages by type, equivalent to a feature or function of the device. For example, the rip class denotes RIP routing.

All syslog messages in a particular class share the same initial three digits in their syslog message ID numbers. For example, all syslog message IDs that begin with the digits 611 are associated with the vpnc (VPN client) class. Syslog messages associated with the VPN client feature range from 611101 to 611323.

In addition, most of the ISAKMP syslog messages have a common set of prepended objects to help identify the tunnel. These objects precede the descriptive text of a syslog message when available. If the object is not known at the time that the syslog message is generated, the specific heading = value combination does not appear.

The objects are prefixed as follows:

Group = groupname, Username = user, IP = IP_address

Where the group is the tunnel-group, the username is the username from the local database or AAA server, and the IP address is the public IP address of the remote access client or Layer 2 peer.

The following table lists the message classes and the range of message IDs in each class.

Table 2. Syslog Message Classes and Associated Message ID Numbers

Class

Definition

Syslog Message ID Numbers

auth

User Authentication

109, 113

Access Lists

106

Application Firewall

415

Botnet Traffic Filtering

338

bridge

Transparent Firewall

110, 220

ca

PKI Certification Authority

717

citrix

Citrix Client

723

Clustering

747

Card Management

323

config

Command Interface

111, 112, 208, 308

csd

Secure Desktop

724

cts

Cisco TrustSec

776

dap

Dynamic Access Policies

734

eap, eapoudp

EAP or EAPoUDP for Network Admission Control

333, 334

eigrp

EIGRP Routing

336

email

E-mail Proxy

719

Environment Monitoring

735

ha

Failover

101, 102, 103, 104, 105, 210, 311, 709

Identity-based Firewall

746

ids

Intrusion Detection System

400, 733

IKEv2 Toolkit

750, 751, 752

ip

IP Stack

209, 215, 313, 317, 408

ipaa

IP Address Assignment

735

ips

Intrusion Protection System

400, 401, 420

IPv6

325

Licensing

444

mdm-proxy

MDM Proxy

802

nac

Network Admission Control

731, 732

nacpolicy

NAC Policy

731

nacsettings

NAC Settings to apply NAC Policy

732

NAT and PAT

305

Network Access Point

713

np

Network Processor

319

NP SSL

725

ospf

OSPF Routing

318, 409, 503, 613

Password Encryption

742

Phone Proxy

337

rip

RIP Routing

107, 312

rm

Resource Manager

321

Smart Call Home

120

session

User Session

106, 108, 201, 202, 204, 302, 303, 304, 305, 314, 405, 406, 407, 500, 502, 607, 608, 609, 616, 620, 703, 710

snmp

SNMP

212

ScanSafe

775

ssl

SSL Stack

725

svc

SSL VPN Client

722

sys

System

199, 211, 214, 216, 306, 307, 315, 414, 604, 605, 606, 610, 612, 614, 615,701, 711, 741

Threat Detection

733

tag-switching

Service Tag Switching

779

transactional-rule-engine-tre

Transactional Rule Engine

780

uc-ims

UC-IMS

339

vm

VLAN Mapping

730

vpdn

PPTP and L2TP Sessions

213, 403, 603

vpn

IKE and IPsec

316, 320, 402, 404, 501, 602, 702, 713, 714, 715

vpnc

VPN Client

611

vpnfo

VPN Failover

720

vpnlb

VPN Load Balancing

718

VXLAN

778

webfo

WebVPN Failover

721

webvpn

WebVPN and AnyConnect Client

716

Custom Message Lists

Creating a custom message list is a flexible way to exercise control over which syslog messages are sent to which output destination. In a custom syslog message list, you specify groups of syslog messages using any or all of the following criteria:
  • Severity level

  • Message IDs

  • Ranges of syslog message IDs

  • Message class.

For example, you can use message lists to do the following:

  • Select syslog messages with the severity levels of 1 and 2 and send them to one or more e-mail addresses.

  • Select all syslog messages associated with a message class (such as ha) and save them to the internal buffer.

A message list can include multiple criteria for selecting messages. However, you must add each message selection criterion with a new command entry. It is possible to create a message list that includes overlapping message selection criteria. If two criteria in a message list select the same message, the message is logged only once.

Clustering

Syslog messages are an invaluable tool for accounting, monitoring, and troubleshooting in a clustering environment. Each ASA unit in the cluster (up to eight units are allowed) generates syslog messages independently; certain logging commands then enable you to control header fields, which include a time stamp and device ID. The syslog server uses the device ID to identify the syslog generator. You can use the logging device-id command to generate syslog messages with identical or different device IDs to make messages appear to come from the same or different units in the cluster.

Guidelines for Logging

This section includes guidelines and limitations that you should review before configuring logging.

IPv6 Guidelines

  • IPv6 is supported. Syslogs can be sent using TCP or UDP.

  • Ensure that the interface configured for sending syslogs is enabled, IPv6 capable, and the syslog server is reachable through the designated interface.

  • Secure logging over IPv6 is not supported.

Additional Guidelines

  • The syslog server must run a server program called syslogd. Windows provides a syslog server as part of its operating system.

  • The syslog server operates based on the syslog-ng process of the firewall system. Do not use external configuration files, like the scwx.conf file from SecureWorks. Such files are not compatible with the device. Using them will lead to parsing error and eventually the syslog-ng process will fail.

  • To view logs generated by the ASA, you must specify a logging output destination. If you enable logging without specifying a logging output destination, the ASA generates messages but does not save them to a location from which you can view them. You must specify each different logging output destination separately. For example, to designate more than one syslog server as an output destination, enter a new command for each syslog server.

  • Sending syslogs over TCP is not supported on a standby device.

  • If you use TCP as the transport protocol, the system opens 4 connections to the syslog server to ensure that messages are not lost. If you are using the syslog server to collect messages from a very large number of devices, and the combined connection overhead is too much for the server, use UDP instead.

  • It is not possible to have two different lists or classes being assigned to different syslog servers or same locations.

  • You can configure up to 16 syslog servers. However, in multiple context mode, the limitation is 4 servers per context.

  • The syslog server should be reachable through the ASA. You should configure the device to deny ICMP unreachable messages on the interface through which the syslog server is reachable and to send syslogs to the same server. Make sure that you have enabled logging for all severity levels. To prevent the syslog server from crashing, suppress the generation of syslogs 313001, 313004, and 313005.

  • The number of UDP connections for syslog is directly related to the number of CPUs on the hardware platform and the number of syslog servers you configure. At any point in time, there can be as many UDP syslog connections as there are CPUs times the number of configured syslog servers. This is the expected behavior. Note that the global UDP connection idle timeout applies to these sessions, and the default is 2 minutes. You can adjust that setting if you want to close these session more quickly, but the timeout applies to all UDP connections, not just syslog.

  • When you use a custom message list to match only access list hits, the access list logs are not generated for access lists that have had their logging severity level increased to debugging (level 7). The default logging severity level is set to 6 for the logging list command. This default behavior is by design. When you explicitly change the logging severity level of the access list configuration to debugging, you must also change the logging configuration itself.

    The following is sample output from the show running-config logging command that does not include access list hits, because their logging severity level has been changed to debugging:

    
    ciscoasa# show running-config logging
    logging enable
    logging timestamp
    logging list test message 106100
    logging buffered test
    
    

    The following is sample output from the show running-config logging command that does include access list hits:

    
    ciscoasa# show running-config logging
    logging enable
    logging timestamp
    logging buffered debugging
    
    

    In this case, the access list configuration does not change and the number of access list hits appears, as shown in the following example:

    
    ciscoasa(config)# access-list global line 1 extended 
    permit icmp any host 4.2.2.2 log debugging interval 1 (hitcnt=7) 0xf36b5386
    ciscoasa(config)# access-list global line 2 extended 
    permit tcp host 10.1.1.2 any eq www log informational interval 1 (hitcnt=18) 0xe7e7c3b8
    ciscoasa(config)# access-list global line 3 extended 
    permit ip any any (hitcnt=543) 0x25f9e609
    
    
  • When the ASA sends syslogs via TCP, the connection takes about one minute to initiate after the syslogd service restarts.

  • The server certificate received from a Syslog Server must contain "ServAuth" in the Extended Key Usage field. This check will be done on non self-signed certificates only, self-signed certificates do not provide any value in this field.

Configure Logging

This section describes how to configure logging.

Enable Logging

To enable logging, perform the following steps:

Procedure


Enable logging.

logging enable

Example:


ciscoasa(config)# logging enable


Configure an Output Destination

To optimize syslog message usage for troubleshooting and performance monitoring, we recommend that you specify one or more locations where syslog messages should be sent, including an internal log buffer, one or more external syslog servers, ASDM, an SNMP management station, the console port, specified e-mail addresses, or Telnet and SSH sessions.

When you configure syslog logging on an interface with management-only access enabled, the dataplane related logs (syslog IDs 302015, 302014, 106023, and 304001) are dropped and does not reach the syslog server. The syslog messages are dropped because the datapath routing table does not have the management interface routing. Hence, ensure the interface that you are configuring has management-only access disabled

Send Syslog Messages to an External Syslog Server

You can archive messages according to the available disk space on the external syslog server, and manipulate logging data after it is saved. For example, you could specify actions to be executed when certain types of syslog messages are logged, extract data from the log and save the records to another file for reporting, or track statistics using a site-specific script.

To send syslog messages to an external syslog server, perform the following steps:

Procedure

Step 1

Configure the ASA to send messages to syslog servers.

You can configure the ASA to send messages to IPv4 or IPv6 syslog servers.

logging host interface_name syslog_ip [tcp[/port] | udp [/port] [format emblem]]

Example:

ciscoasa(config)# logging host dmz1 192.168.1.5 udp/1026
ciscoasa(config)# logging host dmz1 2002::1:1 udp/2020

The format emblem keyword enables EMBLEM format logging for the syslog server with UDP only. The interface_name argument specifies the interface through which you access the syslog server. The syslog_ip argument specifies the IP address of the syslog server. The tcp[/port] or udp[/port] keyword-argument pair specify that the ASA should use TCP or UDP to send syslog messages to the syslog server.

You can configure the ASA to send data to a syslog server using either UDP or TCP, but not both. The default protocol is UDP if you do not specify a protocol.

Warning

 

If you specify TCP, when the ASA discovers syslog server failures, for security reasons, new connections through the ASA are blocked. To allow new connections regardless of connectivity to a TCP syslog server, see Step 3.

If you specify UDP, the ASA continues to allow new connections whether or not the syslog server is operational. Valid port values for either protocol are 1025 through 65535. The default UDP port is 514. The default TCP port is 1470.

Step 2

Specify which syslog messages should be sent to the syslog server.

logging trap {severity_level | message_list}

Example:

ciscoasa(config)# logging trap errors

You can specify the severity level number (1 through 7) or name. For example, if you set the severity level to 3, then the ASA sends syslog messages for severity levels 3, 2, and 1. You can specify a custom message list that identifies the syslog messages to send to the syslog server.

Step 3

(Optional) Disable the feature to block new connections when a TCP-connected syslog server is down.

logging permit-hostdown

Example:

ciscoasa(config)# logging permit-hostdown

When the ASA is configured to send syslog messages to a TCP-based syslog server, and if either the syslog server is down or the log queue is full, then new connections to ASA are blocked. New connections are allowed again after the syslog server is back up and the log queue is no longer full. Using this command, you can permit new connections even if the syslog server is not operational.

Step 4

(Optional) Set the logging facility to a value other than 20, which is what most UNIX systems expect.

logging facility number

Example:

ciscoasa(config)# logging facility 21


Enable Secure Logging
Procedure

Enable secure logging by specifying the secure keyword in the logging host command. Also, optionally enter the reference-identity .

logging host interface_name syslog_ip [tcp/port | udp/port] [format emblem] [secure [reference-identity reference_identity_name] ]

Where:

  • logging host interface_name syslog_ip specifies the interface on which the syslog server resides and the IP address of the syslog server.

  • [tcp/port | udp/port] specifies the port (TCP or UDP) that the syslog server listens to for syslog messages. The tcp keyword specifies that the ASA should use TCP to send syslog messages to the syslog server. The udp keyword specifies that the ASA should use UDP to send syslog messages to the syslog server.

  • format emblem keyword enables EMBLEM format logging for the syslog server.

  • secure keyword specifies that the connection to the remote logging host should use SSL/TLS for TCP only. Secure logging does not support UDP; an error occurs if you try to use this protocol.

  • [reference-identity reference_identity_name] enables RFC 6125 reference identity checks on the certificate based on the previously configured reference identity object. See Configure Reference Identities for details on the reference identity object.

Example:
ciscoasa(config)# logging host inside 10.0.0.1 TCP/1500 secure  reference-identity syslogServer

Generate Syslog Messages in EMBLEM Format to a Syslog Server

To generate syslog messages in EMBLEM format to a syslog server, perform the following steps:

Procedure

Send syslog messages in EMBLEM format to a syslog server over UDP using port 514.

logging host interface_name ip_address{tcp [/port] | udp [/ port]] [format emblem]

Example:

ciscoasa(config)# logging host interface_1 127.0.0.1 udp format emblem
ciscoasa(config)# logging host interface_1 2001::1 udp format emblem

You can configure IPv4 or IPv6 syslog servers.

The format emblem keyword enables EMBLEM format logging for the syslog server (UDP only). The interface_name argument specifies the interface through which you access the syslog server. The ip_address argument specifies the IP address of the syslog server. The tcp[/port] or udp[/port] keyword and argument pair specify that the ASA should use TCP or UDP to send syslog messages to the syslog server.

You can configure the ASA to send data to a syslog server using either UDP or TCP. The default protocol is UDP if you do not specify a protocol.

You can use multiple logging host commands to specify additional servers that would all receive syslog messages. If you configure two or more logging servers, make sure that you limit the logging severity level to warnings for all logging servers.

Warning

 

If you specify TCP, when the ASA discovers syslog server failures, for security reasons, new connections through the ASA are blocked. To permit new connections despite syslog server failures, see Step 3 of Send Syslog Messages to an External Syslog Server.

If you specify UDP, the ASA continues to allow new connections whether or not the syslog server is operational. Valid port values for either protocol are 1025 through 65535. The default UDP port is 514. The default TCP port is 1470.

Note

 

Sending syslogs over TCP is not supported on a standby ASA.


Generate Syslog Messages in EMBLEM Format to Other Output Destinations

To generate syslog messages in EMBLEM format to other output destinations, perform the following steps:

Procedure

Send syslog messages in EMBLEM format to output destinations other than a syslog server, such as Telnet or SSH sessions.

logging emblem

Example:

ciscoasa(config)# logging emblem


Send Syslog Messages to the Internal Log Buffer

You need to specify which syslog messages should be sent to the internal log buffer, which serves as a temporary storage location. New messages are appended to the end of the list. When the buffer is full, that is, when the buffer wraps, old messages are overwritten as new messages are generated, unless you configure the ASA to save the full buffer to another location.

To send syslog messages to the internal log buffer, perform the following steps:

Procedure

Step 1

Specify which syslog messages should be sent to the internal log buffer, which serves as a temporary storage location.

logging buffered {severity_level | message_list}

Example:

ciscoasa(config)# logging buffered critical
ciscoasa(config)# logging buffered level 2
ciscoasa(config)# logging buffered notif-list

New messages are appended to the end of the list. When the buffer is full, that is, when the buffer wraps, old messages are overwritten as new messages are generated, unless you configure the ASA to save the full buffer to another location. To empty the internal log buffer, enter the clear logging buffer command.

Step 2

Change the size of the internal log buffer. The default buffer size is 4 KB.

logging buffer-size bytes

Example:

ciscoasa(config)# logging buffer-size 16384

Step 3

Choose one of the following options:

  • Save new messages to the internal log buffer and save the full log buffer content to the internal flash memory.

    logging flash-bufferwrap

    Example:

    
    ciscoasa(config)# logging flash-bufferwrap
    
    
  • Save new messages to the internal log buffer and save the full log buffer content to an FTP server.

    logging ftp-bufferwrap

    Example:

    
    ciscoasa(config)# logging flash-bufferwrap
    
    

    When saving the buffer content to another location, the ASA create log files with names that use the following time-stamp format:

    
    LOG-YYYY-MM-DD-HHMMSS.TXT
    
    

    where YYYY is the year, MM is the month, DD is the day of the month, and HHMMSS is the time in hours, minutes, and seconds.

  • Identify the FTP server on which you want to store log buffer content.

    logging ftp-server server pathusername password

    Example:

    
    ciscoasa(config)# logging ftp-server 10.1.1.1 /syslogs logsupervisor 1luvMy10gs
    
    

    The server argument specifies the IP address of the external FTP server. The path argument specifies the directory path on the FTP server where the log buffer data is to be saved. This path is relative to the FTP root directory. The username argument specifies a username that is valid for logging into the FTP server. The password argument indicates the password for the username specified.

  • Save the current log buffer content to the internal flash memory.

    logging savelog [savefile]

    Example:

    
    ciscoasa(config)# logging savelog latest-logfile.txt
    
    

Change the Amount of Internal Flash Memory Available for Logs

To change the amount of internal flash memory available for logs, perform the following steps:

Procedure

Step 1

Specify the maximum amount of internal flash memory available for saving log files.

logging flash-maximum-allocation kbytes

Example:

ciscoasa(config)# logging flash-maximum-allocation 1200

By default, the ASA can use up to 1 MB of internal flash memory for log data. The minimum amount of internal flash memory that must be free for the ASA to save log data is 3 MB.

If a log file being saved to internal flash memory would cause the amount of free internal flash memory to fall below the configured minimum limit, the ASA deletes the oldest log files to ensure that the minimum amount of memory remains free after saving the new log file. If there are no files to delete or if, after all old files have been deleted, free memory is still below the limit, the ASA fails to save the new log file.

Step 2

Specify the minimum amount of internal flash memory that must be free for the ASA to save a log file.

logging flash-minimum-free kbytes

Example:

ciscoasa(config)# logging flash-minimum-free 4000


Send Syslog Messages to an E-mail Address

To send syslog messages to an e-mail address, perform the following steps:

Procedure

Step 1

Specify which syslog messages should be sent to an e-mail address.

logging mail {severity_level | message_list}

Example:

ciscoasa(config)# logging mail high-priority

When sent by e-mail, a syslog message appears in the subject line of the e-mail message. For this reason, we recommend configuring this option to notify administrators of syslog messages with high severity levels, such as critical, alert, and emergency.

Step 2

Specify the source e-mail address to be used when sending syslog messages to an e-mail address.

logging from-address email_address

Example:

ciscoasa(config)# logging from-address xxx-001@example.com

Step 3

Specify the recipient e-mail address to be used when sending syslog messages to an e-mail address.

logging recipient-address e-mail_address[severity_level]

Example:

ciscoasa(config)# logging recipient-address admin@example.com

Step 4

Specify the SMTP server to be used when sending syslog messages to an e-mail address. You may provide a primary and secondary server address to ensure unfailing log messaging service. Optionally, you can also associate an interface along with the server to identify the routing table to be used for logging. If no interface is provided, ASA would refer to the management routing table , and in absence of a route entry it would look at the data routing table.

smtp-server [primary-interface] primary-smpt-server-ip-address [[backup-interface ]backup-smpt-server-ip-address]

Example:

ciscoasa(config)# smtp-server 10.1.1.24 10.1.1.34
ciscoasa(config)# smtp-server 10.1.1.24
ciscoasa(config)# smtp-server management 10.1.1.24 outside 10.1.1.34
ciscoasa(config)# smtp-server management 10.1.1.24


Send Syslog Messages to ASDM

To send syslog messages to ASDM, perform the following steps:

Procedure

Step 1

Specify which syslog messages should be sent to ASDM.

logging asdm {severity_level | message_list}

Example:

ciscoasa(config)# logging asdm 2

The ASA sets aside a buffer area for syslog messages waiting to be sent to ASDM and saves messages in the buffer as they occur. The ASDM log buffer is a different buffer than the internal log buffer. When the ASDM log buffer is full, the ASA deletes the oldest syslog message to make room in the buffer for new ones. Deletion of the oldest syslog message to make room for new ones is the default setting in ASDM. To control the number of syslog messages retained in the ASDM log buffer, you can change the size of the buffer.

Step 2

Specify the number of syslog messages to be retained in the ASDM log buffer.

logging asdm-buffer-size num_of_msgs

Example:

ciscoasa(config)# logging asdm-buffer-size 200

Enter the clear logging asdm command to empty the current content of the ASDM log buffer.


Configure the Logging Queue

To configure the logging queue, perform the following steps:

Procedure

Specify the number of syslog messages that the ASA can hold in its queue before sending them to the configured output destination.

logging queue message_count

Example:

ciscoasa(config)# logging queue 300

The ASA have a fixed number of blocks in memory that can be allocated for buffering syslog messages while they are waiting to be sent to the configured output destination. The number of blocks required depends on the length of the syslog message queue and the number of syslog servers specified. The default queue size is 512 syslog messages. The queue size is limited only by block memory availability. Valid values are from 0 to 8192 messages, depending on the platform. If the logging queue is set to zero, the queue is the maximum configurable size (8192 messages).


Send Syslog Messages to the Console Port

To send syslog messages to the console port, perform the following steps:

Procedure

Specify which syslog messages should be sent to the console port.

logging console { severity_level | message_list}

Example:

ciscoasa(config)# logging console errors


Send Syslog Messages to an SNMP Server

To enable logging to an SNMP server, perform the following steps.

Procedure

Enable SNMP logging, and specify which messages are to be sent to SNMP servers.

logging history [ logging_list | level ]

Example:

ciscoasa(config)# logging history errors


Send Syslog Messages to a Telnet or SSH Session

To send syslog messages to a Telnet or SSH session, perform the following steps:

Procedure

Step 1

Specify which syslog messages should be sent to a Telnet or SSH session.

logging monitor {severity_level | message_list}

Example:

ciscoasa(config)# logging monitor 6

Step 2

Enable logging to the current session only.

terminal monitor

Example:

ciscoasa(config)# terminal monitor

If you log out and then log in again, you need to reenter this command. Enter the terminal no monitor command to disable logging to the current session.


Configure Syslog Messages

Show or Hide Invalid Usernames in Syslogs

You can show or hide invalid usernames in syslog messages for unsuccessful login attempts. The default setting is to hide usernames when the username is invalid or if the validity is unknown. If a user accidentally types a password instead of a username, for example, then it is more secure to hide the “username” in the resultant syslog message. You might want to show invalid usernames to help with troubleshooting login issues.

Procedure


Step 1

Show invalid usernames:

no logging hide username

Step 2

Hide invalid usernames:

logging hide username


Include the Date and Time in Syslog Messages

To include the date and time in syslog messages, perform the following steps:

Procedure


Specify that syslog messages should include the date and time that they were generated.

logging timestamp

Example:


ciscoasa(config)# logging timestamp
LOG-2008-10-24-081856.TXT

To remove the date and time from syslog messages, enter the no logging timestamp command.


Disable a Syslog Message

To disable a specified syslog message, perform the following steps:

Procedure


Prevent the ASA from generating a particular syslog message.

no logging message syslog_id

Example:


ciscoasa(config)# no logging message 113019

To reenable a disabled syslog message, enter the logging message syslog_id command (for example, logging message 113019 ). To reenable logging of all disabled syslog messages, enter the clear configure logging disabled command.


Change the Severity Level of a Syslog Message

To change the severity level of a syslog message, perform the following steps:

Procedure


Specify the severity level of a syslog message.

logging message syslog_id level severity_level

Example:


ciscoasa(config)# logging message 113019 level 5

To reset the severity level of a syslog message to its setting, enter the no logging message syslog_id level severity_level command (for example, no logging message 113019 level 5 ). To reset the severity level of all modified syslog messages to their settings, enter the clear configure logging level command.


Block Syslog Messages on a Standby Unit

Procedure


Use the following command to block a specific syslog message from being generated on a standby unit.

no logging message syslog-id standby

Example:


ciscoasa(config)# no logging message 403503 standby

Unblock a specific syslog message to ensure that the syslog messages of the failover standby ASA stay synchronized if failover occurs. Use the logging standby command to unblock a specific syslog message that was previously blocked from being generated on a standby unit.

Note

 

During a steady state when both active and standby ASAs are logging, the traffic doubles on the shared logging destinations, such as syslog servers, SNMP servers, and FTP servers. However, at times of a failover, during the switchover phase, the standby ASA generates more events including switchover intrusion and connection events of the active unit.


Include the Device ID in Non-EMBLEM Format Syslog Messages

To include the device ID in non-EMBLEM format syslog messages, perform the following steps:

Procedure


Configure the ASA to include a device ID in non-EMBLEM-format syslog messages. You can specify only one type of device ID for syslog messages.

logging device-id {cluster-id | context-name | hostname | ipaddress interface_name [system] | string text}

Example:


ciscoasa(config)# logging device-id hostname
ciscoasa(config)# logging device-id context-name

The context-name keyword indicates that the name of the current context should be used as the device ID (applies to multiple context mode only). If you enable the logging device ID for the admin context in multiple context mode, messages that originate in the system execution space use a device ID of system , and messages that originate in the admin context use the name of the admin context as the device ID.

Note

 

In an ASA cluster, always use the control unit IP address for the selected interface.

The cluster-id keyword specifies the unique name in the boot configuration of an individual ASA unit in the cluster as the device ID. The hostname keyword specifies that the hostname of the ASA should be used as the device ID. The ipaddress interface_name keyword-argument pair specifies that the interface IP address specified as interface_name should be used as the device ID. If you use the ipaddress keyword, the device ID becomes the specified ASA interface IP address, regardless of the interface from which the syslog message is sent. In the cluster environment, the system keyword dictates that the device ID becomes the system IP address on the interface. This keyword provides a single, consistent device ID for all syslog messages that are sent from the device. The string text keyword-argument pair specifies that the text string should be used as the device ID. The string can include as many as 16 characters.

You cannot use blank spaces or any of the following characters:

  • & (ampersand)

  • ‘ (single quote)

  • “ (double quote)

  • < (less than)

  • > (greater than)

  • ? (question mark)

Note

 

If enabled, the device ID does not appear in EMBLEM-formatted syslog messages nor in SNMP traps.


Create a Custom Event List

You use the following three criteria to define an event list:

  • Event Class

  • Severity

  • Message ID

To create a custom event list to send to a specific logging destination (for example, an SNMP server), perform the following steps:

Procedure


Step 1

Specify criteria for selecting messages to be saved in the internal log buffer. For example, if you set the severity level to 3, then the ASA sends syslog messages for severity levels 3, 2, and 1.

logging list name {level level [class message_class] | message start_id[-end_id]}

Example:


ciscoasa(config)# logging list list-notif level 3

The name argument specifies the name of the list. The level level keyword and argument pair specify the severity level. The class message_class keyword-argument pair specify a particular message class. The message start_id [-end_id] keyword-argument pair specify an individual syslog message number or a range of numbers.

Note

 

Do not use the names of severity levels as the name of a syslog message list. Prohibited names include emergencies, alert, critical, error, warning, notification, informational, and debugging. Similarly, do not use the first three characters of these words at the beginning of an event list name. For example, do not use an event list name that starts with the characters “err.”

Step 2

(Optional) Add more criteria for message selection to the list.

logging list name {level level [class message_class] | message start_id[-end_id]}

Example:


ciscoasa(config)# logging list list-notif message 104024-105999
ciscoasa(config)# logging list list-notif level critical
ciscoasa(config)# logging list list-notif level warning class ha

Enter the same command as in the previous step, specifying the name of the existing message list and the additional criterion. Enter a new command for each criterion that you want to add to the list. For example, you can specify criteria for syslog messages to be included in the list as the following:

  • Syslog message IDs that fall into the range of 104024 to 105999.

  • All syslog messages with the critical severity level or higher (emergency, alert, or critical).

  • All ha class syslog messages with the warning severity level or higher (emergency, alert, critical, error, or warning).

Note

 

A syslog message is logged if it satisfies any of these conditions. If a syslog message satisfies more than one of the conditions, the message is logged only once.


Configure Logging Filters

Send All Syslog Messages in a Class to a Specified Output Destination

To send all syslog messages in a class to a specified output destination, perform the following steps:

Procedure


Override the configuration in the specified output destination command. For example, if you specify that messages at severity level 7 should go to the internal log buffer and that ha class messages at severity level 3 should go to the internal log buffer, then the latter configuration takes precedence.

logging class message_class {buffered | console | history | mail | monitor | trap} [severity_level]

Example:


ciscoasa(config)# logging class ha buffered alerts

The buffered , history , mail , monitor , and trap keywords specify the output destination to which syslog messages in this class should be sent. The history keyword enables SNMP logging. The monitor keyword enables Telnet and SSH logging. The trap keyword enables syslog server logging. Select one destination per command line entry. To specify that a class should go to more than one destination, enter a new command for each output destination.


Limit the Rate of Syslog Message Generation

To limit the rate of syslog message generation, perform the following steps:

Procedure


Apply a specified severity level (1 through 7) to a set of messages or to an individual message (not the destination) within a specified time period.

logging rate-limit {unlimited | {num [interval]}} message syslog_id | level severity_level

Example:


ciscoasa(config)# logging rate-limit 1000 600 level 6

Rate limits affect the volume of messages being sent to all configured destinations. To reset the logging rate limit to the default value, enter the clear running-config logging rate-limit command. To reset the logging rate limit, enter the clear configure logging rate-limit command.


Monitoring the Logs

See the following commands for monitoring logging status.

  • show logging

    This command shows syslog messages, including the severity level.


    Note


    The maximum number of syslog messages that are available to view is 1000, which is the default setting. The maximum number of syslog messages that are available to view is 2000.


  • show logging message

    This command shows a list of syslog messages with modified severity levels and disabled syslog messages.

  • show logging message message_ID

    This command shows the severity level of a specific syslog message.

  • show logging queue

    This command shows the logging queue and queue statistics.

  • show running-config logging rate-limit

    This command shows the current logging rate-limit setting.

  • Configuration > Firewall > Access Rules

    This pane allows you to filter the live viewer of logging to that specific logs based on the search criteria (Rule Hex Id). To view the results, select the rule and click Show Log.

Examples for Logging

The following examples show the logging information, that displays for the show logging command:


ciscoasa(config)# show logging
Syslog logging: enabled
    Facility: 16
    Timestamp logging: disabled
    Standby logging: disabled
    Deny Conn when Queue Full: disabled
    Console logging: disabled
    Monitor logging: disabled
    Buffer logging: disabled
    Trap logging: level errors, facility 16, 3607 messages logged
        Logging to infrastructure 10.1.2.3
    History logging: disabled
    Device ID: 'inside' interface IP address “10.1.1.1”
    Mail logging: disabled
    ASDM logging: disabled


ciscoasa (config)# show logging
Syslog logging: enabled
    Facility: 20
    Timestamp logging: disabled
    Hide Username logging: enabled
    Standby logging: disabled
    Debug-trace logging: enabled
    Console logging: disabled
    Monitor logging: disabled
    Buffer logging: level debugging, 330272 messages logged
    Trap logging: level debugging, facility 20, 325464 messages logged
        Logging to inside 2001:164:5:1::123
    Permit-hostdown logging: disabled
    History logging: disabled
    Device ID: disabled
    Mail logging: disabled
    ASDM logging: disabled

The following examples show how to control both whether a syslog message is enabled and the severity level of the specified syslog message:


ciscoasa(config)# show logging message 403503
syslog 403503: -level errors (enabled)

ciscoasa(config)# logging message 403503 level 1
ciscoasa(config)# show logging message 403503
syslog 403503: -level errors, current-level alerts (enabled)

ciscoasa(config)# no logging message 403503
ciscoasa(config)# show logging message 403503
syslog 403503: -level errors, current-level alerts (disabled)

ciscoasa(config)# logging message 403503
ciscoasa(config)# show logging message 403503
syslog 403503: -level errors, current-level alerts (enabled)

ciscoasa(config)# no logging message 403503 level 3
ciscoasa(config)# show logging message 403503
syslog 403503: -level errors (enabled)

History for Logging

Table 3. History for Logging

Feature Name

Platform Releases

Description

Logging

7.0(1)

Provides ASA network logging information through various output destinations, and includes the option to view and save log files.

Rate limit

7.0(4)

Limits the rate at which syslog messages are generated.

We introduced the following command: logging rate-limit.

Logging list

7.2(1)

Creates a logging list to use in other commands to specify messages by various criteria (logging level, event class, and message IDs).

We introduced the following command: logging list.

Secure logging

8.0(2)

Specifies that the connection to the remote logging host should use SSL/TLS. This option is valid only if the protocol selected is TCP.

We modified the following command: logging host.

Logging class

8.0(4), 8.1(1)

Added support for the ipaa event class of logging messages.

We modified the following command: logging class.

Logging class and saved logging buffers

8.2(1)

Added support for the dap event class of logging messages.

We modified the following command: logging class.

Added support to clear the saved logging buffers (ASDM, internal, FTP, and flash).

We introduced the following command: clear logging queue bufferwrap.

Password encryption

8.3(1)

Added support for password encryption.

We modified the following command: logging ftp server.

Log viewers

8.3(1)

The source and destination IP addresses were added to the log viewers.

Enhanced logging and connection blocking

8.3(2)

When you configure a syslog server to use TCP, and the syslog server is unavailable, the ASA blocks new connections that generate syslog messages until the server becomes available again (for example, VPN, firewall, and cut-through-proxy connections). This feature has been enhanced to also block new connections when the logging queue on the ASA is full; connections resume when the logging queue is cleared.

This feature was added for compliance with Common Criteria EAL4+. Unless required, we recommended allowing connections when syslog messages cannot be sent or received. To allow connections, continue to use the logging permit-hostdown command.

We introduced the following syslog messages: 414005, 414006, 414007, and 414008.

We modified the following command: show logging.

Syslog message filtering and sorting

8.4(1)

Support has been added for the following:

  • Syslog message filtering based on multiple text strings that correspond to various columns

  • Creation of custom filters

  • Column sorting of messages. For detailed information, see the ASDM configuration guide.

This feature interoperates with all ASA versions.

Clustering

9.0(1)

Added support for syslog message generation in a clustering environment on the ASA 5580 and 5585-X.

We modified the following command: logging device-id.

Blocking syslogs on a standby unit

9.4(1)

We added support for blocking the generation of specific syslog messages on the standby unit in a failover configuration.

We introduced the following command: logging message syslog-id standby.

Reference Identities for Secure Syslog Server connections

9.6(2)

TLS client processing now supports rules for verification of a server identity defined in RFC 6125, Section 6. Identity verification will be done during PKI validation for TLS connections to the Syslog Server. If the presented identity cannot be matched against the configured reference identity, the connection is not established.

We added or modified the following commands: [no] crypto ca reference-identity , logging host .

IPv6 address support for syslog servers

9.7(1)

You can now configure syslog servers with IPv6 addresses to record, send, and receive syslogs over TCP and UDP.

We modified the following command: logging host

Logging class

9.12(1)

Added support for the BFD, BGP, interface, IPv6, Muticast, Object-Group-Search, PBR, routing, SLA class of logging messages.

We modified the following command: logging class.

Loopback interface support for syslog

9.18(2)

You can now add a loopback interface and use it for syslog.

New/Modified commands: interface loopback , logging host