Réduire les parasites

qui passent au peigne fin leurs fichiers log gérés ont un jour souhaité pouvoir arrêter quelques événements répétitifs, comme ceux qui sont générés par le compte d’un service (comme sauvegarde sur bande, antivirus, outil de management) qui s’exécute de manière ou fréquente et crée des parasites inutiles dans le journal.

L’audit lui-même peut être votre ennemi en matière de génération de parasites. Par mesure de sécurité, j’ai les catégories d’audit Detailed Tracking (c’est-à-dire, suivi de processus) et Object Access validés pour intercepter toute action malveillante d’un pirate. Bien qu’on vous ait peut-être appris que le fait d’activer Detailed Tracking produit toujours trop de parasites dans le journal d’événements, ce n’est généralement pas le cas sur des DC (domain controllers) dédiés qui, en principe, n’ont pas pour mission d’arrêter et de démarrer beaucoup de programmes et de processus pendant leurs prestations normales une fois qu’ils sont opérationnels. Toutefois, j’utilise fréquemment Remote Desktop pour vérifier les fichiers log des DC. En transgression radicale de la Star Trek Prime Directive, le seul fait de me connecter à distance et d’ouvrir le journal d’événements génère des événements. Le fait de rafraîchir l’écran du journal d’événements crée deux messages d’événement. Maintenant que l’audit par utilisateur est disponible dans Windows 2003 SP1, je peux utiliser un simple fichier batch au moment de la connexion, pour limiter les messages qui me concernent directement et qui concernent mes activités de supervision à distance.

L’audit par utilisateur peut servir à améliorer la sécurité. Ainsi, sur la plupart des machines Windows dont j’ai la charge, je renomme les comptes Administrator et Guest. Ensuite, je crée deux comptes fictifs, fortement restreints et bardés de mots de passe longs et complexes, que je mets à leur place. Je leur donne les noms Administrator et Guest et je copie même les descriptions par défaut des comptes originaux. J’ai toujours voulu être alerté si un intrus essayait d’utiliser les comptes fictifs. L’audit par utilisateur peut signaler les événements impliquant les deux comptes fictifs au journal d’événements, et ne pas faire le rapport des mêmes événements pour tous les comptes.

Il pourrait être intéressant de toujours exporter vos paramètres d’audit par utilisateur vers un fichier, pour la documentation, la gestion des changements et la reconstruction. Dans un scénario de dépannage, vous pourriez désactiver l’audit par utilisateur pour éliminer son éventuel impact sur un problème. Vous pouvez exporter les paramètres, les effacer, continuer le dépannage puis, après le dépannage, réimporter les paramètres.

Quand vous changez les paramètres d’audit par utilisateur, les changements sont enregistrés par Event ID 806 (Per User Audit Policy was refreshed) que montre la figure 2, et Event ID 807 (Per user auditing policy set for user) que montre la figure 3. Event ID 806 n’est pas tellement utile mais, son apparition peut vous signaler le fait que l’audit par utilisateur est activé ou que ses paramètres sont en cours de modification. Event ID 807 révèle au moins quel utilisateur est impliqué. Malheureusement, les catégories d’audit montrées dans la section Description de event ID 807 ne sont pas les catégories modifiées.

Signalons au passage que des pirates malveillants ne connaissent peut-être pas encore l’audit par utilisateur et, par conséquent, ne le testent probablement pas. Les paramètres d’audit par utilisateur sont maintenus dans un endroit différent des autres paramètres d’audit, de telle sorte que si des pirates testent des paramètres d’audit manuellement ou par un outil ligne de commande automatisé qui révèle la stratégie d’audit en vigueur, ils n’auront pas une vue complète de vos paramètres d’audit. Bien entendu, les outils des pirates se hisseront un jour au niveau de l’audit par utilisateur mais, en attendant, profitez de cet avantage.