Vous pouvez utiliser les outils de cet article pour centraliser vos journaux d’événements Windows à partir de plusieurs serveurs et bureaux. En administrant correctement vos journaux, vous pouvez suivre l’état de vos systèmes, sécuriser vos fichiers journaux et filtrer le contenu pour trouver des informations spécifiques.
- Pourquoi Centraliser les Journaux ?
- Abonnement aux événements Windows
- Exemple de système
- Configuration
- Activer le Service de gestion à distance Windows
- Configurer le Service Collecteur d’événements Windows
- Configurez le groupe de lecteurs de journaux d’événements
- Configurer le Pare-feu Windows
- Créer un abonnement
- Vérifiez les événements sur l’ordinateur collecteur
- Créer une vue personnalisée (Facultatif)
- Services de journalisation Windows
- Installer NXLog
- Configure NXLog
- Journaux de fichiers
- Journaux IIS
- Journaux d’erreurs SQL Server
- Transfert des journaux vers un serveur
- Chiffrer les journaux avec TLS
Pourquoi Centraliser les Journaux ?
La centralisation de vos journaux permet de gagner du temps et d’augmenter la fiabilité de vos données de journaux. Lorsque les fichiers journaux Windows sont stockés localement sur chaque serveur, vous devez vous connecter individuellement à chacun d’eux pour les parcourir et rechercher les erreurs ou les avertissements. Si le serveur ne répond pas, vous pourriez avoir de la chance. Si vous ne savez pas quels serveurs sont affectés, vous devez parcourir chacun d’eux, ce qui peut prendre beaucoup de temps sur les grands réseaux. Les fichiers journaux sont également plus sûrs dans un emplacement centralisé car même lorsque vos instances sont terminées ou que vos fichiers sont supprimés (intentionnellement ou non), les copies de sauvegarde centralisées de vos journaux ne sont pas affectées.
Abonnement aux événements Windows
Il est possible pour un serveur Windows de transférer ses événements vers un serveur collecteur. Dans ce scénario, le serveur collecteur devient un référentiel central pour les journaux Windows provenant d’autres serveurs (appelés sources d’événements) du réseau. Le flux d’événements d’une source à un collecteur s’appelle un abonnement.
Cette procédure montre comment la configurer. Ces étapes fonctionnent sur Windows Server 2008 R2, Windows Server 2012 et Windows Server 2019.
Exemple de système
Nous utilisons deux systèmes Windows Server 2012 associés au domaine Active Directory. Le nom de domaine est mytestdomain.com et les deux machines sont enregistrées avec le domaine.
Serveur source MYTESTSQL héberge une instance SQL Server 2014. Collector server MYTESTSERVER fonctionne en tant qu’abonné au journal des événements pour centraliser tous les journaux liés à SQL Server à partir de MYTESTSQL.
Configuration
Activer le Service de gestion à distance Windows
La gestion à distance Windows (WinRM) est un protocole permettant d’échanger des informations entre les systèmes de votre infrastructure. Vous devez l’activer sur chacun de vos ordinateurs sources pour échanger des fichiers journaux.
- Connectez-vous à distance à l’ordinateur source (MYTESTSQL) en tant qu’administrateur local ou de domaine.
- Activer le Service de gestion à distance Windows à partir d’une invite de commande :
winrm quickconfig
S’il est déjà en cours d’exécution, un message similaire à cet exemple s’affiche.
Configurer le Service Collecteur d’événements Windows
Vous devez activer le Service Collecteur d’événements Windows sur votre serveur collecteur pour lui permettre de recevoir les journaux de vos sources.
- Connectez-vous à distance à l’ordinateur collecteur (MYTESTSERVER) en tant qu’administrateur local ou de domaine.
- Configurez le service Collecteur d’événements Windows à partir d’une invite de commande :
wecutil qcin
Si vous y êtes invité comme dans l’exemple, appuyez sur y
Configurez le groupe de lecteurs de journaux d’événements
Par défaut, certains journaux sont réservés aux administrateurs. Cela peut causer des problèmes lors de la réception des journaux d’autres systèmes. Pour éviter cela, vous pouvez accorder l’accès à l’ordinateur collecteur en l’ajoutant au groupe Lecteurs de journaux d’événements.
- Retournez à l’ordinateur source (MYTESTSQL).
- Ouvrez le gestionnaire de serveur.
- Gestion ouverte de l’ordinateur.
- Développez le nœud Utilisateurs et groupes locaux dans le volet de navigation et sélectionnez Groupes.
- Double-cliquez sur Lecteurs de journaux d’événements.
- Cliquez sur Ajouter pour ouvrir la boîte de dialogue Sélectionner des utilisateurs, des ordinateurs, des comptes de service ou des groupes.
- Cliquez sur Types d’objets.
- Vérifiez Ordinateurs et cliquez sur OK.
- Entrez MYTESTSERVER comme nom d’objet et cliquez sur Vérifier les noms. Si le compte d’ordinateur est trouvé, il est confirmé par un soulignement.
- Cliquez deux fois sur OK pour fermer les boîtes de dialogue.
Configurer le Pare-feu Windows
Si l’ordinateur source exécute le Pare-feu Windows, assurez-vous qu’il permet la gestion à distance du journal des événements et le trafic de Surveillance des événements à distance.
Créer un abonnement
Les abonnements définissent la relation entre un collecteur et une source. Vous pouvez configurer un collecteur pour qu’il reçoive des événements provenant de n’importe quel nombre de sources (un abonnement initié par une source) ou spécifier un ensemble limité de sources (un abonnement initié par un collecteur). Dans cet exemple, nous créons un abonnement initié par le collecteur car nous savons quels journaux d’ordinateur nous voulons recevoir.
- Démarrez l’application d’observateur d’événements sur le serveur de collecteur MYTESTSERVER.
- Sélectionnez Abonnements dans le volet de navigation
- Cliquez sur Créer un abonnement dans le volet Actions.
- Dans les Propriétés de l’abonnement, entrez les éléments suivants comme indiqué dans l’exemple :
Nom de l’abonnement : MYTESTSQL_EVENTS
Description : Événements du serveur source distant MYTESTSQL
Journal de destination: Événements transférés
Sélectionnez Collecteur lancé et cliquez sur Sélectionner des ordinateurs pour ouvrir la boîte de dialogue Ordinateurs.
- Cliquez sur Ajouter des ordinateurs de domaine.
- Entrez MYTESTSQL comme nom d’objet et cliquez sur Vérifier les noms. Si l’ordinateur est trouvé, il est confirmé par un soulignement.
- Cliquez sur OK.
- Cliquez sur OK pour revenir aux propriétés de l’abonnement.
- Cliquez sur Sélectionner des événements pour ouvrir le filtre de requête et entrez les éléments suivants pour configurer le serveur distant pour transférer tous les événements d’application des 24 dernières heures :
Enregistré: Dernières 24 heures
Vérifier tous les niveaux d’événements
Sélectionner par journal
Journaux d’événements : Sélectionnez l’application dans la liste déroulante
- Cliquez sur OK pour revenir aux propriétés de l’abonnement.
- Cliquez sur Avancé pour ouvrir les Paramètres d’abonnement avancés et entrez les éléments suivants :
Sélectionnez Compte machine
Sélectionnez Minimiser la latence
Protocole: Port HTTP
: 5985
- Cliquez sur OK pour revenir aux propriétés de l’abonnement.
- Cliquez sur OK pour fermer.
Le nœud d’abonnement dans l’observateur d’événements de l’ordinateur collecteur affiche maintenant le nouvel abonnement.
Vérifiez les événements sur l’ordinateur collecteur
Sélectionnez Événements transférés dans le volet de navigation de l’ordinateur collecteur.
La colonne Ordinateur du volet Détails indique que les événements proviennent de l’ordinateur distant MYTESTSQL.MYTESTDOMAIN.COM . Vous pouvez activer ou désactiver l’abonnement au collecteur en cliquant avec le bouton droit de la souris sur l’abonnement et en choisissant Désactiver. L’état de l’abonnement est alors affiché comme désactivé dans la fenêtre principale. Un abonnement collecteur actif ne signifie pas qu’il réussit. Pour voir si le collecteur peut se connecter à la source, cliquez avec le bouton droit sur l’abonnement et sélectionnez État d’exécution. Dans cet exemple, le collecteur ne peut pas se connecter à la source. Par défaut, il réessaie toutes les cinq minutes.
Si tout est OK, le statut d’exécution de l’abonnement affiche une coche verte avec un statut actif.
Créer une vue personnalisée (Facultatif)
Une fois les événements transférés, vous pouvez créer des vues personnalisées pour afficher les événements consolidés. Par exemple, vous pouvez créer une vue personnalisée pour les événements d’erreur. Cet exemple crée une vue personnalisée pour les messages liés à SQL Server. Un ordinateur collecteur peut héberger des milliers d’enregistrements provenant de dizaines de serveurs. L’utilisation d’une vue personnalisée vous permet de créer une commande à partir d’une surcharge d’informations. Pour des étapes détaillées, reportez-vous à la section Création d’une vue personnalisée dans les bases de la journalisation Windows.
Services de journalisation Windows
Il existe plusieurs services Windows que vous pouvez utiliser pour centraliser toutes vos données de journalisation vers un service de journalisation externe. Ces services envoient des journaux via syslog à un serveur de journaux multiplateforme ou à un service de journalisation basé sur le cloud tel que SolarWinds® Loggly®.
Nous recommandons NXLog, un service populaire téléchargeable gratuitement qui fonctionne en arrière-plan. Alternativement, il y a syslog-ng et Snare, qui sont des services qui collectent vos fichiers journaux. Tous ces services fournissent un soutien professionnel supplémentaire moyennant des frais.
Installer NXLog
Cet exemple installe et configure NXlog pour empaqueter vos fichiers journaux.
Téléchargez et installez la version actuelle de NXlog. Le téléchargement comprend un programme d’installation intuitif. Une fois l’installation terminée, ouvrez le fichier de configuration. Par défaut, le fichier de configuration de NXLog se trouve à C:/Program Fichiers (x86) / nxlog/conf/nxlog.conf
Vous pouvez créer différents types de modules de configuration.
- Entrées pour la source de vos journaux
- Sorties pour l’endroit où envoyer les journaux
- Routes pour mapper vos entrées à vos sorties
Chaque fois que vous apportez des modifications au fichier de configuration NXlog, vous devez redémarrer le service NXlog.
Configure NXLog
Cet exemple modifie le fichier de configuration NXLog pour centraliser vos journaux d’événements Windows. Ajout de l’extrait de code ci-dessous à la fin de votre nxlog.le fichier conf active le module et lui donne le nom « eventlog ». Le module d’entrée im_msvistalog envoie de nouvelles entrées au journal des événements Windows, y compris les événements liés au système, au matériel, aux applications et à la sécurité.
# Windows Event Log<Input eventlog># Uncomment im_msvistalog for Windows Vista/2008 and laterModule im_msvistalog# Uncomment im_mseventlog for Windows XP/2000/2003# Module im_mseventlog# If you prefer to send events as JSON dataExec $Message = to_json();</Input>
Journaux de fichiers
NXLog peut être utilisé pour lire les fichiers de journaux stockés sur un lecteur. Dans cet exemple, le nom du fichier est FILE1. SavePos TRUE signifie que NXLog suivra son emplacement actuel dans le fichier journal à la sortie. ExecMessageMessage=raraw_event signifie que NXLog ingérera le message de journal brut sans appliquer de formatage supplémentaire. Le nom de fichier peut également inclure des répertoires ou des caractères génériques.
<Input FILE1>Module im_fileFile "FILE1"SavePos TRUEExec $Message = $raw_event;</Input>
Journaux IIS
Comme nous l’avons couvert dans la section Bases de la journalisation Windows, les journaux IIS contiennent des journaux d’accès stockés au format W3C. Nous vous recommandons de les convertir au format JSON pour un traitement facile par un outil de gestion des journaux. NXLog peut effectuer cette conversion en utilisant l’extension W3C. Assurez-vous d’utiliser le format approprié dans le fichier de configuration, de sorte que l’analyse se passe correctement et que vous incluez des fichiers journaux de tous vos sites.
<Extension w3c>Module xm_csvFields $date, $time, $s-ip, $cs-method, $cs-uri-stem, $cs-uri-query, $s-port, $cs-username, $c-ip, $csUser-Agent, $cs-Referer, $sc-status, $sc-substatus, $sc-win32-status, $time-takenFieldTypes string, string, string, string, string, string, integer, string, string, string, string, integer, integer, integer, integerDelimiter ' 'QuoteChar '"'EscapeControl FALSEUndefValue -</Extension># Convert the IIS logs to JSON and use the original event time<Input IIS_Site1>Module im_fileFile "C:/inetpub/logs/LogFiles/W3SVC1/u_ex*"SavePos TRUEExec if $raw_event =~ /^#/ drop();else{w3c->parse_csv();$SourceName = "IIS";$Message = to_json();}</Input>
Journaux d’erreurs SQL Server
SQL Server est la plate-forme de base de données phare de Microsoft. Il est livré dans une suite d’outils de base de données et d’entrepôt de données. SQL Server a généralement ses propres journaux enregistrés dans le répertoire d’installation de l’application dans le système de fichiers Windows. L’emplacement par défaut pour SQL Server 2012 est C:/Program Fichiers / Microsoft SQL Server / MSSQL11.MSSQLSERVER/MSSQL/Log. Les entrées de journal sont également envoyées au journal des événements de l’application Windows.
Les opérations SQL Server telles que la sauvegarde et la restauration, les délais d’attente des requêtes ou les E / S lentes sont donc faciles à trouver dans le journal des événements de l’application Windows, tandis que les messages liés à la sécurité tels que les tentatives de connexion échouées sont capturés dans le journal des événements de sécurité Windows.
Transfert des journaux vers un serveur
NXLog peut transférer les journaux de l’une des entrées décrites ci-dessus vers une destination externe, telle qu’un serveur de journaux ou un service de gestion des journaux basé sur le cloud. Pour ce faire, NXLog utilise des concepts appelés Sorties et routes. Les sorties sont des modules qui fournissent des fonctionnalités pour envoyer des journaux à une destination, telle qu’un fichier ou un serveur distant. Les routes sont les chemins qu’un message de journal emprunte d’une entrée (telle que le module im_msvistalog) à une sortie (telle qu’un service de gestion des journaux).
Pour transférer les journaux, ajoutez un module de sortie dans votre nxlog.fichier de configuration de la configuration. Ajoutez ensuite un module de routage pour envoyer les journaux des entrées que vous avez choisies aux sorties que vous avez choisies. Dans cet exemple, nous envoyons des journaux en tant que syslog sur TCP au NOM d’hôte de l’hôte sur le port syslog par défaut 514. Nous créons une route qui prend les journaux de l’entrée eventlog et l’envoie à la nouvelle sortie (nommée out):
<Output out>Module om_tcpHost HOSTNAMEPort 514</Output><Route 1>Path eventlog => out</Route>
Plusieurs solutions de gestion des journaux proposent des instructions de configuration spécifiques pour la journalisation Windows. Loggly est un exemple d’un fournisseur et contient des informations plus détaillées sur la configuration de NXLog pour rassembler vos fichiers journaux dans leur guide, Journalisation à partir de Windows.
Chiffrer les journaux avec TLS
Par défaut, les journaux envoyés sur Internet sont transmis en texte clair. Cela signifie que les fouineurs peuvent intercepter et afficher vos données de journal. Il est recommandé de chiffrer vos données de journal lorsqu’elles sont en transit, en particulier si elles contiennent des informations sensibles telles que des informations d’identification personnelles, des données réglementées par le gouvernement ou des informations financières. Le protocole le plus courant pour chiffrer la communication syslog est TLS, ou Transport Layer Security.
TLS crypte vos journaux, empêchant quiconque d’espionner les données sensibles dans vos journaux. La meilleure pratique est de ne pas enregistrer d’informations comme les mots de passe, mais certaines applications le font quand même. Le cryptage TLS permet de sécuriser ces données. Le cryptage empêche les parties malveillantes situées entre vos sources et destinations de journaux de lire ou de modifier vos données de journaux.
Voici un exemple de configuration de NXLog avec cryptage TLS pour Loggly.
- Téléchargez le certificat numérique de Loggly depuis la page de configuration TLS de NXLog.
- Copiez le fichier de certificat numérique dans votre répertoire de certificats NXLog :
copiez loggly_full.crt C:/Program Fichiers */nxlog/cert - Configurez votre module de sortie avec om_ssl et l’emplacement du certificat. Le port syslog par défaut pour les journaux chiffrés est 6514. AllowUntrusted FALSE empêche une connexion au serveur si le certificat n’est pas approuvé ou auto-signé:
<Output out>Module om_sslHost server.example.comPort 6514CAFile %CERTDIR%/example.crtAllowUntrusted FALSE<Output>