Analyseur de logs SSH en Python : détection des activités suspectes
Présentation du projet
Dans le cadre de la construction de mon portfolio en cybersécurité, j'ai développé un outil en Python permettant d'analyser des journaux d'authentification SSH afin d'identifier des comportements potentiellement malveillants.
L'objectif est de transformer des logs système en informations exploitables pour détecter des tentatives de brute force, des connexions suspectes et des comportements pouvant indiquer une compromission de compte.
Le projet m'a permis de travailler sur l'analyse de journaux, la détection basée sur des règles, la corrélation d'événements et les tests automatisés.
Stack technique
- Python : développement de l'analyseur.
- Logs SSH : données d'authentification à analyser.
- Pytest : tests automatisés.
- Git / GitHub : versionnement et documentation du projet.
1. Fonctionnement général
L'analyseur lit un fichier de logs SSH, identifie les événements d'authentification et extrait les informations utiles à leur analyse : horodatage, adresse IP source, nom d'utilisateur et résultat de la tentative.
Les événements sont ensuite exploités pour rechercher des séquences inhabituelles. Le programme s'appuie sur des règles définies à l'avance afin de produire des alertes structurées lorsqu'un comportement correspond à un scénario suspect.
Le traitement est organisé en plusieurs étapes :
- Lecture du fichier de logs.
- Identification et normalisation des événements.
- Analyse des tentatives de connexion.
- Application des règles de détection.
- Génération des alertes.
2. Fonctionnalités principales
Analyse des authentifications
L'outil distingue les tentatives d'authentification échouées des connexions réussies. Il permet notamment de suivre les adresses IP sources, les comptes ciblés et la fréquence des échecs.
Ces informations constituent une base utile pour identifier des comportements pouvant correspondre à une tentative d'accès non autorisé.
Détection des tentatives de brute force
Une règle identifie les adresses IP générant au moins 5 tentatives de connexion échouées sur une période de 60 secondes.
Cette règle permet de signaler les tentatives répétées susceptibles de correspondre à une attaque par force brute.
- Règle :
BRUTE_FORCE - Seuil : 5 échecs
- Fenêtre temporelle : 60 secondes
- Gravité :
HIGH
Détection d'une connexion réussie après plusieurs échecs
Une connexion réussie après au moins 3 échecs provenant de la même adresse IP et visant le même compte constitue un autre scénario surveillé.
Ce comportement peut correspondre à une tentative de brute force ayant abouti, mais il doit être interprété dans son contexte : des erreurs de saisie répétées peuvent également être légitimes.
- Règle :
SUCCESS_AFTER_FAILURES - Condition : au moins 3 échecs avant une connexion réussie, pour la même IP et le même utilisateur
- Gravité :
HIGH
Détection d'une IP ciblant plusieurs utilisateurs
L'analyseur repère également les situations où une même adresse IP tente de s'authentifier sur plusieurs comptes.
Ce comportement peut indiquer une tentative d'énumération de comptes ou une attaque ciblant plusieurs utilisateurs.
- Règle :
MULTIPLE_USERS - Comportement surveillé : une IP cible plusieurs noms d'utilisateur
- Gravité :
MEDIUM
3. Corrélation des événements
Au-delà de l'analyse de chaque règle séparément, le projet inclut une détection combinée : BRUTE_FORCE_SUCCESS.
Cette alerte vise à corréler une séquence de tentatives de connexion échouées avec une authentification réussie ultérieure, lorsque les conditions de la règle sont satisfaites.
La corrélation permet de donner davantage de contexte aux événements : une succession d'échecs suivie d'une connexion réussie mérite une attention particulière par rapport à des échecs isolés.
- Règle :
BRUTE_FORCE_SUCCESS - Objectif : identifier une séquence de brute force suivie d'un succès
- Gravité :
CRITICAL
Cette détection est une indication nécessitant une investigation complémentaire ; elle ne prouve pas, à elle seule, qu'un compte a été compromis.
4. Structuration et traitement des alertes
Les alertes sont structurées autour d'un type de détection et d'un niveau de gravité. Cette organisation facilite leur lecture et permet de distinguer les événements nécessitant une attention immédiate de ceux qui doivent être examinés dans leur contexte.
Les niveaux utilisés dans le projet comprennent :
L'analyseur prévoit également la gestion des problèmes de lecture, notamment lorsqu'un fichier est inaccessible ou absent.
5. Tests automatisés avec Pytest
Pour vérifier le comportement du programme, j'ai ajouté des tests automatisés avec Pytest.
Les scénarios couvrent notamment :
- la détection d'une tentative de brute force ;
- l'absence d'alerte lorsque le seuil n'est pas atteint ;
- une connexion réussie après plusieurs échecs ;
- le ciblage de plusieurs utilisateurs par une même IP ;
- la corrélation d'événements dans une fenêtre temporelle ;
- les cas négatifs où les conditions de détection ne sont pas réunies ;
- la lecture des fichiers et la gestion des fichiers absents.
Les tests permettent de vérifier que les règles fonctionnent comme prévu et que des événements ne déclenchent pas systématiquement des alertes lorsqu'ils ne répondent pas aux conditions définies.
6. Métriques et règles de détection
Le projet s'appuie sur plusieurs paramètres mesurables pour identifier des comportements suspects.
Ces valeurs correspondent aux règles de détection définies dans le projet. Elles ne représentent pas des performances mesurées ni un taux de détection d'attaques réelles.
7. Résultats et compétences acquises
Ce projet m'a permis de mettre en pratique plusieurs compétences utiles en cybersécurité :
- analyse de journaux d'authentification ;
- identification de comportements suspects ;
- détection basée sur des règles et des seuils temporels ;
- corrélation d'événements ;
- génération d'alertes avec différents niveaux de gravité ;
- tests automatisés et validation des scénarios ;
- structuration d'un outil Python maintenable.
L'analyseur constitue une première étape vers des outils de surveillance de sécurité plus avancés. Il pourrait notamment être enrichi par la prise en charge de nouveaux formats de logs, une configuration externe des règles, un export des alertes en JSON et une intégration avec une solution SIEM.
Le projet m'a surtout permis de comprendre comment passer de journaux bruts à des alertes structurées pouvant servir de point de départ à une investigation de sécurité.