====== Supervision SIEM ====== {{indexmenu_n>21}} ===== Introduction ===== L'acronyme **SIEM** signifie //Security Information and Event Management// (gestion des informations et des événements de sécurité). Un SIEM décrit les fonctionnalités de surveillance de la sécurité par la collecte, le filtrage, la normalisation, la corrélation et la visualisation des événements de sécurité. Il combine la gestion des informations de sécurité (**SIM**) et la gestion des événements de sécurité (**SEM**). Un SIEM gère les événements de sécurité, qui peuvent provenir d'un //log// ordinaire (par exemple //logs// d'un Apache), du //log// d'un outil de sécurité spécifique (//logs// d'un //firewall//, IDS, //honeypot//, EDR, et cætera) ou d'événements enrichis provenant d'un autre outil (un autre SIEM). ===== Comment cela fonctionne-t-il? ===== **Pandora FMS SIEM** est responsable du traitement des entrées //logs// obtenues par [[:fr:documentation:pandorafms:monitoring:09_log_monitoring|votre collection]], de la normalisation des données et de la génération d'événements de sécurité basés sur ces entrées. Comme pour la collecte //logs//, les **événements SIEM** générés sont stockés dans OpenSearch®, donc la première condition pour que cette surveillance fonctionne est d'avoir une [[:fr:documentation:pandorafms:technical_annexes:38_opensearch_installation|Installation OpenSearch]]. Pandora FMS SIEM génère les événements de sécurité à l'aide de deux composants dans le serveur, de sorte que les événements sont également générés en deux étapes: * **Normalisation des données**: Toutes les entrées de la collection //logs// sont décodées, générant de nouvelles entrées //logs// normalisées qui sont stockées temporairement. * **Génération d'événements**: La conformité des //logs// normalisés à un ensemble de règles est vérifiée, auquel cas un événement SIEM est produit avec toutes les informations relatives aux règles et le //log// normalisé à l'origine de l'événement. Le flux complet de la surveillance SIEM est donc le suivant: * Les agents, //plugins// et autres sources d'information surveillent ou génèrent des //logs// qui sont envoyés au ''dataserver'' ou au ''syslogserver''. * Le ''dataserver'' et le ''syslogserver'' se chargent de traiter ces entrées //logs// et de les stocker sur le serveur OpenSearch configuré pour la collecte des //logs//. * ''siemserver'' décode tous les //logs// obtenus par la collecte des //logs// pour générer des //logs// normalisés sur le serveur OpenSearch configuré pour la surveillance SIEM. Ces //logs// normalisés sont stockés temporairement. * ''siemevents'' traite chacun des //logs// normalisés et s'ils répondent à un ensemble de règles prédéfinies, des événements SIEM sont générés et stockés sur le serveur OpenSearch configuré pour la surveillance SIEM. Avec les événements générés, il est possible de les consulter pour leur fonctionnement à partir de la console Pandora FMS. ===== Configuration de la Console ===== Pour utiliser la surveillance des événements SIEM, il faut d'abord l'activer à partir de la configuration principale. Menu **Management → Settings → System Settings → SIEM → Activate SIEM**,remplissez complètement le formulaire et cliquez sur **Update** pour enregistrer les modifications. Cela créera les modèles nécessaires sur le serveur OpenSearch spécifié pour la normalisation des //logs// et la génération d'événements SIEM. Il activera également ce type de surveillance dans les serveurs Pandora FMS où ''siemserver'' et ''siemevents'' ont été lancés. ===== Configuration du serveur ===== Pour effectuer la surveillance des événements SIEM, il est nécessaire d'activer les serveurs ''siemserver'' et ''siemevents'' dans la [[:fr:documentation:pandorafms:installation/04_configuration#siemserver|configuration du serveur]]. Pour décoder et normaliser les entrées de la collection //logs//, il sera nécessaire de disposer de fichiers de décodage XML qui établissent la manière d'obtenir les informations nécessaires dans chaque cas (ci-après, "decoders"). Ces fichiers XML seront situés dans le chemin indiqué par le paramètre ''siem_decoders'' de la configuration du serveur, par défaut dans: /usr/share/pandora_server/util/siem/decoders Afin de générer des événements SIEM, il sera nécessaire de disposer de fichiers XML de règles qui établissent les conditions pour générer un événement sur la base des informations obtenues dans les //logs// standardisés (ci-après, "rules"). Ces fichiers XML seront situés dans le chemin indiqué par le paramètre ''siem_events_rules'' de la configuration du serveur, par défaut dans: /usr/share/pandora_server/util/siem/rules Les fichiers XML //decoders// et //rules// de Wazuh® sont compatibles avec la surveillance SIEM de Pandora FMS. ===== Configuration des agents ===== La majeure partie de la collecte des //logs// est effectuée par les agents du logiciel Pandora FMS. Ces agents, tant dans les systèmes GNU/Linux® que MS Windows®, disposent de types de modules spécifiques pour effectuer cette tâche. La surveillance SIEM dépend fortement du type de //log// collecté, il sera donc nécessaire de spécifier ''module_source_type'' dans les modules de collecte //logs// pour indiquer ce type. Le type est utilisé par les //decoders// et les //rules//, il convient donc de consulter les //decoders// et les //rules// actifs pour savoir quel type indiquer dans chaque //log//. Les types //logs// les plus couramment utilisés sont les suivants: * syslog * ids * web-log * squid * windows * host-information * ossec ==== Agents Linux ==== La collecte des //logs// sur les systèmes Linux se fait principalement par la lecture des fichiers //log//. Ceci peut être réalisé en utilisant des configurations de modules avec cette structure minimale: module_begin module_name module_type log module_regexp module_pattern module_source_type module_end Par exemple, pour collecter toutes les entrées de connexion //log// d'un serveur Apache: module_begin module_name apache module_type log module_regexp /var/log/httpd/access_log module_pattern .* module_source_type web-log module_end Les entrées collectées à partir d'un //log// comme ci-dessus seraient normalisées par des //decoders// tels que ''web-accesslog'', ''web-accesslog-ip'' ou ''web-accesslog-domain'', entre autres. Les //logs// décodés d'un //log// comme ci-dessus pourraient générer des événements tels que ''Common\_web\_attack'', ''XSS\_(Cross\_Site\_Scripting) attempt'' ou ''SQL\_injection\_attempt'' entre autres. ==== Agents MS Windows® ==== Sous MS Windows®, la collecte des //logs// se fait principalement en surveillant les événements du système, bien qu'elle puisse également se faire en lisant les fichiers //log// comme sur les systèmes Linux. En utilisant le système d'événements Windows, ces //logs// peuvent être collectés en utilisant des configurations de modules avec l'une des deux configurations minimales. Dans le cas d'événements de type **Application**, **System** ou **Security**: module_begin module_name module_type log module_logevent module_source module_source_type module_end Ou s'il s'agit d'événements sur un autre canal: module_begin module_name module_type log module_logchannel module_source module_source_type module_end Par exemple, pour collecter toutes les entrées d'événements de l'application **Security** et **Windows Defender**: module_begin module_name Windows_LogEvents_System module_type log module_logevent module_source Security module_source_type ossec module_end module_begin module_name Windows_LogchannelEvents_WindowsDefender module_type log module_logchannel module_source Microsoft-Windows-Windows Defender/Operational module_source_type ossec module_end Les données recueillies à l'occasion d'événements tels que ceux mentionnés ci-dessus sont normalisées par //decoders// como ''windows_eventchannel''. Les //logs// décodés d'événements tels que ceux mentionnés ci-dessus pourraient générer des événements tels que ''Windows\_error\_event'', ''Short-time\_multiple\_Windows\_Defender\_warning events'' ou ''Multiple\_Windows\_Defender\_error\_events'' entre autres. En utilisant la surveillance du fichier //log//, la configuration est identique à celle des systèmes Linux. Une configuration minimale comme celle-ci est nécessaire: module_begin module_name module_type log module_regexp module_pattern module_source_type module_end Par exemple, pour collecter toutes les entrées de journal d'un serveur X: module_begin module_name xserver module_type log module_regexp C:\server\logs\xserver.log module_pattern .* module_source_type xserver module_end ===== Événements SIEM ===== Lorsque la surveillance SIEM est activée et configurée, un aperçu de l'état de la surveillance est accessible dans le menu **Operation → SIEM → Dashboard**. {{ :wiki:siem_dashboard.png }} Les événements SIEM générés peuvent être consultés dans leur intégralité dans le menu **Operation → SIEM → Events**. {{ :wiki:siem_events.png }} Chaque événement SIEM dispose d'une fenêtre de détails sur l'événement SIEM, affichant des informations sur le //log// normalisé et la règle qui a généré l'événement. {{ :wiki:siem_event_details.png }} En fonction des //decoders// qui ont normalisé le //log//, l'événement aura un onglet **Dynamic fields** avec des informations utiles sur le //log//. {{ :wiki:siem_event_fields.png }} En fonction de la règle qui a généré l'événement, des onglets **MITRE ATT&CKS®** et **SIEM groups** contiennent des informations utiles sur l'impact de l'événement. {{ :wiki:siem_mitre_event.png }} {{ :wiki:siem_event_groups.png }} Les informations présentées dans le Dashboard general et dans le tableau des événements peuvent être incluses dans les [[:fr:documentation:pandorafms:management_and_operation:09_dashboard|Pandora FMS Dashboards]] à travers les //widgets// de SIEM inclus. ===== Decoders ===== Pandora FMS inclut par défaut une série de //decoders// pour la surveillance SIEM, mais tout administrateur peut inclure ses propres //decoders//. ==== Gestion ==== Pour inclure de nouveaux //decoders//, vous devez d'abord ajouter ou éditer un fichier XML dans le chemin indiqué au **Pandora FMS server** dans son paramètre de configuration ''siem_decoders''. Les //décodeurs// sont chargés dans l'environnement via des fichiers XML que le serveur **Pandora FMS master** lit à chaque démarrage du service. Une fois que les //décodeurs// sont chargés, leur configuration est stockée dans la base de données, et chaque ''siemserver'' les traite pour les entrées obtenues en collectant les //logs//. A partir de la console Pandora FMS, il sera possible de visualiser les //decoders// chargés avec leur configuration complète à partir du menu **Operation → SIEM → Decoders**. Il est également possible de désactiver les //decoders// de cette vue, afin que ''siemserver'' ne les prenne pas en compte lors de la normalisation des entrées //log//. Tous les //decoders// sont entièrement chargés à chaque redémarrage. Cela signifie que les //decoders// qui n'ont pas pu être lus à partir des fichiers XML ne seront pas disponibles (même s'ils l'ont été à un moment donné), et que les //decoders// qui ont été désactivés à partir de la console seront réactivés (s'ils existent). ==== Syntaxe ==== Les //decoders// sont configurés et chargés dans Pandora FMS avec des fichiers XML. Ces fichiers peuvent avoir la syntaxe valide suivante: VarValue DecoderName REGEXP EventType REGEXP REGEXP REGEXP REGEXP REGEXP REGEXP Field1, Field2.Sub1, Field2.Sub2 string|discard * ''var'': Utilisé pour indiquer les variables avec leurs valeurs, pour une utilisation ultérieure dans XML (''$VarName''). * ''decoder'': Il s'agit de l'information sur le //decoder//, avec son nom. Un seul fichier XML peut contenir plusieurs //decoders//. - ''name'': C'est le nom du //decoder//. Plusieurs //decoders// peuvent avoir le même nom, et tous sont évalués. - ''discard'': Avec une valeur ''yes'' ou ''no'', permet aux //logs// d'être écartés de l'évaluation des //decoders// s'ils correspondent à celui-ci. Les //decoders// avec ''discard="yes"'' sont évalués avant les autres (tant qu'ils n'ont pas de //decoder// //parent//). ---- * ''parent'': Spécifie le nom du //decoder// parent pour générer une structure hiérarchique. * ''program_name'': Le nom du programme à trouver dans les en-têtes //log// ou dans le ''source_id'' //log//. - ''type'': Permet de spécifier le type d'expression régulière. S'il n'est pas spécifié, **OS Regex** est utilisé. ---- * ''type'': Le type de //logs// pour lequel le //decoder// doit être comparé. Il doit correspondre au ''type'' du //log//. * ''prematch'': Si le contenu de //log// correspond, il génère un //log// normalisé. - ''type'': Permet de spécifier le type d'expression régulière. S'il n'est pas spécifié, **OS Regex** est utilisé. ---- * ''regex'': Les groupes capturés avec cette expression régulière sont des informations normalisées pour //log//. - ''type'': Permet de spécifier le type d'expression régulière. S'il n'est pas spécifié, **OS Regex** est utilisé. ---- * ''order'': Les valeurs capturées par les expressions rationnelles sont stockées dans ces noms de champs, dans l'ordre des groupes de capture. * ''json_null_field'': Les valeurs nulles dans les groupes de capture sont stockées sous forme de //chaîne// vide ou rejetées. * ''offset'': Utilisé pour indiquer l'ordre dans lequel les vérifications sont effectuées et pour écarter du contenu de //log// pour les vérifications suivantes le texte correspondant à l'expression régulière : ''after_parent'', ''after_regex'', ''after_prematch''. Par exemple: ^\d\d\d\d/\d\d/\d\d \d\d:\d\d:\d\d (\w):(\d+) srcip,srcport Il vérifiera que le texte //log// correspond à l'expression régulière ''^\d\d\d\d/\d\d/\d\d \d\d:\d\d:\d\d '', écartera ce contenu du texte et, lors de l'évaluation de l'expression régulière ''regex'', il capturera ce qui est approprié. Dans l'exemple, je supprimerais une date du texte lors de l'évaluation pour simplifier les groupes de capture. ===== Rules ===== Pandora FMS inclut par défaut une série de //rules// pour la surveillance SIEM, mais tout administrateur peut inclure ses propres //rules//. ==== Gestion ==== Pour inclure de nouvelles //rules//, vous devez d'abord ajouter ou éditer un fichier XML dans le chemin indiqué au serveur Pandora FMS dans son paramètre de configuration ''siem_rules''. Les //rules// sont chargées dans l'environnement via des fichiers XML que le serveur **Pandora FMS master** lit à chaque démarrage du service. Une fois que les //rules// sont chargées, leur configuration est stockée dans la base de données, et chaque serveur ''siemevents'' les traite pour les entrées de surveillance SIEM normalisées. Depuis la console du Pandora FMS, il sera possible de visualiser les //rules// chargées avec leur configuration complète à partir du menu **Operation → SIEM → Rules**. Il est également possible de désactiver //rules// de cette vue, afin que ''siemevents'' ne les prenne pas en compte lors du traitement des //logs// normalisés. Toutes les //rules// sont entièrement chargées à chaque redémarrage. Cela signifie que les //rules// qui n'ont pas pu être lues à partir des fichiers XML ne seront pas disponibles (même si elles l'ont été à un moment donné). Contrairement aux //decoders//, les //rules// ont un identifiant qui leur permet d'être désactivées à chaque rechargement. Les //rules// qui n'ont pas pu être lues à partir des fichiers XML seront marquées dans la console comme "non actives" et ne seront pas prises en compte lors de la génération d'événements SIEM. Les //rules// qui ont été désactivées manuellement par un administrateur ne seront pas non plus prises en compte. Par conséquent, pour que les //rules// soient évaluées, elles doivent être actives et activées. ===== Classification ===== Les //rules// sont classées en plusieurs niveaux, allant du plus bas (''0'') au plus haut (''15''). Le tableau suivant décrit chaque niveau et fournit des informations sur la gravité de chaque événement généré par la surveillance SIEM. ^Niveau ^Titre ^Description^ |0 |Ignoré. |Aucune action n'est entreprise. Utilisé pour éviter les faux positifs. Ces règles sont analysées avant toutes les autres règles, incluent les événements sans rapport avec la sécurité et n'apparaissent pas dans le volet des événements de sécurité.| |2 |Notification système de faible priorité. |Notifications système ou messages d'état. Ils n'ont aucune incidence sur la sécurité et n'apparaissent pas dans le panneau des événements de sécurité.| |3 |Événements réussis/autorisés. |Il s'agit des tentatives de connexion réussies, des événements autorisés par le //firewall//, et cetera.| |4 |Erreur de faible priorité du système. |Erreurs liées à des configurations erronées ou à des dispositifs/applications inutilisés. Ces erreurs n'ont aucune incidence sur la sécurité et sont généralement dues à des installations par défaut ou à des tests de logiciels.| |5 |Erreurs générées par l'utilisateur. |Il s'agit notamment des mots de passe oubliés, des actions refusées, et cetera. En soi, ils n'ont pas d'importance pour la sécurité.| |6 |Attaque de faible importance. |Il s'agit d'un ver ou d'un virus qui n'a aucun effet sur le système (comme le code rouge pour les serveurs Apache, etc.). Cela inclut également les événements fréquents du //Intrusion Detection System// (**IDS**) et les erreurs fréquentes.| |7 |Correspondance des "mauvais mots". |Il s'agit de mots tels que "mauvais", "erreur", et cetera. La plupart de ces événements ne sont pas classifiés et peuvent avoir une certaine importance du point de vue de la sécurité.| |8 |Première consultation. |Inclure les événements consultés pour la première fois. La première fois qu'un événement **IDS** est déclenché ou la première fois qu'un utilisateur se connecte. Il comprend également les actions relatives à la sécurité, telles que l'activation d'un //sniffer// ou d'autres activités similaires.| |9 |Erreur de source invalide. |Inclut les tentatives de connexion en tant qu'utilisateur inconnu ou à partir d'une source non valide. Peut avoir une incidence sur la sécurité (surtout si elle est répétée). Cela inclut également les erreurs liées au compte "admin" (//root//).| |10 |Plusieurs erreurs générées par l'utilisateur. |Il peut s'agir de plusieurs mots de passe incorrects, de plusieurs échecs de connexion, etc. Cela peut indiquer une attaque ou simplement le fait qu'un utilisateur a oublié ses informations d'identification.| |11 |Avertissements de contrôle d'intégrité. |Il s'agit notamment de messages relatifs à la modification de binaires ou à la présence de //rootkits// (pour //Rootcheck//). Ces messages peuvent indiquer une attaque réussie. Sont également inclus les événements **IDS** qui seront ignorés (grand nombre de répétitions).| |12 |Événement de grande importance. |Il s'agit de messages d'erreur ou d'avertissement provenant du système, du noyau, et cetera. Ils peuvent indiquer une attaque contre une application spécifique.| |13 |Erreur inhabituelle (importance élevée). |Correspond à un schéma d'attaque courant la plupart du temps.| |14 |Événement de sécurité de grande importance. |Il est le plus souvent déclenché par corrélation et indique une attaque.| |15 |Attaque sévère. |Possibilité de faux positifs. Une attention immédiate est nécessaire.| En fonction de ces niveaux, les événements auront une gravité spécifique qui sera affichée dans la Console: * **Informational**: Niveaux 0 à 6. * **Normal**: Niveaux 7 à 8. * **Warning**: Niveaux 9 à 11. * **Critical**: Niveaux 12 à 15. ==== Syntaxe ==== VarValue N GROUP Field1 Field2.Sub1 Field1 Field2.Sub1 TEXT RREGEXP RREGEXP RREGEXP RREGEXP DecoderName EventType REGEXP REGEXP REGEXP DAYS PARENT1, PARENT2 GROUP N TEXT|LINK|CVE GROUP1,GROUP2, MITRE_ID MITRE_ID * ''var'': Utilisé pour indiquer les variables avec leurs valeurs, pour une utilisation ultérieure dans XML (''$VarName''). * ''group'': Permet de regrouper des règles. Il est également utilisé pour les conditions des mêmes règles. * ''rule'': Il s'agit de l'information contenue dans la règle : - ''id'': Identifiant de la règle. Il doit être unique (à moins qu'une autre règle ne soit écrasée). - ''level'': Niveau de l'événement lorsqu'il est généré (''0'' à ''15''). Les règles de niveau ''0'' ne génèrent pas d'événement. - ''frequency'': Nombre de fois qu'une simultanéité doit se produire pour générer un événement. La fréquence indiquée dans les règles est vérifiée pour les //logs// du même agent, et non pour n'importe quel //log//. - ''timeframe'': Fenêtre temporelle dans laquelle les concordances doivent être données (secondes). - ''ignore'': Cette règle remet à zéro les compteurs de ''frequency'' après ces secondes. - ''overwrite'': Avec une valeur ''yes'' ou ''no'', elle permet d'écraser la configuration d'une règle avec le même ID. Si avec ''overwrite="yes"'' la règle a ''level="0"'', elle est évaluée avant toute autre règle et en cas de correspondance avec le //log//, elle écarte l'évaluation du reste des règles pour ce //log//. ---- * ''if_matched_sid'': La règle est satisfaite si une autre règle avec l'ID indiqué a déclenché une alerte les fois indiquées par ''frequency'' dans le ''timeframe''. * ''if_matched_group'': Comme ''if_matched_sid'' mais pour les groupes. * ''same_id'': Les devises ayant le même numéro d'identification doivent être indiquées. * ''different_id'': Les devises ayant des identifiants différents doivent être indiquées. * ''same_field'': Il doit y avoir des concomitances avec les mêmes valeurs dans le champ. * ''different_field'': Les concomitances doivent se produire avec des valeurs différentes dans le champ. * ''description'': Le texte de l'événement à générer. * ''match'': Si le contenu de //log// correspond, un événement SIEM est généré. - ''type'': Permet de spécifier le type d'expression régulière. S'il n'est pas spécifié, **OS Regex** est utilisé. - ''negate'': Avec une valeur de ''yes'', il permet de refuser la correspondance. ---- * ''regex'': Identique à ''match''. - ''type'': Permet de spécifier le type d'expression régulière. S'il n'est pas spécifié, **OS Regex** est utilisé. - ''negate'': Avec une valeur de ''yes'', il permet d'annuler l'expression régulière. ---- * ''decoded_as'': La règle est satisfaite si le //log// a été décodé par le //decoder// spécifié. * ''category'': La règle est satisfaite si le type du //decoder// correspond. * ''field'': Si le champ indiqué correspond à la valeur, il est conforme à la règle. - ''negate'': La valeur ''oui'' permet de refuser la correspondance avec le champ. ---- * ''program_name'': Si l'origine de //log// correspond, la règle est respectée. - ''negate'': Avec une valeur de ''oui'', il permet de refuser les correspondances avec l'origine //log//. ---- * ''time'': Si l'événement est généré dans l'intervalle de temps indiqué, la règle correspond. * ''weekday'': Si l'événement est généré ces jours-là, la règle est conforme aux dispositions suivantes (''monday - sunday'', ''weekdays'', ''weekends''). * ''if_sid'': La règle est satisfaite si l'une des règles parentes est satisfaite. * ''if_group'': La règle est satisfaite si l'enregistrement satisfait à toute autre règle du groupe spécifié. * ''if_level'': La règle est satisfaite si une autre règle de même niveau a été satisfaite. * ''info'': Informations supplémentaires sur l'événement généré. * ''group'': Liste des groupes dans la règle. * ''mitre'': Liste des ID MITRE de la règle. Les variables peuvent être utilisées dans la description et dans ''info'' avec les valeurs des champs personnalisés, par exemple : ''$(Field1)'', ''$(Field2.Sub1)'', ''$(Field2.Sub2)''. ===== Expressions régulières ===== Les expressions régulières sont des séquences de caractères qui définissent un motif. Il existe deux types d'expressions régulières valables pour les //decoders// et les //rules//: [[#os_regex|OS Regex]] y [[#PCRE2|PCRE2]]. ==== OS Regex ==== Il s'agit d'expressions régulières simples basées sur une bibliothèque en langage C. Elle est conçue pour être simple tout en prenant en charge les expressions régulières les plus courantes. === Expressions acceptées === ^Expression ^Caractères valides^ |''\w'' |A-Z, a-z, 0-9, '-', '@', '_'| |''\d'' |0-9| |''\s'' |Espaces " "| |''\t'' |Tabulation| |''\p'' |()*+,-.:;<=>?[]!"'#$%&|{}| |''\W'' |Tout ce qui n'est pas \w| |''\D'' |Tout ce qui n'est pas \d| |''\S'' |Tout ce qui n'est pas \s| |''\.'' |Tout ce qui| === Modificateurs === ^Expression ^Comportement^ |''+'' |Faire correspondre une ou plusieurs fois| |''*'' |Pour correspondre à zéro ou plusieurs fois| === Caractères spéciaux === ^Expression ^Comportement^ |''^'' |Pour spécifier le début du texte| |''$'' |Pour spécifier la fin du texte| |''|'' |Pour créer un motif logique "ou" entre plusieurs motifs| === Caractères échappés === Pour utiliser les caractères suivants, vous devez les échapper avec ''\'': ^ $ ^ ( ^ ) ^ \ ^ | ^ < ^ | \$ | \( | \) | \\ | \| | \< | === Limites === * Les modificateurs ''*'' et ''+'' ne peuvent être appliqués qu'aux expressions avec barre oblique inverse, et non aux caractères simples (par exemple, ''+'' est pris en charge, ''0+'' ne l'est pas). * Vous ne pouvez pas utiliser l'alternance dans un groupe, par exemple ''(foo|bar)'' n'est pas autorisé. * Les retours en arrière complexes ne sont pas pris en charge, par exemple ''\p*d*\s*\w*:'' ne correspond pas à un seul deux-points car ''\p*'' consomme les deux deux-points. * ''.'' correspond à un point littéral, tandis que ''\.'' correspond à n'importe quel caractère. * ''\s'' ne correspond qu'à un espace ASCII (32), pas à d'autres espaces tels que les tabulations. * Il n'existe pas de syntaxe pour faire correspondre un caret, un astérisque ou un caractère plus littéral (bien que fasse correspondre un astérisque ou plus, ainsi que d'autres caractères). ==== PCRE2 ==== //Perl Compatible Regular Expression// (**PCRE2**) offre des fonctionnalités telles que les motifs récursifs, les assertions de type "look-ahead" et "look-back", les groupes de non-capture, les quantificateurs non-voraces, une syntaxe étendue pour les caractères et les classes de caractères, entre autres. Pour plus de détails, voir la [[https://www.pcre.org/current/doc/html/pcre2syntax.html|Documentation syntaxique CPRE2]]. === Expressions acceptées === ^Expression ^Caractères valides^ |''.'' |Tout caractère à l'exception de la nouvelle ligne| |''\d'' |Tout chiffre décimal, égal à ''[0-9]''| |''\D'' |Tout caractère, autre qu'un chiffre décimal, égal à ''[^0-9]''| |''\h'' |Tout caractère d'espace blanc horizontal| |''\H'' |Tout caractère autre qu'un espace horizontal| |''\s'' |Tout caractère d'espacement, égal à ''[\t\r\n\f]''| |''\S'' |Tout caractère qui n'est pas un espace vide, égal à ''[^\t\r\n\f]''| |''\w'' |N'importe quel caractère "mot".| |''\W'' |Tout caractère "non-mot".| === Modificateurs === ^Expression ^Comportement| |''?'' |0 ou 1, greedy| |''?+'' |0 ou 1, possessive| |''??'' |0 ou 1, lazy| |''*'' |0 ou plus, greedy| |''*+'' |0 ou plus, possessive| |''*?'' |0 ou plus, lazy| |''+'' |1 ou plus, greedy| |''++'' |1 ou plus, possessive| |''+?'' |1 ou plus, lazy| |''{n}'' |Exactement n| |''{n,m}'' |Au moins n, pas plus de m, greedy| |''{n,m}+'' |Au moins n, pas plus de m, possessive| |''{n,m}?'' |Au moins n, pas plus de m, lazy| |''{n,}'' |n ou plus, greedy| |''{n,}+'' |n ou plus, possessive| |''{n,}?'' |n ou plus, lazy| === Caractères échappés === ^Expression ^Comportement| |''\f'' |Page suivante (hexadecimal ''0C'')| |''\n'' |Nouvelle ligne (hexadecimal ''0A'')| |''\r'' |Retour du chariot (hexadecimal ''0D'')| |''\t'' |Tabulation (hexadecimal ''09'')| |''\0dd'' |Caractère codé en octal ''0dd''| |''\o{ddd..}'' |Caractère codé en octal ''ddd..''| |''\xhh'' |Caractère codé en hexadécimal ''hh''| |''v\x{hhh...}'' |Caractère codé en hexadécimal ''hh..''| [[:fr:documentation:start|Retour à l'index de la documentation du Pandora FMS]]