Collecte et supervision des journaux

La supervision des logs dans Pandora FMS permet à l'utilisateur de visualiser dans une console unique tous les registres (logs) provenant de sources multiples qu'il souhaite capturer, en organisant l'information de manière séquentielle, en utilisant l'horodatage dans lequel les logs ont été traités.

Ces informations ne contiennent pas de structures ou de formatage, elles sont stockées au format texte avec un horodatage (de l'heure de réception), en plus des horodatages d'origine que les fichiers peuvent avoir.

Ces journaux 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 journaux n'est limitée que par la capacité du dispositif utilisé pour le stockage des journaux.

• Les logs analysés par les Agents logiciels (eventlog ou fichiers texte) sont transmis au serveur Pandora FMS, sous forme RAW dans le rapport XML de l'agent.
• Le Pandora FMS Data server reçoit le fichier XML de l'agent, qui contient à la fois des informations de surveillance et des informations logs.
• Lorsque le Data server traite les données XML, il identifie les informations logs, en stockant dans la base de données principale les références de l'agent de notification et l'origine du log, puis en envoyant automatiquement les informations à OpenSearch.
• Pandora FMS stocke les données dans des index OpenSearch générant quotidiennement un index unique pour chaque instance de Pandora FMS.
• Le Pandora FMS server dispose d'une tâche de maintenance qui supprime les index dans l'intervalle défini par l'administrateur du système (par défaut, 30 jours, modifiable).
• Les logs voyagent à travers le réseau encodés pour éviter les problèmes de formatage.
• Si vous souhaitez que logs voyage sur le réseau de manière cryptée, un transport sécurisé (Tentacle crypté) peut être utilisé à cette fin.
• Les logs peuvent être envoyés par Syslog au serveur Syslog de Pandora FMS, qui traite directement les logs à partir d'un serveur Syslog local, ce qui accélère considérablement le traitement.
• La charge peut être répartie à l'aide de différents agents et serveurs Syslog distants afin d'adopter la meilleure répartition et de s'adapter à la topologie du réseau.

Pour activer le système d'affichage des journaux, vous devez activer Management → Settings → System Settings → Log collector. Cliquez sur Activate Log Collector et Update.

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: Il doit être activé si l'environnement OpenSearch installé a activé HTTPS pour sa connexion.
3. OpenSearch Port: Le 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: (facultatif) Si l'authentification de base a été installée dans OpenSearch (recommandé) l'utilisateur (champ User) doit être renseigné et mot de passe (champ Password) défini.

La collecte des journaux s'effectue via des agents, à la fois dans l'agent pour Microsoft Windows® et dans les agents Unix® (Linux®, MacOS X®, Solaris®, HPUX®, AIX®, BSD®, et cetera).

Les agents sont utilisés pour collecter les informations locales de chaque EndPoint supervisé.

Vous pouvez collecter des événements ou des textes simples (conventionnel logs).

Comme dans la syntaxe Linux, le type de module log est utilisé avec le jeton module_regexp.

MS Windows ne prend pas en charge 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

À cette fin, le type de module spécial logchannel est utilisé, qui ne fonctionne que pour les environnements Microsoft Windows®. Permet d'obtenir des informations à partir du journal des événements de MS Windows® log 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 survenus depuis la dernière exécution de l'agent sont pris en compte. Lors de la première exécution, il ne récupérera donc pas tous les événements qui existent déjà. Il commencera à envoyer les événements collectés dès la première exécution.

Tous les paramètres énumérés ci-dessous requièrent la saisie correcte de lettres majuscules et minuscules:

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

Source à l'origine de l'événement enregistré dans 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 facultatif si module_application est utilisé, mais l'un des deux doit être utilisé.

Il s'agit d'une ancienne catégorisation qui remonte à MS Windows NT®. Les plus connus sont Système, Application, Sécurité et des centaines d'autres. On peut les voir dans tous les cas, en l'occurrence en espagnol sous le nom de “Registro” ou “Nombre de registro”.

En d'autres termes, dans cette capture d'écran, il s'agit de “Sistema”, mais les clés de filtrage doivent être exprimées en anglais, “System” dans ce cas. “Application” au lieu de “Aplicación” et “Security” au lieu de “Seguridad”. Les autres noms de registre longs doivent être utilisés tels quels, System, Application, Security et doivent toujours être placés en anglais afin d'obtenir et d'afficher des événements.

Exemple de module_source avec un nom long, sans traduction:

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

La supervison 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 decoders et rules, vous devrez donc consulter la section decoders et rules atouts pour connaître le type à indiquer dans chaque log.

Les types logs les plus couramment utilisés sont les suivants:

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

Le type ossec est utilisé pour traiter les événements Windows par le SIEM. Pour plus d'informations, veuillez vous référer à la Documentation de monitoring SIEM.

Il s'agit d'un exemple concret de collecte de tous les événements de sécurité dans Windows, qui permet le traitement des événements spécifiques à la sécurité par le SIEM:

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

Il s'agit d'un attribut facultatif utilisé pour filtrer le type d'événement (en fonction de la version de MS Windows®): Error, Warning, Information, Audit success, Audit failure …). Elle est exprimée sous la forme d'une valeur visible dans l'observateur d'événements Windows.

Cet exemple prend en compte les é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 facultatif. Permet d'utiliser un identifiant d'événement spécifique pour filtrer uniquement les événements portant cet identifiant. Il s'agit peut-être du filtre le plus précis.

Comme vous pouvez le voir dans cette capture d'écran, l'eventID est référencé dans le visualiseur d'événements:

Cet exemple prend en compte les é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. Il s'agit d'un champ facultatif.

Pour obtenir le nom du fournisseur d'événements, vous devrez spécifier le nom exact du fournisseur d'événements qui 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 Windows, après avoir fait un clic droit, sélectionnez Propriétés et copiez le paramètre Full name, requis pour module_application, comme le montre la capture d'écran ci-dessous :

Il s'agit là d'exemples courants de noms de fournisseurs qui apparaissent dans l'observateur d'événements Windows, mais il peut y en avoir beaucoup d'autres, car chaque application utilise un nom spécifique.

Fournisseurs de systèmes 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

Application commune ou fournisseurs de services:

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

Exemples spécifiques d'événements liés aux 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 par l'intermédiaire de l'agent Pandora FMS. S'il y a 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 dans le cadre des Sysinternals Tools, conçu pour améliorer de manière significative la supervision et l'enregistrement d'é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é des systèmes et des applications, qui ne sont normalement pas enregistrées de manière suffisamment détaillée dans le visualiseur 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é par le biais d'un journal complet 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 de Windows.
4. Chargement des bibliothèques DLL.
5. Accès et modifications des 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, collectant des informations en temps réel sur les activités du système d'exploitation. Ces données sont ensuite 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'agent Windows pour collecter ces événements détaillés directement à partir du canal Sysmon et les envoyer au serveur central de Pandora.

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 traditionnel des événements. Permet une analyse complète 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éaction immédiate: Pandora FMS peut générer des alertes automatiques basées sur des règles définies dans les événements Sysmon (par exemple, l'exécution de processus suspects, des accès au registre ou des tentatives de connexion inhabituelles).
4. Historique et corrélation: Pandora FMS permet de stocker, de consulter et de corréler les événements historiques générés par Sysmon sur de longues périodes, ce qui est essentiel dans le cadre d'enquêtes judiciaires ou d'audits de sécurité.
5. Rapports avancés: L'extraction automatisée permet de créer facilement des rapports pour les audits de cyber sécurité, la conformité ou l'analyse post-incident.

• Exemple pratique d'intégration.

Supposons une alerte Sysmon envoyée par l'agent Pandora indiquant 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. Un processus inattendu a tenté de modifier le registre de Windows.
4. Pandora FMS recevrait ces événements détaillés, générerait une alerte immédiate et permettrait une action rapide sur l'incident avant que des dommages importants ne soient causés.

• Installation et utilisation de Sysmon.

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

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

Pour plus d'informations sur l'utilisation de 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. Utilisez également le nom WinEvtLog, tel que défini dans les règles SIEM fournies avec Pandora SIEM. Si d'autres noms et/ou types sont utilisés, le système 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, veuillez vous référer à la section suivante sur les Directives spécifiques.

En définissant ce type de balise, module_type log, vous indiquez qu'elle n'est pas stockée dans la base de données, mais envoyée au collecteur log. Tout module contenant ce type de données sera envoyé au collecteur logs, à condition qu'il soit activé. Dans le cas contraire, les informations seront rejeté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 de Syslog Server est de compléter l'unification des logs. Pris en charge par les fonctionnalités d'exportation de Syslog Server depuis les environnements Linux® et Unix®, Syslog Server permet d'interroger les journaux quelle que soit leur origine, en recherchant dans un seul point commun (visualiseur de journaux de la console Pandora FMS).

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 les entrées 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, il est configuré pour qu'il puisse envoyer les logs au serveur Syslog, accéder à rsyslog /etc/rsyslog.conf. Localisez et activez la ligne qui vous 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 journaux reçus par rsyslog est de 8 kilo-octets par défaut. Si des journaux plus volumineux sont reçus, de nouvelles entrées sont ajoutées avec le contenu restant jusqu'à ce que le journal complet soit reçu. Ces nouvelles entrées ne contiennent pas le nom de l'hôte qui a envoyé le journal. Ce comportement peut donc entraîner la création de nouvelles sources de journaux indésirables et de nouveaux agents dans la console. 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 Pandora FMS Server, activez dans le fichier pandora_server.conf le contenu suivant:

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

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

# Number of threads for the Syslog Server
syslog_threads 2

# Maximum number of lines queued by the Syslog Server's
# producer on each run.
syslog_max 65535

Sur le serveur Pandora FMS, à l'aide du token syslog_whitelist, vous pouvez admettre uniquement les logs qui correspondent à une expression régulière ou regexp, qui est sensible à la casse (par exemple, windows n'est pas la même chose que Windows) et ignorer tout le reste.

Avec le token syslog_blacklist vous pouvez refuser les logs qui correspondent à l'ensemble regexp (et laisser tout le reste dans).

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

• syslog_whitelist: L'activation de ce jeton laissera entrer uniquement les journaux conformes à la regexp et le reste sera supprimé.
  • Si ce token est activé et que vous avez le filtre par défaut .*, tout sera accepté.
  • Important: Si ledit token est activé SANS regexp, RIEN ne sera admis.
• Le filtrage des mots-clés autorisés est effectué en premier, cela réduit le travail pour l'étape suivante.
• syslog_blacklist: Placer une regexp supprimera tout ce qui y est conforme (si ce token 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 -filtrage par date, sources de données et/ou mots-clés, et cetera- et pouvoir visualiser ces informations (menu Operation → Logs → Log viewer) dessiné en occurrences par unité de temps.

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

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

Avec cette fonctionnalité, vous pouvez afficher les entrées de journal sous forme graphique, en classant les informations en fonction de 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 vous 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 dans lequel vous pourrez choisir le type d'affichage des résultats:

• Afficher les entrées du log (texte brut).
• Afficher le graphique du log.
• À l'aide de l'option d'affichage du graphique du log (Display mode), vous pouvez 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 d'analyser les logs Apache au format standard (access_log), pouvant extraire des graphiques comparatifs de temps de réponse, regroupés par page visitée et code de réponse:
• Vous pouvez appuyer sur le bouton Modifier ou sur le bouton Créer pour créer un nouveau modèle de capture.

Cette option permet d'enregistrer les préférences de filtrage fréquemment utilisées et de créer ainsi une liste de filtres. Lorsque toutes les valeurs du filtre ont été configurées, appuyez sur le bouton Save filter et attribuez un nom pour pouvoir appuyer sur le bouton Save et sauvegarder vos préférences ou vos modifications (peut être sauvegardé sur un filtre existant).

A tout autre moment, ces préférences peuvent être chargées à l'aide du bouton Load filter pour dérouler la liste des filtres sauvegardés. Sélectionnez l'un d'entre eux et appuyez sur Load filter.

En utilisant le système de favoris de PFMS, un raccourci vers le Log viewer avec des préférences de filtrage peut être sauvegardé en cliquant sur l'icône en forme d'étoile dans le titre de la section.

À 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 apparaîtra la date de la dernière mise à jour des journaux par cet agent. Lorsque vous cliquez sur l'icône en forme de loupe Review, vous redirigez vers la vue Log Viewer filtrée par ce log.

Retour à l'index de la documentation Pandora FMS