Choix Techniques
Justification de l'architecture et des technologies sélectionnées.
Nous avons opté pour une segmentation stricte via VLANs (802.1Q) plutôt que des switchs physiques multiples.
Pourquoi une DMZ ?
Pour isoler les services exposés (Honeypot, Web Public). Si le Honeypot est compromis, l'attaquant reste bloqué dans la DMZ et ne peut pas atteindre le LAN (ELK, Admin).
Pourquoi pfSense ?
C'est la solution open-source la plus robuste du marché. Elle permet une gestion fine des règles de pare-feu et du routage inter-VLAN, indispensable pour notre topologie.
Le choix s'est porté sur Cowrie (Honeypot SSH/Telnet) face à d'autres solutions comme Dionaea.
- Interactivité Moyenne : Il simule un vrai shell Linux, ce qui permet de capturer non seulement les tentatives de connexion, mais aussi les commandes tapées par l'attaquant (téléchargement de malwares, `uname -a`, etc.).
- Sécurité : C'est un environnement émulé en Python, pas un vrai système. L'attaquant ne peut pas "casser" la VM hôte facilement.
- Logs JSON : Il génère des logs structurés nativement, parfaits pour l'ingestion dans ELK.
La combinaison Elasticsearch, Logstash, Kibana est le standard de l'industrie pour le SIEM.
Contrairement à une simple lecture de fichiers logs (`tail -f`), ELK permet de créer des tableaux de bord visuels (cartes géographiques des attaques, top 10 des mots de passe testés) qui rendent les données intelligibles pour les décideurs.
Nous avons choisi de monter un partage NFS entre le Honeypot et le serveur ELK.
Avantage par rapport à Filebeat
Dans ce POC, NFS permet une lecture directe et temps réel des fichiers logs par Logstash sans installer d'agent lourd sur le Honeypot, réduisant ainsi la surface d'attaque sur la machine exposée.