Gérer les logs de vos serveurs à moindre coût!

Cela fait plusieurs mois que je songe à faire un article sur la gestion des logs. J’ai mis en place, dans un passé très récent, un petit outil de centralisation des logs de serveurs pour pouvoir générer quelques statistiques sur l’utilisation de services “web” et autres évènements de l’”EventViewer” dans un environnement Windows. Pour cela j’ai utilisé une application gratuite appelé LogParser.

Je pensais que cette problématique de gestion de logs à moindre coût était simplement une préoccupation de “geek”. Et bien non, lors d’une réunion récente avec le TOP 10 des RSSI français (selon mes critères à moi ;-)), j’ai constaté qu’il pouvait finalement être intéressant de partager ce type information.

LogParser est à la base un outil de gestion des logs utilisables en ligne de commande. Mais on trouve aussi LogParserLizard qui permet de faire les mêmes opérations avec une interface graphique qui facilite grandement la vie.

J’ai utilisé la version gratuite de LogParserLizard. Cette version est bien sûr quelque peu limitée. Cependant vous pouvez définir vos requêtes de récupérations de logs sur le serveur local ou sur des serveurs distants, les sauvegarder et les exécuter. Mais vous êtes limité lors de l’exploration des données récupérées pour les intégrer dans vos rapports. Je n’ai personnellement utilisé uniquement que le format “csv”.

Après avoir installé LogParser puis LogParserLizard et lancer LogParserLizard, vous pouvez créer vos premières requêtes (au format SQL).

Voici l’exemple d’une requête qui récupère des données dans les fichiers de log d’IIS pour extraire le nombre de connexions par utilisateur d’un site web:

SELECT DISTINCT cs-username, count(cs-username) AS Number
FROM \\mon_serveur.com\C$\WINDOWS\system32\LogFiles\W3SVC1\ex*.log WHERE cs-username LIKE 'MON_DOMAIN%' AND cs-uri-stem LIKE '/mon_site%' GROUP BY cs-username ORDER BY Number

Les fichiers en entrée de la requête sont de la forme “ex*.log”. Le site “web” qui nous intéresse contient dans son URL le mot clef “mon_site”. Le serveur sur lequel fonctionne IIS se nomme “mon_serveur.com”. Les utilisateurs appartiennent au domaine “MON_DOMAINE”.

Les résultats sont triés par nombre de connexions décroissants.

Si vous connaissez ne serait-ce qu’un peu SQL, la création de ce type de requêtes ne présente pas de difficulté (les spécialistes pourront par ailleurs améliorer la requête ci-dessus). Il est par contre nécessaire de configurer les informations que vous souhaitez qu’IIS enregistre dans ces fichiers “log” et de connaitre les noms des champs correspondants aux informations qui vous intéressent.

Voici l’exemple d’une autre requête dans l’EventViewer de Windows qui permet de récupérer des informations sur les opérations effectuées sur un service Windows particulier:

SELECT TimeGenerated, Strings FROM Application WHERE EventID=16666 AND SourceName='Mon_Service' ORDER BY Strings

L’EventViewer tourne sur le serveur en local. L’identifiant de l’évènement est 166666. Le nom de l’application est “Mon_Service”. Il est nécessaire de connaitre les noms des champs de l’EventViewer pour paramétrer correctement la requête.

Les résultats sont ordonnés en fonction de la valeur du champ “Strings”.

Remarque: les requêtes peuvent être exporter et importer.

Une fois les requêtes crées, vous pouvez récupérer vos résultats et générer le rapport. Voici une liste d’actions étape par étape qu’il est possible de réaliser:

1. Sélectionner "IIS Logs"
2. Sélectionner "Liste des utilisateurs de mon_site sur un serveur distant"
3. Lancer Query
4. Sélectionner "Tools/Log Parser Export..."
5. Exporter au format = “Comma Separated Values"
6. Sélectionner Path: mon_site_utilisateurs.prn
7. Sélectionner "Event Logs"
8. Sélectionner "Liste des utilisateurs du service mon_service"
9. Lancer Query

1. Sélectionner "Tools/Log Parser Export..."
2. Exporter au format = “Comma Separated Values"
3. Sélectionner Path: “mon_service_utilisateurs.prn”
4. Intégrer les fichiers dans un fichier “Excel” (“Resultats.xlsx”)
5. Générer le rapport

Remarque: si une erreur se produit pendant la génération du fichier “prn” et que ce message est suivi par un message de succès, alors le résultat est bon

Est-il nécessaire de rappeler qu’une bonne gestion des logs fait partie intégrante de la sécurité de vos systèmes?