Cómo exportar de forma segura los registros del sistema SLES a un servidor Syslog remoto

La forma más segura y práctica de exportar los registros del sistema de SUSE Linux Enterprise Server (SLES) a un recolector de syslog remoto es usar rsyslog sobre TCP con TLS, validar el certificado del recolector por nombre y asignar una cola propia a la acción de reenvío. El syslog UDP simple es sencillo, pero no proporciona confidencialidad ni autenticación entre pares. El TCP simple mejora el comportamiento de entrega, pero aún deja el contenido de los registros expuesto durante la transmisión.

Esta guía utiliza el controlador de flujo de red GnuTLS gtlsy la sintaxis de acciones de rsyslog moderna. El procedimiento está dirigido a sistemas SLES 15 SP7, cuya Guía de administración se actualizó el 1 de octubre de 2026. Compruebe siempre los paquetes exactos y la versión de rsyslog en su host antes de copiar una configuración tal cual. La documentación oficial de rsyslog recomienda TCP con TLS para implementaciones modernas y una cola de acciones para el reenvío de TCP.

Referencias autorizadas: documentación de SUSE Linux Enterprise Server 15 SP7 , documentación de rsyslog omfwd , configuración del cliente TLS de rsyslog y RFC 5425: Asignación de transporte TLS para Syslog .

Referencia rápida

Antes de configurar el reenvío

Necesitas el nombre de dominio completo del recopilador remoto, el puerto TCP en el que escucha y el certificado de la autoridad de certificación (CA) que firma el certificado del recopilador. Para TLS mutuo, también necesitas un certificado de cliente y una clave privada para la máquina SLES. El certificado del recopilador debe ser válido para el nombre de host que configures en rsyslog, preferiblemente mediante un nombre alternativo del sujeto (SAN). No soluciones una discrepancia de nombre desactivando la verificación del certificado.

El recolector remoto debe estar configurado para aceptar syslog TLS. Este artículo se centra en el emisor SLES, ya que la configuración del receptor varía entre rsyslog, syslog-ng, dispositivos SIEM y servicios de registro gestionados. Si un firewall separa los sistemas, permita que el host SLES inicie conexiones TCP con el recolector en el puerto configurado. Una política de firewalld con estado predeterminada generalmente no requiere abrir un puerto de entrada en el emisor SLES.

Paso 1: Confirme que rsyslog esté instalado e identifique la compilación actual.

Empiece por comprobar la versión del paquete y del demonio. Esto evita confusiones cuando ejemplos antiguos utilizan directivas que no son compatibles con la compilación en su servidor.

rpm -q rsyslog
rsyslogd -v
systemctl status rsyslog --no-pager

Si rsyslog no está instalado, instálelo desde los repositorios SLES habilitados. Mantenga el sistema actualizado mediante el proceso de actualización habitual de SUSE antes de establecer una conexión de registro de larga duración.

Paso 2: Instalar el módulo rsyslog de GnuTLS

En SLES, el controlador de red TLS se empaqueta por separado. Instale el módulo GnuTLS y mantenga presente el paquete base rsyslog:

sudo zypper install rsyslog rsyslog-module-gtls

Puedes confirmar que los archivos provienen del paquete esperado con rpm -ql rsyslog-module-gtls. Los nombres de los paquetes son específicos de cada distribución, así que no copies los nombres de los paquetes de las guías orientadas a Debian o RHEL.

Paso 3: Guarde de forma segura las credenciales de la CA y del cliente.

Utilice certificados emitidos por su organización o plataforma de registro. Para un sistema de producción, evite crear una nueva CA privada en el host que envía los registros. Un laboratorio puede usar una CA de prueba, pero el material de confianza para producción debe seguir el proceso PKI de su organización.

Cree un directorio propiedad del usuario root, copie los archivos y restrinja la clave privada. Reemplace los nombres de archivo de ejemplo con las rutas proporcionadas por su equipo de PKI:

sudo install -d -m 0755 /etc/rsyslog.d/certs
sudo install -m 0644 ca.pem /etc/rsyslog.d/certs/ca.pem
sudo install -m 0644 sles-client.crt /etc/rsyslog.d/certs/sles-client.crt
sudo install -m 0600 sles-client.key /etc/rsyslog.d/certs/sles-client.key
sudo chown root:root /etc/rsyslog.d/certs/*

Inspeccione el certificado de la CA y del cliente en lugar de confiar en los nombres de los archivos:

openssl x509 -in /etc/rsyslog.d/certs/ca.pem -noout -subject -issuer
openssl x509 -in /etc/rsyslog.d/certs/sles-client.crt -noout -subject -issuer -dates

La documentación del cliente TLS de rsyslog advierte explícitamente que la clave privada de la máquina debe estar protegida. Si otro usuario puede leer la clave privada, podría suplantar la identidad del cliente de registro.

Paso 4: Configurar el reenvío TLS con verificación del nombre del servidor.

Cree una configuración dedicada como esta /etc/rsyslog.d/60-remote-tls.conf. Mantener el reenvío remoto separado de la configuración del proveedor facilita la revisión y la reversión.

global(
    DefaultNetstreamDriver="gtls"
    DefaultNetstreamDriverCAFile="/etc/rsyslog.d/certs/ca.pem"
    DefaultNetstreamDriverCertFile="/etc/rsyslog.d/certs/sles-client.crt"
    DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/certs/sles-client.key"
)

action(
    type="omfwd"
    target="logs.example.com"
    port="6514"
    protocol="tcp"
    StreamDriver="gtls"
    StreamDriverMode="1"
    StreamDriverAuthMode="x509/name"
    StreamDriverPermittedPeers="logs.example.com"
    queue.type="linkedList"
)

StreamDriverMode="1"Es importante: elegir un controlador compatible con TLS no es suficiente en configuraciones donde el modo predeterminado es TCP simple. StreamDriverAuthMode="x509/name"Luego, verifica el certificado remoto y comprueba que la identidad del servidor coincida con la del par permitido. Utilice el nombre exacto del recopilador en el certificado en lugar de un comodín amplio siempre que sea posible.

La acción anterior reenvía todos los mensajes que recibe. Si solo desea que se apliquen ciertas funcionalidades o prioridades, agregue un filtro antes de la acción. Por ejemplo, un entorno centrado en la seguridad podría reenviar los eventos de autenticación y demonio, conservando localmente los registros de depuración de aplicaciones de gran volumen. El filtrado debe basarse en las necesidades de retención, respuesta a incidentes y cumplimiento normativo, en lugar de asumir que todos los mensajes deben salir del host.

Paso 5: Validar, reiniciar, enviar un evento de prueba y comprobar la entrega.

Valide la configuración completa de rsyslog antes de reiniciar el servicio. Esta es la forma más rápida de detectar errores de sintaxis y referencias de módulos faltantes:

sudo rsyslogd -N1

Si la validación se realiza correctamente, reinicie rsyslog y envíe un mensaje de prueba único:

sudo systemctl restart rsyslog
sudo systemctl status rsyslog --no-pager
logger -t sles-tls-test "remote syslog TLS test $(date -Is)"
sudo journalctl -u rsyslog -n 50 --no-pager

En el recopilador, busque la etiqueta sles-tls-testy el nombre de host del remitente. Una aparición remota exitosa demuestra que el mensaje llegó al recopilador, pero no prueba por sí sola que la verificación del certificado se haya configurado correctamente. La comprobación más rigurosa consiste en mantener x509/namehabilitada la función y confirmar que no haya errores de protocolo de enlace TLS ni de nombre de par en el registro del servicio rsyslog.

Si la conexión falla, pruebe la resolución DNS para logs.example.com, confirme que el puerto TCP 6514 sea accesible, verifique las fechas de validez del certificado y compruebe que el certificado del recopilador contenga el nombre DNS esperado. Asimismo, confirme que el recopilador confía en la CA que emitió el certificado de cliente SLES cuando TLS mutuo está habilitado.

Lista de verificación para la resolución de problemas

• Conexión rechazada: el recolector no está escuchando en la dirección/puerto configurado o un cortafuegos está rechazando la conexión.
• Tiempo de espera agotado: el enrutamiento, las ACL de red o un cortafuegos están descartando el tráfico silenciosamente.
• Error al verificar el certificado: el archivo de la CA es incorrecto, incompleto, ha caducado o la cadena de certificados del servidor está incompleta.
• Discrepancia en el nombre del par: el nombre target/ StreamDriverPermittedPeersno coincide con la identidad del certificado del recolector.
• Permiso denegado en la clave: la ruta de la clave o los permisos no permiten que el proceso rsyslog lea el archivo en la configuración del servicio SLES.
• Los mensajes se detienen durante una interrupción: revise el diseño y la capacidad de la cola de acciones. La documentación de omfwd recomienda específicamente una cola para el reenvío TCP para que un destino no disponible no bloquee el procesamiento normal.

Notas de seguridad que son fáciles de pasar por alto

No reemplace la validación de certificados con TLS anónimo a menos que comprenda completamente las implicaciones. El cifrado sin autenticar el servidor aún puede exponer los registros a un atacante intermediario. Del mismo modo, no abra el puerto TCP 6514 entrante en el remitente SLES solo porque el destino utilice ese puerto; el reenvío es una conexión de cliente saliente.

Proteja las claves privadas de los clientes como credenciales, rote los certificados antes de que caduquen y utilice un nombre de host de recopilación que se mantenga estable ante cambios de dirección IP. Si necesita garantías de entrega más sólidas que las del reenvío TCP/TLS habitual, la documentación de rsyslog recomienda RELP como alternativa diseñada para la entrega con confirmación. Esta es una decisión de diseño distinta al cifrado de transporte.

Verificación final

Una implementación correcta debe cumplir cuatro condiciones observables: la validación de la configuración de rsyslog se realiza correctamente, el servicio permanece activo tras el reinicio, el recolector recibe el evento de prueba único y el registro del remitente no muestra errores de confianza TLS ni de nombre de par. Una vez superadas estas comprobaciones, documente las fechas de caducidad de los certificados y la dependencia del recolector remoto para que el mantenimiento futuro no interrumpa silenciosamente el registro centralizado.