Collecte et surveillance des journaux

La surveillance des logs dans Pandora FMS permet à l'utilisateur de visualiser dans une seule console tous les journaux (logs) provenant de sources multiples qu'il souhaite capturer, en organisant les informations de manière séquentielle, en utilisant l'horodatage de traitement des logs.

Ces informations ne contiennent ni structures ni formats, elles sont enregistrées au format texte avec un horodatage (au moment de leur réception), en plus des horodatages d'origine que ces fichiers pourraient avoir.

Ces logs peuvent être utilisés pour générer des événements de sécurité (SIEM) et/ou à des fins de dépannage, de conformité légale ou d'analyse médico-légale. La capacité de traitement des logs n'est limitée que par la capacité de l'appareil utilisé pour leur stockage.

• Les logs analysés par les EndPoints (eventlog ou fichiers texte), sont transmis au serveur Pandora FMS, sous forme RAW dans le XML de rapport de l'agent.
• Le Data Server Pandora FMS reçoit le XML de l'EndPoint, qui contient à la fois des informations de surveillance et de logs.
• Lorsque le Data Server traite les données XML, il identifie les informations des logs, en sauvegardant dans la base de données principale les références de l'EndPoint qui a signalé et l'origine du log, puis en envoyant automatiquement les informations à OpenSearch.
• Pandora FMS stocke les données dans des index OpenSearch en générant quotidiennement un index unique pour chaque instance de Pandora FMS.
• Le serveur Pandora FMS dispose d'une tâche de maintenance qui supprime les index dans l'intervalle défini par l'administrateur système (par défaut, 30 jours, modifiable).
• Les logs transitent sur le réseau encodés pour éviter les problèmes de format.
• Si l'on souhaite que les logs transitent sur le réseau de manière cryptée, un transport sécurisé (Tentacle crypté) peut être utilisé à cet effet.
• Les logs peuvent être envoyés par Syslog au serveur Syslog de Pandora FMS, qui traite directement les logs depuis un serveur Syslog local, rendant le traitement beaucoup plus rapide.
• La charge peut être distribuée en utilisant différents agents (avec leurs EndPoints) et des serveurs Syslog distants pour adopter la meilleure distribution et adaptation à la topologie du réseau.

Les valeurs suivantes doivent être configurées dans la section OpenSearch options:

1. OpenSearch IP: Adresse IP du serveur OpenSearch à utiliser avec Pandora FMS.
2. Use https: Doit être activé si l'environnement OpenSearch installé a activé le HTTPS pour sa connexion.
3. OpenSearch Port: Numéro de port TCP.
4. Days to purge old information: Nombre de jours avant la suppression des données collectées.
5. Basic authentication: (optionnel) si l'authentification de base a été installée dans OpenSearch (recommandé) vous devez entrer l'utilisateur défini (champ User) et le mot de passe (champ Password).

• Indexing size: Cette valeur de paramètre sera utilisée comme configuration ignore_above dans OpenSearch.
• Number of shards: Le nombre de fragments primaires qu'un index doit avoir. La valeur par défaut est 1. Cette configuration ne peut être établie qu'au moment de la création de l'index. Elle ne peut pas être modifiée sur un index fermé.
• Number of replicas: Le nombre de répliques que chaque fragment primaire possède. La valeur par défaut est 1. AVERTISSEMENT: Le configurer à 0 peut entraîner une perte temporaire de disponibilité lors des redémarrages du nœud ou une perte permanente de données en cas de corruption de celles-ci.
• Auto expand replicas: Étend automatiquement le nombre de répliques en fonction du nombre de nœuds de données dans le cluster. Définit une limite inférieure et supérieure délimitée par des tirets (par exemple, 0-5) ou utilise « all » pour la limite supérieure (par exemple, 0-all). Gardez à l'esprit que le nombre de répliques automatiquement étendues ne prend en compte que les règles de filtrage d'allocation, mais ignore les autres règles d'allocation, telles que le total des fragments par nœud, ce qui peut faire passer l'état du cluster à YELLOW si les règles applicables empêchent l'allocation de toutes les répliques.

La collecte de logs se fait en réalité via les EndPoints, tant pour Microsoft Windows® que pour Unix® (Linux®, MacOS X®, Solaris®, HPUX®, AIX®, BSD®, etc.).

Les agents sont utilisés pour héberger les informations locales de chaque EndPoint surveillé.

Vous pouvez collecter des événements ou des textes bruts (logs conventionnels).

Similaire à la syntaxe Linux, le type de module log est utilisé conjointement avec le jeton module_regexp.

MS Windows ne supporte pas module_pattern_exclude.

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

Pour cela, le type de module spécial logchannel est utilisé, qui ne fonctionne que pour les environnements Microsoft Windows®. Il permet d'obtenir des informations à partir du log d'événements MS Windows® en fonction de certains filtres, selon la source et le type d'événement.

Format général de ce module:

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

Pour éviter d'afficher des informations répétées, seuls les événements MS Windows qui se sont produits depuis la dernière exécution de l'EndPoint sont pris en compte. Par conséquent, lors de la première exécution, il ne collectera pas tous les événements déjà existants. Il commencera à envoyer les événements collectés à partir de la première exécution.

Tous les paramètres indiqués ci-dessous nécessitent l'introduction correcte des majuscules et minuscules:

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

Source à l'origine de l'événement enregistré dans le log. Il est essentiel de bien le distinguer de module_application, qui indique le nom de l'application (une autre façon d'obtenir des événements). C'est un paramètre optionnel si module_application est utilisé, mais l'un des deux doit être utilisé.

Il s'agit d'une ancienne catégorisation qui vient de l'époque de MS Windows NT®. Les plus connus sont Système, Application, Sécurité et des centaines d'autres. Ils peuvent être vus dans n'importe quel événement, dans ce cas en espagnol sous le nom de “Registro” ou “Nombre de registro”.

C'est-à-dire que dans cette capture d'écran, il apparaît comme “Sistema”, mais les clés pour pouvoir filtrer doivent être exprimées en anglais, “System” dans ce cas. “Application” au lieu de “Aplicación” et “Security” au lieu de “Seguridad”. D'autres noms de journaux longs doivent être utilisés tels quels, System, Application, Security et ils doivent toujours être placés en anglais pour pouvoir obtenir et afficher les événements.

Exemple de module_source avec un nom long, sans traduction:

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

La surveillance SIEM repose en grande partie sur le type de log collecté, il sera donc nécessaire de spécifier module_source_type dans les modules de collecte de logs pour indiquer ce type. Le type est utilisé par les décodeurs et les règles, vous devrez donc consulter les décodeurs et les règles actifs pour connaître le type qui doit être indiqué dans chaque log.

Les types de logs les plus utilisés sont:

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

Le type ossec doit être utilisé pour traiter les événements Windows par le SIEM. Pour plus d'informations, consultez la documentation de la surveillance SIEM.

Ceci serait un exemple concret pour collecter tous les événements de sécurité sous Windows, ce qui permet au SIEM de traiter les événements de sécurité spécifiques:

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

C'est un attribut optionnel qui sert à filtrer le type d'événement (selon la version de MS Windows® : Error, Warning, Information, Audit success, Audit failure …). Il s'exprime comme une valeur qui peut être observée dans l'observateur d'événements de Windows.

Cet exemple prendrait des événements de sécurité de niveau 3 (avertissement):

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

Paramètre optionnel. Il permet d'utiliser un ID d'événement spécifique pour ne filtrer que les événements ayant cet ID. C'est peut-être le filtre le plus précis.

Comme vous pouvez le voir sur cette capture d'écran, il est fait référence à l' eventID dans l'observateur d'événements:

Cet exemple prendrait des événements de sécurité de niveau 3 (avertissement):

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

Origine de l'événement. C'est un champ optionnel.

Pour obtenir le nom du fournisseur de l'événement, il sera nécessaire de spécifier son nom exact tel qu'il apparaît dans le champ name de la liste détaillée des événements. Pour ce faire, dans l'observateur d'événements de MS Windows, après avoir fait un clic droit dessus, sélectionnez Propriétés et copiez le paramètre Full name, nécessaire pour module_application, comme indiqué dans la capture d'écran suivante:

Voici quelques exemples courants de noms de fournisseurs qui apparaissent dans l'Observateur d'Événements de MS Windows, il peut en exister beaucoup d'autres puisque chaque application utilisera un nom spécifique.

Fournisseurs du système d'exploitation:

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

Fournisseurs d'applications ou de services courants:

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

Exemples spécifiques d'événements pertinents pour les diagnostics avancés:

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

Voici quelques exemples de fournisseurs courants (non Microsoft):

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

Ces fournisseurs servent de critères de filtrage pour collecter ou exclure des événements MS Windows via l'EndPoint Pandora FMS. S'il comporte des espaces, les guillemets ne doivent pas être utilisés, par exemple, dans le cas de “Pandora FMS” ce serait:

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

• Qu'est-ce que Sysmon?

Sysmon (System Monitor) est un outil gratuit développé par Microsoft® qui fait partie des Sysinternals Tools, conçu pour améliorer considérablement la surveillance et l'enregistrement des événements détaillés sur les systèmes d'exploitation Windows.

Son objectif principal est d'enregistrer les activités liées à la sécurité du système et des applications, qui ne sont normalement pas enregistrées avec suffisamment de détails dans l'observateur d'événements standard.

• À quoi sert Sysmon?

Sysmon est principalement axé sur la surveillance et la détection précoce des incidents de sécurité grâce à un enregistrement exhaustif des événements clés du système, tels que:

1. Création et exécution de processus.
2. Connexions réseau (entrantes et sortantes).
3. Modifications du registre Windows.
4. Chargement de bibliothèques DLL.
5. Accès et modifications de fichiers.
6. Utilisation suspecte de la mémoire et des processus.
7. Injections de code dans des processus légitimes.

Ces activités sont généralement exploitées par des logiciels malveillants ou des attaquants lors de tentatives d'intrusion ou de mouvements latéraux au sein d'un réseau d'entreprise.

• Comment fonctionne Sysmon?

Sysmon fonctionne en installant un pilote en mode noyau, en collectant des informations en temps réel sur les activités du système d'exploitation. Ensuite, ces données sont envoyées à l'Observateur d'Événements de Windows (Event Viewer).

• Comment Sysmon améliore-t-il la surveillance avec Pandora FMS?

Pandora FMS peut utiliser l'EndPoint sous MS Windows pour collecter ces événements détaillés directement à partir du canal Sysmon et les envoyer au serveur PFMS correspondant.

Cette approche combinée (Sysmon + Pandora FMS + Pandora SIEM) offre de grands avantages dans la surveillance et la sécurité d'un hôte basé sur Windows:

1. Visibilité approfondie de la sécurité: Fournit un niveau de détail bien supérieur à l'enregistrement des événements traditionnel. Permet une analyse exhaustive des comportements suspects, en identifiant les anomalies et les menaces potentielles en temps réel.
2. Détection précoce des attaques avancées: Facilite la détection des attaques sophistiquées telles que les mouvements latéraux, l'exécution de scripts malveillants ou la connexion à des serveurs suspects.
3. Capacité de réponse immédiate: Pandora FMS peut générer des alertes automatiques basées sur des règles définies sur les événements Sysmon (par exemple, exécution de processus suspects, accès au registre ou tentatives de connexion inhabituelles).
4. Historique et corrélation: Pandora FMS permet de stocker, de consulter et de corréler des événements historiques générés par Sysmon sur de longues périodes, ce qui est fondamental dans les enquêtes médico-légales ou les audits de sécurité.
5. Rapports avancés: L'extraction automatisée permet la création simple de rapports orientés vers les audits de cybersécurité, la conformité réglementaire ou l'analyse post-incident.

• Exemple pratique d'intégration.

Supposons qu'une alerte Sysmon envoyée via l'agent dans Pandora FMS indique que:

1. Un processus inconnu a créé une connexion sortante vers une adresse IP suspecte.
2. Une DLL inconnue a été chargée en mémoire.
3. Une tentative de modification du registre Windows a été effectuée par un processus inattendu.
4. Pandora FMS recevrait ces événements détaillés, générerait une alerte immédiate et permettrait d'agir rapidement sur l'incident avant que des dommages importants ne se produisent.

• Installation et utilisation de Sysmon.

Sysmon est inclus dans le package officiel Microsoft “Sysinternals Suite” et est disponible pour les systèmes Intel 32 et 64 bits ainsi que pour la nouvelle architecture ARM 64 bits (Windows 11).

Sysmon dispose d'un fichier de configuration assez étendu pour indiquer ce qu'il doit “surveiller”. Surveiller “tout” affecterait à la fois les performances de l'hôte et le système qui collecte toutes ces informations. Les EndPoints de Pandora FMS intègrent un fichier de configuration de base distant qui peut être amélioré par l'utilisateur car, par défaut, il générera de nombreuses informations de sécurité.

Pour plus d'informations sur la façon d'utiliser Sysmon, consultez la documentation SIEM.

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

Contrairement aux autres événements, il utilise module_source_type windows au lieu de module_source_type ossec. De plus, il utilise le nom WinEvtLog, tel que défini dans les règles SIEM fournies avec PFMS SIEM. Si d'autres noms et/ou types sont utilisés, cela ne fonctionnera pas comme prévu.

Exemple de log:

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

Pour plus d'informations sur la description des modules de type log, vous pouvez consulter la section suivante concernant les Directives spécifiques.

En définissant ce type de balise, module_type log, il est indiqué de ne pas stocker dans la base de données, mais de l'envoyer au collecteur de logs. Tout module avec ce type de données sera envoyé au collecteur de logs, tant qu'il est activé. Dans le cas contraire, les informations seront ignorées.

Plus d'exemples complets:

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

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

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

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

Ce composant permet à Pandora FMS d'analyser le syslog de la machine où il se trouve, en analysant son contenu et en stockant les références dans le serveur OpenSearch correspondant.

Le principal avantage du Syslog Server consiste à compléter l'unification des logs. Avec le support des fonctionnalités d'exportation de Syslog Server des environnements Linux® et Unix®, Syslog Server permet de consulter les logs indépendamment de l'origine, en effectuant une recherche dans un seul point commun (l'afficheur de logs de la console Pandora FMS).

Pour chaque hôte à partir duquel des logs sont reçus, s'il n'existe pas déjà d'agent correspondant dans Pandora FMS, cet agent sera automatiquement créé pour stocker les logs de cet hôte.

L'installation de Syslog Server 8.2102 doit être effectuée à la fois sur le client et sur le serveur:

dnf install rsyslog

Accédez au fichier de configuration /etc/rsyslog.conf pour activer l'entrée de TCP et UDP.

(...)

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

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

(...)

Redémarrez le service rsyslog. Une fois le service disponible, vérifiez que le port 514 est accessible avec:

netstat -ltnp

Sur le client, configurez-le pour qu'il puisse envoyer les logs au Syslog Server, accédez à rsyslog /etc/rsyslog.conf. Localisez et activez la ligne qui permet de configurer l'hôte distant (remplacez remote-host par l'adresse IP du serveur):

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

La taille des logs reçus par rsyslog est de 8 kilo-octets par défaut. Si des logs d'une taille supérieure sont reçus, de nouvelles entrées sont ajoutées avec le contenu restant jusqu'à ce que le log complet soit reçu. Ces nouvelles entrées ne contiennent pas le nom de l'hôte qui a envoyé le log, par conséquent, ce comportement peut entraîner la création de nouvelles origines de logs indésirables ainsi que de nouveaux agents dans la console web. Pour éviter cela, il est recommandé d'augmenter la taille des logs reçus en ajoutant la ligne suivante:

$MaxMessageSize 512k

Enregistrez le fichier et quittez l'éditeur de texte.

Pour activer cette fonctionnalité dans le serveur Pandora FMS, activez le contenu suivant dans le fichier pandora_server.conf:

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

# Absolute path to the input file read by the SyslogServer.
syslog_file /var/log/messages

# Number of threads for the Syslog Server
syslog_threads 2

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

Dans le serveur Pandora FMS, via le jeton syslog_whitelist, vous pouvez uniquement admettre les enregistrements qui correspondent à une expression régulière ou regexp, qui est sensible à la casse (par exemple, windows n'est pas égal à Windows) et ignorer tout le reste .

Avec le jeton syslog_blacklist, vous pouvez refuser les enregistrements qui correspondent à la regexp établie (et laisser entrer tout le reste ).

Ces deux jetons sont désactivés par défaut.

• syslog_whitelist: En activant ce jeton, il ne laissera entrer que les logs qui répondent à la regexp et le reste sera ignoré.
  • Si ce jeton est activé et que le filtre par défaut .* est présent, tout sera admis.
  • Important: Si ce jeton est activé SANS regexp, RIEN ne sera admis.
• Le filtrage des mots-clés autorisés est effectué en premier, ce qui réduit le travail pour l'étape suivante.
• syslog_blacklist: En plaçant une regexp, tout ce qui y correspond sera ignoré (si ce jeton est activé mais laissé SANS regexp, RIEN ne sera bloqué).
• Le filtrage par syslog_blacklist est effectué en dernier.

Dans un outil de collecte de logs, deux caractéristiques sont principalement intéressantes : pouvoir rechercher des informations - en filtrant par date, sources de données et/ou mots-clés, etc. - et pouvoir visualiser ces informations (menu Operation → Logs → Log viewer) dessinées en occurrences par unité de temps.

Le champ le plus important - et le plus utile - sera la chaîne à rechercher à saisir dans la zone de texte Search en combinaison avec les trois types de recherche disponibles (Search mode):

• Exact match: Recherche de chaîne littérale, le log contient une correspondance exacte.
• All words: Recherche qui contient tous les mots indiqués, quel que soit leur ordre dans une même ligne de log.
• Any word: Recherche qui contient certains des mots indiqués, quel que soit leur ordre.
• Si vous cochez l'option pour voir le contexte du contenu filtré, vous obtiendrez un aperçu général de la situation avec des informations provenant d'autres lignes de logs liées à la recherche.

Grâce à cette fonctionnalité, il est possible d'afficher sous forme graphique les entrées de log, en classant les informations en fonction des modèles de capture de données.

Ces modèles de capture de données sont essentiellement des expressions régulières et des identifiants qui permettent d'analyser les sources de données et de les afficher sous forme de graphique.

Pour accéder aux options avancées, cliquez sur Advanced options. Un formulaire s'affichera où vous pourrez choisir le type d'affichage des résultats:

• Afficher les entrées de log (texte brut).
• Afficher le graphique de log.
• Grâce à l'option afficher le graphique de log (Display mode), vous pourrez sélectionner le modèle de capture (Use capture model).
• Le modèle par défaut, Apache log model, offre la possibilité de traiter ou de faire le parse des logs d'Apache au format standard (access_log), permettant d'extraire des graphiques comparatifs du temps de réponse, en regroupant par page visitée et par code de réponse:
• Vous pouvez soit cliquer sur le bouton éditer, soit sur le bouton créer pour réaliser un nouveau modèle de capture.

Grâce à cette option, vous pourrez enregistrer les préférences de filtrage fréquemment utilisées, créant ainsi une liste de filtres. Une fois que toutes les valeurs de filtrage ont été configurées, en cliquant sur le bouton Save filter et en attribuant un nom, vous pourrez appuyer sur le bouton Save et enregistrer les préférences ou les modifications (il peut être enregistré dans un filtre existant).

À tout autre moment, ces préférences pourront être chargées à l'aide du bouton Load filter pour dérouler la liste des filtres enregistrés. Vous devez sélectionner l'un d'entre eux et cliquer sur Load filter.

Grâce au système d'éléments épinglés dans PFMS, vous pourrez enregistrer un raccourci pour le Log viewer avec les préférences de filtrage si vous cliquez sur l'icône en forme de punaise située dans le titre de la section.

Lorsque le filtre sera rechargé, l'icône apparaîtra et lorsqu'elle sera cliquée, le filtre sera supprimé des éléments épinglés.

À partir de la version 749 de Pandora FMS, une boîte appelée Log sources status a été ajoutée à la vue de l'agent, dans laquelle la date de la dernière mise à jour des logs par cet agent apparaîtra. En cliquant sur l'icône de la loupe Review, il redirige vers la vue du Log Viewer filtrée par ce log.

Retour à l'index de documentation de Pandora FMS