Syslog et CEF (Common Event Format) via des connecteurs AMA pour Microsoft Sentinel

Syslog via AMA et Common Event Format (CEF) via les connecteurs de données AMA pour les Microsoft Sentinel filtrer et ingérer les messages Syslog, y compris les messages au format CEF (Common Event Format), à partir de machines Linux et des appareils et appliances réseau et de sécurité. Ces connecteurs installent l’agent Azure Monitor (AMA) sur n’importe quelle machine Linux à partir de laquelle vous souhaitez collecter des messages Syslog et/ou CEF. Cet ordinateur peut être l’initiateur des messages, ou il peut s’agir d’un redirecteur qui collecte des messages à partir d’autres machines, telles que les appareils et appliances réseau ou de sécurité. Le connecteur envoie les instructions des agents en fonction des règles de collecte de données (DCR) que vous définissez. Les DCR spécifient les systèmes à surveiller et les types de journaux ou de messages à collecter. Ils définissent des filtres à appliquer aux messages avant qu’ils ne soient ingérés, pour de meilleures performances, des requêtes et des analyses plus efficaces.

Syslog et CEF sont deux formats courants pour la journalisation des données provenant 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 permettant d’envoyer et de recevoir des 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 maintenant 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 UDP, TCP ou TLS, en fonction de la configuration et des exigences de sécurité.

L’agent Azure Monitor (AMA) prend en charge les messages Syslog au format RFC 3164 (BSD Syslog) et RFC 5424 (IETF Syslog).

Qu’est-ce que Common Event Format (CEF) ?

CEF, ou Common Event Format, est un format indépendant du fournisseur pour la journalisation des données provenant d’appareils et d’appliances réseau et de sécurité, tels que les pare-feu, les routeurs, les solutions de détection et de réponse et les systèmes de détection des intrusions, ainsi que d’autres types de systèmes tels que les serveurs web. Extension de Syslog, elle a été développée spécialement pour les solutions SIEM (Security Information and Event Management). 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 plus de détails sur l’événement, telles 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 de Syslog via AMA et du Common Event Format (CEF) via les connecteurs 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é.

Diagramme de la collection Syslog à partir d’une source unique.

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 vos 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 votre préférence).

  • Le démon Syslog local ( rsyslog ou syslog-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 ensuite ces journaux à l’agent Azure Monitor de deux manières différentes, en fonction de la version AMA :

    • Les versions AMA 1.28.11 et ultérieures reçoivent des journaux sur le port TCP 28330.
    • Les versions antérieures d’AMA reçoivent les journaux via le socket de domaine Unix.

    Si vous souhaitez utiliser un port autre que 514 pour recevoir des messages Syslog/CEF, assurez-vous que la configuration du port sur le démon Syslog correspond à celle de l’application qui génère les messages.

  • Agent Azure Monitor que vous installez sur chaque machine virtuelle Linux à partir de laquelle vous souhaitez collecter des 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 les analyser pour détecter les menaces de sécurité et y répondre.

Remarque

Lors de l’ingestion de données syslog à l’aide d’un redirecteur de journal et d’Azure Monitor Agent (AMA), des incohérences peuvent survenir entre les TimeGenerated champs et EventTime .

  • TimeGenerated reflète l’heure UTC à laquelle le message syslog a été traité par la machine hébergeant le redirecteur ou le collecteur de journaux.
  • EventTime est extrait de l’en-tête syslog, qui n’inclut pas d’informations de fuseau horaire et est converti au format UTC à l’aide du décalage de fuseau horaire local du redirecteur/collecteur.

Cela peut entraîner des différences entre les deux champs lorsque le redirecteur/collecteur et l’appareil générant le journal se trouvent dans des fuseaux horaires différents.

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 CEF (Common Event Format) via le connecteur de données AMA. Pour plus d’informations, consultez Découvrir et gérer Microsoft Sentinel contenu prête à 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 à l’aide du portail Azure ou Microsoft Defender ou à l’aide de l’API d’ingestion des journaux Azure Monitor.

  • Lorsque vous configurez le connecteur de données pour le Microsoft Sentinel dans le portail Azure ou Microsoft Defender, vous pouvez créer, gérer et supprimer des DCR 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 des journaux. Avec cette configuration, vous pouvez créer, gérer et supprimer des DCR. Cette option est plus flexible que le portail. Par exemple, avec l’API, vous pouvez filtrer par niveaux de journal spécifiques. Dans le portail Azure ou Defender, vous pouvez uniquement sélectionner un niveau de journalisation minimal. L’inconvénient de l’utilisation de cette méthode est que vous devez installer manuellement l’agent Azure Monitor sur le redirecteur de journal avant de créer une DCR.

Une fois que vous avez créé la DCR et qu’AMA est 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 pour ouvrir les ports locaux nécessaires. Ensuite, configurez les appareils de sécurité ou les appliances en fonction des besoins.

Si vous souhaitez en savoir plus, consultez les articles suivants :

Évitement de la duplication d’ingestion de données

L’utilisation de la même fonctionnalité 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 active la configuration de l’installation cible : sur chaque ordinateur 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. De cette façon, les installations envoyées dans CEF ne sont pas également envoyées dans Syslog. Assurez-vous que chaque DCR que vous configurez utilise la fonctionnalité appropriée pour CEF ou Syslog, respectivement.

    Pour voir un exemple montrant comment organiser une DCR pour ingérer des messages Syslog et CEF à partir du même agent, accédez à Flux Syslog et CEF dans la même DCR.

  • Si la modification de la fonctionnalité pour le Appliance source n’est pas applicable : après avoir créé la DCR, ajoutez une transformation de temps d’ingestion pour filtrer les messages CEF du flux Syslog afin d’éviter la duplication. Consultez Tutoriel : Modifier une règle de collecte de données (DCR). Ajoutez une transformation KQL similaire à l’exemple suivant :

    "transformKql": "  source\n    |  where ProcessName !contains \"CEF\"\n"

Étapes suivantes

Configurer les connecteurs de données

  • Last updated on