Connecteurs Syslog et Common Event Format (CEF) via AMA pour Microsoft Sentinel
Les connecteurs de données Syslog via AMA et Common Event Format (CEF) via AMA pour Microsoft Sentinel filtrent et ingèrent des messages Syslog, y compris des messages au format CEF, à partir de machines Linux et d’appliances et de périphériques réseau et de sécurité. Ces connecteurs installent l’agent Azure Monitor (AMA) sur n’importe quel ordinateur Linux à partir duquel vous souhaitez collecter des messages Syslog et/ou CEF. Cette machine peut être à l’origine des messages, ou il peut s’agir d’un redirecteur qui collecte des messages à partir d’autres machines, tels que des appliances et appareils de sécurité ou de réseau. Le connecteur envoie les instructions des agents en fonction de règles de collecte de données (DCR) que vous définissez. Les règles de collecte de données spécifient les systèmes à monitorer et les types de journaux ou de messages à collecter. Elles définissent les filtres à appliquer aux journaux avant qu’ils ne soient ingérés, pour accroître les performances et améliorer l’analyse et l’interrogation.
Syslog et CEF sont deux formats courants pour la journalisation des données à partir de différents appareils et applications. Ils aident les administrateurs système et les analystes de sécurité à surveiller et à dépanner le réseau et à identifier les menaces ou incidents potentiels.
Qu’est-ce que Syslog ?
Syslog est un protocole standard pour l’envoi et la réception de messages entre différents appareils ou applications sur un réseau. Il a été initialement développé pour les systèmes Unix, mais il est désormais largement pris en charge par diverses plateformes et fournisseurs. Les messages Syslog ont une structure prédéfinie qui se compose d’une priorité, d’un horodatage, d’un nom d’hôte, d’un nom d’application, d’un ID de processus et d’un texte de message. Les messages Syslog peuvent être envoyés via les protocoles UDP, TCP ou TLS, en fonction de la configuration et des exigences de sécurité.
L’agent Azure Monitor prend en charge les RFC 3164 et 5424 Syslog.
Qu’est-ce que le CEF (Common Event Format) ?
CEF, ou Common Event Format, est un format indépendant du fournisseur pour la journalisation des données à partir d’appliances et de périphériques réseau et de sécurité, tels que des pare-feu, des routeurs, des solutions de détection et de réponse, ainsi que des systèmes de détection d’intrusion, ainsi que d’autres types de systèmes tels que des serveurs web. Une extension de Syslog, elle a été développée en particulier pour les solutions SIEM (gestion des informations et des événements de sécurité). Les messages CEF ont un en-tête standard qui contient des informations telles que le fournisseur de l’appareil, le produit de l’appareil, la version de l’appareil, la classe d’événements, la gravité de l’événement et l’ID d’événement. Les messages CEF ont également un nombre variable d’extensions qui fournissent davantage de détails sur l’événement, tels que les adresses IP source et de destination, le nom d’utilisateur, le nom de fichier ou l’action effectuée.
Collecte de messages Syslog et CEF avec AMA
Les diagrammes suivants illustrent l’architecture de la collection de messages Syslog et CEF dans Microsoft Sentinel, à l’aide des connecteurs Syslog via AMA et Common Event Format (CEF) via AMA.
Ce diagramme montre les messages Syslog collectés à partir d’une seule machine virtuelle Linux sur laquelle l’agent Azure Monitor (AMA) est installé.
Le processus d’ingestion des données à l’aide de l’agent Azure Monitor utilise les composants et flux de données suivants :
Les sources de journaux sont les différentes machines virtuelles Linux dans votre environnement qui produisent des messages Syslog. Ces messages sont collectés par le démon Syslog local sur le port TCP ou UDP 514 (ou un autre port selon vos préférences).
Le démon Syslog local (soit
rsyslogousyslog-ng) collecte les messages de journal sur le port TCP ou UDP 514 (ou un autre port selon vos préférences). Le démon envoie ces journaux à l’agent Azure Monitor de deux façons différentes, en fonction de la version de l’AMA :- Les versions 1.28.11 et ultérieures de l’AMA reçoivent les journaux sur le port TCP 28330.
- Les versions antérieures de l’AMA reçoivent des journaux via le socket de domaine Unix.
Si vous souhaitez utiliser un port autre que 514 pour recevoir des messages Syslog/CEF, vérifiez que la configuration du port sur le démon Syslog correspond à celle de l’application qui génère les messages.
L’agent Azure Monitor que vous installez sur chaque machine virtuelle Linux dont vous souhaitez collecter les messages Syslog, en configurant le connecteur de données. L’agent analyse les journaux, puis les envoie à votre espace de travail Microsoft Sentinel (Log Analytics).
Votre espace de travail Microsoft Sentinel (Log Analytics) : les messages Syslog envoyés ici se retrouvent dans la table Syslog, où vous pouvez interroger les journaux et effectuer des analyses pour détecter les menaces de sécurité et y répondre.
Processus de configuration pour collecter les messages de journal
À partir du Hub de contenu dans Microsoft Sentinel, installez la solution appropriée pour Syslog ou Common Event Format. Cette étape installe les connecteurs de données respectifs Syslog via AMA ou Common Event Format (CEF) via AMA. Pour plus d’informations, consultez Découvrir et gérer le contenu Microsoft Sentinel prêt à l’emploi.
Dans le cadre du processus d’installation, créez une règle de collecte de données et installez l’agent Azure Monitor (AMA) sur le redirecteur de journal. Effectuez ces tâches soit à l’aide du portail Azure ou Microsoft Defender, soit à l’aide de l’API d’ingestion de journaux Azure Monitor.
Quand vous configurez le connecteur de données pour Microsoft Sentinel dans le portail Azure ou Microsoft Defender, vous pouvez créer, gérer et supprimer des règles de collecte de données par espace de travail. L’AMA est installé automatiquement sur les machines virtuelles que vous sélectionnez dans la configuration du connecteur.
Vous pouvez également envoyer des requêtes HTTP à l’API d’ingestion de journaux. Avec cette configuration, vous pouvez créer, gérer et supprimer les DCR. Cette option est plus flexible que le portail. Par exemple, avec l’API, vous pouvez filtrer par niveaux de journalisation spécifiques. Dans le portail Azure ou Defender, vous ne pouvez sélectionner qu’un niveau de journalisation minimum. L’inconvénient de cette méthode est que vous devez installer manuellement l’agent Azure Monitor sur le redirecteur de journal avant de créer une règle de collecte de données.
Une fois la règle de collecte de données créée et AMA installé, exécutez le script « installation » sur le redirecteur de journal. Ce script configure le démon Syslog pour écouter les messages provenant d’autres machines et ouvrir les ports locaux nécessaires. Configurez ensuite les périphériques ou les appliances de sécurité en fonction des besoins.
Pour plus d’informations, consultez Ingérer des messages Syslog et CEF dans Microsoft Sentinel avec l’agent Azure Monitor.
Prévention de la duplication de l’ingestion des données
L’utilisation de la même catégorie pour les messages Syslog et CEF peut entraîner une duplication de l’ingestion des données entre les tables CommonSecurityLog et Syslog.
Pour éviter ce scénario, utilisez l’une des méthodes suivantes :
Si l’appareil source permet la configuration de la fonctionnalité cible : sur chaque machine source qui envoie des journaux au redirecteur de journaux au format CEF, modifiez le fichier de configuration Syslog pour supprimer les fonctionnalités utilisées pour envoyer des messages CEF. Ainsi, les catégories envoyées au format CEF ne sont pas également envoyées au format Syslog. Assurez-vous que chaque règle DCR que vous configurez dans les prochaines étapes utilise la fonctionnalité appropriée pour CEF ou Syslog, respectivement.
Pour voir un exemple de l’organisation d’une règle de collecte de données pour ingérer les messages Syslog et CEF du même agent, accédez à Flux Syslog et CEF dans la même règle de collecte de données.
Si la modification de la catégorie pour l’appliance source n’est pas applicable : utilisez une transformation au moment de l’ingestion pour filtrer les messages CEF provenant du flux Syslog afin d’éviter la duplication, comme le montre l’exemple de requête suivant.
source | where ProcessName !contains "CEF"