Set Up Syslog Export for Compliance Auditing on a Cisco ASA

Before you run this

This guide configures a Cisco ASA to send its event logs to a central syslog server (or SIEM) so you have off-box, timestamped audit evidence. It changes the firewall's logging configuration only — it does not touch access rules, NAT, or routing — but you are still editing a production security appliance, so treat it accordingly.

• Privileges: You need enable (privileged EXEC) mode and then global configuration mode on the ASA. This is the appliance's own administrative access, not a Linux or Windows account.
• Console/out-of-band access: Keep a separate console (or dedicated management) session open while you work. A logging misconfiguration is unlikely to lock you out, but if you use TCP syslog you can inadvertently affect traffic (see the "permit-hostdown" step) — so have the console cable ready.
• Back up first: Before changing anything, save a copy of the current config off-box or to flash (shown below). The ASA has no timed auto-rollback like PAN-OS; your rollback path is restoring that backup or negating the commands with no.
• Maintenance window: Make the change in a window. UDP syslog is low-risk; TCP syslog changes failure behaviour and deserves the window.
• Test first: If you have a lab ASA or an ASAv, apply this there first, or point at a throwaway syslog listener before the production collector. Read each command and know what it does before you paste it.

Nothing here deletes data. The no forms in the "Undo" section reverse everything cleanly.

What I'm assuming

• A physical or virtual Cisco ASA running ASA software 9.x (the logging syntax below has been stable across 9.x). ASDM exists and can do all of this under Configuration → Device Management → Logging, but the CLI is the reliable, scriptable path, so that's what I use here.
• The syslog collector is reachable through an existing interface named inside at 10.10.10.50. Replace the interface name and IP with yours.
• The ASA clock is accurate. Timestamps are only useful for audit if the clock is right, so configure NTP first if you haven't:

configure terminal
ntp server 10.10.10.10          ! replace with your NTP source

Step 1 — Back up the running config

Save the current config so you can restore it verbatim. To flash:

copy running-config disk0:/pre-syslog-backup.cfg

Or copy it off-box to a TFTP/SCP server you control (copy running-config tftp: and answer the prompts). Confirm the file exists with dir disk0:.

Step 2 — Enable logging and timestamps

configure terminal
logging enable                  ! master switch for the logging subsystem
logging timestamp               ! prefix each message with the device clock time

logging timestamp is important for audit: without it, messages carry only uptime-relative sequence info, which auditors hate. Because the timestamp comes from the ASA clock, this is why Step "What I'm assuming" insisted on NTP.

If you send logs from several firewalls to one collector, add a device identifier so you can tell them apart:

logging device-id hostname      ! tags messages with the ASA's hostname

logging device-id also accepts ipaddress <interface>, context-name, or a fixed string — check the Cisco ASA CLI configuration guide for which field your SIEM parses most cleanly.

Step 3 — Point at the syslog server

For standard UDP syslog on the default port 514:

logging host inside 10.10.10.50

Compliance regimes often want a reliable transport so you don't silently lose events. The ASA supports TCP syslog (default port 1470). If your collector listens for TCP syslog, use:

logging host inside 10.10.10.50 tcp/1470

Match the port to what your collector expects (many SIEMs take TCP syslog on 514 or 1514 — set the port after the slash accordingly). If you need encrypted transport (TLS), the ASA supports a secure option on the TCP host line tied to a configured SSL trustpoint; the exact keyword order and certificate prerequisites vary, so configure that from the "Configuring Logging" / secure logging section of the Cisco ASA Series CLI Configuration Guide rather than guessing it here.

Step 4 — Choose what gets sent

logging trap sets the severity threshold for messages sent to syslog servers. Levels run 0 (emergencies) through 7 (debugging). For audit trails, informational (6) is the usual choice — it captures connection builds/teardowns and admin events without the noise of debugging:

logging trap informational

Optionally set the syslog facility (the default is 20, i.e. local4). Only change it if your collector expects a specific facility:

logging facility 20

If you also want a local ring buffer on the ASA itself for quick show logging review:

logging buffered informational

For fine-grained control — sending only specific message IDs or an event class — the ASA has logging list (a named event list) and per-message logging message <id> tuning. That's the mainstream way to trim volume; see the CLI configuration guide for the list syntax before building one.

Step 5 — Decide TCP failure behaviour (TCP only)

This is the one step that can affect production traffic, so read it. When you use TCP syslog and the syslog server becomes unreachable, the ASA's default is fail-closed: it blocks new connections through the firewall to guarantee no event goes unlogged. That is deliberate for strict compliance, but it means a dead log collector can take down traffic.

If your policy prefers the firewall to keep passing traffic even when the log server is down (fail-open), enable:

logging permit-hostdown

Pick this consciously and document the choice — it is exactly the kind of decision an auditor will ask about. UDP syslog has no such blocking behaviour, so this command is irrelevant there.

Step 6 — Save

end
write memory

write memory (equivalently copy running-config startup-config) persists the change across reload.

Verifying it worked

On the ASA, confirm the configuration and watch the counters climb:

show logging

The output shows whether logging is enabled, the trap level, and each syslog host with a message count. Watch that the count for 10.10.10.50 increments over a minute of normal traffic.

Then confirm messages actually land on the collector. On a Linux syslog server you can tail the receiving file — for example:

sudo tail -f /var/log/remote/asa.log     # path depends on your rsyslog/syslog-ng config

The exact path depends entirely on your collector's ruleset — check where your rsyslog/syslog-ng or SIEM writes remote ASA messages. You should see timestamped lines carrying your device-id.

If you used TCP, verify the session is established from the ASA side and that a message like a login or a config change appears on the collector. Generate a test event by logging out and back in.

Undoing it

Everything here reverses with the no form. To stop sending to the collector but keep local logging:

configure terminal
no logging host inside 10.10.10.50

To back out completely:

no logging permit-hostdown
no logging trap informational
no logging device-id hostname
no logging timestamp
no logging enable
end
write memory

Or restore the pre-change config wholesale from your Step 1 backup:

copy disk0:/pre-syslog-backup.cfg running-config

That merges the saved config back in; review with show running-config logging afterwards to confirm the state matches what you intended, then write memory.

For the authoritative command reference — especially the secure/TLS logging and logging list syntax I deliberately left in prose — see the Cisco ASA Series CLI Configuration Guide, "Logging" chapter for your specific 9.x release on Cisco's documentation site.