> Tech > L’essentiel de la supervision du réseau, 2e partie

L’essentiel de la supervision du réseau, 2e partie

Tech - Par Randy Franklin Smith - Publié le 24 juin 2010
email

Nous avons souligné combien il importe de superviser les serveurs, leurs applications, et l’équipement réseau, afin d’intercepter et de corriger les problèmes avant qu’ils n’affectent vos utilisateurs. Une bonne supervision de réseau est également précieuse pour deux autres raisons : savoir exactement ce qui se passe sur le réseau, qui y accède et quand.Dans la première partie de cette série, destinée aux PME (petites et moyennes entreprises), j’évoquais les avantages du travail en réseau et je recensais les sources les plus courantes que l’on peut superviser (par la télémesure), y compris les journaux d’événements Windows, Syslog et SNMP. Dans ce second article, j’explique comment construire une solution de supervision dépouillée à l’aide d’outils gratuits peu coûteux, évoluant autour du journal d’événements Windows. Plus précisément, je vous présente trois outils intéressants à ajouter à votre panoplie de supervision de réseau : Log Parser, un outil gratuit de Microsoft, tail, un utilitaire Unix simple d’emploi, et Kiwi Syslog Daemon, qui existe en édition gratuite et en édition plus puissante mais néanmoins abordable. Même si vous possédez déjà un outil ou si vous envisagez d’en acquérir un, poursuivez cette lecture : la plupart des outils du marché se limitent à des fonctions d’alerte et de reporting, parfois avec quelques rapports standard et des modèles de règles d’alerte. Il reste quand même à définir les rapports et alertes adaptés à votre environnement. Les méthodes de conception et d’analyse décrites ci-après seront très intéressantes même lorsqu’une application de supervision est déjà en place.

Avez-vous besoin d’un outil qui supervise les journaux d’événements Windows et vous signale (par courrier électronique ou pager) la présence d’événements correspondant à certains critères ? Pour mettre en place un mécanisme d’alerte personnalisé, je vous conseille d’utiliser VBScript et WMI (Windows Management Instrumentation). Dans « UseWMI to Monitor Your Web Site for Changes » (www.itpro.fr Club abonnés), je fournis un exemple de script qui surveille des événements spécifiques et envoie un message électronique à une adresse désignée chaque fois que des événements correspondants se produisent. Le script ne consomme aucun cycle de CPU pendant qu’il attend le prochain événement correspondant et vous pouvez facilement modifier la requête WMI qui détermine quel événement le script traite, et vous le signale. Les requêtes WMI utilisent une commande SQL Select semblable à celles à partir desquelles les requêtes Microsoft Access sont construites. La difficulté est de déterminer quels événements devraient générer une alerte. En effet, il est facile d’inonder le pager ou la boîte de réception avec un flot d’alertes, pas toutes intéressantes.

Pour commencer à créer les critères d’alertes, utilisez un outil de reporting qui collectera les informations nécessaires dans les journaux d’événements. En la matière, rien ne vaut Log Parser de Microsoft. Il vous permet d’appliquer des requêtes au journal d’événements en utilisant une instruction Select, semblable à une requête WMI mais mieux adaptée aux requêtes adressées à un journal existant. J’ai écrit plusieurs articles sur Log Parser, qui incluent de nombreux exemples de requêtes qu’il vous sera facile d’adapter à vos besoins. L’objectif est d’écrire une ou plusieurs requêtes pour chaque type de journal d’événements (Application, Security, System, par exemple). Un filtrage permet d’ignorer les événements sans intérêt et de présenter les événements importants. Je vous conseille d’appliquer les requêtes aux journaux de sécurité pour les event ID les plus courants et les plus importants, que montre le tableau 1. (Vous pouvez aussi obtenir un tableau de référence rapide gratuit sur mon site Ultimate Windows Security à http://www.ultimatewindowssecurity.com.) Une telle requête ressemblerait à ceci :

Logparser "select TimeGenerated,EventID,Message
from \\mtg1\security
where EventID
in (675;676; 681;642;624;644;617;632;660;636)"

Téléchargez gratuitement cette ressource

Sécurité Office 365 : 5 erreurs à ne pas commettre

Sécurité Office 365 : 5 erreurs à ne pas commettre

A l’heure où les données des solutions Microsoft de Digital Workplace sont devenues indispensables au bon fonctionnement de l’entreprise, êtes-vous certain de pouvoir compter sur votre plan de sécurité des données et de sauvegarde des identités Microsoft 365, Exchange et Teams ? Découvrez les 5 erreurs à ne pas commettre et les bonnes pratiques recommandées par les Experts DIB France.

Tech - Par Randy Franklin Smith - Publié le 24 juin 2010