Ce guide explique comment configurer le transfert Syslog pour Microsoft Sentinel à l'aide de trois configurations courantes. Vous n'avez pas besoin d'être un expert de Linux pour suivre.
Qu'est-ce que Syslog
Syslog est un protocole de journalisation normalisé défini dans la RFC 5424 qui spécifie comment les messages de journalisation sont formatés et transmis sur un réseau.
Par défaut, Syslog utilise le port UDP 514, mais il peut également fonctionner via TCP, généralement sur le port 6514 lorsqu'il est sécurisé par TLS. Il s'agit d'un moyen léger et efficace de centraliser la journalisation à partir d'une grande variété de sources.
Syslog est largement pris en charge dans les domaines suivants :
Systèmes Unix/Linux
Appareils réseau tels que les pare-feux et les routeurs
De nombreux produits de sécurité et applications d'entreprise
Voici un exemple de message syslog brut :
<134>1 flux d'appliance 1515988859.626061236 src=172.21.84.107 dst=10.52.193.137 mac=5C:E0:C 5:22:85:E4 protocol=tcp sport=50395 dport=443 schéma : tout autoriser
Qu'est-ce que le transfert Syslog
Le transfert Syslog envoie des messages de journal depuis un appareil tel qu'un serveur, un routeur ou un pare-feu vers un système distant tel qu'un serveur de journaux ou un SIEM. Cela permet une journalisation centralisée pour faciliter la surveillance et l'analyse.
C'est particulièrement important car la plupart des pare-feux envoient des journaux au format Syslog.
Exemple de configuration Syslog de FortiGate
Qu'est-ce que Syslog Forwarder
Un redirecteur Syslog est généralement une machine Linux qui reçoit des journaux au format Syslog et les transmet via le réseau à une plateforme de surveillance telle qu'un SIEM. Certains redirecteurs peuvent également analyser, filtrer ou transformer les messages avant de les envoyer.
Les outils de transfert Syslog courants incluent rsyslog, syslog-ng, NxLog et Graylog.
Dans ce guide, nous utiliserons rsyslog, une option populaire et légère incluse par défaut dans la plupart des distributions Linux.
Transfert Syslog pour Microsoft Sentinel
À un niveau élevé, le transfert Syslog vers Microsoft Sentinel fonctionne comme suit :
La source de données (par exemple un pare-feu ou un serveur) est configurée pour envoyer des messages Syslog à une machine Linux exécutant un démon Syslog. Dans ce guide, il s'agit de rsyslog.
L'agent Azure Monitor (AMA) de cette machine collecte les messages Syslog.
L'AMA transmet ensuite les journaux à Microsoft Sentinel via une règle de collecte de données (DCR) configurée.
Vue de haut niveau du transfert Syslog pour MS Sentinel
Considérations
Avant de configurer un redirecteur Syslog, il convient de réfléchir à quelques points clés :
Volume de journaux : combien de journaux envoyez-vous ? La taille et les spécifications de votre machine virtuelle dépendront largement du débit des journaux.
Lieu de déploiement : vos redirecteurs fonctionneront-ils sur site ou dans le cloud ?
Fiabilité : une seule machine virtuelle est-elle suffisante ou avez-vous besoin d'une configuration à charge équilibrée pour une haute disponibilité ?
En production, il existe également d'autres considérations techniques, telles que l'UDP contre le TCP, le TLS mutuel, la liaison privée, l'inspection du trafic, le contrôle d'accès, l'audit, les alertes sur les sources silencieuses, etc.
Mais honnêtement, dans la plupart des cas, elles sont dictées par l'architecture globale de votre sécurité et de votre réseau. Si vous ne faites que commencer, ne vous inquiétez pas trop:)
Configuration de la démo
Dans cette démo, je vais vous présenter une configuration de réseau virtuel simple et unique :
Une machine virtuelle Ubuntu génère des journaux au format syslog.
Une autre machine virtuelle Ubuntu, exécutant rsyslog, reçoit ces journaux.
Cette machine virtuelle transmet ensuite les journaux à Microsoft Sentinel à l'aide de l'agent Azure Monitor.
Pas de complexité, pas de HA, pas de Bicep, pas de Terraform, juste un exemple simple pour montrer comment fonctionne le transfert syslog de bout en bout.
configuration de démonstration VNET unique
[FACULTATIF] Générateur Syslog
Cette étape est facultative, mais utile pour les tests. Vous pouvez simuler le trafic Syslog à l'aide d'outils tels que Logger, Echo ou en exportant des données depuis une application qui prend en charge la sortie Syslog.
Nous allons commencer par créer une machine virtuelle qui générera des messages Syslog. Pour cette démonstration, nous utiliserons une machine virtuelle Standard_D2LS_v5 (2 processeurs virtuels, 4 Go de mémoire).
Accédez à portal.azure.com → Machines virtuelles → Créer.
Vous trouverez ci-dessous les principaux paramètres de configuration sur lesquels vous devez vous concentrer. Nous ignorerons les paramètres par défaut et ne mettrons en évidence que ce qui compte.
Sélectionnez Ubuntu Server 22.04 :
Ubuntu 22.04
2. Réglez les ports du réseau public sur « Aucun » (nous y reviendrons plus tard) :
Aucun port entrant public
3. FACULTATIF : activez l'arrêt automatique sous Gestion :
Arrêt automatique en option
Créez la machine virtuelle. Il vous sera demandé de télécharger une clé SSH.
4. Générez un script qui génère des données syslog factices. Le script ci-dessous fera l'affaire :
prise d'importation
heure d'importation
importation aléatoire
# Configuration
SYSLOG_SERVER = 'ADRESSE IP DE VOTRE COLLECTIONNEUR' # Changez l'adresse IP de votre serveur Syslog
SYSLOG_PORT = 514 # Port UDP Syslog
EPS = 20 # événements par seconde
ÉTABLISSEMENT = 20 # local4
GRAVITÉ = 6 # informatif
PRI = (ÉTABLISSEMENT * 8) + GRAVITÉ
# Exemples de pools de données
source_ips = ['172.21.84.107', '192.168.1.10', '10.0.0.55', '192.168.100.23']
dest_ips = ['10.52.193.137', '8.8.8.8', '172.16.0.1', '192.168.1.100']
macs = ['5C:E0:C 5:22:85:E4', '00:1 A:2B:3C:4D:5E', 'D4:EE : 07:11:22:33']
protocoles = ['tcp', 'udp', 'icmp']
actions = ['Tout autoriser', 'Tout refuser', 'Autoriser HTTP', 'Refuser FTP']
def get_local_ip () :
« Essayez d'obtenir l'adresse IP locale utilisée pour accéder au SERVEUR SYSLOG_SERVER »
essayez :
s = socket.socket (Socket.AF_INET, Socket.SOCK_DGRAM)
# N'a pas besoin d'être joignable ; juste pour obtenir l'interface sortante
s.connect ((SYSLOG_SERVER, SYSLOG_PORT))
local_ip = s.getsockname () [0]
s.fermer ()
renvoie local_ip
sauf exception :
renvoie '0.0.0.0'
def generate_syslog_message () :
horodatage = time.time ()
version = 1
device_type = « appareil »
log_type = « flux »
src_ip = choix aléatoire (source_ips)
dst_ip = choix aléatoire (dest_ips)
mac = choix aléatoire (macs)
protocole = random.choice (protocoles)
sport = random.randint (1024, 65535) si le protocole est dans ['tcp', 'udp'] sinon 0
dport = random.choice ([80, 443, 53, 22, 0]) si le protocole est dans ['tcp', 'udp'] sinon 0
modèle = choix aléatoire (actions)
msg = (f"< {PRI} > {version} {horodatage : .9f} {type d'appareil} {log_type} »
« src= {src_ip} dst= {dst_ip} mac= {mac} protocol= {protocole} »
« fsport= {sport} dport= {sport} modèle : {modèle} »)
renvoyer le message
def send_syslog_messages (eps) :
sock = socket.socket (Socket.AF_INET, Socket.SOCK_DGRAM)
intervalle = 1,0/eps
adresse_locale = obtenir_adresse_locale ()
print (« Envoi de messages Syslog depuis {eps} EPS vers {SYSLOG_SERVER} : {SYSLOG_PORT}... (Appuyez sur Ctrl+C pour arrêter) »)
essayez :
alors que c'est vrai :
msg = generate_syslog_message ()
sock.sendto (msg.encode (), (SYSLOG_SERVER, SYSLOG_PORT))
print (« Envoyé de {local_ip} à {SYSLOG_SERVER} : {msg} »)
time.sleep (intervalle)
sauf KeyboardInterrupt :
print (»\nArrêté par l'utilisateur. »)
enfin :
sock.close ()
si __name__ == « __main__ » :
envoi_syslog_messages (EPS)
5. Accédez à « Paramètres réseau » et créez une nouvelle règle de port entrant pour autoriser le SSH sur le port 22 à partir de votre adresse IP :
Exemple de règle NSG autorisant SSH dans
6. Utilisez SSH pour vous connecter à votre machine virtuelle :
ssh -i « votre-clé-ssh » votre-nom d'utilisateur @public -ip-of-your-vm
7. Créez un fichier .py à l'aide d'un éditeur de texte, par exemple nano :
nano syslog_generator.py
8. Collez le contenu du script dans le fichier, remplacez l'adresse IP par l'adresse IP de votre collecteur et enregistrez. Exécutez le fichier pour vérifier s'il fonctionne correctement. La sortie de la console doit se présenter comme suit :
python3 syslog_generator.py
Exemple de sortie de console
Parfait Notre script générateur Syslog fonctionne. Nous allons maintenant créer des redirecteurs Syslog.
Scénarios de redirecteur Syslog
Scénario 1 : Single Syslog Forwarer alias « Big Boy »
Parfois, vous voulez simplement faire simple et je respecte cela. Un serveur de grande taille faisant office de redirecteur Syslog dédié. Cette configuration fonctionne bien pour :
Démonstrations et tests
Environnements de production plus petits
Environnements présentant un volume d'événements prévisible ou faible
Un élément essentiel à garder à l'esprit : le transfert des journaux vers Microsoft Sentinel s'effectue via Azure Monitor Agent (AMA), dont la limite recommandée est de 10 000 événements par seconde (EPS) par agent. Bien qu'il puisse techniquement gérer jusqu'à 20 000 EPS, le plafond pris en charge et recommandé est de 10 000 EPS.
📚 Conseils de performance de l'AMA
Cela signifie qu'une architecture à redirecteur unique ne peut être un bon choix que si le volume total de votre Syslog entrant reste inférieur à ce seuil. Si tel est le cas, la configuration « Big Boy » est simple et fait le travail.
Configuration d'une machine virtuelle Syslog unique.
Scénario 2 : machines virtuelles à charge équilibrée
Pour les environnements de production, une configuration de redirecteur Syslog à charge équilibrée constitue un choix judicieux. Cela implique le déploiement de deux machines virtuelles ou plus derrière un équilibreur de charge Azure interne, chacune exécutant un démon syslog tel que rsyslog.
Cette approche offre :
Fiabilité et évolutivité améliorées
Redondance, en cas de panne d'un transitaire
Une voie claire vers une mise à l'échelle horizontale si le volume de log augmente
C'est particulièrement efficace lorsque les volumes de journaux sont prévisibles (et honnêtement, ils le sont dans la plupart des environnements). Cette configuration offre un bon équilibre entre simplicité et préparation à la production.
VM à charge équilibrée
Scénario 3 : ensemble d'échelle de machines virtuelles à charge équilibrée (VMSS)
Un ensemble d'échelle de machines virtuelles (VMSS) est un groupe dynamique de machines virtuelles qui peuvent automatiquement évoluer vers ou vers la sortie en fonction de l'utilisation des ressources, telle que la charge du processeur ou des mesures personnalisées.
Dans le contexte du transfert Syslog, cela signifie :
Lorsque la charge sur les redirecteurs existants dépasse un seuil défini, une nouvelle machine virtuelle est automatiquement ajoutée pour gérer le trafic.
Lorsque la charge diminue, les machines virtuelles sont déprovisionnées, ce qui permet de réduire les coûts et de maintenir l'efficacité du système.
Cette configuration combine évolutivité, résilience et automatisation, ce qui la rend idéale pour les environnements plus grands ou plus dynamiques où le volume de journaux peut augmenter ou fluctuer. Le VMSS est placé derrière un équilibreur de charge interne, comme dans le scénario de machine virtuelle fixe, mais avec une élasticité accrue.
VMSS à charge équilibrée
Big Boy (machine virtuelle unique)
Pour déployer un seul redirecteur Syslog, suivez les mêmes étapes que celles décrites précédemment pour créer la machine virtuelle du générateur de Syslog, mais cette fois, elle agira en tant que redirecteur.
Créez la machine virtuelle :
Accédez à portal.azure.com → Machines virtuelles → Créer.
Choisissez Ubuntu 22.04 LTS comme image.
Sélectionnez une taille en fonction du volume de journal attendu (par exemple, Standard_D2S_v3 ou supérieur).
2. Installez le connecteur Syslog dans Sentinel :
Installation du pack de contenu Syslog
3. Créez un DCR :
Accédez à Microsoft Sentinel et ouvrez votre espace de travail.
Dans le menu de gauche, sélectionnez Connecteurs de données.
Recherchez « Syslog via AMA » dans la liste et cliquez pour ouvrir la page du connecteur.
Cliquez sur Créer un DCR pour démarrer le processus de configuration.
Les règles de collecte de données (DCR) définissent quelles données sont collectées et à partir de quelles ressources.
Dans l'assistant, sélectionnez la machine virtuelle que vous venez de déployer comme ressource à partir de laquelle effectuer la collecte.
Sélecteur de ressources
Ensuite, dans la section Collecter, choisissez les types de messages Syslog que vous souhaitez collecter.
Pour cette démonstration, je sélectionne LOG_LOCAL4 comme fonction et LOG_DEBUG comme niveau de gravité, car c'est là que mon script écrit les journaux.
Dans une configuration de production, cela peut varier en fonction de l'appareil ou de l'application source.
Si vous n'êtes pas sûr, vous pouvez d'abord sélectionner toutes les installations et toutes les sévérités, puis les affiner ultérieurement en fonction de ce que vous recevez réellement.
Sélecteur d'installation/de gravité
Créez la règle de collecte de données. Il déploiera automatiquement l'agent Azure Monitor sur votre serveur Syslog.
3. Connectez-vous à votre machine virtuelle via SSH et exécutez ce script :
sudo wget -O Forwarder_AMA_installer.py https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/DataConnectors/Syslog/Forwarder_AMA_installer.py&&sudo python3 Forwarder_AMA_installer.py
Script exécuté avec succès
Ce script va :
Détecter si rsyslog ou syslog-ng est en cours d'exécution
Activez les écouteurs TCP/UDP sur le port 514.
Redémarrez le démon approprié pour appliquer les modifications.
La configuration est terminée et nous pouvons tester le transfert.
Important : dans cet environnement de démonstration, le trafic est envoyé au sein d'un seul réseau virtuel. Les groupes de sécurité réseau (NSG) autorisent le trafic inter-réseaux virtuels. Si vous envoyez un Syslog depuis l'extérieur de votre réseau virtuel, vous devez l'autoriser sur NSG :
Autoriser les journaux provenant de l'extérieur du VNET
VM à charge équilibrée
Un équilibreur de charge distribue le trafic entre les machines virtuelles de son pool principal, ce qui le rend idéal pour la haute disponibilité et la mise à l'échelle horizontale.
Vous pouvez ajouter une seule machine virtuelle au pool principal à des fins de test, mais en production, vous aurez probablement besoin d'au moins deux machines virtuelles de transfert. Si nécessaire, suivez les mêmes étapes que précédemment pour créer une machine virtuelle de redirection Syslog supplémentaire.
Accédez au portail Azure, recherchez des équilibreurs de charge et créez un nouvel équilibreur de charge standard.
Cela sera utilisé pour acheminer le trafic syslog entrant (UDP/TCP 514) sur les machines virtuelles de votre redirecteur.
Configuration de l'équilibreur de charge interne :
Dans la section Principes de base de la configuration de l'équilibreur de charge, sélectionnez SKU : Standard et Type : Internal.
Cela crée un équilibreur de charge interne uniquement, idéal pour recevoir du trafic en provenance de périphériques au sein d'un même réseau virtuel.
Si vous devez accepter du trafic provenant de l'extérieur de votre réseau virtuel (par exemple, depuis des périphériques sur site ou des sources externes), vous pouvez choisir Type : Public à la place et associer une adresse IP publique à l'équilibreur de charge.
Onglet « Principes de base » de Load Balancer
Créez une configuration IP frontale et choisissez une adresse IP dynamique.
Ensuite, accédez à la section Pools principaux et sélectionnez la ou les machines virtuelles que vous souhaitez inclure dans le pool.
Il s'agira de vos redirecteurs Syslog qui recevront le trafic du Load Balancer.
Exemple de pool dorsal
Accédez à Règles entrantes et sélectionnez « Ajouter une règle d'équilibrage de charge » :
Adresse IP du frontend : votre configuration IP du frontend
pool backend : votre pool backend
Protocole : UDP
Hafen : 514
Port principal : 514
Créez une sonde d'intégrité qui vérifie le port TCP 514.
Le script de configuration que nous utilisons lors de la configuration du démon syslog sur chaque machine virtuelle ouvre à la fois les ports UDP et TCP 514, afin que la sonde puisse vérifier la disponibilité de la machine virtuelle.
Une fois la sonde configurée, créez le Load Balancer.
La configuration de votre machine virtuelle à charge équilibrée pour le transfert Syslog est maintenant prête à être testée.
Reportez-vous aux étapes de la section « Tester les scénarios du redirecteur Syslog » pour vérifier que les journaux sont correctement reçus et transférés.
VMSS à charge équilibrée
À ce stade, nous avons expliqué comment créer un équilibreur de charge et configurer des redirecteurs Syslog pour relayer les journaux vers Microsoft Sentinel.
Si vous souhaitez plus de flexibilité et la capacité de gérer les pics de volume de journaux, pensez à utiliser un Virtual Machine Scale Set (VMSS). VMSS est un groupe de machines virtuelles qui peuvent automatiquement évoluer (ajouter des instances) ou augmenter (supprimer des instances) en fonction de l'utilisation des ressources.
Configurer Azure Policy pour installer automatiquement Azure Monitor Agent sur VMSS
Cette étape garantit que toutes les nouvelles instances de machine virtuelle créées dans le cadre de l'ensemble d'échelles sont automatiquement configurées avec :
L'agent Azure Monitor (AMA) est installé.
La règle de collecte de données (DCR) correcte associée.
En d'autres termes, cela garantit que l'agent responsable de l'envoi des journaux est présent et sait ce qu'il faut collecter et où l'envoyer.
Pour configurer la politique, procédez comme suit :
Accédez à Azure Policy sur le portail.
Recherchez « Activer Azure Monitor pour VMSS avec Azure Monitoring Agent (AMA) ».
Cliquez sur Attribuer.
Définissez la portée, idéalement uniquement le groupe de ressources qui contient votre VMSS.
Activez l'application des politiques pour garantir la conformité.
Une fois attribuée, cette politique appliquera automatiquement la configuration AMA et DCR à toute instance de machine virtuelle créée dans le cadre de l'échelle définie.
Accédez à « Paramètres » et sélectionnez :
Apportez votre propre identité gérée attribuée par l'utilisateur : false
ID de ressource de la règle de collecte de données VMI : votre identifiant de ressource DCRs
La configuration de « false » pour le premier paramètre créera une identité gérée attribuée au système. Dans les environnements de production, ce n'est pas idéal, mais convient parfaitement aux tests à petite échelle.
Pour obtenir l'ID de ressource du DCR, accédez à la ressource DCR, cliquez sur « Affichage JSON » et copiez l'ID de ressource en haut de la page :
ID de ressource DCR
2. Créez un ensemble de balances pour machines virtuelles :
Accédez au portail Azure, recherchez les ensembles d'échelles de machines virtuelles et sélectionnez Créer.
Dans l'assistant de configuration, définissez le mode de mise à l'échelle sur Autoscaling.
Choisissez Ubuntu Server 22.04 comme image.
Sélectionnez Standard_D2LS_V5 comme taille de machine virtuelle.
Cette configuration fournit une base de référence solide pour le transfert Syslog avec une marge de manœuvre suffisante pour évoluer en fonction de la charge.
Interface utilisateur « Basics » de VMSS
Le paramètre obligatoire suivant est l'activation de la « surveillance de l'état des applications ». Pour la mise à l'échelle orchestrée par Azure, cela doit être fait. Utilisez les paramètres suivants :
États de santé : Binaire - sain ou malsain
Protocole : TCP
Numéro de port : 514
Et l'élément le plus important pour configurer correctement le Scale Set de votre machine virtuelle est probablement le script cloud-init. Vous souhaitez exécuter le script de configuration syslog dès qu'une nouvelle machine virtuelle est provisionnée afin qu'elle soit prête à fonctionner immédiatement. Sous Avancé, collez-le dans « Données personnalisées » :
#cloud -config
exécutez cmd :
- wget -O /tmp/Forwarder_AMA_installer.py https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/DataConnectors/Syslog/Forwarder_AMA_installer.py
- python3 /tmp/Forwarder_AMA_installer.py
Parfait Nous pouvons maintenant créer le VMSS.
Tester les scénarios du redirecteur Syslog
Dans le script de votre générateur Syslog, mettez à jour la variable SYSLOG_SERVER pour qu'elle corresponde à l'adresse IP privée de votre machine virtuelle de transfert Syslog ou de votre équilibreur de charge (si vous en utilisez un).
Variables de script
Exécutez le script sur la machine virtuelle du générateur Syslog :
python3 syslog_generator.py
Ensuite, validez si les journaux sont reçus sur le redirecteur syslog en exécutant tcmdump :
tcpdump -i n'importe quel port 514 -A -vv &
Vous devriez voir une sortie comme dans la capture d'écran ci-dessous.
Les journaux affluent
La dernière étape consiste à vérifier si ces journaux sont reçus dans Microsoft Sentinel. Accédez à Sentinel -> Logs et tapez « Syslog » :
Les journaux sont arrivés à Microsoft Sentinel
Dans ce guide, nous avons décrit le processus de configuration du transfert Syslog vers Microsoft Sentinel à l'aide de plusieurs scénarios de déploiement. En commençant par une simple machine virtuelle unique (« Big Boy »), nous avons ensuite exploré des configurations plus évolutives et prêtes pour la production en utilisant des machines virtuelles à charge équilibrée et des ensembles d'échelle de machines virtuelles (VMSS).
Nous avons abordé des concepts clés tels que :
Ce que sont le syslog et le transfert de données syslog, et pourquoi ils sont importants pour la surveillance de la sécurité.
Comment configurer un redirecteur Syslog basé sur Linux à l'aide de rsyslog et d'Azure Monitor Agent (AMA).
Comment configurer les règles de collecte de données (DCR) et connecter vos redirecteurs à Microsoft Sentinel.
Comment utiliser Azure Load Balancer et Azure Policy pour automatiser et faire évoluer votre infrastructure de journalisation.
Que vous mettiez en place un environnement de test rapide ou que vous posiez les bases d'un déploiement de production, ces étapes vous permettent de garantir que vos journaux circulent de manière fiable dans Microsoft Sentinel, même si vous n'êtes pas un « utilisateur Linux ».
.svg){kind=small}
.svg){kind=small}
.svg){kind=small}
