Syslog y SIEM
Reenvíe el registro de auditoría de forma continua a un colector externo (syslog sobre UDP, TCP o TLS, exportación en texto o Elasticsearch) para que los registros sobrevivan con independencia del app
El envío de registros manda los datos que produce la solución a un colector que usted ya opera, a medida que ocurren. La finalidad es la independencia: un registro que además vive en su SIEM sobrevive a la pérdida, el compromiso o la reinstalación del appliance, y puede correlacionarse con todo lo demás que vigila su SOC.
Qué es esto y cuándo usarlo
Existen dos mecanismos, se configuran en sitios distintos y transportan cosas distintas. Confundirlos es la razón habitual por la que un proyecto de SIEM se atasca.
Reenvío syslog
Los registros de eventos: inicios de sesión, sesiones, cambios de configuración, transferencias de archivos
En el archivo de configuración del appliance
Backend de almacenamiento de comandos
Los comandos escritos en sesiones de terminal, indexados para búsqueda
Configuración del sistema › Almacenamiento › Almacenamiento de comandos
Use el reenvío syslog cuando el requisito sea "nuestro SIEM debe contener el registro de acceso privilegiado". Use un backend Elasticsearch de almacenamiento de comandos cuando el requisito sea "buscar el historial de comandos en la consola es demasiado lento": por defecto los comandos viven en la base de datos de la propia solución, lo cual funciona bien hasta que crece el volumen de sesiones de terminal.
Destinos disponibles para el registro:
Syslog sobre UDP
Puerto por defecto 514. Disparar y olvidar: sin garantía de entrega
Syslog sobre TCP
Puerto por defecto 514. Orientado a conexión
Syslog sobre TLS
Puerto por defecto 6514. Úselo siempre que el colector no esté en un segmento de confianza
Exportación en texto
Un archivo de texto plano, para colectores que leen archivos o para una entrega en entorno aislado
Elasticsearch
Indexa los registros de comandos para búsqueda, como backend de almacenamiento de comandos
Antes de empezar
La dirección y el puerto del colector, y una decisión sobre el protocolo. Prefiera TLS en 6514 salvo que el colector esté en un segmento en el que ya confía.
El colector debe ser alcanzable desde todos los nodos. En un clúster, cada nodo reenvía sus propios registros; una regla de firewall que solo cubra un nodo produce un registro con agujeros.
La facility syslog que espera su colector, para que los registros caigan en el pipeline correcto y no en el predeterminado.
Una ventana de mantenimiento. Habilitar el reenvío exige reiniciar los servicios de la solución.
El reenvío syslog no se configura desde la consola. Se establece en el archivo de configuración del appliance, y el cambio solo surte efecto después de que los servicios se reinicien. Abra un ticket de soporte para que el cambio se haga y quede registrado. No edite a mano un appliance de producción sin él.
Pasos
Elija el destino y el protocolo y abra el camino desde todos los nodos hasta el colector en ese puerto.
Fije los parámetros en el archivo de configuración del appliance,
/opt/datadike/config/config.txt:SYSLOG_ADDRrecibe la dirección y el puerto del colector juntos.SYSLOG_FACILITYdebe coincidir con lo que espera la configuración del colector.Reinicie los servicios de la solución. No se reenvía nada hasta que vuelvan.
Repita en todos los nodos de un clúster. Cada nodo envía sus propios registros.
Añada un backend de almacenamiento de comandos, si el objetivo es la búsqueda de comandos, en Configuración del sistema › Almacenamiento › Almacenamiento de comandos. Dejar la lista vacía mantiene los comandos en la base de datos local.
Construya el lado del colector: parsers, índices y paneles. Los registros siguen un estándar común, de modo que los colectores habituales los consumen sin un parser a medida.
Qué debería ver
Los registros llegan como líneas syslog que llevan un tipo de registro y una carga JSON. El tipo de registro indica de qué log procede el evento:
Inicio de sesión en la consola
login_log
El backend de autenticación, la ip de origen, el username y un objeto status con el resultado
Subida de archivo
ftp_log
La account usada en el activo, el filename, un value igual a upload, el remote_addr y el user de la consola
Descarga de archivo
ftp_log
Los mismos campos, con un value igual a download
Una línea suelta tiene este aspecto, abreviada:
La etiqueta datadike: es por lo que se filtra en el colector para aislar los registros de la solución.
Cómo verificar que funcionó
Confirme la llegada al colector, no solo que la configuración se guardó.
Fuerce un evento conocido. Inicie sesión en la consola, o inicie sesión con una contraseña deliberadamente incorrecta. Ambos producen un registro
login_logen segundos.Busque en el colector la etiqueta
datadike:en los últimos minutos y localice ese evento exacto. Compare elusername, laipde origen y elstatuscon lo que acaba de hacer: un registro que llega con los campos equivocados es un problema de parser, no de entrega.Ejercite un segundo tipo de registro. Suba un archivo pequeño durante una sesión y confirme que llega un registro
ftp_logcon"value": "upload". Que un tipo de registro funcione no demuestra que los demás lo hagan.Compruebe todos los nodos. En un clúster, inicie sesión a través de cada nodo y confirme que los registros de cada uno llegan al colector. Este es el fallo que pasa meses inadvertido.
Si añadió un backend de almacenamiento de comandos, ejecute una sesión de terminal, escriba un comando y después busque ese comando en Auditoría › Sesiones › Keylogger. El comando debe aparecer: si el backend está mal configurado, la indexación falla en silencio y la búsqueda en la consola vuelve vacía aunque la sesión sí se grabara.
Pruebe con un inicio de sesión fallido, además de uno correcto. Una regla de colector que solo coincide con los aciertos oculta precisamente los eventos para los que se montó el pipeline.
Errores frecuentes
No llega nada al colector
Los servicios no se reiniciaron después de cambiar el archivo
Reinicie los servicios de la solución; la configuración se lee al arrancar
No llega nada, y los servicios sí se reiniciaron
Protocolo o puerto equivocados, o el colector es inalcanzable desde los nodos
Compruebe contra 514/UDP, 514/TCP y 6514/TLS, y pruebe el alcance desde todos los nodos
Llegan registros de unas sesiones y de otras no
Solo un nodo del clúster está reenviando
Aplique la configuración en todos los nodos
Los registros llegan pero caen en el pipeline equivocado
SYSLOG_FACILITY no coincide con la configuración del colector
Fije la facility que espera el colector y reinicie
Los registros llegan de forma intermitente por UDP bajo carga
UDP no tiene garantía de entrega
Pase a TCP, o a TLS en 6514
El destino TLS rechaza la conexión
El certificado del colector no es de confianza, o el puerto es incorrecto
Arregle la cadena de confianza y confirme que el colector escucha en 6514
La búsqueda de comandos en la consola es lenta o vuelve vacía
Los comandos están en la base de datos local, o el backend Elasticsearch está mal configurado
Añada o repare el backend de almacenamiento de comandos y verifíquelo buscando un comando que acabe de escribir
Los eventos dejan de aparecer para fechas más antiguas
La retención expiró, con independencia del reenvío
La retención se fija en Configuración del sistema › Retenciones; la retención del propio colector es aparte y suele ser más larga
Referencia de campos
Claves de configuración
SYSLOG_ENABLE
true activa el reenvío. Se lee al arrancar el servicio
SYSLOG_ADDR
El colector, como dirección:puerto, por ejemplo 10.1.12.116:514
SYSLOG_FACILITY
La facility syslog, por ejemplo local2. Debe coincidir con la configuración del colector
Puertos por defecto
Syslog UDP
514
Syslog TCP
514
Syslog TLS
6514
Colectores que consumen el formato sin parser a medida
SIEM
Splunk, IBM QRadar, Microsoft Sentinel, Elastic Security, Google Security Operations, Securonix, LogRhythm, Graylog, Wazuh
Plataformas de logs y búsqueda
Elastic Stack (ELK), OpenSearch, Loki con Grafana
Colectores y reenviadores
rsyslog, syslog-ng, Fluentd, Fluent Bit
Suites de monitorización
SolarWinds, ManageEngine, Paessler PRTG, Nagios
El formato de los registros sigue un estándar común; cualquier cosa que lea syslog estándar o ingiera cargas JSON lo manejará, aparezca o no en la lista anterior.
Páginas relacionadas
Registro de auditoría: los registros que se reenvían, y dónde vive cada uno en la consola
Informes: la otra vía de entrega, extracciones periódicas para personas, no envío continuo
Grabaciones de sesión: almacenadas aparte de los registros de eventos
Acceso aplicación a aplicación: la otra integración que produce registros de auditoría dignos de vigilar en un SIEM
Atualizado
Isto foi útil?