Introduction

Détectez les tentatives de force brute et les abus d'identifiants avant qu'ils ne réussissent. Le moniteur de connexions échouées déclenche une alerte lorsqu'un appareil enregistre des tentatives de connexion échouées égales ou supérieures à votre seuil dans une fenêtre temporelle que vous définissez.

Il s'agit d'un moniteur natif qui fonctionne sur Windows, macOS et Linux. Pas d'identifiants d'événements, pas d'analyse de journaux, pas de scripts personnalisés.

Moniteur de connexions échouées

Level lit les tentatives d'authentification échouées depuis les journaux de sécurité propres à chaque système d'exploitation, les comptabilise sur une fenêtre d'observation glissante, et déclenche une alerte lorsque le nombre atteint votre Seuil.

La combinaison seuil + fenêtre permet de distinguer le signal du bruit. Un mot de passe mal saisi, c'est un incident banal. 10 échecs en 5 minutes, c'est une attaque active.

Ce qui est détecté, par plateforme

Les sources de détection diffèrent selon le système d'exploitation, donc la couverture n'est pas identique partout. Il n'y a pas de configuration par système d'exploitation : assignez la politique du moniteur aux appareils Windows, macOS ou Linux et le moniteur fonctionne sur tous.

🖥️ REMARQUE SUR LA PLATEFORME :

Windows: Lit le journal des événements de sécurité (Event ID 4625) via un abonnement en direct. Couvre toutes les tentatives d'ouverture de session échouées enregistrées par Windows : interactives, RDP, réseau, etc. La détection est en temps réel.
macOS: Lit le journal unifié. Couvre les échecs SSH, les échecs sudo et su, ainsi que les échecs de la fenêtre de connexion GUI et de l'écran de verrouillage. Vérifié toutes les 10 secondes.
Linux: Lit /var/log/btmp, le même enregistrement de mauvaise connexion lastb lectures. Couvre tout ce que PAM y écrit : console, SSH, etc. Vérifié toutes les 10 secondes.

⚠️ AVERTISSEMENT : Le moniteur ne voit que ce que le système d'exploitation enregistre. Sur Windows, l'audit des ouvertures de session échouées doit être activé (il l'est par défaut). Sur Linux, la détection dépend de /var/log/btmp existant. Certaines distributions ne le créent pas par défaut, et s'il est absent, l'agent ne signale rien plutôt qu'une erreur. Un appareil silencieux ne prouve pas l'absence de connexions échouées.

💡 CONSEIL : Avant l'existence de ce moniteur, l'approche standard consistait à utiliser un moniteur de journal d'événements surveillant l'Event ID Windows 4625. Le moniteur de connexions échouées remplace cette approche dans la plupart des cas, et contrairement au moniteur de journal d'événements, il couvre également macOS et Linux.

Configuration du moniteur de connexions échouées

Ouvrez la politique du moniteur à laquelle vous souhaitez l'ajouter, puis cliquez sur + Ajouter un nouveau moniteur (ou ouvrez un moniteur de connexions échouées existant pour le modifier). Le panneau de configuration s'ouvre.

Nom et type

Saisissez un nom dans le Nom champ. Soyez précis sur la portée et l'intention : « Serveurs - Connexions administrateur échouées » est plus lisible dans une liste d'alertes que « Alerte de connexion échouée ».
Définissez Type sur Connexion échouée.

Gravité

Définissez Gravité pour correspondre à la manière dont votre équipe doit réagir :

Information — priorité faible, niveau informatif
Avertissement — mérite attention mais pas urgent
Critique — nécessite une réponse rapide
Urgence — tout arrêter immédiatement

💡 CONSEIL : Critique est un choix par défaut raisonnable ici. Des connexions échouées répétées sur un serveur ou un compte administrateur méritent généralement un examen rapide, même si la plupart s'avèrent être un utilisateur ayant oublié son mot de passe après des vacances.

Portée

Portée contrôle quels comptes sont comptabilisés dans le seuil :

Tous les utilisateurs — les tentatives échouées depuis n'importe quel compte sur l'appareil sont comptabilisées
Administrateurs uniquement — seules les tentatives échouées contre des comptes de niveau administrateur sont comptabilisées ; les échecs non-administrateur sont ignorés avant le comptage

Ce qui qualifie un compte d'administrateur dépend de la plateforme :

🖥️ REMARQUE SUR LA PLATEFORME :

Windows: Le compte Administrateur intégré, ou l'appartenance au groupe Administrateurs local.
macOS: root, ou l'appartenance au admin ou wheel groupe.
Linux: root, ou l'appartenance au sudo, wheel, ou root groupe.

💡 CONSEIL : Exécutez deux moniteurs dans la même politique : un large Tous les utilisateurs moniteur en gravité Avertissement, et un Administrateurs uniquement moniteur en Critique ou Urgence. Les attaques contre des comptes privilégiés méritent une alarme plus sonore.

Seuil

Seuil définit le nombre de tentatives échouées qui déclenche l'alerte. Réglez-le avec les flèches haut/bas.

La comparaison est « atteint ou dépasse ». Avec un seuil de 3, la 3e tentative échouée dans la fenêtre déclenche l'alerte. Il n'y a pas d'exigence de vérifications consécutives ; l'alerte se déclenche à la première évaluation qui franchit le seuil.

Durée

Durée est la fenêtre d'observation glissante par rapport à laquelle le seuil est mesuré. Les tentatives plus anciennes que la fenêtre sont retirées du comptage.

Choisissez une unité dans la liste déroulante, puis définissez la valeur avec les flèches ou le curseur :

Minutes — 1 à 120
Heures — 1 à 24

Des fenêtres plus courtes détectent les attaques rapides et automatisées. Des fenêtres plus longues détectent les attaques lentes et délibérées. 3 tentatives en 60 minutes est un point de départ raisonnable pour les postes de travail ; resserrez-le pour les serveurs exposés à RDP ou SSH.

ℹ️ REMARQUE : La fenêtre est glissante, pas fixe. Level vérifie en continu (en temps réel sur Windows, en quelques secondes sur macOS et Linux) et évalue la fenêtre passée, donc les comptages ne se réinitialisent pas en début d'heure.

Remédiation

Associez une ou plusieurs automatisations à exécuter lorsque cette alerte se déclenche. Pour les connexions échouées, Verrouiller l'appareil est le candidat évident : arrêtez d'abord l'attaque, enquêtez ensuite.

Cliquez dans le Remédiation champ et sélectionnez une automatisation.
Pour en ajouter d'autres, cliquez sur + Ajouter une autre remédiation.
Pour en supprimer un, cliquez sur × à côté de celui-ci.

Chaque automatisation associée dispose de 2 icônes : l'icône de lien ouvre l'automatisation dans un nouvel onglet, et l'icône d'œil affiche un aperçu rapide de ce qu'elle fait.

⚠️ AVERTISSEMENT : Les remédiations s'exécutent automatiquement au moment où l'alerte est créée. Associer ce moniteur à une automatisation destructrice (verrouillage, effacement, désactivation de compte) avec un seuil trop bas peut bloquer des utilisateurs légitimes qui se trompent de mot de passe plusieurs fois. Testez votre seuil par rapport au comportement réel avant d'associer des remédiations agressives.

Notifier les destinataires

Deux cases à cocher contrôlent si les destinataires de la politique reçoivent un e-mail :

À la création de l'alerte — les destinataires reçoivent un e-mail lorsque l'alerte se déclenche
À la résolution de l'alerte — les destinataires reçoivent un e-mail lorsque l'alerte est résolue

Les destinataires sont configurés au niveau de la politique du moniteur, dans la Destinataires section. Si aucun destinataire n'est défini dans la politique, aucun e-mail n'est envoyé, quelles que soient ces cases à cocher.

Résolution automatique

Le bouton Résoudre automatiquement l'alerte lorsque les conditions sont levées contrôle si Level ferme automatiquement l'alerte une fois que les tentatives échouées repassent sous le seuil dans la fenêtre d'observation.

Les alertes de connexions échouées représentent quelque chose qui s'est déjà produit, et une fenêtre silencieuse ne signifie pas que l'événement n'avait pas d'importance. Laisser la résolution automatique désactivée maintient l'alerte ouverte jusqu'à ce qu'un technicien l'examine.

Ce que montre l'alerte

Lorsque le moniteur se déclenche, l'alerte résume le comptage (« Détecté 3 tentatives de connexion échouées pour les utilisateurs ») suivi d'une liste par tentative de l'utilisateur et de la source.

Ce qui apparaît dans le champ source dépend de la plateforme :

🖥️ REMARQUE SUR LA PLATEFORME :

Windows: Le nom d'utilisateur apparaît comme DOMAIN\user. La source est l'IP d'origine, avec repli sur le nom du poste de travail.
macOS: La source est l'IP pour les échecs SSH, « local » pour les échecs sudo et su, et « fenêtre de connexion » pour les échecs de l'interface graphique.
Linux: La source est le nom d'hôte enregistré dans btmp.

FAQ

Qui peut créer et modifier des moniteurs ? Les techniciens ayant accès à la politique du moniteur concernée. Les paramètres de permission sont gérés dans Espace de travail → Permissions.
Ce moniteur remplace-t-il le moniteur de journal d'événements pour les connexions échouées ? Dans la plupart des cas, oui. Le moniteur de connexions échouées est natif, ne nécessite aucune configuration d'identifiant d'événement, et fonctionne sur les 3 plateformes. L'approche par journal d'événements reste pertinente si vous souhaitez surveiller des Event ID Windows connexes que ce moniteur ne couvre pas, ou combiner les connexions échouées avec d'autres événements de sécurité dans un seul moniteur.
Quels types de connexions sont comptabilisés ? Tout ce que le système d'exploitation enregistre comme authentification échouée. Sur Windows, il s'agit de tout échec de connexion Event ID 4625 (interactif, RDP, réseau). Sur macOS : SSH, sudo, su, et la fenêtre de connexion GUI ou l'écran de verrouillage. Sur Linux : tout ce que PAM écrit dans btmp, y compris la console et SSH.
Qu'est-ce qui compte comme utilisateur administrateur avec « Administrateurs uniquement » ? Sur Windows, le compte Administrateur intégré ou les membres du groupe Administrateurs local. Sur macOS, root ou les membres du groupe admin ou wheel. Sur Linux, root ou les membres du groupe sudo, wheel ou root.
Les tentatives échouées contre des noms d'utilisateur inexistants sont-elles comptabilisées ? Oui. Level comptabilise chaque tentative échouée enregistrée par le système d'exploitation, que le compte existe ou non sur l'appareil. Une attaque par force brute SSH contre des noms d'utilisateur invalides déclenche quand même le moniteur.
Pourquoi un appareil Linux n'affiche-t-il jamais de connexions échouées, même quand je sais qu'il y en a ? Vérifiez que /var/log/btmp existe. Certaines distributions ne le créent pas par défaut, et sans lui l'agent n'a rien à lire. Il signale zéro plutôt qu'une erreur.
Pourquoi mon alerte ne s'est-elle pas déclenchée ? Je sais que quelqu'un a échoué une connexion. Le comptage doit atteindre ou dépasser le seuil dans la fenêtre de durée. Les tentatives plus anciennes que la fenêtre sont retirées du compte. Vérifiez également que l'appareil est couvert par les tags cibles de la politique, et que votre paramètre de portée correspond au compte concerné.
Puis-je définir des seuils différents pour les serveurs et les postes de travail ? Oui. Créez des politiques de moniteur distinctes ciblant des tags différents et configurez le seuil de chaque moniteur indépendamment.
Que se passe-t-il avec les alertes de connexions échouées ouvertes si je supprime le moniteur ? Les alertes existantes restent en place. Supprimer un moniteur ne ferme pas les alertes qu'il a déjà créées. Résolvez-les manuellement.