# Centralized Syslog: Protocol, Architecture and Log Management

> How centralized syslog works: RFC 3164 vs 5424, UDP/TCP/TLS transport, facility and severity, collector architecture, cloud vs on-prem, retention and SIEM.

Centralized syslog means sending log messages from routers, switches, firewalls, access points, servers and applications to one collector over the standard syslog protocol, where they are stored, searched and used for alerts. The protocol is defined in RFC 3164 (BSD syslog) and RFC 5424. Messages travel over UDP 514, TCP or TLS (port 6514), and each one carries a facility (source type) and a severity level.

A central collector shortens troubleshooting and keeps evidence intact even when a device is compromised. It also makes audits much easier.

## Why centralize logs?

Logs that stay on the device cause three problems. They can disappear on reboot, an attacker can erase them, and investigating an incident means logging in to dozens of devices one at a time. A central collector addresses all three:

- **Correlation:** firewall, VPN and server events from the same minute appear on one screen.
- **Integrity:** records are kept outside the source, on a system with separate permissions.
- **Retention:** archives follow your retention policy instead of device storage limits.
- **Compliance:** evidence of logging and monitoring for frameworks such as ISO/IEC 27001 and PCI DSS, and in Türkiye for Law 5651 and KVKK.

## How the syslog protocol works

Syslog uses a simple model. An **originator** creates the message, optional **relays** forward it, and a **collector** stores it. Every message starts with a `<PRI>` value:

`PRI = facility × 8 + severity`

For example, `<34>` means facility 4 (auth) and severity 2 (critical).

### RFC 3164 vs RFC 5424

| Aspect | RFC 3164 (BSD syslog) | RFC 5424 |
|---|---|---|
| Status | Informational RFC documenting existing practice (2001) | Standards-track protocol definition (2009) |
| Timestamp | `Oct 11 22:14:15`, with no year or time zone | RFC 3339 format with fractional seconds and time zone |
| Header fields | PRI, timestamp, hostname, tag | PRI, version, timestamp, hostname, APP-NAME, PROCID, MSGID |
| Structured data | None | STRUCTURED-DATA as `[id key="value"]` |
| Character set | ASCII in practice | UTF-8 supported |
| In the field | Still the default on many network devices | Common on modern Linux, applications and security products |

A sample RFC 5424 message:

```text
<165>1 2026-09-13T10:42:07.215+03:00 fw01.gebze.local firewall 2211 LOGIN [auth@32473 user="admin" src="10.0.20.15" result="fail"] Admin panel login failed
```

Here `<165>` means facility 20 (local4) and severity 5 (notice). With the structured data in square brackets, the collector can read the user and IP fields without a custom parser.

### Facility and severity

| Severity | Meaning | Typical example |
|---|---|---|
| 0 Emergency | System is unusable | Kernel panic |
| 1 Alert | Action must be taken immediately | Database corruption |
| 2 Critical | Critical condition | Hardware failure |
| 3 Error | Error condition | Service failed to start |
| 4 Warning | Warning condition | Disk 90% full |
| 5 Notice | Normal but significant | Interface state changed |
| 6 Informational | Informational message | User logged in |
| 7 Debug | Debug-level detail | Verbose protocol output |

Facilities run from 0 to 23. They include system sources such as kern (0), user (1), mail (2), daemon (3), auth (4), syslog (5), cron (9) and authpriv (10), plus local0–local7 (16–23), which network devices use a lot. Collector filtering and retention rules are usually written against these two fields.

## Transport: UDP, TCP and TLS

| Transport | Port | Spec | Reliability | Encryption | Best for |
|---|---|---|---|---|---|
| UDP | 514 | RFC 5426 | No delivery or ordering guarantee | None | High-volume, loss-tolerant logs on a local network |
| TCP | 514 or vendor-specific | RFC 6587 (framing) | Delivered while the connection holds | None | Reliable delivery inside the network |
| TLS | 6514 | RFC 5425 | TCP reliability | Encrypted, certificate-based authentication | Sending over the internet or to the cloud, sensitive logs |

UDP has two important weaknesses. Messages are silently dropped under load or congestion, and source addresses are easy to spoof. Use TCP for security-relevant logs and TLS whenever logs cross the internet. TCP on its own does not prevent loss either. If there is no **disk-assisted queue** to hold messages while the collector is unreachable, a connection outage still loses data.

Forwarding over TCP with a disk-assisted queue in rsyslog:

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

## Layers of a central log collection system

A scalable design usually has these layers:

1. **Sources:** network devices, servers, hotspot and VPN gateways, applications.
2. **Relay or agent layer:** collects logs at branches or network segments, queues and compresses them, and forwards them securely to the core.
3. **Collectors:** at least two highly available nodes with load balancing and rate limiting.
4. **Parsing and normalization:** maps vendor formats to common fields such as time, source, user, IP and action.
5. **Storage:** a fast tier for recent, frequently queried data and a compressed, cheaper tier for older data.
6. **Search, dashboards and alerts:** queries, saved searches, and threshold- or pattern-based alerts.
7. **Archive:** immutable (WORM) storage, hash chains and timestamps.

Design points that often get overlooked:

- **Time sync:** if sources are not synchronized via NTP, you can't trust the order of events.
- **Consistent hostnames:** use a naming standard. Otherwise history breaks when a device's IP changes.
- **Capacity planning:** multiply events per second (EPS) and daily volume by the retention period to size storage.
- **Management network:** carry log traffic over a dedicated management VLAN or an encrypted tunnel where possible.
- **Logging the log system:** record who queried or exported which records.

## Cloud or on-premises?

| Criterion | Cloud | On-premises |
|---|---|---|
| Deployment | Fast, with no hardware | Requires servers, storage and installation |
| Scaling | Elastic with volume | Bound by hardware capacity |
| Data location | Depends on the provider's data centre. Cross-border transfer rules such as KVKK's apply | Data stays within the organization |
| Bandwidth | All logs travel over the internet, so compression and TLS matter | Carried on the local network |
| Maintenance | Updates and backups handled by the provider | The organization's own team is responsible |
| Good fit | Multi-site organizations, small IT teams | Isolated networks, very high volume, strict data locality |

Many organizations end up with a hybrid setup: lightweight relays at branches, and the search layer at headquarters or in the cloud. [Syslog](/en/solutions/syslog) collects logs from any syslog-capable device and can run in the cloud or on-premises.

## Retention, search and analysis

How long to keep logs is a policy decision more than a technical one. Three inputs shape it:

- **Regulation and standards:** in Türkiye, Law 5651 and its regulations require collective-use providers and access providers to keep certain records for set periods. PCI DSS requires at least 12 months of audit log history, with the most recent three months immediately available.
- **Data protection:** personal data in logs should not be kept longer than the purpose requires. When the period ends, it must be deleted or anonymized under KVKK or GDPR.
- **Operational need:** how far back incident response realistically has to look.

Logs only have evidential value if tampering can be detected. A common method is to hash each day's files, chain the hashes and seal them with RFC 3161 timestamps. This proves that a record existed at a given time and has not changed since. On the guest Wi-Fi side, [WiPoint](/en/solutions/wipoint) archives session records this way.

A good search layer offers:

- field-based queries such as `src_ip=10.0.20.15 AND severity<=3`
- time-range filters and saved searches
- threshold alerts such as "5 failed logins in 10 minutes"
- ready-made dashboards for interface, VPN and admin-session events

## Log management vs SIEM

| Aspect | Centralized log management | SIEM |
|---|---|---|
| Core purpose | Collect, store and search logs | Detect and manage security incidents |
| Analysis | Search, filters, simple threshold alerts | Multi-source correlation rules, behaviour analytics |
| Context | Log content | Asset inventory, user identity, threat intelligence |
| Output | Records, reports, archives | Prioritized security alerts and cases |
| Operations | Manageable by IT or network teams | Usually needs a SOC team and ongoing rule maintenance |
| Cost | Relatively low, driven by volume | Higher licensing and expertise costs |

The two layers complement each other. A SIEM can only work with the data it receives, and log management makes sure that data is complete, consistently parsed and correctly timed. A common model keeps everything in the log management layer for the long term and forwards the security-relevant subset to the SIEM.

## Frequently asked questions

### Should I use UDP or TCP for syslog?

UDP can be acceptable for high-volume, loss-tolerant logs on a local network. For security and compliance logs, use TCP with a disk-assisted queue. Whenever logs travel over the internet or to the cloud, use TLS on port 6514.

### Can RFC 3164 devices send logs to a collector that expects RFC 5424?

Yes, modern collectors parse both formats. RFC 3164 messages carry no year or time zone, though, so the collector has to interpret their timestamps correctly. That is one more reason to keep sources synchronized via NTP.

### How long should logs be retained?

There is no single answer. Weigh regulatory requirements (for example Türkiye's Law 5651 regime), industry standards (at least 12 months for PCI DSS) and the data-minimization principle together. Then write the result down as a formal retention and disposal policy.

### Does centralized syslog replace a SIEM?

No, but a SIEM is built on top of it. Log management handles collection, storage and search, and a SIEM adds correlation and threat detection. Small and mid-sized organizations often start with log management and basic alerting and add a SIEM when they need one.

### Can syslog records be used as evidence?

Yes. How much weight they carry depends on their integrity and reliability. Immutable storage, access logs, accurate time and timestamped hash chains are the main ways to show that records were not altered.

---
Canonical: https://internetten.com.tr/en/knowledge-base/centralized-syslog-log-management