
Honeypot SSH/Telnet avec Cowrie
Simulation d'intrusion et analyse forensique sur un lab cybersécurité isolé
Contexte
Ce projet fait partie d'un lab cybersécurité personnel construit sous VMware Workstation Pro, avec une machine attaquante (Kali Linux) et une machine cible (Debian) isolées sur un réseau virtuel dédié (VMnet2), sans accès au réseau de production ni à Internet.
L'objectif : déployer un honeypot SSH/Telnet (Cowrie) sur la machine cible, simuler une attaque par force brute depuis la machine attaquante, puis analyser en détail les traces laissées par l'attaquant.
Objectifs
- Déployer et configurer Cowrie pour émuler un service SSH vulnérable, avec redirection du vrai service SSH vers un port non standard.
- Mener une attaque par force brute réaliste (Hydra) contre le honeypot depuis la machine attaquante.
- Extraire et analyser les journaux JSON générés par Cowrie (commandes tapées, tentatives de téléchargement de fichiers).
- Documenter intégralement la démarche, y compris les incidents rencontrés, dans une base de connaissance Notion.
Déroulé du projet
- 1Mise en place du honeypotJ'ai installé Cowrie sur la cible, redirigé le port 22 vers le honeypot via iptables et déplacé le vrai service SSH vers le port 2200, avec persistance des règles via iptables-persistent.
- 2Incident majeur : perte d'accès à la machine attaquanteJe me suis retrouvée bloquée hors du mot de passe de Kali Linux, sans snapshot de secours exploitable. J'ai décidé de réinstaller entièrement la VM à partir de l'image officielle plutôt que de tenter une récupération incertaine.
- 3Attaque par force bruteJ'ai lancé Hydra contre le honeypot. Ma première tentative a échoué (parallélisme par défaut trop élevé pour l'implémentation Twisted de Cowrie) ; je l'ai corrigée en réduisant le nombre de tâches parallèles.
- 4Analyse forensique des logsJ'ai extrait les événements JSON avec jq : commandes tapées par l'attaquant simulé, tentatives de téléchargement de fichiers, reconstitution complète de la session.
Résultats
- Mots de passe compromis
- 3 / 3 testés
- Commandes attaquant capturées
- 17
- Tentatives de téléchargement de fichiers
- 0 (bloquées, cible isolée)
- Snapshots de restauration
- 2 (cible + attaquant)
Gestion d'incident
Le point le plus formateur du projet n'était pas prévu au départ : une erreur de manipulation de ma part a verrouillé mon accès à la machine attaquante, sans snapshot exploitable pour revenir en arrière.
Plutôt que de perdre du temps sur une récupération incertaine (tentative infructueuse en mode recovery GRUB), j'ai réinstallé entièrement la VM depuis l'image officielle Kali, restauré la configuration réseau et les outils nécessaires, puis repris l'attaque planifiée. J'ai documenté cet incident en détail dans le journal du projet, avec la chronologie complète et les commandes de remédiation.
Stack et outils
- Kali Linux (machine attaquante) et Debian (cible), sous VMware Workstation Pro 17
- Cowrie (honeypot SSH/Telnet, déploiement Python via pip)
- Hydra (attaque par force brute)
- iptables / iptables-persistent (redirection de ports, persistance des règles)
- jq (extraction et analyse des logs JSON)
Captures d'écran
