Send ASA Syslog Events to the Cisco Cloud Using CLI

Procedure


Step 1

Configure the ASA to send messages to the SEC as if it were a syslog server

When sending syslog events from the ASA to the Cisco cloud, you forward them to the SEC as if it were an external syslog server, and it forwards the messages to the Cisco cloud.

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

  1. Configure the ASA to send messages, using TCP or UDP, to the SEC as if it were a syslog server. The SEC can use an IPv4 or IPv6 addresss. You will be sending events to either a TCP or UDP port. See Finding Your Device's TCP, UDP, and NSEL Port Used for Cisco Security Analytics and Logging to determine what ports you should use.

    Here is an example of the logging host command syntax:

    logging host interface_name SEC_IP_address [[ tcp/port ]|[ udp/port ]]

    Examples:

    
     > logging host mgmt 192.168.1.5 tcp/10125 
    > logging host mgmt 192.168.1.5 udp/10025 
    > logging host mgmt 2002::1:1 tcp/10125 
    > logging host mgmt 2002::1:1 udp/10025 
    • The interface_name argument specifies the ASA interface from which messages are sent to the syslog server. It is a "best practice" to send the syslog messages to the SDC over the same ASA interface already in use for communication with the SDC.

    • The SEC_IP_address argument should contain the IP address of the VM on which the SEC is installed.

    • The tcp/port or udp/port keyword-argument pair specifies that syslog messages should be sent using either TCP protocol and relevant port, or the UDP protocol and relevant port. 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.

      If you specify TCP, the ASA will discover syslog server failures and as a security protection, new connections through the ASA are blocked. To allow new connections regardless of connectivity to a TCP syslog server, see step b. If you specify UDP, the ASA continues to allow new connections whether or not the syslog server is operational. Valid port values

      Note

      If you want to send ASA messages to two separate syslog servers, you can run a second logging host command with the appropriate interface, IP address, protocol and port of the other syslog server.

  2. (Optional) If you send events to the SEC over TCP, and if either the SEC is down or the log queue on the ASA is full, then new connections are blocked. New connections are allowed again after the syslog server is back up and the log queue is no longer full. To allow new connections regardless of connectivity to a TCP syslog server, disable the feature to block new connections when a TCP-connected syslog server is down using this command:

    logging permit-hostdown

    Example:

     > logging permit-hostdown 

Step 2

Specify which syslog messages should be sent to the syslog server with the following command:

logging trap { severity_level | message_list }

Examples:

> logging trap 3 
> logging trap asa_syslogs_to_cloud 

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.

The message_list argument is replaced with the name of a custom event list, if you have created one. When specifying a custom event list, you only send the syslog messages that are in that list to the Secure Event Connector. In the example above, asa_syslogs_to_cloud is the name of the event list.

Using a message_list could save you money by tightly defining which syslog messages are sent to the Cisco cloud.

See Create a Custom Event List to create a message_list. See Security Analytics and Logging Event Storage for more information about data ingest and storage costs.

Step 3

(Optional) Add the syslog timestamp

Add the date and time that the syslog message originated on the ASA to the message using the logging timestamp command. The timestamp value is displayed in the SyslogTimestamp field.

Example:

> logging timestamp 
Note

Beginning with version 9.10(1), ASA provides the option to enable timestamp as per RFC 5424 in eventing syslogs. When this option is enabled, all timestamp of syslog messages would be displaying the time as per RFC 5424 format. Following is a sample output with RFC 5424 format:

<166>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. 

Step 4

(Optional) Include a device ID in non-EMBLEM format syslog messages

A device ID is an identifier you can insert in a syslog message that will help you easily distinguish all syslog messages sent from a particular ASA. See Include the Device ID in Non-EMBLEM Format Syslog Messages for instructions.

Step 5

(Optional) Enable logging on access control rule "permit" events

When an access control rule denies access to a resource, the event is automatically logged. If you also want to log events generated when an access control rule allows access to a resource, you need to turn on logging for the access control rule and configure a severity type. See Log Rule Activity for instructions on how to turn on logging for an individual network access control rule.

Note

Enabling logging on access control rule "permit" events will use-up more of your purchased data plan as it is based on your daily ingest rate of events.

Step 6

Enable logging

At the command prompt, type logging enable. On the ASA, logging is enabled for the entire device, not for individual rules.

Example:

 > logging enable 
Note

At this time, Security Cloud Control does not support enabling secure logging.

Step 7

Save your Changes to the Startup Config

At the command prompt, type write memory. On the ASA, logging is enabled for the entire device, not for individual rules.

Example:

> write memory