Enable Logging to Syslog Without Flooding the Server

Proper logging is critical for network security monitoring, troubleshooting, and compliance. Cisco ASA and Firepower Threat Defense (FTD) devices generate…

Proper logging is critical for network security monitoring, troubleshooting, and compliance. Cisco ASA and Firepower Threat Defense (FTD) devices generate a significant volume of log data, which can quickly overwhelm syslog servers if not managed carefully. This article details how to configure logging to external syslog collectors on Cisco ASA and FTD, focusing on optimizing message flow to prevent server flooding while retaining essential visibility.

Understanding Syslog Levels and Facilities

Syslog uses two primary identifiers for each message: a severity level and a facility code. Understanding these is fundamental to effective filtering.

• Severity Levels (0-7, higher number = lower severity):
  • 0 - Emergency: System unusable
  • 1 - Alert: Immediate action needed
  • 2 - Critical: Critical conditions
  • 3 - Error: Error conditions
  • 4 - Warning: Warning conditions
  • 5 - Notice: Normal but significant condition
  • 6 - Informational: Informational messages
  • 7 - Debug: Debug-level messages
• Facility Codes: Identify the process or application generating the message. Common ASA/FTD facilities include AUTH (authentication), DAEMON (system daemon), LOCAL4 (custom, often used by ASA for firewall-specific messages), etc. The ASA typically uses LOCAL4 or LOCAL7 for most of its security-related events.

Cisco ASA Syslog Configuration

The ASA offers granular control over syslog messages. The goal is to send informational (level 6) messages to your primary syslog collector for steady-state operation, while potentially raising the level for specific troubleshooting periods or critical alerts.

Basic Syslog Server Configuration

First, define your syslog server(s). You can specify up to 4 servers per logging buffer/interface.

hostname(config)# logging enable
hostname(config)# logging timestamp
hostname(config)# logging host inside 192.168.1.100 udp/514
hostname(config)# logging host outside 203.0.113.5 udp/514
hostname(config)# logging trap informational
hostname(config)# logging facility 20  ! Equivalent to LOCAL4

• logging enable: Globally enables logging.
• logging timestamp: Adds a timestamp to all syslog messages, crucial for correlation.
• logging host <interface> <IP_address> [udp/port | tcp/port]: Specifies a syslog server. Replace <interface> with the interface from which the ASA will send the syslog packets (e.g., inside, outside, management). UDP 514 is standard; TCP 1470 is also common for reliable delivery.
• logging trap informational: Sets the global severity level for messages sent to all configured syslog hosts to "informational" (level 6). Messages with severity 6 or lower (more severe) will be sent.
• logging facility 20: Sets the syslog facility code. Cisco ASA typically uses facility 20 (LOCAL4). This is important for syslog servers to correctly parse and filter messages.

Fine-tuning Message Selection with Logging Lists

To prevent flooding, avoid sending debug (level 7) messages to production syslog servers for extended periods. Instead, use logging lists to selectively send specific message IDs or severities.

hostname(config)# logging list CRITICAL_EVENTS level critical
hostname(config)# logging list CRITICAL_EVENTS message 106001 ! Deny/permit rule hit
hostname(config)# logging list CRITICAL_EVENTS message 106100 ! Teardown XLATE
hostname(config)# logging list CRITICAL_EVENTS message 106021 ! TCP SYN timeout
hostname(config)# logging list ACCESS_VIOLATIONS level warnings
hostname(config)# logging list ACCESS_VIOLATIONS message 106023 ! Deny TCP (no connection)
hostname(config)# logging list ACCESS_VIOLATIONS message 106015 ! Deny UDP (no connection)

hostname(config)# logging host inside 192.168.1.100 list CRITICAL_EVENTS
hostname(config)# logging host outside 203.0.113.5 list ACCESS_VIOLATIONS
hostname(config)# logging host outside 172.16.1.10 list INFORMATIONAL_ALL ! For a full SIEM

In this example:

• CRITICAL_EVENTS sends only critical-level messages and specific message IDs to 192.168.1.100. This is useful for high-priority alerts to an incident response system.
• ACCESS_VIOLATIONS sends warnings and specific deny messages to 203.0.113.5, perhaps for a firewall specific log analyzer.
• A third host, 172.16.1.10, might receive a broader set of logs if configured with a less restrictive list or the default informational trap. You would define logging list INFORMATIONAL_ALL level informational if you needed to explicitly assign it.

Buffering and Rate Limiting

Even with filtering, a burst of events (e.g., a port scan) can generate many messages. Buffering and rate limiting help manage this.

hostname(config)# logging buffered debugging
hostname(config)# logging console warnings
hostname(config)# logging monitor errors
hostname(config)# logging history alerts
hostname(config)# logging rate-limit all 100 1 ! Limit all messages to 100 per second
hostname(config)# logging rate-limit 106021 5 1 ! Limit msg 106021 to 5 per second

• logging buffered debugging: Sets the internal buffer to store debug-level messages. This is excellent for short-term troubleshooting without overwhelming external syslog servers. The buffer size is configurable (e.g., logging buffered 409600 for 400KB). Default is 4KB for older ASAs, 1MB for newer.
• logging console warnings: Messages equal to or more severe than 'warnings' (level 4) appear on the console.
• logging monitor errors: Messages equal to or more severe than 'errors' (level 3) appear on VTY lines.
• logging history alerts: Messages equal to or more severe than 'alerts' (level 1) are stored in the logging history buffer.
• logging rate-limit all <count> <interval>: Limits the total number of syslog messages sent per second. A common value is 100 messages per second, averaged over 1 second. Without this, a high-volume attack can cause the ASA to consume CPU cycles solely generating logs, or saturate the syslog server.
• logging rate-limit <message_id> <count> <interval>: Provides granular rate limiting for specific message IDs. Message 106021 ("Deny TCP (no connection)") is notorious for high volume during port scans. Limiting it significantly reduces noise.

Cisco FTD Syslog Configuration (Firepower Management Center - FMC)

FTD logging is managed primarily through the Firepower Management Center (FMC). While the underlying mechanisms are similar, the configuration interface differs.

Configuring Syslog on FMC

1. Navigate to Devices > Platform Settings.
2. Create a new policy or edit an existing one for your FTD device(s).
3. Go to Syslog > Syslog Settings.
4. Click Add Syslog Server.
   • IP Address: Enter your syslog server IP.
   • Port: 514 (UDP) or 1470 (TCP).
   • Protocol: UDP or TCP.
   • Log Facility: Set to LOCAL4 (or another as per your SIEM).
   • Severity: Set the global severity. For a comprehensive SIEM, Informational (6) is appropriate. For critical alerts to a lighter system, choose Errors (3) or Alerts (1).
5. Under Event List, you can define specific event types to send. This is crucial for reducing noise.
   • Click Add to Event List.
   • Select categories like Connection Events, Intrusion Events, File Events, System Events, etc.
   • For each category, you can choose specific event types and their minimum severity. For example, for Connection Events, you might only want to send "Connection Denied" at Informational, while "Connection Allowed" might be sent at Debug (if needed for deep analysis) or not at all if your SIEM is overwhelmed.

Enabling Connection Logging (Access Control Policy)

FTD connection events are generated by the Access Control Policy (ACP).

1. Navigate to Policies > Access Control.
2. Edit your ACP.
3. For each Access Control Rule:
   • Go to the Logging tab.
   • Enable Log Connections at the beginning or end of a connection.
   • Select Send to Syslog.
   • Choose the Syslog Severity for these specific connection events. This overrides the global severity for these messages. For instance, you might log all "block" rules at "Informational" to your primary SIEM, but only "Alert" severity for critical infrastructure protection rules.
   • Specify a Syslog Facility.

Important FTD Note: FTD's logging is highly dependent on the Access Control Policy rules. If a rule doesn't have logging enabled, those connections won't generate syslog messages, regardless of Platform Settings.

Common Pitfalls and Troubleshooting

• Syslog Server Overload: The most common issue. Always start with conservative logging levels (e.g., informational or warnings) and specific rate limiting. Gradually increase verbosity if needed for troubleshooting, but revert afterward. Use logging rate-limit aggressively.
• Incorrect Interface for Syslog: Ensure the logging host <interface> command specifies an interface that has a route to the syslog server and is permitted by ACLs.
• ACLs Blocking Syslog: Verify that no ACL on the ASA/FTD (or upstream firewalls) is blocking UDP 514 or TCP 1470/6514 traffic from the firewall to the syslog server.

  
              hostname(config)# show logging | include hostname
              hostname(config)# show logging host
              hostname(config)# capture CAPTURE-SYSLOG interface management match udp host <ASA_IP> eq 514 host <SYSLOG_IP> eq 514
              hostname(config)# show capture CAPTURE-SYSLOG
              

  (Replace management with your logging interface).
• Time Synchronization (NTP): Ensure your ASA/FTD and syslog server have accurate time synchronization via NTP. Discrepant timestamps make log correlation impossible.
• FTD - No Connection Events: If FTD isn't sending connection events, check two things:
  1. Is logging enabled on the specific Access Control Policy rules?
  2. Are the platform settings configured to send connection events to the syslog server?
• High CPU due to Logging: If the firewall's CPU utilization spikes when logging is enabled, it's often due to excessive debug messages or lack of rate limiting. Check show cpu usage detail (ASA) or FMC's System Dashboard (FTD) and adjust logging levels and rate limits.
• Message ID Lookup: When seeing an unknown message ID, use Cisco's CLI help or documentation. On ASA, ? <message_id> in config mode can sometimes give context. Example: ? 106021