Trouver l'intrusion : lire un pattern de brute-force dans des logs d'authentification
Le défi
Voici vos logs d'authentification web. Une IP a martelé le login avec des échecs puis a soudain obtenu un 200 - l'intrusion. Filtrez le bruit (essayez status:401), confirmez que c'est une seule source, et soumettez l'adresse IP de l'attaquant.
Ce que tu vas apprendre
- Filtrer un flux de logs bruité par champ pour isoler les événements pertinents
- Reconnaître la signature échecs puis succès d'un brute force réussi
- Attribuer une intrusion à une seule IP source
- Passer du succès de connexion à l'action suivante de l'attaquant
Compétences testées
Prérequis
- Comprendre les codes de statut HTTP (200 vs 401)
- Connaissance des flux de connexion (login)
Comment ça marche
La plupart du travail en sécurité commence dans les logs, et la compétence clé consiste à séparer le signal du bruit. Un serveur web en production produit un flux constant de trafic ordinaire - des requêtes GET pour des pages et des ressources, renvoyant le plus souvent 200 ou 304, depuis de nombreuses adresses différentes. Une attaque se cache dans ce bruit, donc on filtre le flux pour ne garder que les événements pertinents.
Un brute force d'identifiants ou un password-spray a une forme reconnaissable entre toutes : de nombreuses tentatives d'authentification échouées (401) contre le point d'entrée de login, depuis une seule source, suivies d'un succès (200). Filtrer sur status:401 fait disparaître le bruit et fait apparaître immédiatement cette série - et ici chaque échec porte la même IP, ce qui donne l'attribution. Le moment décisif est la transition : cette même IP obtient finalement un 200 sur /login, et demande immédiatement une page authentifiée (/admin/users). C'est l'intrusion et la première action post-compromission.
La table du SIEM prend en charge la recherche en texte libre et les filtres field:value, ainsi que des puces rapides. Vous ne lisez pas chaque ligne : vous interrogez le motif, confirmez la source unique, et la suivez au-delà du seuil de succès.
Erreurs fréquentes
- Lire les lignes une par une au lieu de filtrer. Faire défiler tout le log fait perdre du temps ; interrogez
status:401et laissez le motif apparaître. - S'arrêter aux échecs. Les échecs montrent la tentative ; le
200depuis la même IP montre l'intrusion réelle. - Accuser une IP anodine. Le bruit, ce sont des GET depuis de nombreuses adresses ; l'attaquant est celui qui répète des POST vers /login.
- Soumettre un chemin ou un statut au lieu de l'IP. La question demande qui, l'adresse source.
Comment s'en protéger
Côté défense, c'est exactement ce que le rate limiting, le verrouillage de compte et les alertes d'anomalie existent pour arrêter. Le même filtre que vous avez utilisé pour le détecter a posteriori peut devenir une détection automatisée.
- Limiter le débit et verrouiller progressivement les connexions échouées répétées, par source et par compte.
- Alerter sur une rafale de 401 suivie d'un 200 depuis la même IP, la signature d'un brute force réussi.
- Exiger le MFA pour qu'un seul mot de passe deviné ne suffise pas à s'introduire.