Reenvío seguro de Syslog de SLES con rsyslog y TLS mutuo

Para reenviar de forma segura los registros del sistema SUSE Linux Enterprise Server (SLES), configure rsyslog para que envíe mensajes a través del puerto TCP 6514 protegido por TLS, verifique el nombre del certificado del recopilador y confirme la entrega con un evento de prueba. SLES 15 SP7 recibió una actualización opcional de rsyslog el 27 de marzo de 2026 que agregó un módulo OpenSSL TLS; la configuración que se muestra a continuación utiliza deliberadamente el gtlsmódulo GnuTLS ( ) ya establecido.

Este procedimiento abarca un remitente SLES 15 con el nombre especificado sles01.example.nety un recolector rsyslog con el nombre especificado logs.example.net. Reemplace ambos nombres y todas las rutas de los certificados con sus propios valores. Utiliza TLS mutuo, por lo que el recolector autentica al remitente, así como el remitente autentica al recolector.

1. Compruebe rsyslog y la ruta de registro de SLES.

En ambos equipos, instale el demonio rsyslog y su módulo GnuTLS desde los repositorios SUSE registrados. Es posible que las instalaciones existentes ya contengan el primer paquete.

sudo zypper install rsyslog rsyslog-module-gtls
rpm -q rsyslog rsyslog-module-gtls
sudo systemctl enable --now rsyslog
rsyslogd -v

Revise /etc/rsyslog.conflos fragmentos de código existentes /etc/rsyslog.d/antes de agregar reglas. En particular, desactive cualquier regla de reenvío anterior sin cifrar *.* @@hostpara el mismo destino; de lo contrario, los mensajes podrían tomar dos rutas, incluida una sin TLS.

SLES utiliza systemd-journaldeventos de registro mientras rsyslog procesa las entradas de syslog. Confirme que los eventos que necesita llegan a rsyslog a través de la configuración de entrada existente. SUSE documenta ForwardToSyslog=yesel /etc/systemd/journald.confreenvío de registro a syslog; verifique su implementación antes de modificarla, ya que habilitar los lectores de registro por separado puede crear eventos duplicados. Este procedimiento reenvía automáticamente los mensajes ya procesados ​​por rsyslog, no todos los archivos /var/log.

2. Prepare certificados de servidor y cliente de confianza.

Utilice una autoridad de certificación (CA) controlada por la organización para emitir un certificado con el nombre alternativo del sujeto DNS logs.example.netpara el recopilador y un certificado independiente que identifique sles01.example.netal remitente. Asegúrese de que los certificados sean válidos para sus funciones de servidor o cliente TLS y de que ambas máquinas confíen en la CA emisora. Siga su proceso de infraestructura de clave pública (PKI) para la generación y renovación; no reutilice una clave privada en diferentes hosts.

Copie los archivos apropiados a través de un canal seguro aprobado por el administrador. En este ejemplo, ambas máquinas usan /etc/rsyslog.d/tls/ca.pem. El recolector tiene además server-cert.pemy server-key.pem; el remitente tiene client-cert.pemy client-key.pem.

sudo install -d -m 0750 /etc/rsyslog.d/tls
sudo chmod 0600 /etc/rsyslog.d/tls/*-key.pem
sudo chmod 0644 /etc/rsyslog.d/tls/ca.pem

Restrinja el acceso a certificados y claves a la identidad del servicio rsyslog cuando sea necesario. No exponga las claves privadas en los diagnósticos, el historial de la consola, los repositorios Git ni el flujo de registro exportado. Confirme que su proceso rsyslog puede leer su clave antes de reiniciar el demonio.

3. Habilite un receptor TLS autenticado en el recopilador.

En logs.example.net, agregue lo siguiente como /etc/rsyslog.d/30-tls-listener.conf. Si imtcpya está cargado en otro lugar, mantenga solo una instrucción module-load. El conjunto de reglas dedicado coloca los mensajes recibidos remotamente en un archivo separado en lugar de mezclarlos con los mensajes del sistema local.

global(
  DefaultNetstreamDriverCAFile="/etc/rsyslog.d/tls/ca.pem"
  DefaultNetstreamDriverCertFile="/etc/rsyslog.d/tls/server-cert.pem"
  DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/tls/server-key.pem"
)
module(load="imtcp")
ruleset(name="remote_tls") {
  action(type="omfile" file="/var/log/remote-tls.log")
}
input(
  type="imtcp"
  port="6514"
  StreamDriver.Name="gtls"
  StreamDriver.Mode="1"
  StreamDriver.AuthMode="x509/name"
  PermittedPeer="sles01.example.net"
  ruleset="remote_tls"
)

StreamDriver.Mode="1"Habilita TLS x509/namey PermittedPeerrechaza a los clientes sin una identidad de certificado aceptada. El único nombre permitido es intencional; amplía la lista de pares aprobados al agregar otros remitentes en lugar de debilitar la autenticación.

sudo rsyslogd -N1
sudo systemctl restart rsyslog
sudo firewall-cmd --permanent --add-port=6514/tcp
sudo firewall-cmd --reload
sudo ss -ltn | grep ':6514'

Ejecute los comandos del firewall solo si el recopilador utiliza firewalld. Restrinja el tráfico TCP/6514 entrante a redes de remitentes conocidos mediante el firewall de su host o de la red de origen; abrir el puerto no reemplaza la autenticación por certificado. Verifique también que no haya ningún receptor de texto plano preexistente expuesto involuntariamente.

4. Agregar reenvío TLS y una cola limitada a SLES.

En sles01.example.net, asegúrese de que el directorio de trabajo de rsyslog exista y sea escribible por el servicio. El directorio que se muestra aquí es ilustrativo; conserve uno ya configurado workDirectorysi su configuración empaquetada lo proporciona. Agregue este fragmento como /etc/rsyslog.d/60-tls-forward.conf:

global(
  DefaultNetstreamDriverCAFile="/etc/rsyslog.d/tls/ca.pem"
  DefaultNetstreamDriverCertFile="/etc/rsyslog.d/tls/client-cert.pem"
  DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/tls/client-key.pem"
)
*.* action(
  type="omfwd"
  target="logs.example.net"
  port="6514"
  protocol="tcp"
  StreamDriver="gtls"
  StreamDriverMode="1"
  StreamDriverAuthMode="x509/name"
  StreamDriverPermittedPeers="logs.example.net"
  queue.type="LinkedList"
  queue.filename="tls_forward"
  queue.size="10000"
  queue.maxDiskSpace="1g"
  queue.saveOnShutdown="on"
  action.resumeRetryCount="-1"
)

La configuración TLS autentica al recolector antes de enviar los mensajes. La cola de acciones asistida por disco almacena los mensajes en búfer durante interrupciones breves y reintenta las acciones de reenvío fallidas, pero no es infinita ni garantiza la ausencia total de pérdida de mensajes: el espacio disponible en disco, los límites de la cola, el comportamiento de cierre de procesos y el estado del receptor siguen siendo factores importantes. Verifique el directorio de trabajo efectivo de rsyslog y créelo con los permisos adecuados antes de confiar en el almacenamiento en búfer del disco.

Validar y reiniciar el remitente:

sudo rsyslogd -N1
sudo systemctl restart rsyslog

Si falla la validación de la configuración, no reinicie; corrija el primer error detectado. En una implementación de rsyslog existente, las directivas de certificado globales pueden afectar a otras acciones TLS. Revise las demás acciones salientes y utilice los parámetros de certificado por acción compatibles si requieren credenciales diferentes.

5. Verificar la recepción e investigar un apretón de manos fallido.

Primero, confirme que el recolector está escuchando en TCP/6514 y que el remitente puede acceder al host a través del firewall. A continuación, ejecute el siguiente comando en el remitente SLES:

logger -t sles-tls-check "TLS forwarding probe"

En el recopilador, busque el archivo de registro remoto configurado:

sudo grep 'TLS forwarding probe' /var/log/remote-tls.log
sudo journalctl -u rsyslog -n 50 --no-pager

Encontrar el marcador /var/log/remote-tls.logconfirma que la ruta de reenvío a nivel de aplicación funcionó para esta prueba. Esto no demuestra que se estén recopilando todos los archivos de registro específicos de la aplicación. Para probar la autenticación de forma independiente, utilice temporalmente un certificado diferente no confiable o un nombre de par que no coincida en una ventana de mantenimiento controlada y confirme que la conexión TLS falla; restaure la configuración original inmediatamente.

Si el marcador no aparece, proceda en orden según el fallo:

• No hay ningún oyente o la conexión ha sido rechazada: compruebe systemctl status rsysloglas reglas del cortafuegos TCP/6514 y del recopilador.
• Fallo de TLS o certificado: compare los SAN del certificado con PermittedPeery StreamDriverPermittedPeers; verifique la cadena de CA, las fechas de vencimiento, los relojes del sistema y los permisos de clave privada.
• Conectado pero sin eventos: busque entradas de registro/syslog duplicadas o faltantes, acciones de reenvío suspendidas y capacidad de la cola de disco. Revise journalctl -u rsyslogen ambos hosts.

El método sigue la guía oficial de registro del sistema SLES 15 SP7 , la guía del cliente autenticado con certificado rsyslog , la referencia del oyente imtcp y la referencia de reenvío omfwd . El aviso de actualización de SUSE de marzo de 2026 documenta la adición opcional del módulo OpenSSL. Las configuraciones varían según los Service Packs de SLES, por lo que se recomienda validarlas en la versión de rsyslog instalada antes de aplicar los cambios en producción.