Syslog Over TCP

How Syslog over TCP Works

Syslog over TCP keeps the familiar syslog message format but changes the transport from datagram delivery to a connection-oriented TCP stream. That matters because message boundaries, sequencing, and retry behaviour move from “best effort” to a transport that can better support reliable forwarding between senders, relays, and collectors.

In practice, the sender opens a TCP connection to a log endpoint and continues sending events over that session. Compared with UDP syslog, the receiver can observe ordered delivery at the transport layer and detect broken sessions, which makes it easier to build predictable log pipelines across segmented networks or busy estates.

Why Organisations Use It for Log Forwarding

Syslog over TCP is mainly chosen when logging reliability is more important than minimal overhead. Logs are often used for incident response, audit trails, operational troubleshooting, and evidence preservation, so silent loss can create real blind spots. A connection-based transport can reduce the chance that bursts of traffic or transient network issues drop messages without notice.

That said, TCP improves transport reliability, not log quality. It does not validate whether the content is truthful, complete, or protected from tampering after collection. It also does not replace time synchronisation, parsing discipline, log normalisation, or retention controls. Those remain separate design and governance concerns.

Security Implications of Connection-Oriented Logging

Using TCP changes the trust and failure profile of the logging channel. Because the connection is persistent, collectors can more easily notice interrupted transport, but the same channel can also become a dependency that is easier to target with congestion, resource exhaustion, or blocking. If the endpoint is exposed across zones or networks, the collector and relay design should assume the transport itself is a security boundary, not just a plumbing detail.

Syslog over TCP is also relevant to log integrity in transit. It can reduce accidental loss, yet it still needs supporting controls for encryption, endpoint authentication where required, rate handling, and protections against spoofed or malformed sources. For practical guidance on collection, retention, and integrity, see the Log Management and Retention Guide.

Operational Trade-offs and Deployment Considerations

The benefit of TCP comes with cost. Each active session consumes state on senders and receivers, so large fleets can create connection management overhead that does not exist with UDP. Network middleboxes, load balancers, and firewalls may also need explicit tuning so that long-lived log connections are not interrupted unexpectedly.

Because syslog over TCP is still transport, not a complete logging architecture, organisations should decide where it fits in their forwarding path. It works best when the objective is dependable delivery from source to collector, especially for security logs that must survive network instability, but it should be paired with buffering, back-pressure handling, and clear ownership of collector availability.

Risk and Threat Considerations

Reliability improves when syslog uses TCP, but so does the operational importance of the collector path. If the connection is misconfigured, rate-limited, or blocked, logs may queue up, stall, or fail to arrive, which can hide detection signals at the exact moment they are needed. Attackers can also exploit log-path fragility by targeting collectors or saturating the channel to reduce visibility.

Failure mechanism: A persistent connection can be interrupted, exhausted, or deprioritised, causing delayed or missing telemetry, and a weakly protected collector path can be abused as a visibility choke point.

Impact: Missing or delayed logs weaken investigations, alert correlation, audit evidence, and post-incident reconstruction, especially when the logs are needed to confirm compromise or prove scope.

Practitioner Guidance

Why practitioners should care: Treat syslog over TCP as a delivery improvement, not a complete logging control. Its value appears only when the rest of the logging chain can absorb disconnections, preserve message fidelity, and keep collectors reachable under load.

What to watch for: Watch for connection churn, queue growth, collector saturation, and uneven log arrival across sources. Those are often the earliest signs that the transport is reliable in theory but fragile in operation.

Practitioner takeaway: Use TCP when reliability matters, but validate the whole forwarding path, including buffering, protection, and recovery, not just the transport choice.

Related resources from NHI Mgmt Group

• What is the difference between UDP, TCP, and TLS transport for syslog?
• How should security teams reduce message loss when they must keep using syslog over UDP at scale?
• Why does syslog over UDP lose messages more often as enterprise traffic grows?
• What is the difference between SMB over NetBIOS on port 139 and SMB directly over TCP/IP on port 445?