> Tech > Comment interpréter le journal de sécurité

Comment interpréter le journal de sécurité

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

Dans l'article " Le journal de sécurité de Windows NT " du mois dernier, j'ai donné une description générale du Journal de sécurité et cité quelques astuces de configuration pour préserver des analyses rétrospectives utiles. Mais il est également indispensable de comprendre les trois plus importantes catégories d'audit d'événements de sécurité : ouverture et fermeture de session, accès aux objets et suivi de processus. Ces trois catégories fournissent des informations cruciales servant à  faire le suivi des actions des utilisateurs. Chaque système a une stratégie d'audit à  laquelle on accède dans le menu Démarrer, Programmes, Outils d'administration, Administrateur des utilisateurs, Stratégies, Audit, boîte de dialogue Stratégie d'audit (écran 1). La boîte de dialogue Stratégie d'audit dicte laquelle, parmi les sept catégories d'événements d'audit, sera enregistrée par le Journal de sécurité local.

Comment interpréter le journal de sécurité

L’ouverture et la fermeture de session sont des événements majeurs pour lesquels
beaucoup d’administrateurs consultent le Journal de sécurité, mais, bien que simple
en apparence, l’interprétation de cette catégorie d’audit peut s’avérer difficile.
Pour commencer, voyons les diverses caractéristiques des événements d’ouverture
de session. Celles qui ont réussi ont l’identification (ID) d’événement 528 (figure
1). En revanche une ouverture de session ayant échoué ne peut jamais avoir cette
ID ; elle a alors une ID permettant d’identifier la raison de l’échec. (Pour une
liste complète des descriptions d’événements de sécurité, voir l’article de Microsoft
 » Security Event Descriptions  » à  l’adresse http://support.microsoft.com/support/kb/articles/q174/0/74.asp).
L’ID d’événement 538 identifie l’événement de fermeture correspondant à  l’événement
528. L’ID 528 donne plusieurs informations importantes dans la zone de description
de l’enregistrement de l’événement. Nom d’utilisateur et Domaine spécifient l’utilisateur
qui s’est connecté ou le compte employé par celui-ci. L’ID de connexion est un
code d’ID unique pour le système permettant d’identifier la session de connexion.
Il peut servir à  trouver les événements de fermeture de session correspondants.
Un événement d’ouverture de session, ID d’événement 528, et son événement de fermeture
de session correspondant, événement 538, permettent aussi de déterminer la durée
de session d’un utilisateur.

La description de l’événement de connexion montre également comment l’utilisateur
s’est connecté

La description de l’événement de connexion montre également le Type de connexion,
qui identifie comment l’utilisateur s’est connecté. Lorsqu’un utilisateur se connecte
sur la console locale (c’est-à -dire clavier et moniteur), le Type de connexion
est le 2, c’est-à -dire une connexion interactive. Lorsqu’un utilisateur d’une
station de travail mappe une unité ou se connecte d’une autre manière à  un autre
ordinateur du réseau, il effectue une connexion de type 3, c’est-à -dire une connexion
réseau. L’événement 528, type 2, indique donc qu’une session a été ouverte sur
la console locale de cet ordinateur et type 3 signifie, quant à  lui, que quelqu’un
s’est connecté à  ce système à  partir du réseau. Lorsqu’un service démarre sous
son compte d’utilisateur spécifique, Windows NT enregistre une connexion de type
5, c’est-à -dire une connexion de service. Si vous utilisez une fonction de file
d’attente batch d’éditeur tiers, comme Argent Queue Manager d’Argent Software,
l’ordonnanceur exécute les travaux batch dans le compte spécifié et NT enregistre
l’ID d’événement 528 avec une connexion de type 4, c’est-à -dire une connexion
de travaux batch. Les ID d’événements 528 et 538 peuvent aussi s’accompagner d’une
connexion de type 7, lorsque quelqu’un déverrouille une station de travail.

Les ouvertures de session peuvent échouer pour plusieurs raisons. Que se passe-t-il
en cas d’échec ? L’explication la plus fréquente est Nom d’utilisateur inconnu
ou mot de passe incorrect., c’est-à -dire l’événement 529. Si un utilisateur a
un compte désactivé ou verrouillé, son ouverture de session échoue et le système
consigne respectivement l’événement 531 ou 539. L’ID 530 indique qu’un utilisateur
a essayé de se connecter en dehors des heures allouées ou des jours spécifiés
pour ce compte d’utilisateur. Si un compte a atteint sa date d’expiration ou si
le mot de passe d’un utilisateur a expiré, le système consigne respectivement
l’ID d’événement 532 ou 535. Si vous sélectionnez l’option Peut ouvrir une session
sur ces stations de travail dans la boîte de dialogue Stations de travail de connexion
(écran 2), afin de restreindre l’accès d’un utilisateur à  certains postes de travail,
et que l’utilisateur essaie de violer cette restriction, NT enregistre l’événement
533. Il est possible d’utiliser des droits pour restreindre les utilisateurs à 
certains types de connexions pour certains systèmes.
Si un utilisateur ne possède pas les droits suffisants pour accéder à  un certain
ordinateur à  partir du réseau et qu’il essaie de mapper une unité à  ce système
ou de visualiser le Registre, la connexion échouera et le système consignera l’événement
534. Celle-ci se produit aussi lorsqu’un utilisateur essaie de se connecter à 
la console et n’a pas les droits indispensables pour se connecter localement.
Les services qui tentent de démarrer au moyen d’un compte dépourvu des droits
avancés
Se connecter en tant que service déclenchent l’ID d’événement 534. Les processus
qui utilisent un compte sans les droits avancés Se connecter en tant que travail
séquentiel pour essayer de se connecter en tant que tel, déclenchent aussi l’ID
d’événement 534. Si une ouverture de session échoue pour une autre raison, elle
provoque l’événement 537 avec l’explication d’échec suivante Une erreur inattendue
s’est produite pendant l’ouverture de session. Ces événements ayant échoué fournissent
aussi des informations sur le type de connexion. Pour en savoir plus sur les audits
de connexions, voir l’article de Microsoft  » Auditing User Authentication  » à 
http://support.microsoft.com/support/kb/articles/q174/0/73.asp.

En réalité, lorsqu’on utilise un compte de domaine, il ne s’agit à  aucun moment
de se connecter au domaine, ni au contrôleur de domaine

Dans l’article  » Introducing the NT Security Log « , j’ai expliqué la nature distribuée
de la consignation NT. C’est lors de l’ouverture et de la fermeture de session
que cette distribution a l’impact le plus fort. On entend souvent parler, à  propos
de la connexion à  une station de travail avec un compte de domaine, de  » connexion
au domaine « , mais, en réalité, lorsqu’on utilise un compte de domaine, il ne
s’agit à  aucun moment de se connecter au domaine, ni au contrôleur de domaine.
La connexion d’une station de travail signifie que seulement l’on se connecte
à  une station de travail. C’est parce que vous utilisez un compte de domaine que
la station de travail ne peut pas vous authentifier.
Voilà  pourquoi la station de travail utilise le protocole d’authentification de
réseau NTLM (Network LAN Manager) pour envoyer les références de l’utilisateur
au contrôleur de domaine. (Pour en savoir plus sur le protocole NTLM, voir l’article
 » Au coeur des améliorations de sécurité du SP4 : NTLMv2  » de novembre 1999). Après
avoir vérifié que votre mot de passe est bon, le contrôleur de domaine vous oublie.
La station de travail maintient votre session de connexion jusqu’à  la fermeture
de session. En conséquence, le Journal de sécurité de la station de travail enregistre
les connexions interactives.

Comment se faire une idée de l’activité globale des ouvertures de session d’un
domaine sans vérifier le Journal de sécurité de chaque poste de travail ? Habituellement
le script de connexion d’un utilisateur effectue le mapping d’unités standards
avec les serveurs de fichiers dès l’ouverture de session. Beaucoup d’administrateurs
vérifient donc la présence, dans les Journaux de sécurité des serveurs de fichiers,
d’événements avec une connexion de Type 3. Comme il n’existe pas d’enregistrement
central de l’activité de connexion pour le domaine, il est difficile de surveiller
les tentatives d’intrusion. Mais il existe d’autres moyens. Bien que les contrôleurs
de domaines n’enregistrent pas toutes les connexions échouées, ils enregistrent
tous les verrouillages de comptes, l’ID d’événement 644, consécutifs à  plusieurs
échecs de connexions rapprochées. Pour en savoir plus sur les événements de verrouillage
de comptes, voir l’article de Microsoft  » Account Lockout Event also Stored in
Security Event Log on Domain Controller  » à  l’adresse http://support.microsoft.com/support/kb/articles/q182/9/18.asp.

Les comptes locaux impliquent la nécessité de surveiller individuellement l’activité
de connexion sur les systèmes. Bien que chaque station de travail et serveur appartienne
à  un domaine et compte principalement sur les contrôleurs de domaines pour l’authentification,
ils maintiennent également l’un et l’autre une base de données SAM locale. Les
utilisateurs et les hackers peuvent utiliser des comptes locaux pour essayer de
se connecter localement ou par le réseau. Le compte intégré Administrateur est
toujours présent et ouvert à  la connexion. Pour des astuces sur la protection
de ce compte, voir l’article  » Protégez les privilèges d’administrateur  » d’avril
2000.

Il est possible de surveiller efficacement des ouvertures et des fermetures de
sessions si l’on sait quoi chercher et où le chercher

Il est possible de surveiller efficacement des ouvertures et des fermetures de
sessions si l’on sait quoi chercher et où le chercher. Pour faire le suivi de
l’activité de connexion, cherchez (plutôt sur les serveurs et les stations de
travail que sur les contrôleurs de domaines) les ouvertures de session avec l’ID
d’événement 528 et les fermetures de session correspondantes avec l’ID d’événement
538. Pour surveiller les éventuelles tentatives d’intrusion, cherchez les événements
avec l’ID d’événement 529 à  537 et l’ID 539 sur chaque système vulnérable.

Téléchargez cette ressource

SD-WAN de confiance : guide de mise en œuvre

SD-WAN de confiance : guide de mise en œuvre

Ce livre blanc décrit les différents aspects indispensables pour la mise en place d’une approche SD-WAN sécurisée et de confiance. Ce document s’adresse aux consultants et responsables sécurité des systèmes d’information pour bien comprendre les enjeux du Trusted SD-WAN à l’heure de la transformation numérique des entreprises.

Tech - Par iTPro.fr - Publié le 24 juin 2010

A lire aussi sur le site

Revue Smart DSI

La Revue du Décideur IT