Ingérer des messages Syslog et CEF vers Microsoft Sentinel avec l’agent Azure Monitor

Article
03/13/2024

Cet article explique comment utiliser le Syslog via l’agent Azure Monitor et Common Event Format (CEF) via les connecteurs de l’agent Azure Monitor pour filtrer et ingérer rapidement des messages Syslog, y compris ceux au Common Event 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 (DCR) spécifient les systèmes à superviser et les types de journaux d’activité ou de messages à collecter, et elles définissent les filtres à appliquer aux messages avant qu’ils ne soient ingérés, pour accroître les performances et améliorer l’analyse et l’interrogation.

Configurer le connecteur
En savoir plus sur le connecteur
En savoir plus sur les règles de collecte de données

Important

Le 28 février 2023, nous avons introduit des modifications dans le schéma de table CommonSecurityLog. En conséquence de ces modifications, vous devrez peut-être passer en revue et mettre à jour les requêtes personnalisées. Pour plus d’informations, consultez la section Actions recommandées dans ce billet de blog. Du contenu prêt à l’emploi (détections, requêtes de chasse, classeurs, analyseurs, etc.) a été mis à jour par Microsoft Sentinel.

Vue d’ensemble

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é.

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 des détails supplémentaires 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.

Comment Microsoft Sentinel collecte des messages Syslog et CEF avec l’agent Azure Monitor

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.

Machine unique (Syslog)
Redirecteur de journal (Syslog/CEF)

Ce diagramme montre les messages Syslog collectés à partir d’une seule machine virtuelle Linux sur laquelle l’agent Azure Monitor (AMA) est installé.

Diagram of Syslog collection from single source.

Le processus d’ingestion des données à l’aide de l’agent Azure Monitor utilise les composants et flux de données suivants :

Sources de journaux : il s’agit de 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 vos préférences).
Le démon Syslog local (soit 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 (voir la note ci-dessous).
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 en suivant les instructions ci-dessous. 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.

Ce diagramme montre les messages Syslog et CEF collectés à partir d’une machine Linux de transfert de journaux sur laquelle l’agent Azure Monitor (AMA) est installé. Ce redirecteur de journal collecte les messages Syslog et CEF à partir de leurs machines, périphériques ou appliances d’origine.

Le processus d’ingestion des données à l’aide de l’agent Azure Monitor utilise les composants et flux de données suivants :

Sources de journaux : il s’agit de vos différents périphériques et appliances de sécurité dans votre environnement qui produisent des journaux au format CEF ou Syslog brut. Ces appareils sont configurés pour envoyer leurs messages de journal via le port TCP ou UDP 514 (ou un autre port selon vos préférences), et non à leur démon Syslog local, mais plutôt au démon Syslog sur le redirecteur de journal.
Redirecteur de journal : il s’agit d’une machine virtuelle Linux dédiée que votre organisation configure pour collecter les messages de journal à partir de vos sources de journaux CEF et Syslog. La machine virtuelle peut être locale, dans Azure ou dans un autre cloud. Ce redirecteur de journal lui-même a deux composants :
- Le démon Syslog (soit 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 (voir la note ci-dessous).
- L’agent Azure Monitor que vous installez sur le redirecteur de journal en configurant les connecteurs de données Syslog et/ou CEF en suivant les instructions ci-dessous (Syslog | CEF). 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 journaux CEF envoyés ici se retrouvent dans la table CommonSecurityLog et les messages Syslog dans la table Syslog. Vous pouvez interroger les journaux et effectuer des analyses pour détecter et répondre aux menaces de sécurité.

Remarque

L’agent Azure Monitor prend en charge les RFC 3164 et 5424 Syslog.
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.
Le démon Syslog envoie les journaux à l’agent Azure Monitor de deux façons différentes, selon 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.

Configurer Syslog via le connecteur AMA

Le processus d’installation pour le connecteur Syslog via AMA comporte deux parties :

Installez l’agent Azure Monitor et créez une règle de collecte de données (DCR).
- À l’aide du portail Azure
- Utilisation de l’API d’ingestion de journaux dans Azure Monitor
Si vous collectez des journaux à partir d’autres machines à l’aide d’un redirecteur de journal, exécutez le script « installation » sur le redirecteur de journal pour configurer le démon Syslog pour écouter les messages provenant d’autres machines et pour ouvrir les ports locaux nécessaires.

Prérequis

Vous devez activer la solution Microsoft Sentinel appropriée : Syslog ou Common Event Format.

Votre compte Azure doit disposer des rôles/autorisations suivants :

Rôle intégré	Étendue	Motif
- Contributeur de machine virtuelle - Azure Connected Machine Administrateur de ressources	Machines virtuelles Virtual Machine Scale Sets Serveurs avec Azure Arc	Pour déployer l’agent
Tout rôle qui inclut l’action Microsoft.Resources/deployments/*	Abonnement Resource group Règle de collecte de données existante	Pour déployer des modèles Azure Resource Manager
Contributeur de surveillance	Abonnement Resource group Règle de collecte de données existante	Pour créer ou modifier des règles de collecte de données

Prérequis du redirecteur de journal

Si vous collectez des messages à partir d’un redirecteur de journal, les prérequis suivants s’appliquent :

Vous devez disposer d’une machine virtuelle Linux désignée (votre redirecteur de journal) pour collecter les journaux.
- Créer une machine virtuelle Linux dans le portail Azure.
- Systèmes d’exploitation Linux pris en charge pour l’Agent Azure Monitor.
Si votre redirecteur de journal n’est pas une machine virtuelle Azure, l’agent Azure Arc Connected Machine doit être installé sur celui-ci.
La machine virtuelle du redirecteur de journal Linux doit avoir Python 2.7 ou 3 installée. Utilisez la commande python --version ou python3 --version pour vérifier. Si vous utilisez Python 3, vérifiez que ce langage est défini comme commande par défaut sur votre machine, ou exécutez les scripts ci-dessous avec la commande « python3 » au lieu de « python ».
Le redirecteur de journal doit avoir le démon syslog-ng ou rsyslog activé.
Pour connaître les besoins en espace de votre redirecteur de journal, consultez le point de référence des performances de l’agent Azure Monitor. Vous pouvez également examiner ce billet de blog qui traite des conceptions pour une ingestion évolutive.
Vos sources de journal (vos appareils et appliances de sécurité) doivent être configurées pour envoyer leurs messages de journal au démon Syslog du redirecteur de journal au lieu de leur démon Syslog local.

Éviter la duplication de l’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 de 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 fonctionnalités envoyées en 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 la façon d’organiser une DCR pour ingérer les messages Syslog et CEF du même agent, consultez Flux Syslog et CEF dans la même DCR plus loin dans cet article.
Si la modification de la fonctionnalité 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 ci-dessous. Les données sont envoyées deux fois de l’ordinateur collecteur à l’espace de travail :
```
source |
where ProcessName !contains "CEF"
```

Considérations relatives à la sécurité du redirecteur de journal

Veillez à configurer la sécurité de la machine en fonction de la stratégie de sécurité de votre organisation. Par exemple, vous pouvez configurer votre réseau de sorte qu’il s’accorde à la stratégie de sécurité de votre réseau d’entreprise, et modifier les ports et les protocoles dans le démon pour les adapter à vos besoins. Pour améliorer la configuration de la sécurité de votre ordinateur, sécurisez votre machine virtuelle dans Azure ou passez en revue ces meilleures pratiques pour la sécurité réseau.

Si vos appareils envoient des journaux Syslog et CEF sur TLS (par exemple, parce que votre redirecteur de journal se trouve dans le cloud), vous devez configurer le démon Syslog (rsyslog ou syslog-ng) pour qu’il communique dans TLS :

Installer l’AMA et créer une règle de collecte de données (DCR)

Syslog
CEF

Vous pouvez effectuer cette étape de deux manières :

Déployez et configurez le connecteur de données Syslog via AMA dans le portail Microsoft Sentinel. Avec cette configuration, vous pouvez créer, gérer et supprimer les DCR par espace de travail. L’AMA est installé automatiquement sur les machines virtuelles que vous sélectionnez dans la configuration du connecteur.
—OU—
Envoyez des requêtes HTTP à l’API d’ingestion des 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 en fonction de niveaux de journalisation spécifiques, où avec l’interface utilisateur, vous ne pouvez sélectionner qu’un niveau de journalisation minimal. L’inconvénient est que vous devez installer manuellement l’agent Azure Monitor sur le redirecteur de journal avant de créer une DCR.

Sélectionnez l’onglet approprié ci-dessous pour afficher les instructions de chaque façon.

Ouvrez la page du connecteur et démarrez l’Assistant DCR

Ouvrez le portail Azure et accédez au service Microsoft Sentinel.
Sélectionnez Connecteurs de données dans le menu de navigation
Tapez Syslog dans la zone Recherche. Dans les résultats, sélectionnez le connecteur Syslog via AMA.
Sélectionnez Ouvrir la page du connecteur dans le volet d’informations.
Dans la zone Configuration, sélectionnez +Créer une règle de collecte de données.
Sous l’onglet De base :
- Tapez un nom de DCR.
- Sélectionnez votre abonnement.
- Sélectionnez le groupe de ressources dans lequel vous souhaitez localiser votre DCR.
Sélectionnez Suivant : Ressources>.

Définir les ressources (machines virtuelles)

Sous l’onglet Ressources, sélectionnez les machines sur lesquelles vous souhaitez installer l’AMA, dans ce cas, votre machine de redirecteur de journal. (Si votre redirecteur de journal n’apparaît pas dans la liste, il ne dispose peut-être pas de l’agent Azure Connected Machine installé.)

Utilisez les filtres disponibles ou la zone de recherche pour rechercher votre machine virtuelle de redirecteur de journal. Vous pouvez développer un abonnement dans la liste pour afficher ses groupes de ressources et un groupe de ressources pour afficher ses machines virtuelles.
Sélectionnez la machine virtuelle du redirecteur de journal sur laquelle vous souhaitez installer l’AMA. (La case à cocher s’affiche en regard du nom de la machine virtuelle lorsque vous pointez dessus.)
Passez en revue vos modifications et sélectionnez Suivant : Collecter >.

Sélectionner les installations et les gravités et créer la DCR

Remarque

L’utilisation de la même installation pour les messages Syslog et CEF peut entraîner une duplication de l’ingestion de données. Découvrez comment éviter la duplication de l’ingestion des données.

Dans l’onglet Collecter, sélectionnez le niveau minimal de journal pour chaque installation. Quand vous sélectionnez un niveau de journal, Microsoft Sentinel collecte les journaux pour le niveau sélectionné et les autres niveaux avec une gravité supérieure. Par exemple, si vous sélectionnez LOG_ERR, Microsoft Sentinel collecte les journaux pour les niveaux LOG_ERR, LOG_CRIT, LOG_ALERT et LOG_EMERG.
Passez en revue vos sélections, puis sélectionnez Suivant : Vérifier + créer.
Sous l’onglet Vérifier et créer, sélectionnez Créer.

Le connecteur installe l’agent Azure Monitor sur les machines que vous avez sélectionnées lors de la création de votre DCR.
Vous verrez des notifications à partir du portail Azure lorsque la DCR est créée et que l’agent est installé.
Sélectionnez Actualiser dans la page du connecteur pour voir la DCR affichée dans la liste.

Installer l’agent Azure Monitor

Suivez ces instructions, à partir de la documentation Azure Monitor, pour installer l’agent Azure Monitor sur votre redirecteur de journal. N’oubliez pas d’utiliser les instructions pour Linux, et non celles pour Windows.

Vous pouvez créer des règles de collecte de données (DCR) à l’aide de l’API d’ingestion des journaux Azure Monitor. En savoir plus sur les DCR.

Créer la règle de collecte de données

Préparez un fichier DCR au format JSON. Le contenu de ce fichier sera le corps de la demande dans votre demande d’API.

Pour obtenir un exemple, consultez le corps de la demande de création de DCR Syslog/CEF.
- Vérifiez que le champ streams est défini sur Microsoft-Syslog pour les messages Syslog ou sur Microsoft-CommonSecurityLog pour les messages CEF.
- Ajoutez les niveaux de journal des filtres et des installations dans les paramètres facilityNames et logLevels. Consultez les exemples ci-dessous.
Créez une demande d’API dans un client d’API REST de votre choix.
1. Pour l’URL et l’en-tête de la demande, copiez l’URL de la demande et l’en-tête ci-dessous en sélectionnant l’icône Copier dans le coin supérieur droit du cadre.
```
PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Insights/dataCollectionRules/{dataCollectionRuleName}?api-version=2022-06-01
```
  - Remplacez les valeurs appropriées pour les espaces réservés {subscriptionId} et {resourceGroupName}.
  - Entrez le nom de votre choix pour le DCR à la place de l’espace réservé {dataCollectionRuleName}.
2. Pour le corps de la demande, copiez et collez le fichier JSON DCR que vous avez créé (dans l’étape 1 ci-dessus) dans le corps de la demande.
Envoyez la demande.

Pour obtenir un exemple de réponse que vous devez recevoir, consultez Réponse de création de DCR Syslog/CEF

Associer le DCR au redirecteur de journal

Vous devez maintenant créer une association DCR (DCRA) qui lie la DCR à la ressource de machine virtuelle qui héberge votre redirecteur de journal.

Créez une demande d’API dans un client d’API REST de votre choix.
Pour l’URL et l’en-tête de la demande, copiez l’URL de la demande et l’en-tête ci-dessous en sélectionnant l’icône Copier dans le coin supérieur droit du cadre.
```
PUT 
https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/virtualMachines/{virtualMachineName}/providers/Microsoft.Insights/dataCollectionRuleAssociations/{dataCollectionRuleAssociationName}?api-version=2022-06-01
```
- Remplacez les valeurs appropriées pour les espaces réservés {subscriptionId}, {resourceGroupName} et {virtualMachineName}.
- Entrez le nom de votre choix pour le DCR à la place de l’espace réservé {dataCollectionRuleAssociationName}.
Pour le corps de la demande, copiez le corps de la demande ci-dessous en sélectionnant l’icône Copier dans le coin supérieur droit du cadre.
```
{
  "properties": {
    "dataCollectionRuleId": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Insights/dataCollectionRules/{dataCollectionRuleName}"
  }
}
```
- Remplacez les valeurs appropriées pour les espaces réservés {subscriptionId} et {resourceGroupName}.
- Entrez le nom de votre choix pour le DCR à la place de l’espace réservé {dataCollectionRuleName}.
Envoyez la demande.

Exemples de niveaux de journal des filtres et des installations

Passez en revue ces exemples de paramètres d’installations et de niveaux de journalisation. Le champ name inclut le nom du filtre.

Pour l’ingestion de message CEF, la valeur de "streams" doit être "Microsoft-CommonSecurityLog" au lieu de "Microsoft-Syslog".

Cet exemple collecte des événements à partir des installations cron, daemon, local0, local3 et uucp avec les niveaux de journalisation Warning, Error, Critical, Alert et Emergency :

    "dataSources": {
      "syslog": [
        {
        "name": "SyslogStream0",
        "streams": [
          "Microsoft-Syslog"
        ],
        "facilityNames": [ 
          "cron",
          "daemon",
          "local0",
          "local3", 
          "uucp"
        ],
        "logLevels": [ 
          "Warning", 
          "Error", 
          "Critical", 
          "Alert", 
          "Emergency"
        ]
      }
    ]
  }

Flux Syslog et CEF dans la même DCR

Cet exemple montre comment collecter des messages Syslog et CEF dans le même DCR.

Consultez Éviter la duplication d’ingestion de données plus haut dans cet article pour plus d’informations sur les étapes à suivre lors de l’ingestion de messages Syslog et CEF à l’aide d’un seul agent et d’une DCR.

La DCR collecte les messages d’événement CEF pour :

Les installations authpriv et mark avec les niveaux de journal Info, Notice, Warning, Error, Critical, Alert et Emergency
L’installation daemon avec les niveaux de journal Warning, Error, Critical, Alert et Emergency

Elle collecte les messages d’événement Syslog pour :

Les installations kern, local0, local5 et news avec les niveaux de journal Critical, Alert et Emergency
Les installations mail et uucp avec le niveau de journal Emergency

    "dataSources": {
      "syslog": [
        {
          "name": "CEFStream1",
          "streams": [ 
            "Microsoft-CommonSecurityLog"
          ],
          "facilityNames": [ 
            "authpriv", 
            "mark"
          ],
          "logLevels": [
            "Info",
            "Notice", 
            "Warning", 
            "Error", 
            "Critical", 
            "Alert", 
            "Emergency"
          ]
        },
        {
          "name": "CEFStream2",
          "streams": [ 
            "Microsoft-CommonSecurityLog"
          ],
          "facilityNames": [ 
            "daemon"
          ],
          "logLevels": [ 
            "Warning", 
            "Error", 
            "Critical", 
            "Alert", 
            "Emergency"
          ]
        },
        {
          "name": "SyslogStream3",
          "streams": [ 
            "Microsoft-Syslog"
          ],
          "facilityNames": [ 
            "kern",
            "local0",
            "local5", 
            "news"
          ],
          "logLevels": [ 
            "Critical", 
            "Alert", 
            "Emergency"
          ]
        },
        {
          "name": "SyslogStream4",
          "streams": [ 
            "Microsoft-Syslog"
          ],
          "facilityNames": [ 
            "mail",
            "uucp"
          ],
          "logLevels": [ 
            "Emergency"
          ]
        }
      ]
    }

Exécuter le script « installation »

Le script « installation » n’installe pas réellement quoi que ce soit, mais il configure correctement le démon Syslog sur votre redirecteur de journal pour collecter les journaux.

Sur la page du connecteur, copiez la ligne de commande qui s’affiche sous Exécutez la commande suivante pour installer et appliquer le collecteur CEF : en sélectionnant l’icône Copier située à côté.

Vous pouvez également la copier à partir d’ici :
```
sudo wget -O Forwarder_AMA_installer.py https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/DataConnectors/Syslog/Forwarder_AMA_installer.py&&sudo python Forwarder_AMA_installer.py
```
Connectez-vous à l’ordinateur du redirecteur de journal où vous venez d’installer l’AMA.
Collez la commande que vous avez copiée à la dernière étape pour lancer le script d’installation.
Le script configure le démon rsyslog ou syslog-ng pour qu’il utilise le protocole requis et redémarre le démon. Le script ouvre le port 514 pour écouter les messages entrants dans les protocoles UDP et TCP. Pour modifier ce paramètre, reportez-vous au fichier de configuration du démon Syslog en fonction du type de démon en cours d’exécution sur la machine :
- Rsyslog : /etc/rsyslog.conf
- Syslog-ng : /etc/syslog-ng/syslog-ng.conf
Remarque

Pour éviter les scénarios de disque complet dans lesquels l’agent ne peut pas fonctionner, nous vous recommandons de définir la configuration syslog-ng ou rsyslog pour ne pas stocker les journaux inutiles. Un scénario de disque complet interrompt le fonctionnement de l’AMA installé. En savoir plus sur RSyslog ou Syslog-ng.

Tester le connecteur

Pour vérifier que le démon syslog s’exécute sur le port UDP et que l’AMA écoute, exécutez cette commande :
```
netstat -lnptv
```
Le démon rsyslog ou syslog-ng devrait être à l’écoute sur le port 514.
Pour capturer les messages envoyés à partir d’un enregistreur d’événements ou d’un appareil connecté, exécutez cette commande en arrière-plan :
```
tcpdump -i any port 514 -A -vv &
```
Une fois la validation terminée, nous vous recommandons d’arrêter le tcpdump : tapez fg, puis sélectionnez Ctrl+C.
Pour envoyer des messages de démonstration, effectuez l’une des opérations suivantes :
- Utilisez l’utilitaire netcat. Dans cet exemple, l’utilitaire lit les données publiées via la commande echo avec le commutateur de nouvelle ligne désactivé. L’utilitaire écrit ensuite les données dans le port 514 UDP sur l’hôte local sans délai d’expiration. Pour exécuter l’utilitaire netcat, vous devrez peut-être installer un package supplémentaire.
```
echo -n "<164>CEF:0|Mock-test|MOCK|common=event-format-test|end|TRAFFIC|1|rt=$common=event-formatted-receive_time" | nc -u -w0 localhost 514
```
- Utilisez l’enregistreur d’événements. Cet exemple écrit le message dans l’installation local 4, au niveau de gravité Warning, sur le port 514, sur l’hôte local, au format RFC CEF. Les indicateurs -t et --rfc3164 sont utilisés pour se conformer au format RFC attendu.
```
logger -p local4.warn -P 514 -n 127.0.0.1 --rfc3164 -t CEF "0|Mock-test|MOCK|common=event-format-test|end|TRAFFIC|1|rt=$common=event-formatted-receive_time"
```

Pour vérifier que le connecteur est installé correctement, exécutez le script de résolution des problèmes avec l’une des commandes suivantes :

Pour les journaux CEF, exécutez :

 sudo wget -O Sentinel_AMA_troubleshoot.py https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/DataConnectors/Syslog/Sentinel_AMA_troubleshoot.py&&sudo python Sentinel_AMA_troubleshoot.py --cef

Pour les journaux d’activité Cisco Adaptive Security Appliance (ASA), exécutez :

sudo wget -O Sentinel_AMA_troubleshoot.py https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/DataConnectors/Syslog/Sentinel_AMA_troubleshoot.py&&sudo python Sentinel_AMA_troubleshoot.py --asa

Pour les journaux d’activité Cisco Firepower Threat Defense (FTD), exécutez :

sudo wget -O Sentinel_AMA_troubleshoot.py https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/DataConnectors/Syslog/Sentinel_AMA_troubleshoot.py&&sudo python Sentinel_AMA_troubleshoot.py --ftd

Ingérer des messages Syslog et CEF vers Microsoft Sentinel avec l’agent Azure Monitor

Vue d’ensemble

Qu’est-ce que Syslog ?

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

Comment Microsoft Sentinel collecte des messages Syslog et CEF avec l’agent Azure Monitor

Configurer les connecteurs de données

Configurer Syslog via le connecteur AMA

Configurer le connecteur Common Event Format (CEF) via AMA

Prérequis

Prérequis du redirecteur de journal

Éviter la duplication de l’ingestion de données

Considérations relatives à la sécurité du redirecteur de journal

Installer l’AMA et créer une règle de collecte de données (DCR)

Ouvrez la page du connecteur et démarrez l’Assistant DCR

Définir les ressources (machines virtuelles)

Sélectionner les installations et les gravités et créer la DCR

Ouvrez la page du connecteur et démarrez l’Assistant DCR

Définir les ressources (machines virtuelles)

Sélectionner les installations et les gravités et créer la DCR

Installer l’agent Azure Monitor

Créer la règle de collecte de données

Associer le DCR au redirecteur de journal

Exemples de niveaux de journal des filtres et des installations

Flux Syslog et CEF dans la même DCR

Exécuter le script « installation »

Tester le connecteur

Ressources supplémentaires