Log management

Syslog Server Guide: Centralizing Logs from Network Devices

Logchase Security TeamOctober 23, 20268 min read

A syslog server is a system that receives log messages sent over the network by firewalls, routers, switches, servers and applications using the syslog protocol, then stores, filters or forwards them. It is usually the first step toward centralized log management: one place to search device logs instead of logging in to each device.

What is a syslog server?

A syslog server, also called a syslog collector or receiver, listens on the network for syslog messages and writes them to files or a database. Devices act as senders and the server as the receiver; relays can sit in between and forward messages onward.

Syslog is the default logging mechanism on most network equipment and Unix-like systems. Firewalls report allowed and blocked connections, VPN sessions and admin logins; switches and routers report interface changes, authentication and configuration events; Linux servers report authentication, service and kernel events. Without a central server, those logs stay on each device, often in a small local buffer that is overwritten quickly or lost on reboot.

A basic syslog server does four things:

Receive — listen on the configured ports for syslog over UDP, TCP or TLS.
Filter and route — sort messages by source, facility or severity into separate files or destinations.
Store — write messages to disk, with rotation and compression.
Forward — relay some or all messages to another system, such as a SIEM.

In larger networks, syslog servers are often used as relays: devices send to a nearby collector, which buffers messages and forwards them to the central platform over a more reliable or encrypted connection.

Common syslog server software on Linux includes rsyslog and syslog-ng, both of which can act as receivers and relays. NIST SP 800-92 describes syslog-based centralized logging as one type of log management infrastructure and discusses the security features original syslog lacked, such as reliable delivery and protection of messages in transit.

Which syslog formats should you know?

Two formats matter: the legacy BSD format described in RFC 3164 and the standard format defined in RFC 5424. Both start with a priority value that encodes facility and severity, but RFC 5424 adds a version number, a full timestamp with year and time zone, and structured data.

RFC 3164 documented syslog as it was already used on BSD systems. Its timestamp has no year or time zone, and a packet must be 1024 bytes or less. RFC 5424 obsoletes it and defines a clear header (priority, version, timestamp, hostname, app name, process ID and message ID), followed by optional structured data and the message itself.

# RFC 3164 (BSD format)
<134>Oct 23 08:42:31 fw-edge-01 fwlog[2211]: deny src=203.0.113.45 dport=445

# RFC 5424
<134>1 2026-10-23T08:42:31.512Z fw-edge-01 fwlog 2211 TRAFFIC [origin ip="192.0.2.1"] deny src=203.0.113.45 dport=445

The number in angle brackets is the priority (PRI), calculated as facility × 8 + severity. In the example, 134 is facility 16 (local0) and severity 6 (informational). Severity levels run from 0 to 7:

Syslog severity levels as defined in RFC 5424.

Code	Severity	Meaning
0	Emergency	System is unusable
1	Alert	Action must be taken immediately
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

Many devices still send RFC 3164-style messages by default, and vendors often put their own key-value or CSV payload inside the message part. Where you can choose, prefer RFC 5424, and make sure devices include the year and time zone (ideally UTC) so events from different devices line up.

Should you send syslog over UDP, TCP or TLS?

Use TLS for anything that crosses untrusted networks or carries sensitive data, TCP when you need more reliable delivery inside a trusted network, and UDP only where a device supports nothing else or occasional loss is acceptable. RFC 5424 makes TLS the mandatory-to-implement transport, while UDP remains the most widely supported.

Syslog transports at a glance.

Transport	Port	Delivery	Security
UDP	514/udp	No acknowledgement; messages can be lost or truncated silently	None; the source address can be spoofed
TCP	No standard port; 514/tcp is common	Connection-based, but messages in flight can be lost if the connection drops	None without TLS
TLS	6514/tcp	Connection-based, with octet-counted framing	Encryption and certificate-based authentication

A few details catch people out. Over UDP, each datagram carries exactly one message, and RFC 5426 only requires IPv4 receivers to accept 480 octets (it recommends 2048), so long messages may be truncated. Plain TCP syslog was never fully standardized: RFC 6587 is a Historic document that describes the two framing methods in use, octet counting and newline-terminated framing, and both ends must use the same one. TLS syslog (RFC 5425) uses port 6514 and is designed around certificate-based authentication of both sender and receiver.

If a device supports only UDP, place a collector close to it, ideally on the same network segment, and forward from there over TCP or TLS. For more reliable delivery, give senders a disk-backed queue so messages survive a server outage. On Linux with rsyslog, forwarding everything over TCP with a queue looks like this:

# /etc/rsyslog.d/90-forward.conf
*.* action(type="omfwd" target="logs.example.com" port="514" protocol="tcp"
           queue.type="LinkedList" queue.filename="fwd_queue"
           queue.saveOnShutdown="on" action.resumeRetryCount="-1")

How do you send logs from firewalls, switches and servers?

On each device, set the syslog server address, transport and port, choose the minimum severity and the facility, and make sure the device clock is synchronized. Then confirm on the server that messages arrive with the right hostname and timestamp.

What to collect from common syslog sources.

Source	What to send	Watch out for
Firewalls and VPN gateways	Allowed and denied traffic, VPN sessions, admin logins, configuration changes, threat events	Traffic logs are high volume; plan capacity before filtering anything out
Switches and routers	Authentication, configuration changes, interface and routing events	Set a fixed source interface so the sender's IP address doesn't change
Linux servers	auth and authpriv, sudo, SSH, service and kernel messages	Forward with rsyslog or syslog-ng, and include messages that services write only to the systemd journal
Windows servers	Security, System and Application event logs	Windows doesn't send syslog natively; use an agent or forwarder
Applications	Logins, admin actions, errors	Use a structured payload (key=value or JSON) inside the message

Checklist for every device

Synchronize clocks with NTP, and include the time zone or use UTC.
Use a meaningful hostname rather than a default name or a bare IP address.
Choose the severity threshold deliberately: many devices log logins, sessions and traffic at notice (5) or informational (6), so a warning (4) threshold can miss them.
Use distinct facilities, for example local0 to local7, to separate device types if your server routes by facility.
Accept syslog only from known source addresses, and firewall the listening ports.
Test with a known event, such as a failed admin login, and find it on the server.

How do you go from a syslog server to centralized log management?

A syslog server collects logs; centralized log management makes them useful. The next step adds parsing and normalization, indexed search, retention policies, integrity protection, access control and alerting, and brings in sources that don't speak syslog, such as cloud APIs and Windows event logs.

Plain syslog servers start to strain as soon as you need answers rather than files. Searching gigabytes of text with grep is slow, every vendor's message format is different, nothing alerts you when something important appears, and there is no proof that stored files weren't edited. Those are the gaps centralized log management fills.

From syslog to centralized log management

1
Devices
Firewalls, switches and servers send syslog over UDP, TCP or TLS.
2
Collector
Receives and buffers every message, recording when it arrived.
3
Parse and normalize
Vendor formats become common fields: host, user, src_ip, action.
4
Search and alert
Indexed search, dashboards and alert rules.
5
Retain and protect
Archives with hashing and trusted timestamps.

A syslog server covers the first two steps. Centralized log management adds structure, search, alerting and integrity on top.

When you evaluate centralized log management tools, check that they accept syslog alongside agents, APIs and file collection, keep the raw message next to the parsed fields, and can prove log integrity over the whole retention period. How long to keep logs is covered in our log retention guide; for correlation and threat detection on top, see What is SIEM?.

Logchase's collector accepts syslog over UDP and TCP, alongside REST API, file collection and agents. It normalizes events into consistent fields and protects archives with cryptographic hashing and timestamping.

Sources

Written by

Logchase Security Team

The engineers who build Logchase, working on log management, SIEM, threat detection and file integrity monitoring.

FAQ

Frequently asked questions

What port does syslog use?

UDP port 514 is the standard port for syslog over UDP, and TCP port 6514 is assigned to syslog over TLS. Plain TCP syslog has no standardized port; 514/tcp is the most common choice, although that port is officially assigned to the remote shell service.

Is RFC 5424 better than RFC 3164?

Yes, where devices support it. RFC 5424 is the current standard and includes the year, time zone, fractional seconds and structured data. RFC 3164 describes the older BSD format, which many devices still send by default.

Can syslog lose messages?

Yes. UDP has no acknowledgement, so messages can be dropped under load or during network problems without anyone noticing. TCP and TLS reduce loss, and disk-backed queues on the sender protect against server outages. For application-level acknowledgements, rsyslog also supports RELP, its Reliable Event Logging Protocol.

Do Windows servers support syslog?

Not natively. Windows writes to the Windows Event Log, so you need an agent or forwarder that converts events to syslog or sends them directly to a log management platform.

Is a syslog server enough for compliance?

Usually not on its own. Standards and regulations that require log retention generally also expect logs to be protected from modification, access-controlled and reviewed. A plain syslog server needs extra controls, or a log management platform, for integrity checks, retention policies and audit trails.

How much storage does a syslog server need?

It depends on your event rate, average message size and retention period. Measure a normal day's volume from each source, multiply by the number of days you must keep, and add headroom for growth and peaks; compression reduces the stored size.