Sistema de alertas

Una alerta es la reacción de Pandora FMS a un valor incorrecto de un Módulo. Dicha reacción es configurable y puede consistir en cualquier cosa que pueda ser desencadenada por un script configurado en el Sistema Operativo donde corre el servidor de Pandora FMS que procesa el Módulo, Evento o Log.

En Pandora FMS, las alertas funcionan mediante la definición de unas condiciones de disparado, unas acciones elegidas para esa alerta, y finalmente la ejecución de unos comandos en el servidor de Pandora FMS, que se encargarán de llevar a cabo las acciones configuradas.

Existen varios tipos de alertas:

• Alertas simples.
• Alertas sobre eventos.
• Alertas sobre traps SNMP.
• Alertas sobre logs.
• Alertas sobre eventos de seguridad (SIEM).
• Alertas sobre inventario.

Pandora FMS también tiene un sistema de gestión de paradas de servicio planificadas o agendadas en el menú Management → Alerts → Scheduled downtime. Este sistema permite desactivar las alertas en los intervalos que existe una parada de servicio.

• Comandos: Especifican qué se hará; será la ejecución que realizará el servidor de Pandora FMS al disparar la alerta.
• Acciones: Especifican cómo se hará; son las personalizaciones de los argumentos del comando.
• Plantillas: Especifican cuándo se hará; definen las condiciones para disparar la acción o acciones.

Las plantillas y las acciones tienen una serie de campos genéricos llamados Field1 , Field2 , Field3, (…) , Fieldn los cuales se utilizan para transferir la información desde la plantilla a la acción y de la acción al comando, para finalmente utilizarse como parámetros en la ejecución de dicho comando.

Dicha información se transfiere siempre que el paso siguiente no traiga ya información definida en sus campos Fieldn. Es decir, en caso de solapamiento de campos o parámetros, sobrescribe la acción a la plantilla (por ejemplo, si la plantilla tiene definida Field1 y la acción también, el Field1 de la acción sobrescribe la acción de la plantilla).

Menú Management → Alerts → Commands.

Las acciones que realizará Pandora FMS ante situaciones de alerta se traducirán al final en ejecuciones en el servidor, en forma de comandos.

Menú Management → Alerts → Commands → Create.

• Command: Comando que se ejecutará al disparar la alerta. Es posible utilizar macros para reemplazar los parámetros configurados en la declaración de las alertas.
• Group: Esto determina a qué grupo de alertas puede asociar el comando. Solamente podrá asignar un grupo al cual pertenezca el usuario que está creando el comando de alerta, a menos que dicho usuario pertenezca explícitamente al grupo TODOS (ALL).
• Field description y Field values:
  • Valores de campo disponibles: Una colección de posibles valores para ese campo. Si este campo está configurado (no está vacío), el campo será un combo de selección en lugar de una caja de texto. El combo necesita para cada posible valor una etiqueta (la opción visible) y un valor (la opción enviada). La sintaxis es la siguiente: valor1,etiqueta1;valor2,etiqueta2;valor3,etiqueta3;valorN,etiquetaN.
  • Hide: Si el campo alberga alguna contraseña, esta opción oculta con asteriscos el contenido.
• Es posible mostrar un editor de código HTML en un campo del comando en la creación o edición de una acción de una alerta si ese campo del comando tiene como valor el token especial _html_editor_ .

• eMail: Envía un correo electrónico desde el Pandora FMS Server. Los mensajes de correo electrónico son enviados en formato HTML. Se debe tener en cuenta que el receptor debe poder acceder a los recursos utilizados en la plantilla, como por ejemplo las imágenes.
• Internal audit: Genera una entrada en el sistema de auditoría interna de Pandora FMS. Este se almacena en la base de datos de Pandora FMS y puede revisarse con el visor de eventos desde la consola.
• Monitoring Event: Crea un evento personalizado en la consola de eventos de Pandora FMS.
• Alertlog: Es una alerta predefinida que escribe las alertas en formato de ASCII plano en el fichero /var/log/pandora/pandora_alert.log .
• SNMP Trap: Envía un trap SNMP parametrizado con los argumentos que se utilicen.
• Syslog: Envía una alerta al registro del sistema por medio del comando del sistema logger.
• Sound Alert: Reproduce un sonido en la consola sonora de eventos cuando ocurre una alerta.
• Jabber Alert: Envía una alerta Jabber a una sala de conversación en un servidor predefinido (primero se debe configurar el fichero .sendxmpprc). Coloque en field1 el alias de usuario, en field2 el nombre de la sala de chat y field3 el mensaje de texto.
• SMS Text: Envía un SMS a un teléfono móvil determinado. Primero es necesario definir una alerta y configurar una gateway de envío de SMS que sea accesible desde el Pandora FMS Server.
• Validate Event: Valida todos los eventos relacionados con un módulo. Se le pasará el nombre del agente y el nombre del módulo.
• Remote agent control: Envía comandos a los agentes con el servidor UDP habilitado. El servidor UDP se utiliza para ordenar a los agentes (MS Windows® y UNIX®) que refresquen la ejecución del agente: es decir, para obligar al agente a ejecutar y enviar datos.
• Generate Notification: Permite enviar una notificación interna a cualquier usuario. Los destinatarios deben ser agregados de memoria y cada usuario borrará su notificación cuando pueda y/o considere conveniente.
• Send report by e-mail y Send report by e-mail (from template): Ambas opciones permiten enviar un informe en distintos formatos (PDF, JSON, CSV) por correo electrónico, la segunda opción permite utilizar una plantilla para dicho informe adjunto.

• Console notification: Permite enviar una notificación por Consola web a cualquier usuario. Los destinatarios disponibles se agregarán de manera interactiva. Las notificaciones aparecerán y desaparecerán según se dispare o recupere la alerta correspondiente. Además, los mensajes serán borrados definitivamente según el token Max. days before delete old messages. Mediante macros preconfiguradas se mostrará información del agente, módulo, etc. Se debe asegurar de que el destinatario tenga derechos de lectura suficientes sobre los elementos alertados.
• API request: Realiza una consulta API mediante una acción de alerta construida en base a este comando. Se necesitarán, en este orden, los siguientes parámetros:

1. URL: Dirección IP o enlace web al servidor API donde se realizará la consulta.
2. Method: Método a utilizar, de una lista de opciones (GET, POST, PUT, PATCH, DELETE), similares a las utilizadas por la API PFMS (excepto PATCH).
3. Headers: Para incluir formato de solicitud (generalmente en formato JSON), token de autorización, etc.
4. Data: La consulta en sí misma y sus parámetros respectivos.
5. SSL: Indica si se utilizará una conexión cifrada para realizar la conexión.

Una solicitud típica incluye código similar a este:

• HEADER:

Authorization: Bearer abc123token; Content-Type: application/json; X-Request-ID: 123456

• DATA:

{'title': 'foo', 'body': 'bar'}

Menú Management → Alerts → Commands → clic sobre el nombre del comando a editar. Una vez se ha modificado la alerta elegida haga clic en el botón Update.

Las acciones son los componentes de las alertas en los que se relaciona un comando con las variables genéricas Field 1, Field 2, … , Field 10.

Las acciones permiten definir el cómo lanzar el comando.

Menú Management → Alerts → Actions → Create.

• Group: El grupo de la acción. Solamente podrá asignar un grupo al cual pertenezca el usuario que está creando el comando de alerta, a menos que dicho usuario pertenezca explícitamente al grupo TODOS (ALL). Si el comando asociado tiene un grupo diferente de All, solo se podrá establecer como grupo de la acción el grupo asociado al comando o el grupo All. Si por alguna razón esto llega a diferir, verá un mensaje de advertencia para su pronta corrección por parte de un usuario que tenga los derechos necesarios.
• Command: Comando que se usará en el caso de que se ejecute la alerta. Se puede elegir entre los diferentes comandos que hay predefinidos en Pandora FMS.
• Threshold: Una acción de alerta se ejecuta solo una vez dentro de este intervalo de tiempo, independientemente de cuántas veces se active la alerta.
• Command Preview: En este campo, no editable, aparecerá automáticamente el comando que se va a ejecutar en el sistema.
• Field 1 ~ Field 10: En caso de ser necesario, en estos campos se define el valor de las macros, de _field1_ a _field10_, que se usarán en el comando. Estos campos pueden ser un campo de texto o un combo de selección si se configura.

• Console notification: Este comando le permite generar una notificación al supervisor cuando se activa una alerta. Utiliza el comando predefinido de alerta Console notification. Al modificar esta acción predefinida se pueden seleccionar los usuarios que serán notificados.
• Create Pandora ITSM ticket: Al tener activada la integración con Pandora ITSM se podrán crear incidencias de manera automática en dicha aplicación.
• Mail to Admin: Utiliza el comando predefinido eMail para enviar mensaje de correo electrónico según se configure en el campo Destination address.
• Monitoring Event: Utiliza el comando del mismo nombre y se pueden configurar los tipos y severidad (disparado y recuperación) de eventos, entre otros detalles.
• Pandora ilert, Pandora Slack, Pandora Telegram, Pandora Vonage: Pandora FMS puede enviar notificaciones, previa configuración, en varias aplicaciones de mensajería instantánea.
• Restart agent: Permite enviar instrucciones (reiniciar por defecto) según comando Remote agent control a los EndPoints PFMS.
• Send Report by e-mail y Send Report by e-mail (from template): Para el envío de informes por correo electrónico. Aquí se podrán configurar los destinatarios, informe como tal (o plantilla) y el formato del mismo (PDF, JSON o CSV).

Menú Management → Alerts → Actions → clic sobre el nombre de la acción a modificar.

Menú Management → Alerts → Actions → clic en icono correspondiente de papelera (columna Delete).

Las plantillas definen las condiciones de disparo de la alerta (cuándo ejecutar la acción). Se asocian a Módulos, de tal manera que en el momento en que se reúnan las condiciones de la plantilla, se ejecutarán la(s) acción(es) asociada(s). Su diseño permite generar un grupo reducido de plantillas genéricas que sirvan para la mayoría de casos posibles en Pandora FMS.

Menú Management → Alerts → Templates → Create.

• Group: El grupo al cual le será aplicada la plantilla. Solamente podrá asignar un grupo al cual pertenezca el usuario que está creando la plantilla , a menos que dicho usuario pertenezca explícitamente al grupo TODOS (ALL).
• Priority: Campo informativo acerca de la alerta. El evento generado al disparar la alerta heredará esta prioridad, útil para filtrar en búsquedas de alertas.

• Use special days list: Establece el calendario de días especiales que se usará en la plantilla.
• Time Threshold: Tiempo que debe transcurrir para reiniciar el contador de alertas. Define el intervalo de tiempo en el cual se garantiza que una alerta no se va a disparar más veces del número establecido en Max. number of alerts. Pasado el intervalo definido se reiniciará el contador. El reinicio del contador de disparos no se reiniciará si la alerta se recupera al llegar un valor correcto, salvo que esté activado el valor Reset counter for non-sustained alerts, en cuyo caso, el contador se reiniciará inmediatamente después de recibir un valor correcto.
• Min number of alerts: Número mínimo de veces que tiene que ocurrir la situación definida en la plantilla (contando siempre a partir del número definido en el parámetro Flip Flop del Módulo) para empezar a disparar una alerta. El valor por defecto es 0, lo que significa que la alerta se disparará cuando llegue el primer valor que cumpla la condición. Funciona como un filtro, útil para ignorar falsos positivos.
• Max number of alerts: Máximo número de alertas que se pueden enviar consecutivamente en el mismo intervalo de tiempo (Time Threshold). Es el valor máximo del contador de alertas. No llegarán más alertas por intervalo de tiempo que las indicadas en este campo.
• Default Action: En esta lista se define la acción por defecto que va a tener la plantilla. Esta es la acción que se creará automáticamente cuando asigne la plantilla al módulo. Coloque una acción o ninguna, sin embargo no puede colocar varias acciones por defecto.
• Schedule: Establece los días en los que la alerta podrá dispararse. Es posible ver y configurar cuándo estará activa la alerta cada día de la semana gracias al editor incorporado que se muestra por defecto en modo simple. Además, accediendo al modo detallado se pueden configurar los horarios con mayor precisión.
• Reset counter for non-sustained alerts: Su activación depende de que el número indicado en Min. number of alerts sea mayor que 0. Al activar este token se reinicia el contador de alertas cuando no se repita la condición indicada de manera consecutiva. Por ejemplo, si el campo Min. number of alerts tiene un valor de 2, significará que el módulo tiene que pasar 3 veces por el estado asignado en Condition type para disparar la alerta. Hay dos escenarios con este último token:
• Si el token de reinicio está marcado será necesario que el número de estados críticos sea consecutivo, de lo contrario el contador se reiniciará.

• Si no se marca el token de reinicio, la alerta se disparará tras una secuencia alternativa o continua de estados críticos:

• Disable event: Marcando este token, el evento generado en la vista de eventos de disparo de alerta no se creará.
• Condition type: Permite especificar el elemento que desencadenará la alerta, como por ejemplo que esté en estado crítico (Critical estatus) o que simplemente sea distinto al estado normal (Not normal status). También se pueden establecer alertas complejas (Complex alerts), por ejemplo que la suma sea exactamente igual a dos en los últimos treinta días:

• Alert recovery: Combo donde puede definir si habilita o no la recuperación de alertas. En el caso de que la recuperación de alerta esté habilitada, cuando el módulo deje de cumplir las condiciones indicadas por la plantilla, se ejecutará la acción asociada con los argumentos especificados por los campos field definidos en esta columna.
• En todas las instancias de los campos field1 … field10 (tanto en la plantilla de alerta, como en el comando y en la acción) se pueden emplear las definidas en la lista de macros.

Una vez se ha completado la configuración finalice haciendo clic en el botón Finish.

Plantillas que vienen creadas por defecto:

1. Critical condition: Configurado con una severidad crítica, un tipo de condición en estado crítico, con acción por defecto el envío de mensaje de correo electrónico al administrador y con recuperación de alerta activada.
2. Manual alert: Esta es una plantilla usada para disparar alertas manuales, la condición definida aquí nunca será ejecutada. Se utiliza esta plantilla para asignar a las acciones y comandos utilizados para hacer la gestión remota (reinicio del EndPoint, ejecutar comandos en el servidor, etcétera).
3. Warning condition: Configurado con una severidad de advertencia, un tipo de condición en estado de advertencia, con acción por defecto el envío de mensaje de correo electrónico al administrador y con recuperación de alerta activada.
4. Unknown condition: Configurado con una severidad de advertencia, un tipo de condición en estado desconocido, con acción por defecto el envío de mensaje de correo electrónico al administrador y con recuperación de alerta activada.
5. Default critical condition: Las cuatro plantillas anteriores pueden ser personalizadas, esta plantilla es de solamente lectura (plantilla de sistema) y es una copia de la plantilla Critical condition. Se incluye así dada la importancia del estado de criticidad.

Menú Management → Alerts → Module Alerts → clic en el icono de lápiz Builder alert.

• Agent: Autocompletado para elegir el Agente.
• Module: Listado de módulos del Agente anteriormente seleccionado.
• Actions: Acción que se ejecutará al disparar la alerta. Si la plantilla ya tiene una acción por defecto puede dejarse en Default.
• Template: Plantilla que contendrá las condiciones de disparo de la alerta.
• Threshold: Una acción de alerta no será ejecutada más de una vez cada action_threshold segundos, a pesar del número de veces que la alerta sea disparada. Este umbral tiene prioridad sobre la configuración del umbral de la acción.

Una vez que se ha creado una alerta, solamente será posible modificar las acciones que se hayan añadido a la acción que tiene la plantilla.

También es posible suprimir la acción que fue seleccionada cuando se creó la alerta haciendo clic en el icono de papelera gris que está a la derecha de la acción, o añadir nuevas acciones haciendo clic en el botón +.

A partir de la versión 781 la acción por defecto solamente es mostrada si es la única existente.

Desde la sección de administración del agente puede añadir nuevas alertas navegando a la solapa correspondiente:

Allí se podrá:

• Editar o borrar todas y cada una de las acciones de cada alerta asignada al agente (columna Actions).
• De la columna de opciones (Op.):

• Podrá deshabilitar o habilitar.
• Podrá colocar la alerta en modo standby .
• Podrá agregar una acción.
• Podrá borrar por completo la alerta.
• Podrá visualizar en detalle la alerta.

• Definir umbral crítico y de advertencia en módulo.
• Asociar la alerta al módulo, para ello vaya a la solapa de alertas dentro del Agente donde está el Módulo.

De ser necesario se puede crear una acción nueva y/o plantilla nueva, al hacer clic en esos botones se redirigirá a las secciones correspondientes. Una vez se haya(n) creado los nuevos componentes, se debe regresar al paso anterior.

• Con el botón Add alert se guarda la nueva alerta.
• Escalado de alertas: Un escalado de alertas son acciones adicionales que se ejecuten si la alerta se repite una cierta cantidad de veces de forma consecutiva.
  • Únicamente se necesita añadir las acciones adicionales y determinar entre cuáles repeticiones consecutivas (Number of matching alerts) de la alerta va a ejecutar esta acción.
  • Cuando una alerta se recupera, todas las acciones que se hayan ejecutado hasta ese momento se volverán a ejecutar, no solo las que correspondan a la configuración de Number of alerts match from actual.
  • De manera adicional se puede colocar un Threshold como segundo parámetro, por el cual no podrá lanzarse una alerta más de una vez durante dicho intervalo.
• Finalmente se puede configurar envío de mensajes de alerta por medio de mensajería instantánea como Telegram, por ejemplo.

Las alertas pueden estar activadas, desactivadas o en modo de espera (standby). La diferencia entre las alertas desactivadas y las que están en standby es que las desactivadas simplemente no funcionarán y por lo tanto no se mostrarán en la vista de alertas. En cambio, las alertas en standby se mostrarán en la vista de alertas y funcionarán pero solamente a nivel de visualización. Esto es, se mostrará si están o no disparadas pero no realizarán las acciones que tengan programadas ni generarán eventos.

Las alertas en standby son útiles para poder visualizarlas sin que molesten en otros aspectos.

La protección en cascada es una característica de Pandora FMS que permite evitar un bombardeo masivo de alertas cuando un grupo de Agentes no es accesible, debido a una conexión principal que falla.

Este tipo de cosas ocurren, por ejemplo, cuando un elemento de la red intermedio como un router o un switch fallan, y deja inaccesible a una gran parte de la red gestionada con Pandora FMS. Debido a que los chequeos de red fallarían en este escenario, comenzarían a dispararse alertas por dispositivos caídos sin ello ser cierto.

Para que funcione el agente con protección en cascada activada debe tener correctamente configurado el Agente padre (Advanced options, token Parent), del cual depende.

La protección en cascada se activa desde la configuración del Agente, sección Advanced options, haga clic en la opción Cascade protection modules y/o Cascade protection services.

La Protección en cascada basada en servicios evita que los elementos de un servicio disparen sus alertas si se dispara la alerta del servicio al que pertenecen.

Para habilitar esta funcionalidad, se debe activar el token Cascade protection services en la configuración avanzada de los agentes a los cuales se necesite el tener este comportamiento, y activar el token Cascade protection enabled en la configuración del servicio al que pertenezcan dichos agentes.

Cuando se dispare la alerta del servicio se podrá enviar en la alerta la información de cuales elementos del servicio están en crítico con la macro _rca_ que indicará la causa raíz del estado del servicio.

Se puede usar el estado de un Módulo de un Agente padre para evitar que envíen alertas del Agente en caso de que pase a estado crítico.

El modo de operación seguro se puede habilitar en las opciones de configuración avanzadas de un Agente.

Si el estado del Módulo seleccionado pasa a critical, el resto de Módulos del Agente se deshabilitan hasta que vuelva a normal o warning de nuevo. Esto permite, por ejemplo, deshabilitar Módulos remotos si se pierde la conectividad.

Estas macros especificas se pueden añadir expandiendo la sección de macros de cualquier módulo.

• Se definen en el Módulo.
• Almacenan los datos en la base de datos.
• Pueden tener cualquier nombre, por ejemplo _myMacro.
• No se reflejan en la configuración local (.conf).
• Se usan exclusivamente para las alertas.
• No se pueden definir a nivel de componente.
• Se pueden definir en las políticas de monitorización.
• Los valores establecidos pueden ser utilizados como parte de los campos en la definición de alertas.

Pandora FMS por sí sola tiene la facultad de enviar correos electrónicos tal como se explica en la configuración general de la Consola. Sin embargo su flexibilidad permite el envío de correo electrónico con diferentes plataformas de correo. Una vez se hayan establecido ambos mecanismos se podrá configurar la acción de envío y crear su alerta.

Menú Management → Alerts → Event Alerts.

Se pueden construir alertas basándose en los eventos recibidos. Estas alertas pueden ser sencillas o complejas, en base a un conjunto de reglas con relaciones lógicas.

Este tipo de alertas permite trabajar desde una perspectiva mucho más flexible, ya que no se generan alertas en función del estado de un Módulo específico, sino sobre un evento que puede haber sido generado por varios Módulos diferentes e incluso de distintos Agentes.

Cada alerta de evento se configura para saltar ante un determinado tipo de evento; cuando se cumple la ecuación lógica definida por las reglas y sus operadores, la alerta se disparará.

Menú Management → Alerts → Event Alerts.

Con el botón Create se agrega una nueva alerta de evento y el proceso es similar a la creación de una plantilla de alerta. Existen cinco pasos para la creación completa de una alerta de evento, algunos aspectos importantes son:

• Paso 1, Configure: Contiene los datos básicos como nombre, grupo de agentes al que pertenecerá la alerta de evento y su severidad.
• Paso 2, Conditions: Paso donde se asignará una plantilla de alerta, una lista de días especiales, la opción Disable event (el evento generado en la vista de eventos de disparo de alerta no se creará si se marca este token) y un modo de evaluación de reglas:

Cuando existen dos o más alertas de eventos se evalúan una a una siguiendo el orden cronológico de creación y, si se necesita, estableciendo una jerarquía.

Cada alerta de evento tiene para ello dos parámetros de configuración específicos:

• Rule evaluation mode: Puede ser Pass o Drop. El primero significa que, en caso de que un evento cumpla con las reglas de una alerta, se sigan evaluando el resto de alertas a continuación. Es el comportamiento por defecto. Drop, de otra manera, significa que cuando un evento cumpla con una alerta, dejen de evaluarse el resto de alertas.
• Grouped by: Permite agrupar las reglas por Agente, Grupo, Módulo o Alerta de módulo. Así, si se configura una regla para que se dispare cuando se reciban dos eventos críticos y se agrupa por Agente, deberán llegar dos eventos críticos de un mismo Agente.

• Paso 3, Rules: Reglas dentro de una alerta de evento.
• Paso 4, Fields: Campos dentro de una alerta de evento
• Paso 5, Triggering: Disparado dentro de una alerta de eventos.

Al finalizar la creación y regresar a la vista global se tendrá la lista de alertas de eventos registradas y la información sobre ellas, además de opciones sobre ellas (operar con la acción deshabilitada, en modo standby, añadir más acciones, editar o eliminar la alerta de evento correspondiente). También se podrá cambiar el orden entre sí de las diferentes alertas de eventos.

Las alertas de eventos se basan en reglas de filtrado que emplean los siguientes operadores lógicos:

• and
• nand
• or
• nor
• xor
• nxor

Estos operadores lógicos sirven para buscar eventos y/o expresiones que coincidan con las reglas de filtrado configuradas y si se encuentran coincidencias se disparará la alerta. Para definir las reglas del alertado será necesario arrastrar los elementos de la parte izquierda al drop area de la parte derecha para construir su regla.

Elementos de configuración disponibles:

Estos elementos se irán habilitando para guiar al usuario en el cumplimiento de la gramática de la regla. A continuación se explica de manera simplificada la gramática a utilizar:

Donde S es el conjunto de reglas definidas para la alerta de evento.

Para limpiar y deshacer todos los cambios se dispone de dos botones: Cleanup y Reset.

Obliga a que el elemento analizado (evento) cumpla simultáneamente A y B.

Obliga a que ambas reglas (A) y (B) se cumplan en la ventana de evaluación. Esto quiere decir que deben existir entradas que satisfagan ambas reglas en los últimos segundos (definido por el parámetro event_window).

Se deben configurar Field2 , Field3, (…) , Fieldn, los cuales se utilizan para transferir la información desde la plantilla a la acción y de la acción al comando, para finalmente utilizarse como parámetros en la ejecución de dicho comando.

Dicha información se transfiere siempre que el paso siguiente no traiga ya información definida en sus campos Fieldn. Es decir, en caso de solapamiento de campos o parámetros, sobrescribe la acción a la plantilla (por ejemplo, si la plantilla tiene definida Field1 y la acción también, el Field1 de la acción sobre escribe la acción de la plantilla).

En esta sección debe configurar las acciones que va a realizar cuando se dispare la alerta e indicar en qué intervalos y cada cuánto tiempo se va a ejecutar dicha acción.

• Actions: Acción que se necesita ejecutar.
• Threshold: Intervalo de tiempo que tiene que pasar para que se vuelva a ejecutar la acción una vez se dispare la alarma.

Una vez seleccionados los parámetros anteriores se pulsa el botón Add y después se puede elegir y visualizar la lista de acciones configuradas (sección Select the desired action and mode to view the Triggering fields for this action).

Las macros que se pueden utilizar dentro de la configuración de una alerta de evento están en la lista de macros.

Menú Management → Alerts → Log Alerts.

Se pueden construir alertas basándose en los logs recibidos. Estas alertas pueden ser sencillas o complejas, en base a un conjunto de reglas con relaciones lógicas.

Este tipo de alertas permite trabajar desde una perspectiva mucho más flexible, ya que no se generan alertas en función del estado de un Módulo específico, sino sobre un log que puede haber sido generado por varios Módulos diferentes e incluso de distintos Agentes.

Cada alerta de log se configura para dispararse ante un determinado tipo de evento; cuando se cumple la ecuación lógica definida por las reglas y sus operadores, la alerta saltará.

Menú Management → Alerts → Log Alerts.

Con el botón Create se agrega una nueva alerta de log y el proceso es similar a la creación de una plantilla de alerta. Existen cinco pasos para la creación completa de una alerta de log, algunos aspectos importantes son:

• Paso 1, Configure: Contiene los datos básicos como el grupo de agentes al que pertenecerá la alerta de log, nombre de la alerta y su severidad.
• Paso 2, Conditions: Paso donde se asignará una plantilla de alerta, alguna lista de días especiales, la opción Disable event (el evento generado en la vista de eventos de disparo de alerta no se creará si se marca este token) y un modo de evaluación de reglas:

Cuando existen dos o más alertas de logs se evalúan una a una siguiendo el orden cronológico de creación y, si se necesita, estableciendo una jerarquía.

Cada alerta de log tiene para ello dos parámetros de configuración específicos:

• Rule evaluation mode: Al elegir Pass significa que, en caso de que un log cumpla con las reglas de una alerta, se sigan evaluando el resto de alertas de log a continuación. Es el comportamiento por defecto. En el caso de elegir Drop, cuando un log cumpla con una alerta se dejarán de evaluar el resto de alertas de log.
• Grouped by: Permite agrupar las reglas por Agente, Grupo, Módulo o Alerta de módulo. Así, si se configura una regla para que se dispare cuando se reciban dos eventos críticos y se agrupa por Agente, deberán llegar dos eventos críticos de un mismo Agente.

• Paso 3, Rules: Reglas dentro de una alerta de log.
• Paso 4, Fields: Campos dentro de una alerta de log
• Paso 5, Triggering: Disparado dentro de una alerta de log.

Al finalizar la creación y regresar a la vista global se tendrá la lista de alertas de logs registradas y la información sobre ellas, además de opciones sobre ellas (operar con la acción deshabilitada, en modo standby, añadir más acciones, editar o eliminar la alerta de log correspondiente). También se podrá cambiar el orden entre sí de las diferentes alertas de logs.

Las alertas de eventos se basan en reglas de filtrado que emplean los siguientes operadores lógicos:

• and
• nand
• or
• nor
• xor
• nxor

Estos operadores lógicos sirven para buscar logs y/o expresiones que coincidan con las reglas de filtrado configuradas y si se encuentran coincidencias se disparará la alerta.

Para definir las reglas del alertado será necesario arrastrar los elementos de la parte izquierda al drop area de la parte derecha para construir su regla.

Elementos de configuración disponibles:

Estos elementos se irán habilitando para guiar al usuario en el cumplimiento de la gramática de la regla. A continuación se explica de manera simplificada la gramática a utilizar:

Donde S es el conjunto de reglas definidas para la alerta de log.

Para limpiar y deshacer todos los cambios se dispone de dos botones: Cleanup y Reset.

Obliga a que el elemento analizado (log) cumpla simultáneamente A y B.

Obliga a que ambas reglas (A) y (B) se cumplan en la ventana de evaluación. Esto quiere decir que deben existir entradas que satisfagan ambas reglas en los últimos segundos (definido por el parámetro log_window).

Se deben configurar Field2 , Field3, (…) , Fieldn, los cuales se utilizan para transferir la información desde la plantilla a la acción y de la acción al comando, para finalmente utilizarse como parámetros en la ejecución de dicho comando.

Dicha información se transfiere siempre que el paso siguiente no traiga ya información definida en sus campos Fieldn. Es decir, en caso de solapamiento de campos o parámetros, sobrescribe la acción a la plantilla (por ejemplo, si la plantilla tiene definida Field1 y la acción también, el Field1 de la acción sobre escribe la acción de la plantilla).

En esta sección debe configurar las acciones que va a realizar cuando se dispare la alerta de log e indicar en qué intervalos y cada cuánto tiempo se va a ejecutar dicha acción.

• Actions: Acción que se necesita ejecutar.
• Threshold: Intervalo de tiempo que tiene que pasar para que se vuelva a ejecutar la acción una vez se dispare la alarma de log.

Una vez seleccionados los parámetros anteriores se pulsa el botón Add y después se puede elegir y visualizar la lista de acciones configuradas (sección Select the desired action and mode to view the Triggering fields for this action).

Las macros que se pueden utilizar dentro de la configuración de una alerta de evento están en la lista de macros.

Estas alertas son evaluadas por el servidor de eventos SIEM en el momento de su generación, por lo que para su correcto funcionamiento se deberá habilitar y configurar la monitorización SIEM.

Menú Management → Alerts → SIEM Alerts.

En esta sección es posible crear, editar y eliminar alertas SIEM. Es necesario el permiso LW para acceder a esta sección.

Estas alertas se basan en el sistema de filtros de las vistas de eventos SIEM, de manera que cualquier evento que fuese mostrado con las condiciones de filtro configuradas serán los que disparen la alerta.

Por ejemplo, si se configura una alerta SIEM con un filtro de eventos críticos, justo antes de que el servidor de eventos SIEM genere uno con esa condición la alerta se disparará.

Las alertas SIEM, igual que el resto de alertas, cuentan con las opciones de configuración globales para su disparo.

Menú Operation → SIEM → Alerts.

En esta sección es posible ver, habilitar/deshabilitar y cambiar el modo standby de las alertas SIEM disponibles en el entorno. Es necesario el permiso LM para acceder a esta sección.

Las Macros de comandos, Macros de acciones y Macros alerta de evento son comunes entre sí con algunas excepciones especificadas en cada descripción:

Nota:

Para la macro _prevdata_ es necesario descomentar la siguiente sección en el fichero de configuración del servidor de Pandora FMS:

# Default texts for some events. The macros _module_ and _data_ are supported.
text_going_down_normal Module '_module_' is going to NORMAL (_data_) with previous data (_prevdata_)
#text_going_up_critical Module '_module_' is going to CRITICAL (_data_)
#text_going_up_warning Module '_module_' is going to WARNING (_data_)
#text_going_down_warning Module '_module_' is going to WARNING (_data_)
#text_going_unknown Module '_module_' is going to UNKNOWN

Se debe reiniciar el proceso del servidor para que se apliquen los nuevos cambios.

Volver al índice de documentación de Pandora FMS