Blocages temporaires
Pour se protéger des attaques par force brute, l'ENT verrouille automatiquement un identifiant après un nombre de tentatives de connexion échouées trop élevé sur une courte période. Le compte — ou plus exactement l'identifiant saisi — est alors temporairement bloqué : toute nouvelle tentative est refusée jusqu'à l'échéance, où le déblocage est automatique.
La page Dashboard → Administration → Blocages temporaires (/admin/login-bans) donne une vue de
suivi en temps réel de ces verrouillages.
| Blocage temporaire | Blocage d'un utilisateur | |
|---|---|---|
| Origine | Automatique (trop d'échecs de connexion) | Manuel (décision d'un administrateur) |
| Durée | Temporaire, levée automatique à l'échéance | Permanent jusqu'au déblocage manuel |
| Porte sur | L'identifiant saisi (compte existant ou non) | Un compte existant de l'annuaire |
| Stockage | Compteurs Redis avec expiration (TTL) | Propriété blocked du compte (Neo4j) |
Politique de blocage
Le verrouillage est piloté par deux paramètres de configuration du module d'authentification :
| Paramètre | Clé de configuration | Valeur par défaut |
|---|---|---|
| Seuil de verrouillage — nombre d'échecs avant blocage | maxRetry | 5 échecs |
| Durée du blocage — délai avant déverrouillage automatique | banDelay | 900 000 ms (15 min) |
La page rappelle ces valeurs en vigueur dans l'encart « Politique de blocage appliquée », afin que l'administrateur sache à quel seuil et pour quelle durée un compte est verrouillé.
Lire le tableau de bord
L'écran présente :
- Indicateurs de tête :
- Comptes verrouillés — nombre d'identifiants bloqués en ce moment ;
- Comptes sous tension — identifiants dont les échecs sont en cours de comptage (sans avoir encore atteint le seuil) ;
- Échecs comptabilisés — total des tentatives récentes retenues ;
- Identifiants inexistants — logins ciblés ne correspondant à aucun compte (typiquement
admin,root… : signe d'un balayage automatisé).
- Tableau « Comptes actuellement verrouillés », une ligne par identifiant bloqué :
- le compte (nom et profil s'il existe dans l'annuaire, sinon « Identifiant inconnu ») et l'identifiant saisi ;
- le nombre d'échecs (avec un repère « Récidive » lorsque les tentatives ont continué après le verrouillage) ;
- le compte à rebours avant déverrouillage automatique (anneau de progression + temps restant) ;
- l'IP source de la dernière tentative (lorsqu'elle est connue) ;
- l'action Débloquer.
Le compte à rebours s'actualise en continu et la liste se rafraîchit automatiquement ; le bouton Rafraîchir force une mise à jour immédiate.
Débloquer un compte
L'action Débloquer lève immédiatement le verrouillage de l'identifiant : ses compteurs de tentatives sont remis à zéro et l'utilisateur peut retenter une connexion sans attendre l'échéance.
Un déblocage manuel est utile lorsqu'un utilisateur légitime s'est verrouillé (mot de passe oublié, erreurs de saisie répétées). À l'inverse, pour un identifiant inexistant ou manifestement ciblé par une attaque, il vaut mieux laisser le blocage suivre son cours.
Mécanisme technique
- À chaque échec d'authentification, le module auth incrémente une liste Redis
logban:<identifiant>horodatée, expirée automatiquement aprèsbanDelay. Au-delà demaxRetryentrées dans la fenêtre, l'identifiant est refusé (auth.error.ban). - En parallèle, l'IP source de chaque tentative est conservée (liste
logbanip:<identifiant>, même rétention) pour alimenter la colonne IP source. - L'endpoint
GET /auth/admin/login-bans(réservé ADML / super-administrateur) parcourt ces compteurs, calcule l'échéance de déverrouillage et enrichit chaque identifiant avec les informations de l'annuaire (nom, profil). Le déblocage passe parDELETE /auth/admin/login-bans/:identifiant.
Les compteurs de blocage sont globaux à la plateforme (indexés par identifiant, sans rattachement d'établissement) et s'effacent d'eux-mêmes à l'expiration : la page reflète l'état courant et ne conserve pas d'historique au-delà du TTL.