Syslog Servers Explained: Central Log Collection for Network+

A syslog server is the central collector that network devices, servers and appliances send their log messages to. This article is about the collector and the architecture around it; the severity levels themselves are covered separately.

Why centralise

Logs kept only on the device that produced them have four problems, and each is an exam answer.

They are lost when the device fails. A switch that dies takes its logs with it, exactly when you need them.

They can be altered by an attacker. Someone who compromises a host can edit its logs. Shipping entries off the box in real time means the attacker has to compromise the log server too.

They cannot be correlated. An incident spanning a firewall, a switch and three servers is invisible if you read each device separately.

They are limited by local storage. Network devices have small buffers that wrap, often within hours on a busy device.

Transport, and why it matters

Classic syslog uses UDP port 514. That is the number to know. UDP is connectionless, so it adds almost no overhead on the sending device — and it is unreliable by design. Messages can be dropped silently, and during the traffic storm of an incident is precisely when they are most likely to be dropped.

TCP port 514 adds delivery confirmation and retransmission. TLS on port 6514 adds encryption and authentication of the collector.

Encryption matters because syslog messages frequently contain usernames, internal hostnames, IP addresses and occasionally credentials in error messages. Plain syslog crossing an untrusted network is a disclosure risk, and the exam expects you to know TLS syslog exists.

Message structure

A syslog message carries a facility identifying the source subsystem — kernel, mail, auth, and eight local-use facilities — and a severity from 0 (Emergency) to 7 (Debug). Together they produce the priority value.

The rest is a timestamp, the hostname, the application or process, and the message text. Older RFC 3164 format is loose and hard to parse; RFC 5424 adds structured data and proper timestamps with time zones.

The filtering rule in practice: configure devices to send informational and above, not debug. Debug logging from a busy device will overwhelm both the network and the collector, and it is a genuine cause of outages.

Time synchronisation

The prerequisite people skip. Correlating events across devices requires their clocks to agree, so NTP is effectively mandatory before centralised logging is useful. Devices with drifting clocks produce a timeline that cannot be reconstructed, and an investigation built on it reaches wrong conclusions.

Prefer UTC on infrastructure. Mixed local time zones across sites make correlation needlessly painful.

Retention and storage

Decide retention before deployment, because log volume is larger than people expect. Typically: short-term hot storage for fast searching, longer-term cheaper archive for compliance. Regulations often set minimums — PCI DSS requires a year, with three months immediately available.

Protect the archive itself. Write-once storage or an append-only configuration prevents an attacker who reaches the log server from rewriting history, and hashing or signing log files supports their use as evidence.

Syslog server versus SIEM

A distinction worth being precise about.

Syslog server	SIEM
Receives and stores messages	Ingests from many source types, not just syslog
Basic filtering and forwarding	Parses, normalises and enriches
Search is largely text matching	Correlation rules across sources
No alerting logic to speak of	Alerting, dashboards, case management

A syslog server collects; a SIEM makes sense of what was collected. Many deployments use both, with syslog servers as regional collectors forwarding to a central SIEM — which reduces WAN traffic and keeps collection working if the SIEM is unavailable.

Troubleshooting

No messages arriving is usually one of four things: the device is not configured to send, a firewall is blocking UDP 514, the collector is not listening on that interface, or the device's source interface differs from the one in the ACL.

Messages arriving with wrong timestamps means NTP. A flood of messages usually means someone left debug logging enabled. Missing messages during incidents is UDP doing what UDP does — move to TCP.

What to remember

Syslog is UDP 514 by default, TCP 514 for reliability, TLS 6514 for encryption. Centralise to survive device failure, resist tampering, enable correlation and escape small local buffers. Facility identifies the source, severity runs 0 to 7. NTP is a prerequisite. A syslog server collects; a SIEM correlates.

Related reading: Syslog severity levels · SIEM · NetFlow and sFlow