> Tech > Surveiller les défaillances de connexion

Surveiller les défaillances de connexion

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

Les défaillances de connexion dues à  des mots de passe incorrects peuvent indiquer qu'un imposteur est en train d'essayer de deviner le mot de passe d'un utilisateur. Il est donc extrêmement important de surveiller de près ces défaillances. Pour suivre les défaillances de logon pour mot de passe incorrect pour

Surveiller les défaillances de connexion

les comptes domaine,
recherchez dans tous vos Security logs
Win2K l’event ID 675 (Pre-authentication
failed) avec le code de défaillance
0x18 et l’event ID 681 (The logon to account:
%2 by: %1 from workstation: %3
failed. The error code was: %4) avec le
code d’erreur 3221225578. Sur des DC
Windows 2003, ne recherchez pas
l’event ID 681. Dans XP et produits ultérieurs,
Microsoft a remplacé l’event
ID 681 par l’event ID 680. Win2K n’utilisait
l’event ID 680 que pour signaler
les authentifications réussies. Avec XP
et les OS ultérieurs, event ID 680 peut
signifier une authentification réussie ou défaillante, comme indiqué par les
types d’événement Failure Audit ou
Success Audit.
Vous trouverez le code de défaillance
ou d’erreur dans la description
de l’événement. Le DC journalise
l’event ID 675 quand l’authentification
Kerberos échoue et un event ID 680
défaillant ou event ID 681 quand l’authentification
de Windows NT LAN
Manager échoue. Un event ID 680 ou
event ID 681 défaillant signifie que l’un
au moins des ordinateurs impliqués
dans le logon est un ordinateur pré-
Win2K ou un ordinateur provenant
d’un domaine non sécurisé. L’ordinateur
pré-Win2K peut être une station
de travail ou un serveur membre (par
exemple, un utilisateur à  une station
de travail Win2K se connectant à  un
serveur membre pré-Win2K avec un
compte de domaine). Vous pouvez
identifier la station de travail en recherchant
l’adresse IP client dans
event ID 675 ou le nom de la station de
travail dans event ID 680 ou event ID
681.
D’autres types de défaillances de
logon génèrent event ID 676 (Authentication
Ticket Request Failed) pour
l’authentification Kerberos mais, pour
l’authentification NTLM, Windows
2003 et XP continuent à  utiliser event
ID 680 avec le type d’événement
Failure Audit, et Win2K continue à  utiliser
event ID 681. Ces défaillances de
logon incluent des noms d’utilisateurs
incorrects, une expiration de compte
ou de mot de passe, et des heures interdites
dans la journée (quand quelqu’un
essaie de se connecter à  une
heure où il n’y est pas autorisé). Pour
reconnaître la raison de la défaillance
d’authentification, examinons le code
de défaillance pour event ID 676, que
montre la figure 1, et le code d’erreur
pour event ID 681, qu’illustre la figure
2
. A noter que le code de défaillance
d’event ID 676 n’est pas aussi spécifique
que le code d’erreur d’event ID
681. Le code de défaillance d’event ID
676 correspond au code de défaillance
indiqué par le protocole Kerberos.
Si vous avez l’habitude de renommer
le groupe Administrator pour le
masquer aux yeux des assaillants, recherchez
event ID 680 avec le code
d’erreur 3221225572 et event ID 676
avec le code de défaillance 6 et
Administrator comme nom d’utilisateur.
Sur Win2K, recherchez event ID
681. En revanche, sur Windows 2003 et
XP, recherchez event ID 680 avec le
type d’événement Failure Audit.
Microsoft a remplacé event ID 681 par
event ID 680 repéré comme défaillance.
Ces événements indiquent
une défaillance de logon par suite d’un
nom d’utilisateur invalide pour NTLM
et Kerberos, respectivement. Le tableau
1
donne la liste des codes d’erreur
et de défaillance d’authentification.
Le fait de superviser event ID 675
et event ID 676 ainsi que event ID 680
défaillant ou event ID 681 défaillant sur
vos DC vous donnera un aperçu complet
de toutes les défaillances de logon
sur les comptes de domaine mais ne
détectera pas les tentatives de logon
aux serveurs membres au moyen de
comptes SAM locaux. En effet, les assaillants
utilisent souvent des comptes
locaux pour tenter d’atteindre les ordinateurs
parce que ces comptes sont
plus difficiles à  superviser et à  contrôler
et ont souvent de faibles mots de
passe. Pour superviser ce genre d’activité,
activez Audit account logon
events sur vos serveurs membres et
surveillez event ID 681, qui signifie que
quelqu’un a essayé de se connecter au
serveur par le biais du compte local indiqué.
Les serveurs membres ne journalisent
jamais les événements
Kerberos parce que les comptes SAM
locaux utilisent toujours l’authentification
NTLM. Assurez-vous que vos administrateurs
suivent les meilleures
pratiques et évitent d’utiliser des
comptes locaux au lieu de comptes de
domaines. Ensuite, supervisez les logons
de comptes SAM locaux réussis
sur vos serveurs (event ID 681). Si vos
administrateurs évitent d’utiliser des
comptes SAM locaux au lieu de
comptes de domaines, vous devez juger
suspecte toute activité Audit account
logon events sur les serveurs
membres.
Vous pourriez envisager de désactiver
la catégorie Audit logon events sur
les serveurs membres parce qu’elle génère
des événements pour les logons
des comptes SAM locaux et des
comptes de domaines, sans les distinguer
et parce qu’elle est grandement redondante par rapport à  Audit account
logon events. Le seul intérêt
d’activer Audit logon events sur les serveurs
membres est qu’elle vous permet
de distinguer entre des logons interactifs
et des connexions provenant
d’utilisateurs situés ailleurs sur le réseau.
Si vous voulez suivre tous les logons
à  partir de la console serveur, recherchez
event ID 528 (Successful
Logon) avec logon type 2 et les tentatives
Audit logon events défaillantes
avec logon type 2. Pour suivre les
connexions vers un ordinateur par un
utilisateur situé ailleurs sur le réseau,
recherchez event ID 540 (Successful
Network Logon) qui signifie un logon
réseau. Audit logon events permet
aussi de savoir pendant combien de
temps l’utilisateur a été connecté.
Notez le logon ID, que vous pouvez
trouver dans la description de event ID
540 ou event ID 528. Puis recherchez
event ID 538 (User Logoff) avec le
même logon ID. En utilisant le même
logon ID pour lier le logon event
(event ID 540 ou event ID 528) au
logoff event (event ID 538), vous pouvez
connaître la durée de la session.
Si votre politique de verrouillage
des comptes prévoit le verrouillage automatique
après un certain délai, vous
ne pourrez pas détecter les verrouillages
dus à  des utilisateurs appelant
pour redéfinir leurs mots de passe,
sauf si vous recherchez dans vos logs
event ID 644 (User Account Locked
Out). Sur les DC, event ID 644 signifie
qu’un compte de domaine a été évincé
par verrouillage ; sur les serveurs
membres, il signifie qu’un compte SAM
local a été évincé par verrouillage. Cet
événement fait partie de la catégorie
Audit account management, pas des
catégories logon. Il peut être intéressant
de superviser les logons sur les
serveurs et domaines pendant des
heures inhabituelles. Cela peut permettre
de détecter une acticité suspecte
(ou tout simplement quelqu’un
qui travaille tard).

Téléchargez gratuitement cette ressource

Sécurité Office 365 : 5 erreurs à ne pas commettre

Sécurité Office 365 : 5 erreurs à ne pas commettre

A l’heure où les données des solutions Microsoft de Digital Workplace sont devenues indispensables au bon fonctionnement de l’entreprise, êtes-vous certain de pouvoir compter sur votre plan de sécurité des données et de sauvegarde des identités Microsoft 365, Exchange et Teams ? Découvrez les 5 erreurs à ne pas commettre et les bonnes pratiques recommandées par les Experts DIB France.

Tech - Par iTPro - Publié le 24 juin 2010

A lire aussi sur le site

Revue Smart DSI

La Revue du Décideur IT