Recolección y monitorización de logs

La monitorización de logs en Pandora FMS permite al usuario visualizar en una única consola todos los registros (logs) de múltiples orígenes que se deseen capturar, organizando la información de manera secuencial, utilizando la marca de tiempo en que se procesaron los logs.

Esta información no contiene estructuras ni formatos, se guarda en formato texto junto con una marca temporal (del momento de su recepción), además de las marcas de tiempo originales que pudieran tener dichos ficheros.

Estos logs se pueden utilizar para generar eventos de seguridad (SIEM) y/o para fines de troubleshooting, compliance legal o análisis forense. La capacidad de procesamiento de logs está limitada solamente por la capacidad del dispositivo empleado en su almacenamiento.

• Los logs analizados por los Agentes Software (eventlog o ficheros de texto), son reenviados hacia el servidor de Pandora FMS, en forma RAW dentro del XML de reporte del agente.
• El Data Server Pandora FMS recibe el XML del agente, que contiene información tanto de monitorización como de logs.
• Cuando el Data Server procesa los datos del XML identifica la información de los logs, guardando en la base de datos principal las referencias del agente que ha reportado y el origen del log y luego enviando automáticamente la información a OpenSearch.
• Pandora FMS almacena los datos en índices de OpenSearch generando diariamente un índice único por cada instancia de Pandora FMS.
• El Pandora FMS server dispone de una tarea de mantenimiento que elimina los índices en el intervalo definido por el administrador del sistema (por defecto, 30 días, modificable).
• Los logs viajan por la red codificados para evitar problemas de formato.
• Si se desea que los logs viajen por la red cifrados, se puede emplear un transporte seguro (Tentacle cifrado) a tal efecto.
• Los logs se pueden enviar por Syslog a Pandora FMS Syslog Server, que procesa directamente los logs desde un servidor Syslog local, haciendo mucho más rápido el procesamiento.
• Se puede distribuir la carga usando diferentes agentes y servidores Syslog remotos para adoptar la mejor distribución y adecuación a la topología de red.

Menú Management → Settings → System Settings → Log collector. Se debe activar el botón Activate Log Collector y pulsar el botón Update.

Se deberán configurar los siguientes valores en la sección OpenSearch options:

1. OpenSearch IP: Dirección IP del servidor OpenSearch a utilizar con Pandora FMS.
2. Use https: Se debe activar si el entorno OpenSearch instalado tiene habilitado HTTPS para su conexión.
3. OpenSearch Port: Número de puerto TCP.
4. Days to purge old information: Cantidad de días antes de borrar los datos recabados.
5. Basic authentication: (opcional) si se ha instalado la autentificación básica en OpenSearch (recomendado) se deberá colocar el usuario (campo User) y contraseña (campo Password) establecidos.

La recolección de logs se hace mediante los agentes, tanto en el agente para Microsoft Windows® como en los agentes Unix® (Linux®, MacOS X®, Solaris®, HPUX®, AIX®, BSD®, etcétera).

Se emplean los agentes para recoger la información local de cada EndPoint monitorizado.

Se pueden recoger eventos o textos planos (logs convencionales).

Similar a la sintaxis de Linux, se utiliza el tipo de módulo log junto con el token module_regexp.

MS Windows no soporta module_pattern_exclude.

# Logs extraction
module_begin
module_name Apache_log
module_description Logs extraction module
module_type log
module_regexp C:\server\logs\apache.log
module_source_type apache
module_pattern .*
module_end

Para ello se utiliza el tipo de módulo especial logchannel, que funciona únicamente para entornos Microsoft Windows®. Permite obtener información del log de eventos de MS Windows® basándose en ciertos filtros, en función de la fuente y el tipo de evento.

Formato general de este módulo:

module_begin
module_name MyEvent 
module_type log
module_logchannel 
module_source <logName>
module_eventtype <event_type/level (optional)>
module_eventcode <event_id (optional)>
module_application <source (optional)>
module_pattern <text substring to match (optional)>
module_source_type <siem log type (optional)>
module_end

Para evitar mostrar información repetida, solamente se tienen en cuenta aquellos eventos que hayan tenido lugar desde la última vez que se ejecutó el Agente. En la primera ejecución por tanto no recogerá todos los eventos que ya existan. Empezará a enviar los eventos recogidos a partir de la primera ejecución.

Todos los parámetros indicados a continuación exigen la introducción correcta de mayúsculas y minúsculas:

• module_source.
• module_source_type.
• module_eventtype.
• module_eventcode.
• module_application.

Fuente que origina el evento registrado en el log. Es fundamental distinguir bien de module_application, el cual indica el nombre de la aplicación (otra forma de obtener eventos). Es un parámetro opcional si se usa module_application pero uno de los dos se debe utilizar.

Esta es una vieja categorización que viene de los tiempos de MS Windows NT®. Los más conocidos son Sistema, Aplicación, Seguridad y cientos más. Se pueden ver en cualquier evento, en este caso en español bajo el nombre de “Registro” o “Nombre de registro”.

Es decir, en esta captura se ve como “Sistema”, pero las claves para poder filtrar se deben expresar en inglés, “System” en este caso. “Application” en vez de “Aplicación” y “Security” en vez de “Seguridad”. Otros nombres de registro largos se deben usar tal cual, System, Application, Security y se deben colocar siempre en inglés para poder obtener y visualizar eventos.

Ejemplo de module_source con nombre largo, sin traducción:

Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Administración

La monitorización SIEM se basa en gran medida en el tipo de log recolectado, por lo que será necesario especificar module_source_type en los módulos de recolección de logs para indicar dicho tipo. El tipo es usado por decoders y rules, por lo que se deberá consultar los decoders y rules activos para conocer el tipo que se deba indicar en cada log.

Los tipos de logs más usados son:

• syslog.
• ids.
• web-log.
• squid.
• host-information.
• ossec.

El tipo ossec se debe usar para procesar eventos Windows por parte del SIEM. Para más información, consúltese la documentación de la monitorización SIEM.

Este sería un ejemplo concreto para recoger todos los eventos de seguridad en Windows, que permite procesar los eventos específicos de seguridad por el SIEM:

# Security Events
module_begin
module_logchannel 
module_name Security_Events 
module_type log
module_source Security
module_source_type ossec
module_end

Es un atributo opcional que sirve para filtrar el tipo de evento (dependiendo de la versión de MS Windows®: Error, Warning, Information, Audit success, Audit failure …). Se expresa como un valor que se puede observar en el visor de eventos de Windows.

Este ejemplo tomaría eventos de seguridad de nivel 3 (advertencia):

module_begin
module_logchannel 
module_name Security_Events_Warning 
module_type log
module_source Security
module_event_type 3
module_source_type ossec
module_end

Parámetro opcional. Permite usar un ID específico de evento para filtrar solamente eventos con ese ID. Es quizás el filtro más exacto.

Como se puede ver en esta captura, se hace referencia al eventID en el visor de eventos:

Este ejemplo tomaría eventos de seguridad de nivel 3 (advertencia):

module_begin
module_logchannel 
module_name Security_Events_4798
module_type log
module_source Security
module_eventcodee 4798
module_source_type ossec
module_end

Origen del evento. Es un campo opcional.

Para obtener el nombre del proveedor del evento será necesario especificar el nombre exacto del mismo que aparece en el campo name de la lista de eventos detallada. Para ello, en el visor de eventos de Windows, tras hacer clic secundario en el mismo, seleccionar Propiedades y copiar el parámetro Full name, necesario para module_application, tal como se muestra en la captura de pantalla siguiente:

Estos son algunos ejemplos comunes de nombres de proveedores que aparecen en el Visor de Eventos de Windows, pero pueden existir muchos más, ya que cada aplicación utilizará un nombre específico.

Proveedores del sistema operativo:

• Microsoft-Windows-Winlogon
• Microsoft-Windows-Security-Auditing
• Microsoft-Windows-User Profiles Service
• Microsoft-Windows-WindowsUpdateClient
• Microsoft-Windows-DNS-Client
• Microsoft-Windows-GroupPolicy
• Microsoft-Windows-TaskScheduler
• Microsoft-Windows-TerminalServices-LocalSessionManager
• Microsoft-Windows-Eventlog
• Microsoft-Windows-WMI
• Microsoft-Windows-Application-Experience
• Microsoft-Windows-PrintService
• Microsoft-Windows-Time-Service

Proveedores comunes de aplicaciones o servicios:

• MSSQLSERVER
• Microsoft Outlook
• Microsoft Office Alerts
• VSS
• Microsoft Exchange Server
• Application Error
• Windows Defender
• Windows Firewall

Ejemplos específicos de eventos relevantes para diagnóstico avanzado:

• Microsoft-Windows-Kernel-General
• Microsoft-Windows-DistributedCOM
• Microsoft-Windows-Power-Troubleshooter
• Microsoft-Windows-Kernel-Boot
• Microsoft-Windows-Resource-Exhaustion-Detector
• Microsoft-Windows-Ntfs
• Microsoft-Windows-Kernel-Processor-Power

Estos son algunos ejemplos de proveedores comunes (no Microsoft):

• Google Chrome
• Mozilla Firefox
• VMware Tools
• Citrix Broker Service
• Oracle Database
• Symantec Endpoint Protection
• McAfee Security
• ESET Security
• Apache Service
• TeamViewer
• Adobe Acrobat
• Backup Exec
• Dropbox Update

Estos proveedores sirven como criterio de filtrado para recolectar o excluir eventos mediante el agente de Pandora FMS. Si tiene espacios, no se deben utilizar comillas, por ejemplo, en el caso de “Pandora FMS” sería:

module_begin
module_name Pandora_Events_Windows
module_type log
module_logchannel
module_application Pandora FMS
module_source Application
module_end

• ¿Qué es Sysmon?

Sysmon (System Monitor) es una herramienta gratuita desarrollada por Microsoft que forma parte de las Sysinternals Tools, diseñada para mejorar significativamente la monitorización y registro de eventos detallados en sistemas operativos Windows.

Su principal objetivo es registrar actividades relacionadas con la seguridad del sistema y aplicaciones, que normalmente no quedan registradas con suficiente detalle en el visor de eventos estándar.

• ¿Para qué sirve Sysmon?

Sysmon está enfocado principalmente en monitorización y detección temprana de incidentes de seguridad mediante un registro exhaustivo de eventos clave del sistema, tales como:

1. Creación y ejecución de procesos.
2. Conexiones de red (entrantes y salientes).
3. Modificaciones del registro de Windows.
4. Carga de bibliotecas DLL.
5. Acceso y modificaciones en archivos.
6. Uso sospechoso de memoria y procesos.
7. Inyecciones de código en procesos legítimos.

Estas actividades son típicamente explotadas por malware o atacantes durante intentos de intrusión o movimientos laterales dentro de una red corporativa.

• ¿Cómo funciona Sysmon?

Sysmon funciona instalando un controlador en modo kernel, recopilando información en tiempo real sobre las actividades del sistema operativo. Posteriormente estos datos son enviados al Visor de Eventos de Windows (Event Viewer).

• ¿Cómo Sysmon mejora la monitorización con Pandora FMS?

Pandora FMS puede utilizar el agente Windows para recoger estos eventos detallados directamente desde el canal de Sysmon y enviarlos al servidor central de Pandora.

Este enfoque combinado (Sysmon + Pandora FMS + Pandora SIEM) proporciona grandes ventajas en la monitorización y seguridad de un host basado en Windows:

1. Visibilidad profunda de seguridad: Proporciona un nivel de detalle muy superior al registro de eventos tradicional. Permite análisis exhaustivo de comportamientos sospechosos, identificando anomalías y potenciales amenazas en tiempo real.
2. Detección temprana de ataques avanzados: Facilita detección de ataques sofisticados como movimientos laterales, ejecución de scripts maliciosos o conexión a servidores sospechosos.
3. Capacidad de respuesta inmediata: Pandora FMS puede generar alertas automáticas basadas en reglas definidas en los eventos de Sysmon (por ejemplo, ejecución de procesos sospechosos, accesos al registro o intentos de conexión inusuales).
4. Histórico y correlación: Pandora FMS permite almacenar, consultar y correlacionar eventos históricos generados por Sysmon durante largos periodos, lo cual es fundamental en investigaciones forenses o auditorías de seguridad.
5. Reportes avanzados: La extracción automatizada permite la creación sencilla de reportes orientados a auditorías de ciberseguridad, cumplimiento normativo o análisis post-incidente.

• Ejemplo práctico de integración.

Suponga una alerta de Sysmon enviada mediante el agente de Pandora indicando que:

1. Un proceso desconocido ha creado una conexión saliente a una dirección IP sospechosa.
2. Una DLL desconocida ha sido cargada en memoria.
3. Se ha intentado modificar el registro de Windows por parte de un proceso inesperado.
4. Pandora FMS recibiría estos eventos detallados, generaría una alerta inmediata, y permitiría actuar rápidamente sobre el incidente antes de que se produzca un daño significativo.

• Instalación y uso de Sysmon.

Sysmon viene incluido en el paquete oficial de Microsoft “Sysinternals Suite” y está disponible para sistemas Intel 32 y 64 Bits así como la nueva arquitectura ARM 64 bits (Windows 11).

Sysmon dispone de un fichero de configuración bastante extenso para indicar qué debe “monitorizar”. Monitorizar “todo” afectaría tanto al rendimiento del host o anfitrión como al sistema que recoja toda esa información. Los agentes de Pandora FMS incorporan un fichero de configuración base que puede ser mejorado por el usuario, por defecto generará mucha información de seguridad.

Para más información sobre cómo usar Sysmon, revisar la documentación SIEM.

module_begin
module_name WinEvtLog
module_type log
module_logchannel
module_source Microsoft-Windows-Sysmon/Operational
module_source_type windows
module_end

A diferencia de otros eventos, usa module_source_type windows en vez de module_source_type ossec. Además, utiliza el nombre WinEvtLog, tal como se define en las reglas de SIEM proporcionadas con Pandora SIEM. Si se utilizan otros nombres y/o tipos no funcionará como se espera.

Ejemplo de log:

module_begin
module_name Syslog
module_description Sample log collection of syslog messages file
module_type log
module_regexp /var/log/messages
module_pattern .*
module_pattern_exclude DEBUG
module_end

Para más información sobre la descripción de módulos de tipo log puede consultar la siguiente sección referente a Directivas específicas.

Al definir este tipo de etiqueta, module_type log, se indica que no se almacene en base de datos, sino que se envíe al colector de log. Cualquier módulo con este tipo de dato se mandará al colector de logs, siempre y cuando esté habilitado. En caso contrario se descartará la información.

Más ejemplos completos:

module_begin
module_name apache_access
module_type log
module_regexp /var/log/httpd/access_log
module_pattern .*
module_pattern_exclude \s200\s|\s301\s
module_source_type web-log
module_end

module_begin
module_name Audit denied
module_type log
module_regexp /var/log/audit/audit.log
module_pattern denied
module_end

module_begin
module_name Syslog
module_type log
module_regexp /var/log/messages
module_pattern error|fail|panic|segfault|denied|timeout|critical|alert|emergency|memory|core_dumped|failure|attack|bad|illegal|refused|unauthorized|fatal|failed|Segmentation|Corrupted
module_end

module_begin
module_name Secure
module_type log
module_regexp /var/log/secure
module_pattern Failed|failure|invalid|denied|accepted|root
module_end

Este componente permite a Pandora FMS analizar el syslog de la máquina donde está ubicado, analizando su contenido y almacenando las referencias en el servidor OpenSearch correspondiente.

La ventaja principal del Syslog Server consiste en complementar la unificación de logs. Con apoyo de las características de exportado de Syslog Server de los entornos Linux® y Unix®, Syslog Server permite la consulta de logs independientemente del origen, buscando en un único punto común (visor de logs de la consola de Pandora FMS).

La instalación de Syslog Server 8.2102 se debe realizar tanto en cliente como en servidor:

dnf install rsyslog

Acceda al fichero de configuración /etc/rsyslog.conf para habilitar el input de TCP y UDP.

(...)

# Provides UDP syslog reception
module(load="imudp")
input(type="imudp" port="514")

# Provides TCP syslog reception
module(load="imtcp")
input(type="imtcp" port="514")

(...)

Reinicie el servicio rsyslog. Una vez el servicio esté disponible, compruebe que el puerto 514 está accesible con:

netstat -ltnp

En el cliente se configura para que pueda enviar los logs al Syslog Server, acceda al rsyslog /etc/rsyslog.conf . Localice y habilite la línea que permite configurar el host remoto (cambie remote-host por la dirección IP del servidor):

action(type="omfwd" Target="remote-host" Port="514" Protocol="tcp")

El tamaño de los logs recibidos por rsyslog es de 8 kilobytes por defecto. Si se reciben logs con un tamaño mayor se añaden nuevas entradas con el contenido restante hasta recibir el log completo. Estas nuevas entradas no contienen el nombre del host que envió el log, por lo que este comportamiento puede causar que se creen tanto nuevos orígenes de logs indeseados como nuevos agentes en la consola. Para evitar esto se recomienda aumentar el tamaño de los logs recibidos añadiendo la siguiente línea:

$MaxMessageSize 512k

Guarde el fichero y salga del editor de texto.

Para activar esta funcionalidad en Pandora FMS Server, habilite en el archivo pandora_server.conf el siguiente contenido:

# Enable (1) or disable (0) the Pandora FMS Syslog Server
syslogserver 1

# Full path to syslog's output file.
syslog_file /var/log/messages

# Number of threads for the Syslog Server
syslog_threads 2

# Maximum number of lines queued by the Syslog Server's
syslog_max 65535

En el servidor de Pandora FMS, por medio del token syslog_whitelist, se pueden admitir solamente los registros que coincidan con una expresión regular o regexp, la cual es sensible a mayúsculas y minúsculas (por ejemplo, windows no es igual a Windows) y descartar todo lo demás .

Con el token syslog_blacklist se pueden denegar registros que coincidan con la regexp establecida (y dejar entrar todo lo demás ).

Ambos token vienen desactivados por defecto.

• syslog_whitelist: Al activar dicho token solamente dejará entrar los logs que cumplan con la regexp y se descarta el resto.
  • Si dicho token está activado y se tiene el filtro que viene por defecto .*, se admitirá todo.
  • Importante: Si dicho token está activado SIN regexp, NADA será admitido.
• El filtrado de palabras clave permitidas se realiza primero, esto reduce el trabajo para el siguiente paso.
• syslog_blacklist: Al colocar una regexp se descartará todo lo que cumpla con ello (si se activa este token pero se deja SIN regexp, NADA será bloqueado.).
• El filtrado por syslog_blacklist se realiza de último.

En una herramienta de recolección de logs interesan principalmente dos características: el poder buscar información -filtrando por fecha, fuentes de datos y/o palabras clave, etcétera- y poder visualizar esa información (menú Operation → Logs → Log viewer) dibujada en ocurrencias por unidad de tiempo.

El campo más importante -y útil- será la cadena a buscar a introducir en el cuadro de texto Search en combinación con los tres tipos de búsqueda disponibles (Search mode):

• Exact match: Búsqueda de cadena literal, el log contiene una coincidencia exacta.
• All words: Búsqueda que contenga todas las palabras indicadas, independientemente del orden en una misma línea de log.
• Any word: Búsqueda que contenga alguna de las palabras indicadas, independientemente del orden.
• Si marca la opción de ver el contexto del contenido filtrado, obtendrá una vista general de la situación con información de otras líneas de logs relacionadas con la búsqueda.

Con esta característica se puede mostrar de manera gráfica las entradas de log, clasificando la información en base a modelos de captura de datos.

Estos modelos de captura de datos son básicamente expresiones regulares e identificadores que permiten analizar los orígenes de datos y mostrarlos como un gráfico.

Para acceder a las opciones avanzadas pulse en Advanced options. Se mostrará un formulario donde podrá elegir el tipo de vista de resultados:

• Mostrar entradas de log (texto plano).
• Mostrar gráfica de log.
• Mediante la opción mostrar gráfica de log (Display mode) podrá seleccionar el modelo de captura (Use capture model).
• El modelo por defecto, Apache log model, ofrece la posibilidad de procesar o parse logs de Apache en formato estándar (access_log), pudiendo extraer gráficas comparativas de tiempo de respuesta, agrupando por página visitada y código de respuesta:
• Bien puede pulsar el botón de editar o el botón de crear para realizar un nuevo modelo de captura.

Por medio de esta opción se podrán guardar las preferencias de filtrado de uso frecuente, creando así una lista de filtros. Cuando se hayan configurado todos los valores de filtrado, al pulsar el botón Save filter y asignar un nombre se podrá presionar el botón Save y guardar las preferencias o cambios (se puede guardar en un filtro existente).

En cualquier otra oportunidad se podrán cargar dichas preferencias por medio del botón Load filter para descolgar la lista de filtros guardados. Se debe seleccionar uno de ellos y pulsar Load filter.

Mediante el sistema de favoritos en PFMS se podrá guardar un acceso directo para el Log viewer con las preferencias de filtrado si hace clic en el icono con forma de estrella situado en el título de la sección.

A partir de la versión 749 de Pandora FMS, se ha añadido en la Vista del agente un cuadro llamado Log sources status, en el cual aparecerá la fecha de la última actualización de los logs por parte de ese agente. Al pulsar en el icono de la lupa de Review, redirige a la vista del Log Viewer filtrada por ese log.

Volver al índice de documentación de Pandora FMS