Syslog is a standard for message logging. It allows network devices, servers, and applications to send event notification messages across IP networks to a centralized event message collector. It is a cornerstone of Network Monitoring and security auditing.
Why Centralized Logging Matters
When a network issue occurs, checking the local logs on a router is helpful. But what if a massive power failure reboots 50 switches simultaneously? What if an attacker compromises a firewall and wipes its local memory to hide their tracks?
By streaming logs to a centralized Syslog Server (Collector) in real-time, administrators gain a permanent, searchable, network-wide view of events, protected from local device tampering or hardware failure.
Syslog Message Structure
A standard syslog message contains several key pieces of metadata:
- Timestamp: The exact time the event occurred.
- Hostname: The identity of the Syslog Sender (the device that generated the log).
- Facility: A category indicating which subsystem generated the message (e.g., the kernel, the mail system, or local use like
local7for network routing). - Severity: A numerical code indicating how critical the event is.
- Message: The actual text describing the event (e.g.,
"Interface GigabitEthernet1/0/1 changed state to down").
Syslog Severity Levels
Network devices rank events from 0 (Disaster) to 7 (Noise). Knowing these levels is critical for configuring proper alerting.
| Level | Keyword | Description |
|---|---|---|
| 0 | Emergency | System is unusable (e.g., catastrophic hardware failure). |
| 1 | Alert | Action must be taken immediately. |
| 2 | Critical | Critical conditions. |
| 3 | Error | Error conditions (e.g., interface failed). |
| 4 | Warning | Warning conditions. |
| 5 | Notice | Normal but significant condition (e.g., OSPF neighbor went down). |
| 6 | Informational | Routine messages (e.g., User logged in). |
| 7 | Debug | Massive volume of diagnostic data. Used temporarily by developers or engineers. |
Warning: Enabling Level 7 (Debug) logging globally on a busy production firewall can generate so much data that it crashes the firewall's CPU or immediately fills the collector's hard drive.
Transports and Ports
Syslog traditionally uses UDP Port 514. Because UDP is connectionless, if a packet is dropped by the network, the log is permanently lost. Some modern devices and collectors support Syslog over TCP Port 514 for reliability, or TCP Port 6514 (Syslog over TLS) to encrypt sensitive logs in transit.
Practical Architecture & Uses
In an enterprise, hundreds of network devices stream UDP 514 traffic to a centralized collector (like Splunk, ELK, or Graylog). Engineers use search queries and dashboards to investigate VPN failures, firewall deny logs, routing topology changes, and administrative authentication events.
Common Troubleshooting
- No Logs Arriving: A Firewall in transit is blocking UDP 514, or the sender is pointed at the wrong IP address.
- Logs are Present but Unsearchable (Parsing Issues): Different vendors format syslog messages differently. The collector might not know how to extract the username from a specific VPN firewall log format.
- Time Mismatch: If logs are appearing "in the future" or "in the past," the network devices and the collector are not synchronized using NTP (Network Time Protocol). Timestamps will be useless during an investigation.
Best Practices
- Synchronize Time: NTP is absolutely mandatory for syslog correlation.
- Filter at the Source: Configure devices to only send Severity 0 through 5 over the network. Do not send Informational or Debug logs unless specifically required for an investigation.
- Retention Policies: Establish rules to automatically delete logs older than 90/180/365 days to prevent disk exhaustion.