Syslog

Syslog is a standard and protocol that lets devices and applications send event messages (logs) to a single, central place — a collector. Each message describes one event and contains, among other things, a PRI value (encoding the source and severity of the event), a timestamp, a host identifier and the message body. Syslog originated in the 1980s as part of the Sendmail project (created by Eric Allman). It served for years as a de facto standard and was later written down in IETF documents: RFC 3164 (2001, the so-called BSD syslog) and RFC 5424 (2009, a newer, more orderly format).

How is a syslog message structured?

A syslog message has three parts: the PRI header, a descriptive part (HEADER) and the body (MSG). The most important is the PRI — a number in angle brackets at the start, e.g. <34>. It encodes two things at once: facility (where the message came from) and severity (how urgent it is). It is computed with a simple formula:

• PRI = facility × 8 + severity — e.g. <34> is facility 4 (security/authorization) and severity 2 (Critical).

Facility tells you which subsystem produced the message. It takes values 0–23 — e.g. kern = 0, user = 1, mail = 2, daemon = 3, auth/security = 4, plus local0–local7 = 16–23 for custom use. Severity rates the event on a 0–7 scale. The lower the number, the more urgent the event:

1. 0 — Emergency: system is unusable
2. 1 — Alert: action needed immediately
3. 2 — Critical: critical condition
4. 3 — Error: error condition
5. 4 — Warning: warning condition
6. 5 — Notice: something significant but normal
7. 6 — Informational: a routine message
8. 7 — Debug: diagnostic detail

How does RFC 3164 differ from RFC 5424?

Both documents describe the same syslog world, but differ in message format and precision:

• RFC 3164 (BSD syslog) — an informational, non-normative document. It wrote down what already existed. Timestamp in Mmm dd hh:mm:ss format (without year or time zone), a simple hostname, an application tag with PID, and a free-form body. The missing time zone and low time precision make it harder to line up logs from different sources.
• RFC 5424 — the proper, normative standard. It introduces a timestamp compliant with ISO 8601 / RFC 3339 (with milliseconds and time zone), a fully qualified hostname (FQDN), the fields APP-NAME, PROCID, MSGID and a structured data section (key–value pairs in square brackets). This makes messages easier to process by machine. The standard also requires UTF-8 encoding.

In practice, many network devices still send a format close to RFC 3164, while newer systems and collectors prefer RFC 5424. The fact that the message body has no single format is one of the main problems when normalizing logs.

How is syslog transmitted over the network? (ports and transport)

Syslog works in a client–server model: a sender (device, daemon) transmits messages to a collector (syslog server). There are several ways to do it:

• UDP, port 514 — the oldest and still default transport. Lightweight and fast, but connectionless and unreliable. There are no delivery acknowledgments, so under load or packet loss messages can vanish silently.
• TCP, port 514 — a connection-oriented transport, more reliable, with a way to slow the sender under load (back-pressure). How messages are split into frames is described in RFC 6587 (octet-counting or non-transparent framing).
• TLS, port 6514 — syslog encrypted per RFC 5425 (TLS, i.e. Transport Layer Security). It provides confidentiality, integrity and certificate-based confirmation of who the peers are. Recommended when logs travel across networks you do not trust, and where compliance rules apply.
• RELP / RFC 3195 — mechanisms that guarantee delivery: RELP (developed within rsyslog) acknowledges received messages over a back channel, while RFC 3195 describes BEEP-based delivery.

What are the common syslog implementations?

On the system side, syslog is handled by daemons that collect, filter and forward messages:

• rsyslog — the default daemon in many Linux distributions. It supports TCP, TLS, writing to databases, filtering, forwarding to collectors and the RELP protocol.
• syslog-ng — a flexible daemon with rich filtering, TCP/TLS transport and routing of messages to different destinations.
• syslogd / classic implementations as well as NXLog and other agents used to collect and forward logs, including from non-Unix systems.

How does syslog relate to SIEM and log management?

Syslog is one of the primary ways to deliver data to log management and SIEM (Security Information and Event Management) systems. Network devices, firewalls, servers and applications send messages to a central collector, which normalizes, indexes and correlates them. An orderly log stream (especially with RFC 5424) makes it easier to parse, to write detection rules and to catch anomalies. Centralizing logs also matters for audit and regulatory compliance (e.g. PCI DSS, HIPAA, SOX), which require event records to be retained and protected.

Why does syslog matter for security, and what are its limitations?

Syslog logs are evidence for SOC teams and for network monitoring and threat detection (NDR). The protocol itself, though, has a few limitations that matter for security:

• No authentication or encryption over UDP — in the UDP/plaintext variant you cannot check who really sent a message, nor protect its content. This opens the door to spoofing (forging the source) and to injecting crafted entries that pollute logs and mislead analysts.
• No delivery guarantee (UDP) — under load, messages can be lost, and with them the evidence. An attacker may deliberately flood the system with thousands of logs (log-flooding) to bury the traces of a real incident.
• Tampering with and deleting local logs — an attacker who reaches the host can change or delete logs before they are sent. This is why fast, continuous forwarding to a separate, hardened collector matters.
• No single message format — the loose MSG part complicates machine parsing and can hide data important for detection.

How to reduce this risk in practice: use TLS (RFC 5425, port 6514) or reliable mechanisms (TCP, RELP), separate and filter traffic on port 514, protect the collector against tampering, and watch the log stream itself. A gap in the expected flow of messages can also be a sign of an incident.

Learn more

• NSEL (NetFlow Secure Event Logging) — NSEL extends logging with secure event records, complementing syslog in network monitoring.
• ARP spoofing – how to detect a Man-in-the-Middle attack and ARP poisoning in a LAN network — Syslog can record events that help detect ARP spoofing and related network attacks.
• NOC (Network Operations Center) — NOCs use syslog to collect and review device events for operational monitoring.
• Data Retention — Syslog data retention defines how long log messages are stored and available.
• Data Loss Prevention (DLP) — Syslog can provide audit trails that support DLP investigations and alerts.
• NSM (Network Security Monitoring) — Syslog is a common log source used in NSM for detecting and investigating incidents.
• Network Forensics — Syslog provides event records that support timeline reconstruction in network forensics.
• Visibility — Syslog improves visibility by centralizing event data from systems and network devices.