Une surveillance active contre les intrusions et les attaques est nécessaire dans tout environnement sécurisé. Il serait insensé d'installer des systèmes et de ne procéder à aucun audit, en partant du principe qu'ils ne seront l'objet d'aucune attaque.
L'audit et la surveillance des intrusions sont essentiels pour plusieurs raisons, notamment :
· Tout environnement informatique fonctionnel est une cible potentielle d'attaque. Même si le niveau de sécurité de votre environnement est élevé, les risques d'attaques existent.
· Une série d'attaques manquées précède souvent des attaques réussies. Si vous n'instaurez pas un système de surveillance, vous ne pourrez pas détecter les attaques avant qu'elles soient menées à bien.
· Si vous parvenez à détecter une attaque assez tôt, vous pourrez mieux maîtriser les dommages causés.
· Si vous devez effectuer une procédure de récupération après attaque, vous devez connaître les dommages survenus.
· L'audit et la détection des intrusions vous permettent de déterminer plus facilement le responsable de l'attaque.
· L'association de l'audit et de la détection des intrusions permet de mettre en corrélation des informations afin d'identifier des modèles d'attaque.
· Grâce à l'examen régulier des journaux de sécurité, vous pouvez identifier des problèmes inconnus liés à la configuration de la sécurité, en particulier des autorisations incorrectes ou des paramètres de verrouillage des comptes imprécis.
· Lorsqu'une attaque est détectée, l'audit permet de déterminer les ressources réseau qui sont endommagées.
Ce chapitre explique comment auditer votre environnement de façon à augmenter vos chances de détecter les attaques et de retracer leur origine et leurs circonstances. Il traite également de la surveillance des intrusions, notamment de l'utilisation de systèmes de détection des intrusions, logiciels spécialement conçus pour reconnaître les signes avant-coureurs d'une attaque.
Dans le cadre de votre stratégie de sécurité globale, vous devez définir le niveau d'audit approprié pour votre environnement. L'audit doit identifier les attaques, réussies ou non, qui représentent une menace pour votre réseau ou pour des ressources identifiées comme précieuses lors de votre évaluation des risques.
Il vous faut déterminer l'ampleur de l'audit qui sera effectué. N'oubliez pas que plus l'audit est étendu, plus le nombre d'événements générés est important, et plus il est difficile de discerner les éléments critiques. Si vous optez pour un audit étendu, envisagez sérieusement de recourir à des outils complémentaires, qui vous aideront à filtrer les événements de façon à identifier ceux qui ont une importance primordiale. Microsoft® Operations Manager (MOM) en est un exemple.
Les événements d'audit peuvent être répartis en deux catégories : les succès et les échecs. Un événement de type succès indique qu'un utilisateur est parvenu à accéder à une ressource, alors qu'un événement de type échec signale une tentative d'accès ayant échoué.
Les événements de type échec sont très utiles pour détecter les tentatives d'attaques dans un environnement. Quant aux événements de type succès, ils sont bien plus difficiles à interpréter. La grande majorité des événements d'audit de type succès indiquent simplement une activité normale. Cependant, un tel événement est également généré lorsqu'un intrus parvient à s'infiltrer dans un système. Bien souvent, une séquence d'événements est aussi importante que les événements pris individuellement. Par exemple, une série d'échecs suivie d'un succès peut indiquer une tentative d'attaque ayant fini par aboutir.
.
Vous pouvez activer l'audit à l'aide de la stratégie de groupe, au niveau du site, du domaine, de l'unité d'organisation ou de l'ordinateur local. Les paramètres de stratégie d'audit se trouvent à l'emplacement suivant :
Configuration ordinateur\Paramètres Windows\Paramètres
de sécurité\Stratégies locales\Stratégie d'audit
Vous devez généralement implémenter l'audit à un niveau élevé dans la hiérarchie du service d'annuaire Microsoft® Active Directory®. En effet, cela vous permet d'assurer la cohérence de vos paramètres d'audit. Contoso a mis en œuvre l'audit au niveau des unités d'organisation Serveur membre et Contrôleur de domaine. Pour plus d'informations, reportez-vous au chapitre 6, « Renforcement de la sécurité du serveur Windows 2000 de base ».
Vous disposez peut-être de serveurs que vous avez choisi de ne pas intégrer dans le domaine. Dans ce cas, vous pouvez configurer l'audit sur ces systèmes. Pour cela, modifiez la stratégie de groupe de l'ordinateur local ou recourez à l'utilitaire Auditpol.exe disponible dans le Kit de Ressources Techniques Windows 2000 Server.
Remarque : Pour accéder à la stratégie de groupe d'un ordinateur local, démarrez la console MMC, puis ajoutez le composant logiciel enfichable Stratégie de groupe, qui ciblera l'ordinateur local.
L'Observateur d'événements affiche chacun des événements générés par l'audit. Vous devez déterminer de quelle façon le journal des événements va stocker ces événements. Vous pouvez définir directement chacun des paramètres dans l'Observateur d'événements ou dans la stratégie de groupe. Dans ce guide, les paramètres de l'Observateur d'événements sont définis dans la stratégie de groupe. Pour plus d'informations sur les paramètres recommandés, reportez-vous au chapitre 6, « Renforcement de la sécurité du serveur Windows 2000 de base ».
Si vous supprimez les paramètres de l'Observateur d'événements dans la stratégie de groupe, vous pouvez les définir directement dans l'Observateur d'événements. Cependant, le recours à la stratégie de groupe est recommandé afin d'assurer la cohérence des paramètres sur des ordinateurs semblables.
Dans l'environnement de Contoso, la stratégie de groupe n'est pas configurée pour déclencher l'arrêt des systèmes si le journal de sécurité arrive à saturation. Il y a donc remplacement des événements plus anciens par les nouveaux lorsque le journal atteint sa capacité.
Microsoft® Windows® 2000 comprend plusieurs catégories d'audit pour les événements de sécurité. Lorsque vous concevez votre stratégie d'audit d'entreprise, vous devez choisir, parmi les catégories d'événements de sécurité suivantes, celles qu'il faut inclure dans l'audit :
· événements de connexion ;
· événements de connexion de compte ;
· accès aux objets ;
· accès au service d'annuaire ;
· utilisation des privilèges ;
· suivi des processus ;
· événements système ;
· modification de stratégie.
Les sections suivantes décrivent certains des ID d'événements les plus courants renvoyés lorsque l'audit est activé pour des catégories spécifiques.
Remarque : Les outils permettant de rechercher
et de collecter des informations du journal des événements sont décrits plus
loin dans ce chapitre, à la section « Méthodes de détection
passive ».
Si vous auditez les événements de connexion, chaque fois qu'un utilisateur ouvre ou ferme une session sur un ordinateur, un événement est généré dans le journal de sécurité de l'ordinateur sur lequel cette opération se produit. De plus, lorsqu'un utilisateur se connecte à un serveur distant, un événement de connexion est généré dans le journal de sécurité de ce serveur. Les événements de connexion sont générés lorsque la session et jeton de securité sont créés et détruits, respectivement.
Les événements de connexion peuvent être utiles pour assurer le suivi des tentatives de connexion interactive aux serveurs ou pour analyser des attaques perpétrées à partir d'un ordinateur spécifique. Les audits des succès génèrent une entrée lorsqu'une tentative d'ouverture de session se produit, et les audits des échecs, lorsqu'une tentative d'ouverture de session a avorté.
Remarque : Par événements de connexion, l'on
entend les événements d'ouverture et de fermeture de session des utilisateurs
et des systèmes. Des entrées distinctes s'affichent dans le journal de sécurité
pour le compte d'ordinateur et pour le compte d'utilisateur si une tentative de
connexion au réseau se produit à partir d'un ordinateur Microsoft®
Windows NT® ou Windows 2000. Les ordinateurs Windows 9x
ne disposent pas de comptes d'ordinateur dans l'annuaire et ne génèrent donc
pas d'entrées d'événement de connexion ordinateur.
Dans les stratégies de base des serveurs membres et des contrôleurs de domaines, l'audit des événements de connexion de type succès et échec est activé. Vous devez donc vous attendre à trouver dans le journal de sécurité les ID d'événements ci-après pour les ouvertures de session interactives ainsi que celles de Terminal Server pour les ordintateurs exécutant ce service.
|
ID d'événement |
Description |
|
528 |
Ouverture de session réussie sur un ordinateur. |
|
529 |
Tentative d'ouverture de session avec un nom d'utilisateur inconnu ou avec un nom connu et un mot de passe incorrect. |
|
530 |
Tentative d'ouverture de session d'un compte d'utilisateur en dehors de la durée maximale allouée. |
|
531 |
Tentative d'ouverture de session par un compte désactivé. |
|
532 |
Tentative d'ouverture de session par un compte qui a expiré. |
|
533 |
Tentative d'ouverture de session par un utilisateur non autorisé à se connecter à cet ordinateur. |
|
534 |
Tentative d'ouverture de session d'un type non autorisé, par exemple réseau, interactive, par fichier de commande, à un service ou interactive à distance. |
|
535 |
Le mot de passe du compte spécifié a expiré. |
|
536 |
Le service Ouverture de session réseau n'est pas activé. |
|
537 |
La tentative de connexion a échoué pour d'autres raisons. |
|
538 |
Fermeture d'une session utilisateur. |
|
539 |
Verrouillage d'un compte lors d'une tentative d'ouverture de session. Cet événement indique qu'une attaque de mots de passe a été perpétrée sans succès, si bien que le compte a été verrouillé. |
|
540 |
Ouverture de session réseau réussie. Cet événement indique qu'un utilisateur distant s'est connecté à une ressource locale sur le serveur via le réseau. Cette opération a généré un jeton pour l'utilisateur réseau. |
|
682 |
Un utilisateur s'est reconnecté à une session de services Terminal Server déconnectée. Cet événement indique qu'une session de services Terminal Server était ouverte précédemment. |
|
683 |
Un utilisateur a déconnecté une session de services Terminal Server sans la fermer. Cet événement se produit lorsqu'un utilisateur est connecté à une session de services Terminal Server sur le réseau. Il s'affiche sur le serveur Terminal Server. |
Les événements de sécurité ci-après peuvent être diagnostiqués sur la base des entrées d'événements d'ouverture de session :
· Échecs de tentatives d'ouverture de session locale. Les ID d'événements suivants indiquent tous des échecs de tentatives d'ouverture de session : 529, 530, 531, 532, 533, 534 et 537. Les événements 529 et 534 se produisent si un intrus ne réussit pas à deviner la combinaison nom d'utilisateur-mot de passe d'un compte local. Cependant, ces événements peuvent également survenir si un utilisateur oublie son mot de passe ou commence à parcourir le réseau via les Favoris réseau.
Dans un environnement à grande échelle, il peut être difficile d'interpréter efficacement ces événements. En règle générale, vous devez analyser ces modèles s'ils se produisent de façon répétée ou coïncident avec d'autres facteurs inhabituels. Par exemple, plusieurs événements 529 suivis par un événement 528 au milieu de la nuit peuvent indiquer une attaque de mots de passe réussie (ou simplement un administrateur très fatigué).
· Utilisation incorrecte d'un compte. Les événements 530, 531, 532 et 533 peuvent représenter l’utilisation incorrecte d'un compte d'utilisateur. Ces événements indiquent que l'association compte-mot de passe entrée est correcte, mais que d'autres restrictions empêchent l'ouverture de session. Lorsque cela est possible, vous devez analyser ces événements afin de déterminer s'ils témoignent véritablement d'une utilisation incorrecte ou si les restrictions en cours doivent être modifiées. Par exemple, vous devrez peut-être prolonger les heures d'ouverture de session associées à certains comptes.
· Verrouillage des comptes. L'événement 539 signale le verrouillage d'un compte. Il peut indiquer l'échec d'une attaque de mots de passe. Recherchez les éventuels événements 529 antérieurs pour ce compte d'utilisateur afin d’essayer de discerner le modèle des tentatives d'ouverture de session.
· Attaques de services Terminal Server. Les sessions de services Terminal Server peuvent rester connectées, de sorte que l'exécution de processus peut continuer lorsque la session est terminée. L'événement 683 indique qu'un utilisateur n'a pas fermé une session de services Terminal Server, et l'événement 682, qu'une connexion à une session précédemment déconnectée a eu lieu.
Dans l'environnement de Contoso, la surveillance vise à rechercher de très nombreux échecs d'ouverture de session et de verrouillages de comptes. Il arrive relativement souvent que des utilisateurs de Contoso laissent des sessions de services Terminal Server déconnectées pour des raisons légitimes.
Lorsqu'un utilisateur procède à une ouverture de session dans un domaine, celle-ci est traitée au niveau d'un contrôleur de domaine. Si vous auditez les événements de connexion de compte sur les contrôleurs de domaines, vous constaterez que cette tentative d'ouverture de session est enregistrée par le contrôleur de domaine qui valide le compte. Des événements de connexion de compte sont créés lorsqu'un package d'authentification valide les informations d'identification d'un utilisateur. Si des informations d'identification de domaine sont utilisées, les événements de connexion de compte sont uniquement générés dans les journaux des événements des contrôleurs de domaines. Si les informations d'identification présentées proviennent de la base de données SAM (Security Accounts Manager) locale, les événements de connexion de compte sont créés dans le journal des événements de sécurité du serveur.
Les événements de connexion de compte peuvent être enregistrés par n'importe quel contrôleur de domaine actif. Dès lors, il est important de consolider les journaux de sécurité des différents contrôleurs de domaines afin d'analyser tous les événements de connexion de compte du domaine.
Remarque : Tout comme les événements de
connexion, les événements de connexion de compte comportent des événements
d'ouverture de session d'ordinateur et d'utilisateur.
Dans les stratégies de base des serveurs membres et des contrôleurs de domaines, l'audit des événements de connexion de compte de type succès et échec est activé. Vous devez donc vous attendre à trouver les ID d'événements ci-après pour les ouvertures de session réseau et l'authentification des services Terminal Server.
|
ID d'événement |
Description |
|
672 |
Émission et validation d'un ticket du service d'authentification (AS). |
|
673 |
Octroi d'un ticket du service d'attribution de ticket (TGS). |
|
674 |
Renouvellement d'un ticket d'authentification ou d'un ticket TGS pour un principal[1] |
|
675 |
Échec de la pré-authentification. |
|
676 |
Échec de la demande de ticket d'authentification. |
|
677 |
Ticket
TGS non octroyé. |
|
678 |
Mappage d'un compte sur un compte de domaine. |
|
680 |
Identifie le compte utilisé pour la tentative d'ouverture de session réussie. Cet événement indique également le package d'authentification utilisé pour authentifier le compte. |
|
681 |
Tentative d'ouverture de session de compte de domaine. |
|
682 |
Un utilisateur s'est reconnecté à une session de services Terminal Server déconnectée. |
|
683 |
Un utilisateur a déconnecté une session de services Terminal Server sans se deconnecter. |
Le journal des événements affiche des informations
détaillées sur chaque ouverture de session pour chacun de ces événements. Les
événements de sécurité ci-dessous peuvent être diagnostiqués à partir des
entrées d'événements de connexion de compte :
· Échecs de tentatives d'ouverture de session de domaine. Les événements 675 et 677 indiquent des échecs de tentatives d'ouverture de session dans le domaine.
· Problèmes de synchronisation de l'heure. S'il y a un écart de plus de 5 minutes (valeur par défaut) entre l'heure d'un ordinateur client et celle du contrôleur de domaine utilisé pour l'authentification, l'événement 675 s'affiche dans le journal de sécurité.
· Attaques de Terminal Server. Les sessions Terminal Server peuvent rester connectées, si bien que l'exécution de processus peut continuer lorsque la session est terminée. L'événement 683 indique qu'un utilisateur n'a pas fermé une session de services Terminal Server et l'événement 682, qu'une connexion à une session précédemment déconnectée a eu lieu. Afin d'éviter les déconnexions ou pour mettre fin aux sessions déconnectées, attribuez la valeur appropriée comme intervalle avant la fermeture d'une session déconnectée dans la console Configuration des services Terminal Server, dans les propriétés du protocole RDP-TCP.
Dans l'environnement de Contoso, la surveillance a pour but de détecter des nombres anormalement élevés d'échecs d'ouverture de session de domaine, les autres événements ne sont pas jugés pertinents. Lors de la configuration de ces paramètres, les responsables ont déterminé que l'approche la plus efficace consistait à définir d'abord une valeur élevée, pour la réduire progressivement, jusqu'à parvenir à limiter le nombre de fausses alertes. Pour l'instant, l'audit vise à identifier les circonstances dans lesquelles dix échecs de connexion surviennent dans une période de 10 minutes. Ces valeurs sont susceptibles de varier selon les environnements.
L'audit de la gestion des comptes permet de déterminer si des utilisateurs ou des groupes sont créés, supprimés ou modifiés. Il permet d'établir à quel moment un principal a été créé et qui a effectué cette opération.
Dans les stratégies de base des serveurs membres et des contrôleurs de domaines, l'audit des succès et des échecs est activé en matière de gestion des comptes. Vous devez donc vous attendre à trouver les ID d'événements ci-après dans le journal de sécurité.
|
ID d'événement |
Description |
|
624 |
Création d'un compte d'utilisateur. |
|
625 |
Modification du type de compte d'utilisateur. |
|
626 |
Activation d'un compte d'utilisateur. |
|
627 |
Tentative de modification d'un mot de passe. |
|
628 |
Définition du mot de passe d'un compte d'utilisateur. |
|
629 |
Désactivation d'un compte d'utilisateur. |
|
630 |
Suppression d'un compte d'utilisateur. |
|
631 |
Création d'un groupe global de sécurité. |
|
632 |
Ajout d'un membre à un groupe global de sécurité. |
|
633 |
Suppression d'un membre du groupe global de sécurité. |
|
634 |
Suppression du groupe global de sécurité. |
|
635 |
Création d'un groupe local de sécurité. |
|
636 |
Ajout d'un membre au groupe local de sécurité. |
|
637 |
Suppression d'un membre du groupe local de sécurité. |
|
638 |
Suppression d'un groupe local de sécurité. |
|
639 |
Modification d'un groupe local de sécurité. |
|
641 |
Modification d'un groupe global de sécurité. |
|
642 |
Modification d'un compte d'utilisateur. |
|
643 |
Modification de la stratégie d'un domaine. |
|
644 |
Verrouillage d'un compte d'utilisateur. |
Les événements de gestion des comptes suivants peuvent être diagnostiqués à partir des entrées du journal de sécurité :
· Création d'un compte d'utilisateur. Les événements 624 et 626 identifient des comptes d'utilisateur créés et activés. Si la création des comptes est réservée à des membres spécifiques de l'entreprise, vous pouvez examiner ces événements afin de déterminer si des collaborateurs non autorisés ont outrepassé leurs droits.
· Modification du mot de passe d'un compte d'utilisateur. La modification d'un mot de passe par toute autre personne que l'utilisateur auquel il appartient peut indiquer que le compte a été « emprunté » par un autre utilisateur. Recherchez les événements 627 et 628 : ceux-ci indiquent qu'une tentative de modification de mot de passe a été effectuée et réussie. Analysez les informations présentes pour déterminer si un compte distinct a procédé à la modification et si ce compte est membre du support technique ou d'un autre service habilité à réinitialiser les mots de passe des comptes d'utilisateur.
· Modification de l'état d'un compte d'utilisateur. Un intrus peut tenter d'effacer toutes traces de ses actions en désactivant ou en supprimant le compte utilisé pour réaliser l'attaque. Observez toutes les occurrences des événements 629 et 630 afin de vérifier qu'elles correspondent à des transactions autorisées. Recherchez également les occurrences d'événements 626 suivis d'événements 629 peu après. Cette séquence peut indiquer qu'un compte d'utilisateur désactivé a été activé, utilisé, puis désactivé à nouveau.
· Modification des groupes de sécurité. Il est important d'examiner soigneusement les modifications apportées aux membres des groupes Admins du domaine, Administrateurs, aux différents groupes d'opérateurs, aux groupes globaux personnalisés, aux groupes universels ou aux groupes de domaine local auxquels sont déléguées des fonctions d'administration. Les événements 632 et 633 doivent être recherchés pour identifier les modifications apportées aux membres d'un groupe global, et les événements 636 et 637, pour celles apportées aux membres d'un groupe de domaine local.
· Verrouillage des comptes. Lorsqu'un compte est verrouillé, deux événements sont consignés sur le maître d'opérations émulateur du contrôleur principal (PDC). Un événement 644 indique que le compte est verrouillé, puis un événement 642 est enregistré, signalant que le compte d'utilisateur est modifié et verrouillé. Cet événement est uniquement consigné sur l'émulateur PDC.
Comme Contoso est une entreprise d'assez grande taille, la gestion des comptes représente une tâche quotidienne importante. La surveillance de tous ces événements donnerait lieu à un trop grand nombre d'alertes pour qu'elle puisse être raisonnablement appliquée à cet environnement.
Vous pouvez activer l'audit de tous les objets d'un réseau Windows 2000 au moyen d'une liste de contrôle d'accès système (SACL, System Access Control List). Cette liste contient les noms des utilisateurs et des groupes pour lesquels les actions effectuées sur l'objet concerné doivent être auditées. Presque tous les objets pouvant être manipulés par les utilisateurs dans Windows 2000 disposent d'une liste SACL. Cette dernière comprend les fichiers et dossiers des lecteurs NTFS, les imprimantes et les clés de Registre.
Une liste de contrôle d'accès système comporte des entrées de contrôle d'accès (ACE, Access Control Entry). Chacune de ces entrées est composée de trois éléments :
· le principal à auditer ;
· les types d'accès spécifiques à auditer, appelés masque d'accès ;
· un indicateur spécifiant s'il faut auditer les accès de type succès ou échec, ou les deux.
Si vous voulez que des événements s'affichent dans le journal de sécurité, vous devez activer l'option Auditer l'accès aux objets, puis définir la liste de contrôle d'accès système pour chacun des objets à auditer.
Dans Windows 2000, les audits sont générés lorsqu'un descripteur d'objet est ouvert. Windows 2000 utilise un sous-système de sécurité en mode noyau. Ce sous-système permet aux programmes d'accéder aux objets via le noyau uniquement, de telle sorte qu'ils ne peuvent en aucun cas contourner le système de sécurité. L'espace mémoire du noyau est isolé des programmes en mode utilisateur. Dès lors, un programme fait référence à un objet via une structure de données appelée descripteur. L'exemple suivant illustre une tentative d'accès type :
1. Un utilisateur demande à un programme d'accéder à un objet (par exemple, par la commande Fichier/Ouvrir).
2. Le programme demande un descripteur au système, spécifiant le type d'accès (lecture, écriture, etc.) souhaité.
3. Le sous-système de sécurité compare la liste de contrôle d'accès discrétionnaire (DACL, Discretionary Access Control List) de l'objet demandé avec le jeton de l'utilisateur, en recherchant les entrées de la DACL correspondant à l'utilisateur ou à un groupe auquel il appartient et pour lequel il dispose des droits d'accès requis par le programme.
4. Le système compare la liste de contrôle d'accès système de l'objet demandé au jeton de l'utilisateur, en recherchant les entrées de la liste correspondant aux droits effectifs renvoyés au programme ou aux droits requis par le programme. Si une entrée de contrôle d'accès de l'audit des échecs correspond à un accès demandé mais refusé, un événement d'audit de type échec est généré. Si une entrée de contrôle d'accès de l'audit des succès correspond à un accès accordé, un événement d'audit de type succès est généré.
5. Si un accès est octroyé, le système renvoie un descripteur au programme, qui peut ensuite l'utiliser pour accéder à l'objet.
Il est très important de noter que, lors d'un audit et de la génération d'un événement, l'objet n'a pas encore été manipulé. Ce point est essentiel pour interpréter les événements d'audit. Des événements d'audit d'écriture sont générés avant qu'un fichier soit modifié et des événements d'audit de lecture, avant qu'un fichier soit ouvert.
Comme pour tous les audits, il est très important d'adopter une approche ciblée pour auditer l'accès aux objets. Le plan de votre stratégie d'audit doit spécifier le type d'objets à auditer et le type de tentatives d'accès (succès, échec ou les deux) à surveiller pour chaque type d'objet audité. Une approche trop générale de l'audit aura un impact significatif sur les performances du système et entraînera la collecte d'informations trop nombreuses et superflues.
D'une façon générale, il est intéressant d'auditer tous les accès aux objets sélectionnés, notamment à partir de comptes non approuvés. Pour ce faire, ajoutez le groupe Tout le monde à la liste de contrôle d'accès système des objets que vous voulez auditer. Faites preuve de prudence lorsque vous activez l'audit des succès pour l'accès aux objets car le nombre d'entrées générées dans le journal de sécurité peut être impressionnant. Cependant, si vous analysez par exemple la suppression d'un fichier critique, vous devez examiner les événements d'audit des succès afin de déterminer quel compte d'utilisateur a supprimé ce fichier.
Les stratégies de base des serveurs membres et des contrôleurs de domaines sont définies de manière à auditer les succès et les échecs d'accès aux objets. Cependant, aucune liste de contrôle d'accès système n'est spécifiée pour les objets eux-mêmes, et c'est à vous qu'il appartient d'en définir une en fonction des besoins de votre environnement. Vous pouvez définir les listes de contrôle d'accès système directement sur les objets ou via la stratégie de groupe. Si les objets devant être audités résident sur plusieurs ordinateurs, définissez ces listes dans la stratégie de groupe.
L'audit de l'accès aux objets entraîne la consignation des événements suivants dans le journal de sécurité.
|
ID d'événement |
Description |
|
560 |
Accès accordé à un objet existant. |
|
562 |
Fermeture d'un descripteur d'objet. |
|
563 |
Tentative d'ouverture d'un objet avec intention de le supprimer (événement utilisé par les systèmes de fichiers lorsque l'indicateur FILE_DELETE_ON_CLOSE est spécifié). |
|
564 |
Suppression d'un objet protégé. |
|
565 |
Accès accordé à un type d'objet existant. |
Si vous recherchez des événements d'accès à des objets spécifiques, ciblez principalement les événements portant l'ID 560. Les informations utiles se trouvent dans les détails de ces événements, et vous devrez les consulter pour isoler les éléments qui vous intéressent. Le tableau 9.5 répertorie des actions que vous devrez peut-être effectuer et les méthodes pour y parvenir.
|
Action d'audit |
Procédure |
|
Rechercher un fichier, un dossier ou un objet spécifique |
Dans les détails de l'événement 560, recherchez le chemin d'accès complet au fichier ou au dossier pour lequel vous voulez vérifier les actions. |
|
Déterminer les actions effectuées par un utilisateur spécifique |
Définissez un filtre identifiant l'utilisateur spécifique dans un événement 560. |
|
Déterminer les actions effectuées sur un ordinateur spécifique |
Définissez un filtre identifiant le compte de l'ordinateur sur lequel les tâches ont été effectuées dans un événement 560. |
Dans l'environnement de Contoso, les événements d'accès aux objets ne sont pas surveillés de façon spécifique, mais l'audit de l'accès aux objets est activé pour certains fichiers particuliers. Ces informations peuvent être extrêmement utiles en cas d'incident de sécurité.
Les objets Active Directory disposent de listes de contrôle d'accès système (SACL) et peuvent donc être audités. Pour rappel, vous auditez les comptes des utilisateurs et des groupes Active Directory en effectuant l'audit de la gestion des comptes. Il est cependant possible d'auditer la modification d'objets dans d'autres contextes de nommage (de configuration et de schéma, par exemple). Pour cela, activez l'audit de l'accès aux objets, puis définissez la liste de contrôle d'accès système pour les conteneurs spécifiques à auditer. Des entrées d'audit sont générées lorsque des utilisateurs figurant dans la liste de contrôle d'accès système d'un objet Active Directory tentent d'accéder à cet objet.
Vous pouvez modifier la liste de contrôle d'accès système pour les conteneurs et les objets dans le contexte de nommage de configuration (ainsi que dans d'autres contextes de nommage) à l'aide du composant logiciel enfichable MMC ADSIEdit). Pour cela, vous devez afficher le contexte approprié dans la console ADSIEdit, puis modifier la liste de contrôle d'accès système de l'objet dans la boîte de dialogue Paramètres de sécurité avancés.
Il est très difficile de rechercher des événements spécifiques d'accès au service d'annuaire en raison du nombre impressionnant d'événements (généralement anodins) qui se produisent. Pour cette raison, les stratégies de base des serveurs membres et des contrôleurs de domaines prescrivent uniquement l'audit des événements d'accès au service d'annuaire de type échec. Cette approche vous permet d'identifier les tentatives d'accès non autorisé à Active Directory effectuées par un intrus.
Les tentatives d'accès au service d'annuaire apparaissent comme des événements du service d'annuaire sous le numéro 565 dans le journal des événements. Vous pouvez déterminer à quel objet correspond un événement de sécurité en consultant les détails de ce dernier.
Dans l'environnement de Contoso, les événements d'accès au service d'annuaire ne sont pas surveillés de façon spécifique, mais l'audit de l'accès aux objets est activé pour certains fichiers. Ces informations peuvent être extrêmement utiles en cas d'incident de sécurité.
En travaillant, les utilisateurs d'un environnement informatique font valoir les droits qui leur sont accordés. Si vous auditez les événements de type succès et échec liés à l'utilisation des privilèges, un événement est généré chaque fois qu'un utilisateur tente d'exercer l'un de ses droits.
Même si l'audit des privilèges est mis en œuvre, tous les droits des utilisateurs ne sont pas audités. Par défaut, les droits d'utilisateur ci-après sont exclus :
· outrepasser le contrôle du parcours ;
· déboguer des programmes ;
· créer un objet jeton ;
· remplacer un jeton de niveau processus ;
· générer des audits de sécurité ;
· sauvegarder des fichiers et des répertoires ;
· restaurer des fichiers et des répertoires.
Vous pouvez remplacer le comportement par défaut qui désactive l'audit des droits de sauvegarde et de restauration. Pour cela, activez l'option de sécurité Auditer l'utilisation des privilèges de sauvegarde et de restauration dans la stratégie de groupe.
L'audit des succès liés à l'utilisation des privilèges entraîne la création d'un très grand nombre d'entrées dans le journal de sécurité. Pour cette raison, les stratégies de base des serveurs membres et des contrôleurs de domaines limitent l'audit aux seuls événements d'utilisation des privilèges de type échec.
Les événements ci-après sont générés si vous activez l'audit de l'utilisation des privilèges.
|
ID d'événement |
Description |
|
576 |
Ajout de droits spécifiques au jeton d'accès d'un utilisateur (cet événement est généré lorsqu'un utilisateur ouvre une session). |
|
577 |
Tentative d'utilisation d'un service système privilégié par un utilisateur. |
|
578 |
Des privilèges ont été exercés sur un descripteur déjà ouvert d'un objet protégé. |
Les exemples ci-dessous illustrent des entrées susceptibles d'apparaître dans le journal des événements lorsque des droits d'utilisateur spécifiques sont utilisés :
· Agir comme faisant partie du système d'exploitation. Recherchez les événements 577 ou 578 faisant état du privilège SeTcbPrivilege. Le compte d'utilisateur qui a exercé ce privilège est identifié dans les détails de l'événement. Celui-ci peut indiquer une tentative d'élévation des privilèges de sécurité par un utilisateur agissant comme faisant partie du système d'exploitation. Par exemple, l'attaque GetAdmin qui permet à un utilisateur d'ajouter son compte au groupe Administrateurs repose sur l'utilisation de ce privilège. Les seules entrées de cet événement doivent porter sur le compte système et les comptes de service auxquels a été attribué ce privilège.
· Modifier l'heure du système. Recherchez les événements 577 ou 578 faisant état du privilège SeSystemtimePrivilege. Le compte d'utilisateur qui a exercé ce privilège est identifié dans les détails de l'événement. Cet événement peut indiquer une tentative de modification de l'heure système afin de masquer l'heure réelle à laquelle un événement se produit.
· Arrêt forcé à partir d'un système à distance. Recherchez les événements 577 et 578 faisant état du privilège SeRemoteShutdownPrivilege. L'identificateur de sécurité (SID) spécifique auquel est affecté le droit utilisateur et le nom d'utilisateur de l'entité de sécurité qui a affecté le droit sont indiqués dans les détails de l'événement.
· Chargement et déchargement de pilotes de périphériques. Recherchez les événements 577 ou 578 faisant état du privilège SeLoadDriverPrivilege. Le compte d'utilisateur qui a exercé ce privilège est identifié dans les détails de l'événement. Cet événement peut indiquer une tentative de chargement d'une version de pilote de périphérique non autorisée ou comportant un cheval de Troie (type de code hostile).
· Gestion de l'audit et du journal de sécurité. Recherchez les événements 577 ou 578 faisant état du privilège SeSecurityPrivilege. Le compte d'utilisateur qui a exercé ce privilège est identifié dans les détails de l'événement. Cet événement survient lorsque le contenu du journal des événements est supprimé et lorsque des événements d'utilisation des privilèges sont consignés dans le journal de sécurité.
· Arrêt du système. Recherchez les événements 577 faisant état du privilège SeShutdownPrivilege. Le compte d'utilisateur qui a exercé ce privilège est identifié dans les détails de l'événement. Cet événement a lieu lors d'une tentative d'arrêt du système.
· Appropriation de fichiers ou d'autres objets. Recherchez les événements 577 ou 578 faisant état du privilège SeTakeOwnershipPrivilege. Le compte d'utilisateur qui a exercé ce privilège est identifié dans les détails de l'événement. Cet événement peut indiquer qu'un intrus tente de contourner les paramètres de sécurité en cours en prenant possession d'un objet.
L'environnement de Contoso assure la surveillance de tous les événements qui indiquent un arrêt normal ou forcé à partir d'un système distant, ainsi que tout événement signalant que le journal de sécurité et d'audit a été modifié.
L'audit du suivi des processus permet de recueillir des informations détaillées sur les processus exécutés sur des ordinateurs Windows 2000. Le journal des événements affiche alors les tentatives de création et d'arrêt de processus. Il enregistre également toute tentative de génération d'un descripteur d'objet ou d'obtention d'un accès indirect à un objet.
En raison des nombreuses entrées d'audit créées, l'audit du suivi des processus n'est pas activé dans les stratégies de base des serveurs membres et des contrôleurs de domaines. Cependant, si vous auditez les succès et les échecs, les ID d'événements ci-après sont enregistrés dans le journal des événements.
|
ID d'événement |
Description |
|
592 |
Création d'un nouveau processus. |
|
593 |
Sortie d'un processus. |
|
594 |
Duplication d'un descripteur d'objet. |
|
595 |
Obtention d'un accès indirect à un objet. |
Dans l'environnement de Contoso, aucun événement de suivi des processus n'est surveillé et ce type d'audit n'est activé dans aucune des stratégies de serveur.
Des événements système sont générés lorsqu'un utilisateur ou un processus altèrent l'un ou l'autre aspect d'un environnement informatique. Vous pouvez auditer les tentatives de modification du système, notamment l'arrêt de l'ordinateur ou la modification de l'heure système.
Si vous auditez les événements système, veillez à auditer également la purge du journal des événements. Cela est très important car les auteurs d'attaques tentent souvent d'effacer les traces de leur passage après avoir modifié un environnement.
Les stratégies de base des serveurs membres et des contrôleurs de domaines prescrivent l'audit des succès et des échecs liés aux événements système. Les ID d'événements suivants s'affichent dans le journal des événements.
|
ID d'événement |
Description |
|
512 |
Démarrage de Windows. |
|
513 |
Fermeture de Windows. |
|
514 |
Chargement d'un package d'authentification par l'autorité de sécurité locale. |
|
515 |
Inscription d'un processus d'ouverture de session approuvé auprès de l'autorité de sécurité locale. |
|
516 |
Les ressources internes allouées à la mise en file d'attente de messages d'événements de sécurité sont épuisées, ce qui a entraîné la perte de certains de ces messages. |
|
517 |
Purge du journal de sécurité. |
|
518 |
Chargement d'un package de notification par le Gestionnaire de comptes de sécurité. |
Vous pouvez vous baser sur ces ID d'événements pour identifier plusieurs problèmes de sécurité :
· Arrêt/redémarrage du système. Un événement 513 est consigné à chaque fermeture de Windows. Il est primordial de savoir à quel moment les serveurs ont été arrêtés ou redémarrés. Ces opérations peuvent être effectuées pour plusieurs raisons licites, notamment l'installation d'une application ou d'un pilote nécessitant un redémarrage, ou encore l'arrêt ou le redémarrage du serveur aux fins de maintenance. Cependant, un intrus peut également forcer le redémarrage d'un serveur afin d'accéder au système lors de cette opération. Tous les arrêts du système doivent être documentés, afin qu’ils soient comparés avec les entrées du journal des événements.
De nombreuses attaques impliquent le redémarrage du système. En analysant les journaux des événements, vous pouvez déterminer quand un serveur a été redémarré et si ce redémarrage était prévu ou non. Un événement 513 illustre le démarrage de Windows, ainsi qu'une série d'autres événements générés automatiquement dans le journal système. Parmi eux, l'événement 6005 indique que le service Journal des événements a démarré.
Outre cette entrée, recherchez la présence de l'une des deux entrées suivantes dans le journal système. Si l'arrêt précédent était normal (par exemple, si l'administrateur a effectué un redémarrage), l'événement 6006, Le service d'Enregistrement d'événement a été arrêté, est enregistré dans le journal système. Observez les détails de cette entrée pour déterminer quel utilisateur a arrêté le système.
Si le redémarrage était un redémarrage inattendu, l'événement 6008, L'arrêt système précédant à <heure> le <date> n'était pas prévu, est enregistré. Cet événement peut indiquer une attaque de refus de service qui a entraîné l'arrêt du système. N'oubliez cependant pas qu'il peut également être dû à une coupure de courant ou à une défaillance d'un pilote de périphérique.
Si le redémarrage était dû à une erreur d'arrêt (avec affichage de l'écran bleu), l'événement 1001 est enregistré dans le journal système, avec une source d'enregistrement des vidages. Le message d'erreur d'arrêt peut être analysé dans les détails de l'événement.
Remarque : Pour que l'événement 1001 soit enregistré, vous devez activer la case à cocher Écrire un événement dans le journal système dans les paramètres de récupération de l'application Système du Panneau de configuration.
· Modification ou purge du journal de sécurité. Un intrus peut tenter de modifier le journal de sécurité, de désactiver l'audit lors d'une attaque ou de purger le journal de sécurité afin de ne pas être démasqué. Si vous constatez des périodes prolongées pour lesquelles aucune entrée ne figure dans le journal de sécurité, recherchez les événements 612 et 517 afin de déterminer quel utilisateur a modifié la stratégie d'audit. Toutes les occurrences de l'événement 517 doivent être comparées à un journal physique dans lequel ont été documentées toutes les heures auxquelles le journal de sécurité a été vidé de son contenu. Une suppression non autorisée peut révéler une tentative de masquer des événements existants dans le journal de sécurité précédent. Le nom de l'utilisateur qui a effectué l'opération figure dans les détails de l'événement.
Dans l'environnement de Contoso, les arrêts et les redémarrages du système ainsi que la purge du journal de sécurité sont audités.
Votre stratégie d'audit définit les modifications apportées à votre environnement qui sont auditées, vous aidant ainsi à déterminer si votre environnement a fait l'objet de tentatives d'attaque. Cependant, un intrus peut tenter de modifier la stratégie d'audit elle-même, afin que ses modifications ne soient pas auditées.
Si l'audit des modifications de stratégie est activé, il affiche les tentatives de modification de la stratégie d'audit, ainsi que les modifications apportées à d'autres stratégies et aux droits des utilisateurs. Les stratégies de base des serveurs membres et des contrôleurs de domaines prescrivent l'audit des succès et des échecs des modifications de stratégie. Ces événements sont enregistrés dans le journal des événements.
|
ID d'événement |
Description |
|
608 |
Affectation d'un droit de l'utilisateur. |
|
609 |
Suppression d'un droit de l'utilisateur. |
|
610 |
Création d'une relation d'approbation avec un autre domaine. |
|
611 |
Suppression d'une relation d'approbation avec un autre domaine. |
|
612 |
Modification d'une stratégie d'audit. |
|
768 |
Détection d'un conflit entre un élément d'un espace de noms d'une forêt donnée et un élément d'un espace de noms d'une autre forêt. (Cet événement se produit lorsqu'un élément d'un espace de noms d'une forêt chevauche un élément d'espace de noms d'une autre forêt.) |
Les deux événements les plus importants à rechercher sont les événements 608 et 609. Ils peuvent être le résultat de diverses tentatives d'attaques. Les exemples ci-après génèrent tous un événement 608 en cas d'affectation d'un droit de l'utilisateur, ou un événement 609 en cas de suppression d'un droit de l'utilisateur. Dans chacun de ces cas, l'identificateur de sécurité spécifique auquel est affecté le droit de l'utilisateur en question et le nom d'utilisateur de l'entité de sécurité affectant ce droit sont indiqués dans les détails de l'événement.
· Agir comme faisant partie du système d'exploitation. Recherchez les événements 608 et 609 faisant état du droit seTcbPrivilege dans leurs détails.
· Ajout de stations de travail au domaine. Recherchez les événements faisant état du droit SeMachineAccountPrivilege dans leurs détails.
· Sauvegarde de fichiers et de répertoires. Recherchez les événements faisant état du droit SeBackupPrivilege dans leurs détails.
· Outrepasser le contrôle du parcours. Recherchez les événements faisant état du droit SeChangeNotifyPrivilege dans leurs détails. Ce droit permet à l'utilisateur de parcourir une arborescence de répertoires même s'il ne dispose pas d'une autre autorisation d'accès sur ce répertoire.
· Modification de l'heure système. Recherchez les événements faisant état du droit SeSystemtimePrivilege dans leurs détails. Ce droit permet à une entité de sécurité de modifier l'heure système, de façon à dissimuler l'heure à laquelle un événement se produit.
· Création d'objets partagés permanents. Recherchez les événements faisant état du droit SeCreatePermanentPrivilege dans leurs détails. Un utilisateur disposant de ce droit peut créer des partages de fichiers et d'imprimantes.
· Débogage de programmes. Recherchez les événements faisant état du droit SeDebugPrivilege dans leurs détails. Un utilisateur disposant de ce droit peut se lier à n'importe quel processus. Par défaut, ce droit est l'apanage des administrateurs.
· Arrêt forcé à partir d'un système à distance. Recherchez les événements faisant état du droit SeRemoteShutdownPrivilege dans leurs détails.
· Élévation de la priorité de planification. Recherchez les événements faisant état du droit SeIncreaseBasePriorityPrivilege dans leurs détails. Un utilisateur disposant de ce droit peut modifier les priorités des processus.
· Chargement et déchargement de pilotes de périphériques. Recherchez les événements faisant état du droit SeLoadDriverPrivilege dans leurs détails. Un utilisateur disposant de ce droit peut charger une version de pilote de périphérique comportant un Cheval de Troie.
· Gestion de l'audit et du journal de sécurité. Recherchez les événements faisant état du droit SeSecurityPrivilege dans leurs détails. Un utilisateur disposant de ce droit peut consulter le journal de sécurité et le vider de son contenu.
· Remplacement d'un jeton de niveau processus. Recherchez les événements faisant état du droit SeAssignPrimaryTokenPrivilege dans leurs détails. Un utilisateur disposant de ce droit peut modifier le jeton associé par défaut à un sous-processus démarré.
· Restauration de fichiers et de répertoires. Recherchez les événements faisant état du droit SeRestorePrivilege dans leurs détails.
· Arrêt du système. Recherchez les événements faisant état du droit SeShutdownPrivilege dans leurs détails. Un utilisateur disposant de ce droit peut arrêter le système afin d'initialiser l'installation d'un nouveau pilote de périphérique.
· Appropriation de fichiers ou d'autres objets. Recherchez les événements faisant état du droit SeTakeOwnershipPrivilege dans leurs détails. Un utilisateur disposant de ce droit