Bienvenue dans le Guide des opérations sur la sécurité de Windows 2000 Server. Dans un monde de plus en plus interconnecté, la disponibilité d'informations en
télécharger 1.21 Mb.
|
Références/liens : Site de sécurité TechNet de Microsoft : http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/itsolutions/security/bestprac/secthret.asp (site en anglais) Site Microsoft des méthodes de sécurité conseillées : http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/itsolutions/security/bestprac/secthret.asp (site en anglais) How to Publish non-MSI Programs with .zap Files (Q231747) : http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q231747 (site en anglais) 6 Audit et détection des intrusions Une surveillance active contre les intrusions et les attaques est nécessaire dans tout environnement sécurisé. Il faudrait être naïf pour installer des systèmes en pensant 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. Peu importe votre niveau de sécurité, les risques d'attaques existent. ● Une série d'attaques manquées précède souvent des attaques réussies. Si vous ne surveillez pas les attaques, vous ne pourrez pas les détecter 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 qui ont été causés. ● L'audit et la détection des intrusions vous permettent de déterminer 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. ● La révision régulière des journaux de sécurité permet d'identifier des problèmes inconnus liés à la configuration de la sécurité, notamment des autorisations incorrectes ou des paramètres de verrouillage de compte imprécis. ● Lorsqu'une attaque est détectée, l'audit permet de déterminer quelles ressources réseau sont endommagées. Ce chapitre explique comment auditer votre environnement afin de vous procurer les meilleures solutions de détection des attaques. 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 détecter un comportement indiquant une attaque. Audit Vous devez déterminer le niveau d'audit approprié pour votre environnement en tant que partie intégrante de votre stratégie globale de sécurité. L'audit doit identifier les attaques, réussies ou non, qui représentent une menace pour votre réseau ou par rapport à des ressources précieuses faisant partie de votre estimation des risques. Lorsque vous décidez de l'ampleur de l'audit, 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 détecter les événements critiques. Si vous optez pour un audit étendu, vous devez sérieusement envisager d'utiliser des outils complémentaires, notamment Microsoft Operations Manager, afin de vous aider à filtrer les événements les plus stratégiques. Les événements d'audit se divisent en deux catégories : les événements de type succès et échec. Un événement de type succès indique qu'un utilisateur a pu accéder à une ressource alors qu'un événement de type échec indique une tentative d'accès qui a échoué. Les événements de type échec sont très utiles pour détecter les tentatives d'attaques dans votre environnement contrairement aux événements de type succès qui sont bien plus difficiles à interpréter. La majorité des événements d'audit positif indiquent simplement une activité normale. Cependant, un assaillant qui réussit à infiltrer un système génèrera également un événement de type succès. Bien souvent, un modèle d'événement est aussi important que les événements. Par exemple, une série d'échecs suivie par un succès peut indiquer une tentative d'attaque qui a réussi. Si vous le pouvez, associez les événements d'audit à d'autres informations dont vous disposez sur les utilisateurs. Par exemple, si des utilisateurs sont en vacances, vous pouvez désactiver leur compte pendant leur absence, puis les auditer lorsqu'ils sont réactivés. Comment activer l'audit Vous pouvez activer l'audit via une stratégie de groupe, au niveau du site, du domaine, de l'unité d'organisation ou du PC local. Vous trouverez les paramètres de stratégie d'audit sous Configuration de l'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 Active Directory car cela vous permet d'assurer la cohérence de vos paramètres d'audit. Ce guide permet de mettre en œuvre l'audit au niveau du serveur membre et de l'unité d'organisation du contrôleur de domaine (pour plus d'informations, reportez-vous au Chapitre 4, « Sécurisation des serveurs en fonction de leur rôle »). Vous disposez peut-être de serveurs que vous avez choisis de séparer du domaine. Dans ce cas, vous pouvez configurer l'audit sur ces systèmes en modifiant la Stratégie de groupe de l'ordinateur local via l'utilitaire Auditpol.exe disponible dans le Kit de ressources Windows 2000 Server. Remarque : pour accéder à la stratégie de groupe d'un ordinateur local, démarrez la MMC, puis ajoutez le composant logiciel enfichable Stratégie de groupe qui ciblera l'ordinateur local. Spécification des paramètres du journal des événements 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 ces paramètres, reportez-vous au Chapitre 4, « Sécurisation des serveurs en fonction de leur rôle ». Vous pouvez modifier les paramètres définis dans la Stratégie de groupe ou appliquer des paramètres à un autre niveau. Par exemple, si vous constatez que votre journal de sécurité est plein sur les serveurs IIS et qu'il entraîne la fermeture du système, vous pouvez modifier la stratégie de groupe sur l'unité d'organisation du serveur IIS afin d'augmenter la taille du journal de sécurité ou modifier la stratégie afin que le système ne s'arrête pas lorsque le journal de sécurité est saturé. Pour définir les paramètres du journal de sécurité dans une stratégie de groupe, procédez comme suit : Pour modifier les paramètres du journal des événements via une stratégie de groupe ou une unité d'organisation
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, il est recommandé de définir les paramètres de l'Observateur d'événements dans la stratégie de groupe afin d’assurer la cohérence des paramètres sur des ordinateurs semblables. Événements à auditer Windows 2000 intègre 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 les catégories d'événements de sécurité à inclure dans l'audit parmi les catégories suivantes : ● événements d'ouverture de session ; ● événements d'ouverture de session de compte ; ● accès aux objets ; ● accès au service d'annuaire ; ● utilisation des droits ; ● suivi des processus ; ● événements système ; ● modification de stratégie. Les sections suivantes décrivent les 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 ultérieurement dans la section « Méthodes de détection passive » de ce chapitre. Événements d'ouverture de session Si vous auditez les événements d'ouverture de session, à 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 d'ouverture de session est généré dans le journal de sécurité de ce serveur. Les événements d'ouverture de session sont créés lorsque la session d'ouverture est créée et le jeton détruit. Les événements d'ouverture de session peuvent être utiles pour détecter des tentatives de connexion interactive aux serveurs ou pour analyser des attaques perpétrées à partir d'un ordinateur spécifique. Les audits positifs génèrent une entrée lorsqu'une tentative de connexion se produit. Les audits négatifs génèrent une entrée lorsqu'une tentative de connexion échoue. Remarque : les événements d'ouverture de session intègrent les événements d'ouverture de session utilisateur et système. Des entrées distinctes s'affichent dans le journal des événements de sécurité pour le compte système et le compte utilisateur si une tentative de connexion au réseau se produit à partir d'un ordinateur fonctionnant sous Windows NT ou sous Windows 2000. Les ordinateurs fonctionnant sous Windows 9x ne disposent pas de comptes d'ordinateur dans l'annuaire et ne génèrent aucune entrée d'événements d'ouverture de session ordinateur pour les événements de connexion au réseau. Partie intégrante des stratégies de base des serveurs membres et des contrôleurs de domaine, l'audit des événements d'ouverture de session de type succès et échec est activé. Vous devez donc vous attendre à trouver les ID d'événements ci-après pour les connexions interactives et les ouvertures de session de Services Terminal Server connectées aux ordinateurs exécutant les Services Terminal Server. Tableau 6.1 : Événements d'ouverture de session visibles dans le journal des événements
Les événements de sécurité ci-après peuvent être diagnostiqués en utilisant les entrées d’événements d’ouverture de session : ● Échecs de tentatives d’ouverture de session locale. Les ID d’événements ci-après indiquent 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 assaillant ne réussit pas à deviner le nom d’utilisateur et le mot de passe d’un compte local. Cependant, ces événements peuvent également se produire si un utilisateur oublie son mot de passe ou commence à naviguer sur le réseau sous 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 mot 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 une utilisation incorrecte d’un compte utilisateur. Ces événements indiquent que l’association compte/mot de passe 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’il s’agit 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 de certains comptes. ● Verrouillage des comptes. L’événement 539 représente le verrouillage d’un compte. Il peut indiquer l’échec d’une attaque de mot de passe. Vous devez rechercher les événements 529 antérieurs pour ce compte utilisateur et 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. Ainsi l’exécution des processus continue lorsque la session est terminée. L’événement 683 indique un utilisateur qui ne ferme pas une session de Services Terminal Server et l’événement 682 indique une connexion à une session précédemment déconnectée. |
