SOC - Infrastructure et Attaques

L’infrastructure

Proxmox

Toute l’infrastructure a été réalisée sur un Proxmox. Ce choix est détaillé dans mon projet…

pfSense

Le pfSense est l’élément central de l’infrastructure. Il dispose de 2 cartes réseau : une carte reliée au Proxmox côté WAN, et une carte réseau virtuelle côté LAN. Cette dernière permet de segmenter le réseau en 5 VLANs :

• VLAN 10 — Serveur Active Directory
• VLAN 20 — Machine cliente Windows 11
• VLAN 30 — Serveur web (DVWA)
• VLAN 40 — SIEM (Wazuh)
• VLAN 50 — Machine attaquante (Kali Linux)

Il n’y a pas de règles particulières sur le pare-feu : sur tous les VLANs, tout est en “pass”, c’est-à-dire que chaque VLAN peut communiquer avec n’importe quel autre. Ce choix a été fait par manque de temps, pour se concentrer principalement sur la gestion des machines. Une meilleure approche aurait été de configurer le pare-feu selon les recommandations de l’ANSSI pour Fortinet, consultables ici :

Le pfSense est configuré avec Syslog-ng pour envoyer ses logs Suricata directement vers Wazuh, à la fois les logs Suricata et les logs pfSense au niveau matériel.

Suricata

Suricata est l’autre élément clé installé sur le pare-feu. Il écoute sur 2 VLANs : le VLAN 30 (serveur web vulnérable) et le VLAN 50 (machine attaquante simulant Internet).

Au fil du projet, différentes règles ont été mises en place : des règles natives à Suricata, ainsi que des règles personnalisées selon les scénarios d’attaque.

Wazuh

Le SIEM Wazuh est installé sur une machine Debian 12, déployé via Docker en mode “single node”. Ce choix a été fait pour la simplicité du déploiement, même si l’administration est un peu plus difficile, il faut bien ouvrir les différents flux réseau depuis le conteneur. Un agent Wazuh a également été déployé sur chaque machine à surveiller, ce qui permet une remontée directe sur le SIEM sans passer par une configuration rsyslog.

AD & Windows 11

L’infrastructure comprend un serveur Active Directory Windows et une machine Windows 11 qui y est rattachée. Cela permet de simuler un environnement proche de la réalité en entreprise : Active Directory est utilisé par environ 90 % des entreprises dans le monde.

Web DVWA

La machine web “Damn Vulnerable Web App” (DVWA) est installée via le dépôt GitHub officiel. Comme son nom l’indique, c’est une application volontairement vulnérable, conçue pour s’entraîner sur les différentes méthodes d’attaques web. Elle joue ici le rôle de machine cible, et simule un site web public accessible avec authentification dans un environnement d’entreprise.

Kali Linux

La machine Kali Linux est la machine attaquante. Elle simule un attaquant depuis le réseau Internet (VLAN 50).

Les différentes attaques et leurs détections

Dans cette partie, nous allons voir 6 scénarios d’attaques sur notre réseau. Pour chacun, on procède à une simulation puis on vérifie que l’alerte a bien été générée et remontée sur le SIEM.

Attaque réseau depuis une IP malveillante

Le but de cette attaque est de simuler une connexion depuis une IP répertoriée comme malveillante dans la base de données de Suricata.

Depuis Kali Linux, on envoie un ping en usurpant une IP malveillante avec hping3. Le pfSense déclenche alors une alerte : "ET COMPROMISED Known Compromised or Hostile Host Traffic group 1".

Ce log est ensuite envoyé via Syslog-ng au Wazuh. Il arrive d’abord dans un fichier archive.log ou archive.json. Pour le faire remonter sur le dashboard, il faut créer un décodeur, puis une règle qui correspond au log reçu depuis Suricata/pfSense.

Le décodeur est simple : il vérifie que le nom du programme est suricata et décode le log en JSON.

La règle dit que si le log correspond à "ET COMPROMISED Known Compromised or Hostile Host Traffic group", alors on lui attribue la description "Suricata (pfSense): Hôte hostile ou compromis détecté" et elle remonte sur le dashboard.

La règle contient deux éléments importants : l’ID, utilisé pour l’active response (détaillé plus bas), et le level, ici à 12, ce qui déclenche l’envoi d’une alerte par e-mail.

Sur le Discover, on peut voir la remontée du log avec rule.description : "Suricata (pfSense): Hôte hostile ou compromis détecté" :

Accès depuis la Chine ou la Corée du Nord

Pour cette partie, j’ai créé un compte Maxmind pour récupérer une licence GeoLite2 et la configurer sur Suricata. La base de données GeoLite2 est ensuite téléchargée et installée sur le pfSense.

Deux règles personnalisées ont été créées pour le VLAN 50 :

alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"ALERTE - Trafic suspect depuis la Coree du Nord"; geoip:src,KP; classtype:bad-unknown; sid:1000001; rev:1;)

alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"ALERTE - Trafic suspect depuis la Chine"; geoip:src,CN; classtype:bad-unknown; sid:1000002; rev:1;)

Ces règles sont simples : elles déclenchent une alerte sur tout trafic IP venant de $EXTERNAL_NET vers $HOME_NET si l’IP source correspond au code ISO de la Chine (CN) ou de la Corée du Nord (KP) dans la base GeoLite2.

• classtype:bad-unknown : trafic potentiellement malveillant mais inconnu
• sid:1000002 : identifiant de la règle Suricata
• rev:1 : première version de cette règle

L’attaque consiste à envoyer un seul paquet ping en usurpant une IP chinoise :

hping3 -1 -c 1 --spoof 223.5.5.5 10.10.30.11

• -1 : mode ICMP (ping)
• -c 1 : envoyer une seule requête
• --spoof : usurper une IP source (ici une IP chinoise)

Suite à ça, une alerte apparaît sur pfSense :

Le log arrive sur Wazuh, décodé par le même décodeur que précédemment, et matché par cette règle :

Et la remontée sur le Discover :

Pour l’IP coréenne, le principe est identique.

Attaque réseau — Transfert de malware

Le but de cette attaque est de détecter un logiciel malveillant téléchargé sur une machine cliente et de faire remonter l’alerte sur le SIEM.

Pour cela, on utilise l’API VirusTotal. Dans Wazuh, via Server Management → Settings → Edit configuration, on ajoute l’intégration VirusTotal avec la clé API :

Sur la machine Windows 11, on modifie la configuration de l’agent Wazuh pour qu’il surveille le répertoire des téléchargements :

Après avoir désactivé la protection en temps réel de l’antivirus Windows, on télécharge un fichier malveillant de test (Eicar) :

Sur Wazuh, on voit que l’utilisateur a téléchargé un fichier et une alerte "VirusTotal: Alert" est générée :

En cliquant sur le permalink, on est redirigé vers VirusTotal pour voir le statut du fichier :

Attaque réseau — Scan réseau (Nmap)

Cette attaque permet de détecter un scan réseau de type Nmap.

En lançant un Nmap depuis la machine attaquante vers une cible, pfSense déclenche une alerte Nmap :

Ce log est envoyé à Wazuh, qui utilise le même décodeur et fait correspondre cette règle :

Et sur le Discover :

La machine cible (DVWA) remonte aussi une alerte via l’agent :

rule.description : DVWA (web): Scan Nmap détecté

Cela permet de créer une règle de corrélation entre les deux alertes :

La règle de corrélation se déclenche si elle correspond au groupe custom_group créé en amont, et remonte sur le Discover :

Attaque DoS

Cette attaque permet de détecter une tentative de déni de service. La détection repose ici sur Suricata côté pfSense, ce qui n’est pas optimal, l’idéal serait d’avoir un outil de détection plus en amont.

Deux outils sont utilisés pour simuler l’attaque :

# Apache Benchmark — test de charge
ab -n 30000 -c 50 http://cible/
# -n 30000 : envoie 30 000 requêtes au total
# -c 50    : 50 requêtes en parallèle en permanence

# Slowhttptest — attaque Slowloris
slowhttptest -c 5000 -H -i 10 -r 200 -x 24 -u http://cible/
# -c 5000 : tente d'ouvrir 5000 connexions simultanées
# -H      : mode Slowloris (en-têtes HTTP partiels)
# -i 10   : attend 10 secondes entre chaque envoi de données
# -r 200  : ouvre 200 connexions par seconde
# -x 24   : envoie des chaînes aléatoires de 24 octets max

La première commande génère les alertes souhaitées. La seconde fait vraiment tomber le serveur.

Une règle personnalisée a été créée sur le VLAN 50 dans Suricata :

alert http any any -> $HOME_NET 80 (msg:"SURICATA - SYN flood/Attaque DOS"; flow:established,to_server; http.method; content:"GET"; http.user_agent; content:!"Nmap"; detection_filter:track by_src, count 100, seconds 5; sid:1000008; rev:1;)

Voici ce que fait cette règle :

• Elle surveille le trafic HTTP de n’importe quelle source vers $HOME_NET sur le port 80.
• flow:established,to_server : la connexion TCP doit être établie et le trafic doit aller du client vers le serveur.
• Elle filtre les requêtes GET dont le User-Agent ne contient pas “Nmap” (pour éviter les faux positifs avec le scan réseau).
• detection_filter:track by_src, count 100, seconds 5 : l’alerte se déclenche si une même IP envoie 100 requêtes GET ou plus en 5 secondes, comportement typique d’un GET flood.
• sid:1000008 : identifiant de la règle, rev:1 : première version.

En lançant la première commande, une alerte apparaît sur l’onglet Suricata de pfSense :

Elle remonte sur le Discover Wazuh :

L’agent installé sur DVWA remonte aussi des logs :

Ce qui permet de créer une règle de corrélation :

Et la remontée sur le Discover :

Solutions post-détection

Alertes par e-mail

Wazuh n’envoie pas d’e-mails directement, il a besoin d’un serveur SMTP. Pour cela, j’ai créé un compte Gmail dédié qui sert de relais, avec un mot de passe d’application pour lier Wazuh à Gmail :

Sur la machine hôte du Docker Wazuh, j’installe Postfix, un serveur de messagerie qui fait office de bridge entre Wazuh et Gmail.

Une fois configuré, on retourne sur Wazuh pour activer l’envoi par e-mail via Server Management → Settings → Edit configuration :

Les logs sont envoyés vers le serveur SMTP local, qui les relaie vers Gmail, qui les transmet à mon adresse. Le paramètre email_alert_level est réglé à 12 : un e-mail est envoyé dès qu’une règle avec un level ≥ 12 est déclenchée (voir les règles créées lors des attaques).

Active Response

L’active response permet de bloquer automatiquement une IP après une alerte. La configuration se fait dans Server Management → Settings → Edit configuration :

Le paramètre clé est rules_id : il liste les IDs des règles pour lesquelles l’active response doit s’activer (voir les règles créées lors des attaques).

On ajoute ensuite le script à exécuter :

Le script Python bloque l’IP directement sur pfSense via son API. Exemple de résultat dans Firewall → Aliases → IP :

La règle de blocage est créée au préalable avec une IP de base (ici 127.0.0.8) pour pouvoir être activée. Elle est ensuite configurée pour s’appliquer sur toutes les interfaces :

Cela permet de bloquer l’IP sur l’ensemble des VLANs (interfaces : Any).

Les améliorations possibles

Ce projet reste dans un cadre scolaire et personnel. Il est encore loin de ce qu’on peut voir sur le terrain.

En priorité, le pare-feu devrait être configuré selon les standards de l’ANSSI. Les règles actuelles sont volontairement permissives pour faciliter la gestion des machines, ce qui n’est pas acceptable en production.

Les scénarios d’attaque couverts sont ceux attendus dans le cadre du cours. Pour aller plus loin, on pourrait s’appuyer sur la matrice MITRE ATT&CK pour explorer d’autres vecteurs d’attaque et renforcer la couverture de détection.

La partie visualisation mériterait aussi d’être améliorée : toutes les analyses ont été faites directement dans le Discover. Des dashboards clairs et structurés rendraient l’analyse des alertes beaucoup plus efficace.

Enfin, un meilleur parsing des logs permettrait d’en extraire plus d’informations utiles : IP sources, reverse DNS, contexte géographique, etc.

Ce que ce projet m’a apporté

Ce projet m’a beaucoup appris sur plusieurs points.

C’est mon premier projet sur mon propre serveur Proxmox. Je suis habitué à cet outil au travail, mais ici le contexte était différent : je prenais mes propres décisions et j’administrais le serveur comme je le voulais, sans contrainte imposée.

J’ai appris à mettre en place et à utiliser plusieurs outils : pfSense, Suricata et Wazuh, en partant de zéro. Il y a eu des problèmes d’administration, ce qui est normal, mais c’est cette partie-là que j’apprécie le plus : la résolution de problèmes concrets.

Au-delà de l’administration pure, j’ai compris le fonctionnement d’un SIEM. Wazuh n’est pas évident à prendre en main, la documentation est riche mais pas toujours claire. C’est un outil vraiment complet pour de l’open source, et je me suis vraiment amusé à créer des règles, gérer des alertes et simuler des attaques.