Système d'alertes

Une alerte est la réaction de Pandora FMS à une valeur incorrecte d'un Module. Cette réaction est configurable et peut consister en n'importe quoi qui puisse être déclenché par un script configuré dans le Système d'Exploitation où s'exécute le Pandora FMS Server qui traite le Module, l'Événement ou le Log.

Dans Pandora FMS, les alertes fonctionnent en définissant des conditions de déclenchement, des actions choisies pour cette alerte, et enfin l'exécution de commandes sur le Pandora FMS Server, qui seront chargées de mener à bien les actions configurées.

Il existe plusieurs types d'alertes :

• Alertes simples.
• Alertes sur les événements.
• Alertes sur les traps SNMP.
• Alertes sur les logs.
• Alertes sur les événements de sécurité (SIEM).
• Alertes sur l'inventaire.

Pandora FMS dispose également d'un système de gestion des arrêts de service planifiés ou programmés dans le menu Management → Alerts → Scheduled downtime. Ce système permet de désactiver les alertes pendant les intervalles où il y a un arrêt de service.

• Commandes : Spécifient ce qui sera fait ; ce sera l'exécution réalisée par le Pandora FMS Server lors du déclenchement de l'alerte.
• Actions : Spécifient comment cela sera fait ; ce sont les personnalisations des arguments de la commande.
• Modèles : Spécifient quand cela sera fait ; ils définissent les conditions pour déclencher la ou les actions.

Les modèles et les actions ont une série de champs génériques appelés
Field1 , Field2 , Field3, (…) , Fieldn
qui sont utilisés pour transférer les informations du modèle à l'action et de l'action à la commande, pour finalement être utilisés comme paramètres dans l'exécution de ladite commande.

Ces informations sont transférées tant que l'étape suivante n'apporte pas déjà des informations définies dans ses champs Fieldn. C'est-à-dire qu'en cas de chevauchement de champs ou de paramètres, l'action écrase le modèle (par exemple, si le modèle a défini Field1 et l'action aussi, le Field1 de l'action écrase l'action du modèle).

• Command : Commande qui sera exécutée lors du déclenchement de l'alerte. Il est possible d'utiliser des macros pour remplacer les paramètres configurés dans la déclaration des alertes.
• Group : Cela détermine à quel groupe d'alertes la commande peut être associée. Vous ne pourrez attribuer qu'un groupe auquel appartient l'utilisateur qui crée la commande d'alerte, à moins que cet utilisateur n'appartienne explicitement au groupe TOUS (ALL).
• Field description et Field values :

1. Valeurs de champ disponibles : Une collection de valeurs possibles pour ce champ. Si ce champ est configuré (n'est pas vide), le champ sera une liste de sélection au lieu d'une zone de texte. Cette liste nécessite pour chaque valeur possible une étiquette (l'option visible) et une valeur (l'option envoyée). La syntaxe est la suivante :

   valeur1,étiquette1;valeur2,étiquette2;valeur3,étiquette3;valeurN,étiquetteN

2. Hide : Si le champ contient un mot de passe, l'activation de cette option masque le contenu avec des astérisques.

• Il est possible d'afficher un éditeur de code HTML dans un champ de la commande lors de la création ou de la modification d'une action d'alerte si ce champ de la commande a pour valeur le token spécial _html_editor_.

• eMail : Envoie un e-mail depuis le Pandora FMS Server. Les messages e-mail sont envoyés au format HTML. Il faut tenir compte du fait que le destinataire doit pouvoir accéder aux ressources utilisées dans le modèle, telles que les images.
• Internal audit : Génère une entrée dans le système d'audit interne de Pandora FMS. Celle-ci est stockée dans la base de données de Pandora FMS et peut être consultée avec la visionneuse d'événements depuis la Console web.
• Monitoring Event : Crée un événement personnalisé dans la Console d'événements de Pandora FMS.
• Alertlog : C'est une alerte prédéfinie qui écrit les alertes au format ASCII texte brut dans le fichier
  /var/log/pandora/pandora_alert.log .
• SNMP Trap : Envoie un trap SNMP paramétré avec les arguments utilisés.
• Syslog : Envoie une alerte au journal système via la commande système logger.
• Sound Alert : Joue un son dans la console sonore d'événements lorsqu'une alerte se produit.
• Jabber Alert : Envoie une alerte Jabber à un salon de discussion sur un serveur prédéfini (le fichier .sendxmpprc doit d'abord être configuré). Pour ce faire, l'alias de l'utilisateur est placé dans field1, le nom du salon de chat dans field2 et le message texte dans field3.
• SMS Text : Envoie un SMS à un téléphone mobile spécifique. Il est d'abord nécessaire de définir une alerte et de configurer une gateway d'envoi de SMS accessible depuis le Pandora FMS Server.
• Validate Event : Valide tous les événements liés à un module. Le nom de l'agent et le nom du module lui seront transmis.
• Remote agent control : Envoie des commandes aux agents avec le serveur UDP activé. Le serveur UDP est utilisé pour ordonner aux agents (MS Windows® et UNIX®) de rafraîchir l'exécution de l'agent : c'est-à-dire, de forcer l'agent à s'exécuter et à envoyer des données.
• Generate Notification : Permet d'envoyer une notification interne à n'importe quel utilisateur. Les destinataires doivent être ajoutés de mémoire et chaque utilisateur supprimera sa notification lorsqu'il le pourra et/ou le jugera approprié.
• Send report by e-mail et Send report by e-mail (from template) : Les deux options permettent d'envoyer un rapport dans différents formats (PDF, JSON, CSV) par e-mail, la deuxième option permet d'utiliser un modèle pour ledit rapport joint.

• Console notification : Permet d'envoyer une notification par Console web à n'importe quel utilisateur. Les destinataires disponibles seront ajoutés de manière interactive. Les notifications apparaîtront et disparaîtront selon que l'alerte correspondante est déclenchée ou récupérée. De plus, les messages seront définitivement supprimés en fonction du token Max. days before delete old messages. Des macros préconfigurées permettront d'afficher des informations sur l'agent, le module, etc. Il faut s'assurer que le destinataire dispose de droits de lecture suffisants sur les éléments alertés.
• API request : Effectue une requête API via une action d'alerte construite sur la base de cette commande. Les paramètres suivants seront nécessaires, dans cet ordre :

1. URL : Adresse IP ou lien web vers le serveur API où la requête sera effectuée.
2. Method : Méthode à utiliser, parmi une liste d'options (GET, POST, PUT, PATCH, DELETE), similaires à celles utilisées par l'API PFMS (sauf PATCH).
3. Headers : Pour inclure le format de la requête (généralement au format JSON), le token d'autorisation, etc.
4. Data : La requête elle-même et ses paramètres respectifs.
5. SSL : Indique si une connexion chiffrée sera utilisée pour établir la connexion.

Une requête typique inclut un code similaire à celui-ci :

• HEADER :
  

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

• DATA :
  

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

• eMail (Id. 1).
• Internal Audit (Id. 2).
• Monitoring Event (Id. 3).
• Validate Event (Id. 10).
• Generate Notification (Id. 13).
• Send report by e-mail (Id. 14).
• Send report by e-mail (from template) (Id. 15).
• Pandora ITSM Ticket (Id 16).
• Pandora Telegram (Id 19, enregistrer le token dans la configuration générale).
• RMM Script (Id. 22).
• Console notification (Id. 23).
• API request (Id. 24).

Les actions sont les composants des alertes dans lesquels une commande est liée aux variables génériques :
Field 1, Field 2, … , Field 10.

• Group : Le groupe de l'action. Vous ne pourrez attribuer qu'un groupe auquel appartient l'utilisateur qui crée la commande d'alerte, à moins que cet utilisateur n'appartienne explicitement au groupe TOUS (ALL). Si la commande associée a un groupe différent de All, vous ne pourrez définir comme groupe de l'action que le groupe associé à la commande ou le groupe All. Si, pour une raison quelconque, cela vient à différer, un message d'avertissement s'affichera pour sa correction rapide par un utilisateur disposant des droits nécessaires.
• Command : Commande qui sera utilisée au cas où l'alerte serait exécutée. Vous pouvez choisir parmi les différentes commandes prédéfinies dans Pandora FMS.
• Threshold : Une action d'alerte n'est exécutée qu'une seule fois dans cet intervalle de temps, indépendamment du nombre de fois où l'alerte est activée.
• Command Preview : Dans ce champ, non modifiable, apparaîtra automatiquement la commande qui sera exécutée sur le système.
• Field 1 ~ Field 10 : Si nécessaire, ces champs définissent la valeur des macros (de _field1_ à _field10_) qui seront utilisées dans la commande. Ces champs peuvent être un champ de texte ou une liste de sélection, si configurés ainsi.

• Console notification : Cette commande vous permet de générer une notification au superviseur lorsqu'une alerte est activée. Elle utilise la commande d'alerte prédéfinie Console notification. En modifiant cette action prédéfinie, vous pouvez sélectionner les utilisateurs qui seront notifiés.
• Create Pandora ITSM ticket : L'activation de l'intégration avec Pandora ITSM permet de créer automatiquement des incidents dans cette application.
• Mail to Admin : Utilise la commande prédéfinie eMail pour envoyer un message e-mail tel que configuré dans le champ Destination address.
• Monitoring Event : Utilise la commande du même nom et vous pouvez configurer les types et la sévérité (déclenchement et récupération) des événements, entre autres détails.
• Pandora Goggle chat, Pandora ilert, Pandora MS Teams, Pandora Slack, Pandora Telegram, Pandora Vonage : Pandora FMS peut envoyer des notifications, après configuration, dans plusieurs applications de messagerie instantanée.
• Restart agent : Permet d'envoyer des instructions (redémarrer par défaut) selon la commande
  Remote agent control aux EndPoints PFMS.
• Send Report by e-mail et Send Report by e-mail (from template) : Pour l'envoi de rapports par e-mail. Ici, vous pourrez configurer les destinataires, le rapport en tant que tel (ou le modèle) et son format (PDF, JSON ou CSV).

Menu Management → Alerts → Actions → cliquez sur le nom de l'action à modifier.

Menu Management → Alerts → Actions → cliquez sur l'icône de corbeille correspondante (colonne Delete).

Ils sont associés à des Modules, de telle sorte qu'au moment où les conditions du modèle sont remplies, l'action ou les actions associées seront exécutées. Leur conception permet de générer un groupe réduit de modèles génériques qui servent pour la majorité des cas possibles dans Pandora FMS.

• Group : Le groupe auquel le modèle sera appliqué. Vous ne pourrez attribuer qu'un groupe auquel appartient l'utilisateur qui crée le modèle, à moins que cet utilisateur n'appartienne explicitement au groupe TOUS (ALL).
• Priority : Champ informatif concernant l'alerte. L'événement généré lors du déclenchement de l'alerte héritera de cette priorité, utile pour filtrer dans les recherches d'alertes.

• Use special days list : Définit le calendrier des jours spéciaux qui sera utilisé dans le modèle.
• Time Threshold : Temps qui doit s'écouler pour réinitialiser le compteur d'alertes. Il définit l'intervalle de temps dans lequel il est garanti qu'une alerte ne se déclenchera pas plus de fois que le nombre défini dans Max. number of alerts. Passé l'intervalle défini, le compteur sera réinitialisé. La réinitialisation du compteur de déclenchements ne redémarrera pas si l'alerte récupère à l'arrivée d'une valeur correcte, sauf si la valeur est activée Reset counter for non-sustained alerts, auquel cas le compteur sera réinitialisé immédiatement après la réception d'une valeur correcte.
• Min number of alerts : Nombre minimum de fois où la situation définie dans le modèle doit se produire (en comptant toujours à partir du nombre défini dans le paramètre Flip Flop du Module) pour commencer à déclencher une alerte. La valeur par défaut est 0, ce qui signifie que l'alerte se déclenchera lorsque la première valeur remplissant la condition arrivera. Il fonctionne comme un filtre, utile pour ignorer les faux positifs.
• Max number of alerts : Nombre maximum d'alertes pouvant être envoyées consécutivement dans le même intervalle de temps (Time Threshold). C'est la valeur maximale du compteur d'alertes. Il n'arrivera pas plus d'alertes par intervalle de temps que celles indiquées dans ce champ.
• Default Action : Dans cette liste, l'action par défaut qu'aura le modèle est définie. C'est l'action qui sera créée automatiquement lorsque vous attribuerez le modèle au module. Vous pouvez définir une action ou aucune, cependant vous ne pouvez pas définir plusieurs actions par défaut.
• Schedule : Définit les jours où l'alerte pourra se déclencher. Il est possible de voir et de configurer quand l'alerte sera active chaque jour de la semaine grâce à l'éditeur intégré affiché par défaut en mode simple. De plus, en accédant au mode détaillé, les horaires peuvent être configurés avec une plus grande précision.
• Reset counter for non-sustained alerts : Son activation dépend du fait que le nombre indiqué dans Min. number of alerts soit supérieur à 0. En activant ce token, le compteur d'alertes est réinitialisé lorsque la condition indiquée ne se répète pas consécutivement. Par exemple, si le champ Min. number of alerts a une valeur de 2, cela signifiera que le module doit passer 3 fois par l'état assigné dans Condition type pour déclencher l'alerte. Il y a deux scénarios avec ce dernier token :

1. Si le token de réinitialisation est coché, il sera nécessaire que le nombre d'états critiques soit consécutif, sinon le compteur sera réinitialisé :

   normal → critical → critical → critical

2. Si le token de réinitialisation n'est pas coché, l'alerte se déclenchera après une séquence alternative ou continue d'états critiques :

   normal → critical → normal → critical → normal → critical

• Disable event : En cochant ce token, l'événement généré dans la vue des événements de déclenchement d'alerte ne sera pas créé.
• Condition type : Permet de spécifier l'élément qui déclenchera l'alerte, comme par exemple qu'il soit dans un état critique (Critical status) ou qu'il soit simplement différent de l'état normal (Not normal status). Des alertes complexes (Complex alerts) peuvent également être établies, par exemple que la somme soit exactement égale à deux au cours des trente derniers jours :

• Alert recovery : Liste où l'on peut définir s'il faut activer ou non la récupération des alertes. Dans le cas où la récupération d'alerte est activée, lorsque le module cesse de remplir les conditions indiquées par le modèle, l'action associée sera exécutée avec les arguments spécifiés par les champs field définis dans cette colonne.
• Dans toutes les instances des champs field1 … field10 (tant dans le modèle d'alerte, que dans la commande et l'action), les macros définies dans la liste de macros peuvent être utilisées.

Une fois la configuration terminée, cliquez sur le bouton Finish.

Modèles qui sont créés par défaut lors de l'installation de PFMS :

1. Critical condition : Configuré avec une sévérité critique, un type de condition en état critique, avec pour action par défaut l'envoi d'un message e-mail à l'administrateur et avec la récupération d'alerte activée.
2. Manual alert : Il s'agit d'un modèle utilisé pour déclencher des alertes manuelles, la condition définie ici ne sera jamais exécutée. Ce modèle est utilisé pour attribuer aux actions et commandes utilisées pour effectuer la gestion à distance (redémarrage de l'EndPoint, exécuter des commandes sur le serveur, etc.).
3. Warning condition : Configuré avec une sévérité d'avertissement, un type de condition en état d'avertissement, avec pour action par défaut l'envoi d'un message e-mail à l'administrateur et avec la récupération d'alerte activée.
4. Unknown condition : Configuré avec une sévérité d'avertissement, un type de condition en état inconnu, avec pour action par défaut l'envoi d'un message e-mail à l'administrateur et avec la récupération d'alerte activée.
5. Default critical condition : Les quatre modèles précédents peuvent être personnalisés, ce modèle est en lecture seule (modèle système) et est une copie du modèle Critical condition. Il est inclus ainsi compte tenu de l'importance de l'état de criticité.

• Agent : Remplissage automatique pour choisir l'Agent.
• Module : Liste des modules de l'Agent précédemment sélectionné.
• Actions : Action qui sera exécutée lors du déclenchement de l'alerte. Si le modèle a déjà une action par défaut, il peut être laissé sur Default.
• Template : Modèle qui contiendra les conditions de déclenchement de l'alerte.
• Threshold : Une action d'alerte ne sera pas exécutée plus d'une fois toutes les action_threshold secondes, malgré le nombre de fois où l'alerte est déclenchée. Ce seuil a la priorité sur la configuration du seuil de l'action.

Une fois qu'une alerte a été créée, il ne sera possible de modifier que les actions qui ont été ajoutées à l'action qu'a le modèle.

Il est également possible de supprimer l'action qui a été sélectionnée lors de la création de l'alerte en cliquant sur l'icône de corbeille grise située à droite de l'action, ou d'ajouter de nouvelles actions en cliquant sur le bouton +.

Depuis la section d'administration de l'agent, de nouvelles alertes peuvent être ajoutées en naviguant vers l'onglet correspondant :

Là, vous pourrez :

1. Visualiser l'alerte en détail (colonne Template, icône de loupe ).
2. Éditer ou supprimer toutes et chacune des actions de chaque alerte assignée à l'agent (colonne Actions).
3. Depuis la colonne des options (Op.) :

• Vous pourrez désactiver ou activer.
• Vous pourrez placer l'alerte en mode standby .
• Vous pourrez ajouter une action.
• Vous pourrez supprimer complètement l'alerte (sans message de confirmation).

• Définir le seuil critique et d'avertissement dans le module.
• Associer l'alerte au module, pour cela aller dans l'onglet des alertes au sein de l'Agent où se trouve le Module.

Si nécessaire, vous pouvez créer une nouvelle action et/ou un nouveau modèle, en cliquant sur ces boutons, vous serez redirigé vers les sections correspondantes. Une fois le(s) nouveau(x) composant(s) créé(s), vous devez retourner à l'étape précédente.

• Avec le bouton Add alert, la nouvelle alerte est enregistrée.
• Escalade des alertes : Une escalade d'alertes correspond à des actions supplémentaires qui sont exécutées si l'alerte se répète un certain nombre de fois de manière consécutive.

1. Il suffit d'ajouter les actions supplémentaires et de déterminer entre quelles répétitions consécutives (Number of matching alerts) de l'alerte cette action s'exécutera.
2. Lorsqu'une alerte récupère, toutes les actions qui ont été exécutées jusqu'à ce moment-là s'exécuteront à nouveau, pas seulement celles qui correspondent à la configuration actuelle de Number of alerts match from.
3. De plus, un Threshold peut être placé comme deuxième paramètre, grâce auquel une alerte ne pourra pas se déclencher plus d'une fois pendant cet intervalle.

Enfin, vous pouvez configurer l'envoi de messages d'alerte via une messagerie instantanée telle que Telegram ou toute autre disponible.

Les alertes peuvent être activées ou désactivées ou en mode veille (standby).

En revanche, les alertes en standby s'afficheront dans la vue des alertes et fonctionneront uniquement au niveau de l'affichage. C'est-à-dire qu'elles indiqueront si elles sont déclenchées ou non mais elles n'effectueront pas les actions programmées et ne généreront pas d'événements.

Les alertes en standby sont utiles pour pouvoir les visualiser sans qu'elles interfèrent ou gênent d'autres aspects.

La protection en cascade est une fonctionnalité de Pandora FMS qui permet d'éviter un bombardement massif d'alertes lorsqu'un groupe d'Agents n'est pas accessible, en raison de la défaillance d'une connexion principale.

Ce genre de choses se produit lorsqu'un élément de réseau intermédiaire comme un routeur ou un commutateur tombe en panne, rendant inaccessible une grande partie du réseau géré avec Pandora FMS. Les vérifications du réseau échouant dans ce scénario, des alertes pour des appareils hors ligne commenceraient à se déclencher sans que cela soit vrai.

Pour que l'agent fonctionne avec la protection en cascade activée, il doit avoir son Agent parent correctement configuré (Advanced options, token Parent), dont il dépend.

La protection en cascade est activée à partir du Setup de chaque Agent, section Advanced options, cliquez sur l'option Cascade protection modules et/ou Cascade protection services.

La protection en cascade basée sur les services évite que les éléments d'un service ne déclenchent leurs alertes si l'alerte du service auquel ils appartiennent est déclenchée.

Pour activer cette fonctionnalité, le token Cascade protection services doit être activé dans la configuration avancée des agents nécessitant ce comportement, et le token Cascade protection enabled doit être activé dans la configuration du service auquel ces agents appartiennent.

Lorsque l'alerte de service est déclenchée, les informations sur les éléments du service en état critique peuvent être envoyées dans l'alerte avec la macro _rca_ macro qui indiquera la cause fondamentale de l'état du service.

L'état du Module d'un Agent parent peut être utilisé pour empêcher l'envoi des alertes de l'Agent enfant s'il passe dans un état critique (seule la case Hierarchy & behavior est affichée) :

Le mode d'opération sécurisé peut être activé dans les options de configuration avancée d'un Agent.

Si l'état du Module sélectionné passe à critical, le reste des Modules de l'Agent sont désactivés jusqu'à ce qu'il revienne à normal ou warning à nouveau. Cela permet de désactiver des Modules distants si la connectivité est perdue, entre autres utilisations.

Ces macros spécifiques peuvent être ajoutées en développant la section des macros de n'importe quel module.

• Elles sont définies dans le Module.
• Elles stockent les données dans la base de données.
• Elles peuvent avoir n'importe quel nom, par exemple _myMacro.
• Elles ne sont pas reflétées dans la configuration locale (.conf).
• Elles sont utilisées exclusivement pour les alertes.
• Elles ne peuvent pas être définies au niveau du composant.
• Elles peuvent être définies dans les politiques de supervision.
• Les valeurs établies peuvent être utilisées comme partie des champs dans la définition des alertes.

Pandora FMS possède par lui-même la capacité d'envoyer des e-mails tel qu'expliqué dans la configuration générale de la Console. Cependant, sa flexibilité permet l'envoi d'e-mails avec différentes plateformes de messagerie. Une fois les deux mécanismes établis, il sera possible de configurer l'action d'envoi et de créer son alerte.

Ce type d'alertes permet de travailler selon une perspective beaucoup plus flexible, car les alertes ne sont pas générées en fonction de l'état d'un Module spécifique, mais sur un événement qui peut avoir été généré par plusieurs Modules différents et même de différents Agents.

Chaque alerte d'événement est configurée pour se déclencher face à un type d'événement déterminé ; lorsque l'équation logique définie par les règles et leurs opérateurs est remplie, l'alerte se déclenchera.

Il y a cinq étapes pour la création complète d'une alerte d'événement, certains aspects importants sont :

• Étape 1, Configure : Contient les données de base comme le nom, le groupe d'agents auquel appartiendra l'alerte d'événement et sa sévérité.
• Étape 2, Conditions : Étape où seront assignés un modèle d'alerte, une liste de jours spéciaux, l'option Disable event (l'événement généré dans la vue des événements de déclenchement d'alerte ne sera pas créé si ce token est coché) et un mode d'évaluation des règles :

Chaque alerte d'événement a pour cela deux paramètres de configuration spécifiques :

• Rule evaluation mode : Peut être Pass ou Drop. Le premier signifie que, dans le cas où un événement remplit les règles d'une alerte, le reste des alertes continuera d'être évalué ensuite. C'est le comportement par défaut. Drop, d'un autre côté, signifie que lorsqu'un événement remplit les conditions d'une alerte, l'évaluation du reste des alertes cesse.
• Grouped by : Permet de regrouper les règles par Agent, Groupe, Module ou Alerte de module. Ainsi, si une règle est configurée pour se déclencher à la réception de deux événements critiques et qu'elle est regroupée par Agent, deux événements critiques d'un même Agent devront arriver.

• Étape 3, Rules : Règles dans une alerte d'événement.
• Étape 4, Fields : Champs dans une alerte d'événement
• Étape 5, Triggering : Déclenchement dans une alerte d'événements.

À la fin de la création et en retournant à la vue globale, vous aurez la liste des alertes d'événements enregistrées et les informations à leur sujet, en plus des options les concernant (opérer avec l'action désactivée, en mode standby, ajouter plus d'actions, modifier ou supprimer l'alerte d'événement correspondante). Il sera également possible de changer l'ordre entre les différentes alertes d'événements.

Les alertes d'événements sont basées sur des règles de filtrage qui emploient les opérateurs logiques suivants :

Ces opérateurs logiques servent à rechercher des événements et/ou des expressions qui correspondent aux règles de filtrage configurées et, si des correspondances sont trouvées, l'alerte se déclenchera.

Pour définir les règles de l'alerte, il sera nécessaire de faire glisser les éléments de la partie gauche (Available items) vers la partie droite (Rule definition) pour construire chaque règle :

Ces éléments seront activés pour guider l'utilisateur dans le respect de la grammaire de la règle. Ci-dessous, une explication simplifiée de la grammaire à utiliser :

Où S est l'ensemble des règles définies pour l'alerte d'événement.

Field2 , Field3, (…) , Fieldn doivent être configurés, lesquels sont utilisés pour transférer les informations du modèle à l'action et de l'action à la commande, pour finalement être utilisés comme paramètres dans l'exécution de ladite commande.

Ces informations sont transférées tant que l'étape suivante n'apporte pas déjà des informations définies dans ses champs Fieldn. C'est-à-dire qu'en cas de chevauchement de champs ou de paramètres, l'action écrase le modèle (par exemple, si le modèle a défini Field1 et l'action aussi, le Field1 de l'action écrase l'action du modèle).

Dans cette section, vous devez configurer les actions qui seront réalisées lors du déclenchement de l'alerte et indiquer à quels intervalles et à quelle fréquence ladite action ou actions seront exécutées.

• Actions : Action qui doit être exécutée.
• Threshold : Intervalle de temps qui doit s'écouler pour que l'action soit de nouveau exécutée une fois l'alarme déclenchée.

Une fois les paramètres précédents sélectionnés, on appuie sur le bouton Add puis on peut choisir et visualiser la liste des actions configurées (section Select the desired action and mode to view the Triggering fields for this action).

Les macros qui peuvent être utilisées dans la configuration d'une alerte d'événement se trouvent dans la liste de macros.

Ce type d'alertes permet de travailler selon une perspective beaucoup plus flexible, car les alertes ne sont pas générées en fonction de l'état d'un Module spécifique, mais sur un log qui peut avoir été généré par plusieurs Modules différents et même de différents Agents.

Chaque alerte de log est configurée pour se déclencher face à un type d'événement déterminé ; lorsque l'équation logique définie par les règles et leurs opérateurs est remplie, l'alerte sera exécutée.

Il y a cinq étapes pour la création complète d'une alerte de log, certains aspects importants sont :

• Étape 1, Configure : Contient les données de base comme le groupe d'agents auquel appartiendra l'alerte de log, le nom de l'alerte et sa sévérité.
• Étape 2, Conditions : Étape où seront assignés un modèle d'alerte, une liste de jours spéciaux, l'option Disable event (l'événement généré dans la vue des événements de déclenchement d'alerte ne sera pas créé si ce token est coché) et un mode d'évaluation des règles :

Lorsqu'il existe deux alertes de logs ou plus, elles sont évaluées une par une en suivant l'ordre chronologique de création et, si nécessaire, en établissant une hiérarchie.

Chaque alerte de log a pour cela deux paramètres de configuration spécifiques :

• Rule evaluation mode : Choisir Pass signifie que, dans le cas où un log remplit les règles d'une alerte, le reste des alertes de log continuera d'être évalué ensuite. C'est le comportement par défaut. Dans le cas où vous choisissez Drop, lorsqu'un log remplit les conditions d'une alerte, l'évaluation du reste des alertes de log cessera.
• Grouped by : Permet de regrouper les règles par Agent, Groupe, Module ou Alerte de module. Ainsi, si une règle est configurée pour se déclencher à la réception de deux événements critiques et qu'elle est regroupée par Agent, deux événements critiques d'un même Agent devront arriver.

• Étape 3, Rules : Règles dans une alerte de log.
• Étape 4, Fields : Champs dans une alerte de log
• Étape 5, Triggering : Déclenchement dans une alerte de log.

À la fin de la création et en retournant à la vue globale, vous aurez la liste des alertes de logs enregistrées et les informations à leur sujet, en plus des options les concernant (opérer avec l'action désactivée, en mode standby, ajouter plus d'actions, modifier ou supprimer l'alerte de log correspondante). Il sera également possible de changer l'ordre entre les différentes alertes de logs.

Les alertes de logs sont basées sur des règles de filtrage qui emploient les opérateurs logiques suivants :

Ces opérateurs logiques servent à rechercher des logs et/ou des expressions qui correspondent aux règles de filtrage configurées et, si des correspondances sont trouvées, l'alerte se déclenchera.

Pour définir les règles de l'alerte, il sera nécessaire de faire glisser les éléments de la partie gauche vers la partie droite pour construire chaque règle.

Une règle d'alerte de log prédéfinie est affichée (Kernel Panic) :

Ci-dessous, une explication simplifiée de la grammaire à utiliser :

Où S est l'ensemble des règles définies pour l'alerte de log.

Field2 , Field3, (…) , Fieldn doivent être configurés, lesquels sont utilisés pour transférer les informations du modèle à l'action et de l'action à la commande, pour finalement être utilisés comme paramètres dans l'exécution de ladite commande.

Ces informations sont transférées tant que l'étape suivante n'apporte pas déjà des informations définies dans ses champs Fieldn.
C'est-à-dire qu'en cas de chevauchement de champs ou de paramètres, l'action écrase le modèle (par exemple, si le modèle a défini Field1 et l'action aussi, le Field1 de l'action écrase l'action du modèle).

Ici, vous devez configurer les actions qui seront réalisées lors du déclenchement de l'alerte de log et indiquer à quels intervalles et à quelle fréquence ladite action sera exécutée.

• Actions : L'action qui doit être exécutée.
• Threshold : Intervalle de temps qui doit s'écouler pour que l'action soit de nouveau exécutée une fois l'alarme de log déclenchée.

Une fois les paramètres précédents sélectionnés, on appuie sur le bouton Add puis on peut choisir et visualiser la liste des actions configurées (section Select the desired action and mode to view the Triggering fields for this action).

Les macros qui peuvent être utilisées dans la configuration d'une alerte d'événement se trouvent dans la liste de macros.

Ces alertes sont évaluées par le serveur d'événements SIEM au moment de leur génération, donc pour leur bon fonctionnement, la supervision SIEM devra être activée et configurée.

Ces alertes sont basées sur le système de filtres des vues d'événements SIEM, de sorte que tout événement qui serait affiché avec les conditions de filtre configurées sera celui qui déclenchera l'alerte.

Par exemple, si une alerte SIEM est configurée avec un filtre d'événements critiques, juste avant que le serveur d'événements SIEM n'en génère un avec cette condition, l'alerte se déclenchera.

Les alertes SIEM, comme le reste des alertes, disposent d'options de configuration globales pour leur déclenchement.

Les Macros de commandes, les Macros d'actions et les Macros d'alerte d'événement sont communes entre elles avec quelques exceptions spécifiées dans chaque description :

Note :

Pour la macro _prevdata_, il est nécessaire de décommenter la section suivante dans le fichier de configuration du serveur de Pandora FMS :

Le processus du serveur doit être redémarré pour que les nouveaux changements soient appliqués.

←Retour à l'index de la documentation de Pandora FMS