SSH Honeypot with Seccomp/AppArmor Confinement and ELK Monitoring
Mis à jour :
Introduction au Projet
Ce projet met en œuvre un honeypot SSH sécurisé, déployé sur Linux pour attirer et analyser en temps réel les tentatives d’attaque sur le protocole SSH. Toutes les actions des attaquants sont enregistrées, les tentatives de brute-force sont détectées automatiquement, et des alertes instantanées sont envoyées à l’administrateur via Telegram.
Pour centraliser l’analyse, les logs du honeypot sont collectés et visualisés grâce à la stack ELK (Elasticsearch, Logstash, Kibana), entièrement orchestrée sous Docker. Ce système permet ainsi de surveiller, comprendre et renforcer la sécurité face aux menaces réseau de façon efficace et moderne.
Plan du Projet
- 1. Environnement recommandé
- 2. Technologies utilisées
- 3. Architecture globale
- 4. Développement du Honeypot SSH
- 5. Sécurisation : AppArmor et Seccomp
- 6. Détection du Brute-Force et Alertes Telegram
- 7. Centralisation & Visualisation : Stack ELK (Docker)
- 8. Défis rencontrés
- 9. Perspectives & Conclusion
Réalisation du Projet
1. Environnement recommandé
• Système d’exploitation dans VM : Linux, Ubuntu, Debian
• Virtualisation : Docker + Docker Compose (version ≥ 2.20)
• Accès système : Utilisateur avec privilèges root ou sudo
Outils & Dépendances
| Composant | Rôle | Version recommandée |
|---|---|---|
| Python 3 | Exécution du honeypot SSH (script personnel) | 3.8 ou supérieur |
| Paramiko, requests, seccomp | Librairies Python pour SSH, API, sécurité | Dernière stable |
| Docker & Docker Compose | Conteneurisation stack ELK | Dernière stable |
| Elasticsearch + Kibana | Stockage, visualisation des logs | 8.x (ELK Stack) |
| Logstash (optionnel) | Transformation/enrichissement des logs | 8.x |
| AppArmor | Confinement du processus honeypot | Activé par défaut |
| libseccomp | Sécurité kernel avec filtre syscalls | ≥ 2.5.0 |
| Bot Telegram | Envoi d’alertes en temps réel | @BotFather |
Matériel minimum
| Ressource | Minimum | Recommandé |
|---|---|---|
| Processeur | 1 vCPU | 2+ vCPU |
| RAM | 2 Go | 4–8 Go |
| Stockage | 10 Go | 20+ Go (logs) |
| Connexion réseau | Publique IP fixe dédiée |
Configuration supplémentaire
• Compte Telegram + création d’un bot avec @BotFather
• Ports à ouvrir :
- 2222/tcp → accès SSH (honeypot)
- 5601/tcp → interface Kibana
- 9200/tcp → Elasticsearch (optionnel, accès local recommandé uniquement)
• Règles de pare-feu : n’ouvrir que les ports nécessaires, bloquer tout le reste.
2. Technologies utilisées
Honeypot SSH
Un honeypot est un faux serveur déployé volontairement pour attirer les attaquants, enregistrer leurs actions, et mieux comprendre leurs techniques. Ici, il s’agit d’un serveur SSH développé en Python avec la librairie Paramiko. Il accepte toutes les connexions et simule un vrai shell pour piéger les tentatives.
Python et Paramiko
Python 3 est utilisé pour la rapidité de développement et la flexibilité. La librairie Paramiko permet d’implémenter le protocole SSH et de gérer toutes les étapes (authentification, capture de commandes) de façon fine et contrôlée.
AppArmor
AppArmor est un module de sécurité Linux qui permet de confiner les applications : il définit précisément quels fichiers et commandes le honeypot peut utiliser, et bloque tout le reste. Cela isole le système des attaques potentielles, même si l’attaquant “pense” avoir gagné un accès.
Seccomp
Seccomp (Secure Computing Mode) permet de filtrer et limiter les appels système réalisés par le processus Python du honeypot. Il empêche l’exécution de programmes dangereux ou tout “échappement” hors de l’environnement contrôlé.
Stack ELK (Elasticsearch, Logstash, Kibana)
• Elasticsearch : Moteur de base de données NoSQL, indexe et stocke tous les logs du honeypot pour des recherches rapides.
• Logstash : Outil pour collecter, transformer et envoyer les logs, rendant leur format compatible ELK.
• Kibana : Interface web pour visualiser les attaques, créer des tableaux de bord personnalisés et analyser en temps réel toutes les actions capturées.
Docker & Docker Compose
Permet de lancer tous les composants ELK dans des conteneurs isolés, simplifiant l’installation, la gestion et la reproduction du projet.
Telegram API
Utilisée pour envoyer automatiquement des alertes, en cas de détection de brute-force ou de tentative d’intrusion suspecte.
3. Architecture globale
4. Développement du Honeypot SSH
Le honeypot SSH développé dans ce projet est un faux serveur écrit en Python avec la bibliothèque Paramiko, qui simule parfaitement un point d’accès SSH pour piéger et analyser l’activité des attaquants.
Fonctionnement général
Écoute sur le réseau (port 2222)
Le serveur attend les connexions SSH externes et accepte toutes les tentatives (quel que soit le mot de passe ou l’identifiant utilisé).Enregistrement des connexions et commandes
À chaque connexion, le honeypot enregistre :- l’adresse IP source
- le nom d’utilisateur tenté
- le mot de passe soumis
Dès qu’une session interactive s’ouvre, toutes les commandes tapées (ls, pwd, cat, wget, etc.) sont sauvegardées dans des fichiers logs structurés (JSON ou TXT).
- Simulation d’un shell réel
L’interface présentée à l’attaquant ressemble à un vrai terminal Ubuntu.
Les commandes simples retournent des résultats crédibles mais totalement fictifs :whoami→ rootls→ affiche une fausse arborescenceid→ uid=0(root) gid=0(root)
Aucune commande n’est jamais exécutée sur le système réel.
Exemple d’alerte Telegram envoyée instantanément lors d’une détection de brute-force
(IP, nombre de tentatives, derniers login/mot de passe testés, horodatage)
Points techniques essentiels
Utilisation de Paramiko
Cette librairie gère entièrement la couche SSH (handshake, authentification, chiffrement, canaux). Elle permet de personnaliser chaque étape et de capturer tous les types de tentatives (brute-force, keyboard-interactive, etc.).Gestion multi-sessions
Le script repose sur du threading afin de traiter plusieurs connexions simultanées sans blocage.Préparation à l’intégration ELK
Tous les logs sont générés au format JSON compatible avec Logstash, facilitant leur envoi direct vers la stack ELK pour centralisation et visualisation.
5. Sécurisation : AppArmor et Seccomp
Pour éviter tout risque pour la machine qui héberge le honeypot, deux niveaux de confinement très stricts ont été mis en place : AppArmor et Seccomp.
AppArmor : confinement applicatif
Définition
AppArmor est un module de sécurité Linux (LSM) qui applique un profil obligatoire détaillant exactement ce qu’un programme a le droit de faire (fichiers, réseau, capacités, etc.).- Configuration appliquée
- Profil AppArmor personnalisé créé spécifiquement pour le script Python du honeypot.
- Droits strictement limités aux actions indispensables :
- écoute réseau sur le port 2222 (SSH),
- lecture/écriture dans le répertoire des logs,
- chargement des librairies Python et Paramiko nécessaires.
- Tout le reste explicitement interdit :
- accès à /etc/passwd, /etc/shadow, /proc, etc.,
- exécution de binaires (wget, curl, bash, sh, python, …),
- création de nouveaux fichiers hors du dossier logs.
- Effet concret
Si l’attaquant tente de lire ou modifier un fichier sensible, ou d’exécuter une commande non autorisée, AppArmor bloque immédiatement l’action et écrit un événement dans les logs d’audit (/var/log/audit/audit.log).
Seccomp : filtrage au niveau du noyau
Définition
Seccomp (Secure Computing Mode) restreint les appels système (syscalls) qu’un processus peut effectuer directement dans le kernel.- Mise en œuvre
- Utilisation de la bibliothèque Python libseccomp intégrée dans le script du honeypot.
- Politique stricte appliquée dès le démarrage :
- Blocage total des syscalls execve et execveat (exécution de nouveaux programmes).
- Autorisation uniquement des syscalls indispensables (read, write, socket, etc.).
- En cas de tentative d’exécution externe → le kernel tue immédiatement le processus.
- Effet concret
Même si un attaquant parvenait à contourner la simulation du shell, aucune commande réelle ne peut être lancée. Le processus meurt instantanément.
Illustration pratique
| Action tentée par l’attaquant | Résultat | Protection déclenchée |
|---|---|---|
| cat /etc/shadow | Permission denied | AppArmor |
| wget http://malicious/payload | Processus tué | Seccomp (execve bloqué) |
| /bin/sh ou bash | Processus tué | Seccomp |
| python -c ‘import os; os.system(…)’ | Processus tué | Seccomp |
Pourquoi cette double protection ?
La combinaison AppArmor + Seccomp crée une défense en profondeur :
- AppArmor empêche les accès non autorisés aux ressources du système de fichiers et du réseau.
- Seccomp empêche toute exécution réelle de code, même si une vulnérabilité inconnue existait dans le honeypot.
Résultat : le honeypot reste totalement inoffensif pour la machine hôte, même en cas d’attaque sophistiquée ou de faille 0-day dans le script Python. Tout est détecté, bloqué et loggué.
6. Détection du Brute-Force et Alertes Telegram
Dans ce projet, le honeypot intègre un mécanisme de détection automatique des attaques par brute-force sur SSH. Le principe est de surveiller le nombre de tentatives de connexion provenant d’une même adresse IP sur une fenêtre de temps donnée.
Fonctionnement de la détection
- À chaque tentative d’authentification, le honeypot enregistre l’IP source, le couple login/mot de passe et l’horodatage.
- Une structure en mémoire (par exemple un dictionnaire IP → liste de timestamps) permet de compter le nombre d’essais par IP sur les 60 dernières secondes.
- Si une adresse IP dépasse un seuil de 5 tentatives en moins d’une minute, elle est considérée comme une source d’attaque brute-force.
Alerte Telegram en temps réel
Lorsqu’un seuil de brute-force est détecté :
- Le honeypot génère un message d’alerte contenant :
- l’adresse IP de l’attaquant,
- le nombre de tentatives,
- le dernier identifiant et mot de passe testés,
- la date et l’heure de l’événement.
- Ce message est envoyé via l’API Telegram au canal ou compte de l’administrateur, grâce au bot configuré auparavant.
- L’administrateur reçoit ainsi en temps réel une notification sur son téléphone ou client Telegram, ce qui lui permet de réagir rapidement (blocage de l’IP, analyse plus poussée, etc.).
Pour éviter le spam, un système de « cooldown » peut être appliqué : une IP déjà signalée ne déclenche pas une nouvelle alerte avant un délai défini.
7. Centralisation & Visualisation : Stack ELK (Docker)
Les logs générés par le honeypot sont centralisés et analysés à l’aide de la stack ELK, déployée avec Docker et Docker Compose pour simplifier l’installation et l’orchestration.
Collecte et indexation des logs
- Le honeypot écrit tous ses événements (tentatives de login, commandes, alertes, blocages AppArmor/Seccomp) dans des fichiers log au format JSON.
- Logstash lit ces fichiers et les envoie vers Elasticsearch après éventuellement quelques transformations (ajout de champs, parsing, normalisation).
- Elasticsearch indexe les documents, ce qui permet des recherches rapides par IP, utilisateur, commande, plage temporelle, type d’événement, etc.
Visualisation dans Kibana
- Kibana se connecte à Elasticsearch et permet de construire des tableaux de bord (dashboards) :
- Histogrammes du nombre de tentatives par heure ou par jour.
- Top adresses IP attaquantes.
- Top logins et mots de passe testés.
- Top commandes exécutées dans le honeypot.
- Des vues spécifiques peuvent être créées pour suivre :
- les événements AppArmor (bloquage de fichiers/commandes),
- les événements Seccomp (processus tués),
- les alertes brute-force.
Grâce à cette visualisation, le honeypot ne se contente pas de collecter des données : il fournit une vue claire et exploitable de l’activité malveillante en temps réel.
Aperçu des tableaux de bord Kibana
8. Défis rencontrés
Ce projet a présenté plusieurs défis techniques et pratiques :
Compatibilité Hydra / Paramiko :
Certains comportements d’outils de brute-force comme Hydra ne respectent pas totalement l’ordre des messages SSH attendu par Paramiko.
Il a fallu adapter le code du serveur Paramiko (gestion des exceptions, tolérance à certains défauts de protocole) pour éviter que le honeypot ne se déconnecte trop tôt et pour bien enregistrer toutes les tentatives.Conception du profil AppArmor :
Le profil devait être suffisamment strict pour bloquer toutes les actions dangereuses, sans empêcher le script Python de fonctionner.
Plusieurs itérations ont été nécessaires pour trouver l’équilibre entre fonctionnalité (logs, réseau) et sécurité (blocage des binaires, fichiers sensibles).Intégration de Seccomp :
Il a fallu identifier les appels système réellement nécessaires au bon fonctionnement du honeypot, puis construire une politique qui bloque tout le reste (notamment execve/execveat).
Des tests spécifiques ont été menés (tentatives d’exécution de /bin/bash, /usr/bin/wget, etc.) pour valider que Seccomp réagissait correctement (SIGSYS, processus tué).Orchestration Docker + ELK :
La configuration d’Elasticsearch, Logstash et Kibana dans des conteneurs, avec persistance des données et gestion des ports, demande une attention particulière.
L’alignement entre le format des logs générés par le honeypot et les pipelines Logstash/Kibana a également nécessité quelques ajustements.
9. Perspectives & Conclusion
Perspectives
Plusieurs pistes d’évolution sont envisageables à partir de cette base fonctionnelle :
- Étendre le honeypot à d’autres services et protocoles (HTTP, FTP, Telnet…) pour couvrir un périmètre d’attaque plus large.
- Intégrer des techniques d’analyse comportementale ou de machine learning afin de détecter plus finement les attaques avancées ou atypiques à partir des logs collectés.
- Connecter la stack ELK à une plateforme SIEM ou SOAR pour automatiser encore davantage la réponse aux incidents (blocage automatique d’IP, génération de tickets, corrélation avec d’autres sources de logs).
Conclusion
Ce projet de honeypot SSH avec confinement AppArmor/Seccomp et monitoring ELK offre une chaîne complète de détection et d’analyse des attaques, depuis la simulation du serveur jusqu’à la visualisation avancée et l’alerte en temps réel. Il permet d’observer les méthodes des attaquants sans jamais exposer la machine réelle, grâce à une défense en profondeur qui combine durcissement du système et supervision centralisée.
