Mise en place d'un SIEM et d'un Honeypot

Le laboratoire

Le projet est monté sous VirtualBox, avec quatre machines : un pare-feu OPNsense, la VM SIEM qui porte le stack ELK, le honeypot Cowrie et un poste d'administration Ubuntu. Le réseau est découpé en trois zones : un LAN pour l'administration et le SIEM, une DMZ pour le honeypot, et le WAN vers l'extérieur. Chaque interface d'OPNsense tient une zone, adressée en privé.

Segmentation et pare-feu

OPNsense se configure d'abord en console, pour l'assignation des interfaces et des adresses, puis par l'interface web pour les règles. Les points qui comptent :

• une redirection de port qui envoie toute tentative SSH arrivant sur le WAN vers Cowrie, dans la DMZ ;
• un blocage de la DMZ vers le LAN, pour qu'une compromission du honeypot ne serve pas de rebond ;
• l'accès Internet ouvert depuis le LAN et le WAN, le reste bloqué par défaut.

La chaîne ELK

Sur la VM SIEM (Ubuntu 24.04), installation d'Elasticsearch 8.x depuis le dépôt Elastic, clé GPG et source APT, puis de Kibana et de Logstash. Kibana réclame un jeton d'enrôlement et un code de vérification générés en ligne de commande, et le mot de passe du compte elastic est réinitialisé pour la première connexion. Logstash a besoin d'un runtime Java, installé au passage.

Le honeypot Cowrie et Filebeat

Cowrie tourne sous un utilisateur dédié sans droits root, dans un environnement virtuel Python cloné depuis le dépôt officiel. Le fichier cowrie.cfg active aussi Telnet en plus du SSH pour élargir la surface exposée. Sur la même VM, Filebeat lit le journal JSON de Cowrie et l'envoie à Elasticsearch sur la VM SIEM. Un filebeat test config valide la configuration avant démarrage.

Visualisation et alerte

Dans Kibana : création de l'index et d'une vue de données filebeat, puis d'une visualisation Lens qui compte les événements dans le temps, filtrée sur event.module: cowrie pour ne garder que le honeypot, et posée sur un tableau de bord.

Pour l'alerting, il faut d'abord générer une clé de chiffrement (openssl rand -base64 32) et la déclarer dans kibana.yml, puis redémarrer le service. Ensuite une règle Elasticsearch query en KQL surveille event.module: cowrie et déclenche un connecteur Server log qui écrit un message dans le journal de Kibana.

Test de bout en bout

Validation depuis une VM Kali : une connexion SSH vers le honeypot avec de mauvais identifiants. Cowrie enregistre la tentative, Filebeat la pousse dans ELK, et l'événement ressort dans Kibana avec l'IP source, l'horodatage, le login et le mot de passe essayés.

Documentation

Le projet est livré avec deux documents. Une politique de sécurité de l'information qui cadre le périmètre, les rôles, le contrôle d'accès, la conservation des logs (six mois minimum) et la gestion des incidents, en s'appuyant sur l'ISO 27001, le RGPD, NIS2 et les recommandations de l'ANSSI. Et un guide d'exploitation pour un analyste SOC : consultation des logs dans Kibana, traitement des alertes, réponse à incident, sauvegarde et rétention, maintenance des services.