How to Send TLS Encrypted Logs Using syslog-ng: A Practical Guide

SECURE LOGGING
LogZilla Team
April 12, 2024
4 min read

Why encrypt syslog transport

Encrypting syslog in transit protects confidentiality and integrity while supporting mutual authentication between senders and collectors. TLS also reduces the risk of tampering and spoofing on shared networks.

Syslog over TLS is standardized in RFC 5425 (default TCP port 6514). Syslog protocol with structured data is standardized in RFC 5424. Syslog over UDP is described in RFC 5426.

Architecture overview

  • Client(s): syslog‑ng on hosts or network devices that support TLS.
  • Collector: a TLS‑terminating listener on the LogZilla server (TCP/6514).
  • Certificate authority: issues server and client certificates; handles rotation and revocation.

Threat model and objectives

  • Protect confidentiality and integrity of logs in transit.
  • Authenticate collectors and, when required, senders (mutual TLS).
  • Reduce spoofing and tampering risks on shared networks.
  • Maintain availability during network incidents and certificate rotations.

TLS versions and policy

  • Prefer TLS 1.2+; enable TLS 1.3 where platform support exists.
  • Disable legacy protocols and weak ciphers per organizational policy.
  • Maintain a documented cipher policy with periodic review.

Certificates and trust

  • Establish a private CA or use an internal PKI.
  • Issue a server certificate for the collector hostname.
  • Issue client certificates per sender or sender group when mutual authentication is required.
  • Distribute CA trust to all participating nodes.

Minimal configuration (client)

Example syslog‑ng client configuration that forwards with TLS and validates the server certificate chain while presenting a client certificate for mutual TLS:

bash
@version: 3.38
source s_local { system(); internal(); };

destination d_lz_tls {
  syslog(
    "10.10.10.10"
    transport("tls") port(6514)
    tls(
      ca-dir("/etc/syslog-ng/ca.d")
      key-file("/etc/syslog-ng/client.key")
      cert-file("/etc/syslog-ng/client.crt")
      peer-verify(required-trusted)
    )
  );
}

log { source(s_local); destination(d_lz_tls); };

Collector configuration (server) — syslog‑ng example

bash
@version: 3.38

source s_tls {
  network(
    transport("tls")
    port(6514)
    tls(
      key-file("/etc/syslog-ng/server.key")
      cert-file("/etc/syslog-ng/server.crt")
      ca-dir("/etc/syslog-ng/ca.d")
      peer-verify(optional-untrusted)
    )
  );
};

destination d_store { file("/var/log/ingest.log"); };

log { source(s_tls); destination(d_store); };

Collector configuration (server)

  • Enable the TLS listener (TCP/6514) on the collector.
  • Install the server certificate, private key, and CA chain.
  • Require client authentication when mutual TLS is desired.
  • Monitor handshake failures and certificate expirations.

Cipher policy and performance

  • Prefer modern cipher suites; disable legacy protocols.
  • Benchmark CPU overhead at expected send rates; TLS framing adds work per connection.
  • Scale listeners horizontally if many concurrent clients connect.

Disk buffer and failover

  • Enable disk buffers on senders to absorb transient outages.
  • Configure multiple collector endpoints and client failover.
  • Monitor queue depth to detect saturation and back‑pressure.

High availability

  • Use a virtual IP, DNS load balancing, or reverse proxies for multiple collectors.
  • Configure client failover destinations.
  • Keep certificates synchronized across nodes and automate rotation.

Rollout plan

  1. Enable TCP/6514 with TLS on the collector in parallel with existing UDP.
  2. Move a subset of senders to TLS and validate mutual authentication.
  3. Benchmark CPU and latency; tune cipher policy if needed.
  4. Switch remaining senders; keep UDP for break‑glass as required by policy.

Troubleshooting

  • Handshake failures: verify trust chain, hostnames, and certificate validity.
  • Dropouts: check network buffers, keepalive settings, and listener backlog.
  • Performance: review cipher choices, concurrency, and batching settings.

Micro-FAQ

What port is used for syslog over TLS?

RFC 5425 specifies syslog over TLS on TCP port 6514 by default. Use this port on both clients and collectors unless policy dictates otherwise.

When should mutual TLS be enabled?

Enable mutual TLS when sender identity must be authenticated. Issue client certificates per host or group and validate against a trusted CA.

How much overhead does TLS add?

TLS adds CPU and framing overhead. Benchmark with expected send rates and tune cipher policy and concurrency; scale collectors horizontally if needed.

Next Steps

  • Enable a TLS listener on the collector and forward from a single client.
  • Validate mutual authentication and confirm logs arrive with expected fields.
  • Roll out in phases, measure CPU/latency overhead, and tune cipher policies.

Tags

syslog-ngtlssecuritybest-practices

Schedule a Consultation

Ready to explore how LogZilla can transform your log management? Let's discuss your specific requirements and create a tailored solution.

What to Expect:

  • Personalized cost analysis and ROI assessment
  • Technical requirements evaluation
  • Migration planning and deployment guidance
  • Live demo tailored to your use cases
Secure Syslog with TLS (RFC 5425): syslog-ng Configuration and Best Practices