Send ASA syslog events to the Cisco Cloud using the command line interface

After entering every command, you will click Send. Because Security Cloud Control's CLI Interface is a direct connection to the ASA, the command is written to the device's running configuration immediately. For changes to be written to the ASA's startup configuration, you need to issue the write memory command in addition.

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 

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 licenses for more information about data ingest and storage costs.

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. 

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.

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.

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.

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

Example:

> write memory 

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

• Add syslog messages to the event list based on severity. For example, if you set the severity level to 3, then the ASA sends syslog messages for severity levels 3, 2, and 1.

  Example:

  > logging list asa_syslogs_to_cloud level 3 

• Add syslog messages based on other criteria to the event list:

  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 302013-302018.

  • 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).

    Example:

    > logging list asa_syslogs_to_cloud message 302013-302018 
    > logging list asa_syslogs_to_cloud level critical 
    > logging list asa_syslogs_to_cloud level warning class ha 

    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.

At the command prompt, type write memory.

Example:

> write memory

Example:

> logging device-id hostname 
> logging device-id context-name 
> logging device-id string Cambridge 

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 primary 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)

At the command prompt, type write memory.

Example:

  > write memory