TLS para el reenvío con rsyslog mediante el controlador gtls y cuándo conviene añadir RELP

Qué es

El tutorial de TLS de rsyslog describe controladores de flujo de red (network stream drivers) para el transporte cifrado de syslog: gtls (GnuTLS) y, desde rsyslog 8.36, ossl (OpenSSL), que aceptan los mismos parámetros de modo y de modo de autenticación. Una configuración mínima necesita un certificado de CA en ambos extremos, además de un certificado y una clave en el emisor y en el receptor, organizados como se indica en el TLS Certificate Summary de rsyslog, que recoge el material X.509 que necesita cada rol. El archivo de la CA se define de forma global (global(DefaultNetstreamDriverCAFile=...), junto con DefaultNetstreamDriverCertFile/KeyFile). En el lado emisor, una acción omfwd se amplía con StreamDriver="gtls", StreamDriverMode="1" (solo TLS) y StreamDriverAuthMode con el valor x509/name (validación del certificado más comprobación del nombre del par frente a StreamDriverPermittedPeers="collector.example.org") o x509/certvalid (cualquier certificado firmado por la CA de confianza, opción que la documentación del controlador califica de débil y no recomendada).

RELP (Reliable Event Logging Protocol) es un transporte independiente, proporcionado por los módulos omrelp/imrelp, descritos en la documentación de rsyslog como los módulos de salida y entrada de RELP. A diferencia de omfwd sobre TCP o TLS simples, RELP confirma cada mensaje en la capa de aplicación, de modo que el emisor sabe que el receptor realmente procesó el mensaje y no solo que la pila TCP lo aceptó.

Por qué importa

Un envío correcto sobre TCP simple solo significa que los bytes se entregaron a la pila de red; si rsyslog en el colector se cae o el disco se llena justo después de aceptar la conexión, los mensajes ya "enviados" pueden perderse sin que el emisor reciba ninguna señal. TLS sobre TCP hereda esta propiedad: el cifrado cambia la confidencialidad y la autenticación, no la semántica de entrega. RELP está diseñado específicamente para eliminar ese hueco.

Cómo aplicarlo

• Usa TLS siempre que el tráfico de logs cruce una red que no controlas por completo, incluso dentro de un centro de datos; prefiere StreamDriverAuthMode="x509/name" con StreamDriverPermittedPeers indicando el nombre del colector, y considera x509/certvalid solo como alternativa.
• Combina TLS con omrelp/imrelp (el propio RELP puede funcionar sobre TLS) cuando la pérdida de mensajes durante un fallo del receptor sea inaceptable —logs de auditoría, eventos relevantes para el cumplimiento normativo— y se acepte la complejidad añadida de un par de módulos adicional en ambos extremos.
• Para logs cotidianos de aplicaciones o del sistema, donde es tolerable perder algún mensaje de forma ocasional durante una caída, suele bastar TLS simple sobre TCP con una cola asistida por disco en el emisor.
• Vigila la caducidad de los certificados: desde rsyslog 8.2012.0, StreamDriver.PermitExpiredCerts es off por defecto, por lo que un certificado caducado hace fallar el handshake TLS; el reenvío se detiene (los errores aparecen en el propio log de rsyslog) y los mensajes se acumulan en la cola.

Trampas

• Dejar StreamDriverAuthMode sin definir (su valor por defecto en omfwd depende del controlador) o usar anon, que según la documentación del controlador no autentica al par y está expuesto a ataques de intermediario (man-in-the-middle).
• Suponer que TLS por sí solo garantiza la entrega; no lo hace, y RELP es la solución documentada para ese hueco concreto.
• Olvidar que RELP necesita su propio puerto y su propia regla de firewall, distintos del puerto de syslog TCP/TLS simple.