For security logs, plain syslog over UDP is a weak choice. It has no acknowledgment, so messages can be lost, intercepted, modified or replayed without anyone knowing. Use TLS based transport or an authenticated agent, and keep UDP for managed networks where loss is tolerable.
What the RFC says
RFC 5424, the syslog protocol specification, has a security section that reads like a list of reasons not to rely on it for evidence.
- No delivery guarantee. Syslog is one way with no acknowledgment. Messages can be lost, and attackers can intercept or drop them.
- Transport. UDP lacks congestion control. TLS is required for implementations and recommended for deployment, and UDP is only appropriate on managed networks with provisioned capacity.
- Replay. The protocol cannot detect replayed messages even with timestamps. Signing can help.
- Integrity and confidentiality. Messages can be changed in transit and are readable on the wire.
- Truncation. Receivers with size limits may truncate or discard messages, which can hide important information. The RFC advises putting critical data early in the message.
- Control characters. NUL and other control characters can hide data or corrupt processing.
- Flooding. Attackers can flood collectors or fill disks. It suggests accepting messages only from known addresses and rate limiting.
When UDP is acceptable
- Low value informational logs on an isolated management network.
- A secondary copy, in addition to a reliable path.
- Legacy devices that support nothing else, wrapped behind a local relay that forwards over a secure channel.
Do not use it as the only path for authentication, administration or cloud audit events.
Better options
Syslog over TLS. Same message format, reliable stream, server authentication and optionally mutual authentication. Certificates need a lifecycle, so plan renewals.
An agent with acknowledgment. Many collectors buffer to disk and retry until the receiver confirms. That handles outages gracefully.
API based shipping. Application logs sent over HTTPS with credentials and batching.
What to configure regardless of transport
- Authenticate senders, or at least restrict by network.
- Buffer on the sender so a network blip does not drop events.
- Monitor for gaps so you notice when a source goes quiet. See detecting a silent log source.
- Keep messages short and put the critical fields first.
- Rate limit the receiver and watch its disk.
- Use UTC timestamps. See log timestamps.
Severity and facility are hints
RFC 5424 encodes priority as facility times 8 plus severity, with severities from 0 (Emergency) to 7 (Debug). Facilities are informational and not normative, so do not build security meaning on them. Put a stable event name in the message or structured data instead.
Quick check
Does syslog over TLS fix everything?
It fixes in transit confidentiality and, with authentication, impersonation of the server or sender. You still need storage integrity, access control and gap detection.
Is UDP ever faster enough to matter?
For typical security event volumes, TCP or TLS overhead is rarely the constraint. Reliability matters more than a few microseconds.
Sources
Last reviewed: 19 October 2026.
