Infrastructure Réseau TAAF

Vue d’ensemble

Ce document définit l’architecture réseau de référence de la formation TAAF. L’infrastructure suit une montée en charge progressive (crescendo) : l’étudiant démarre des VMs nues acte après acte et y déploie lui-même les services (cf. Acte 0 — Setup Vagrant).

Déploiement

Les VMs sont fournies nues (Ubuntu + user taaf-user + git/docker/curl) par le Vagrantfile du dépôt server (dossier manual/). Les services se déploient ensuite depuis les dépôts de rôle (monitoring, etc.). Voir l’Acte 0.

---

Architecture 4 VMs

Toutes les VMs sont sur le même sous-réseau privé et communiquent par leurs adresses IP (notées IP_APPS, IP_VM1, IP_VM2, IP_VM3 ; relevez les vôtres avec hostname -I sur chaque VM).

Topologie des VMs

                        réseau privé commun
     +---------------+---------------+---------------+---------------+
     |               |               |               |               |
 TAAF-APPS-001  TAAF-MONITORING-001 TAAF-SOC-001  TAAF-AUDIT-001
    IP_APPS         IP_VM1           IP_VM2          IP_VM3
 SI observé +      Observabilité     SOC             Toolbox
 collecteurs       Grafana/Prom/Loki Grafana-natif   d'audit

VM bonus : un Windows Server (Active Directory) est ajouté uniquement pour le TP d’intégration Windows (Acte 2). Il n’est pas requis pour le tronc commun.

---

VM apps : TAAF-APPS-001 (le SI observé + collecteurs)

Rôle : le SI observé (PostgreSQL, NextCloud, Adminer) et ses collecteurs, déployés par docker-compose-apps.yml (dépôt monitoring). C’est aussi la source des logs à l’Acte 2 (SIEM) et la cible auditée à l’Acte 3.

Paramètre	Valeur
Machine Vagrant	apps
Hostname	taaf-apps-001
IP	IP_APPS
OS	Ubuntu 22.04
RAM	4 GB
CPU	2 vCPUs

Services hébergés :

• SI observé : PostgreSQL base_af (5432), NextCloud (8081), Adminer (8080)
• Collecteurs : Alloy (logs), cAdvisor (8082), node-exporter (9100), postgres-exporter (9187)
• Scénario : log-generator (profil scenario) — utilisé uniquement pour le module SIEM (Acte 2), pas pour l’Acte 1
• Falco : surveillance runtime (natif)

Accès :

vagrant ssh apps

http://IP_APPS:8081    # NextCloud (admin.cloud.af / AdminCloudAF2024!)
http://IP_APPS:8080    # Adminer
psql -h IP_APPS -U taaf_admin -d base_af   # PostgreSQL (base_af)

---

VM monitoring : TAAF-MONITORING-001 (plan de contrôle d’observabilité)

Rôle : la stack d’observabilité seule (Grafana, Prometheus, Loki, Alertmanager, Caddy), déployée par docker-compose.yml (dépôt monitoring).

Paramètre	Valeur
Machine Vagrant	monitoring
Hostname	taaf-monitoring-001
IP	IP_VM1
OS	Ubuntu 22.04
RAM	6 GB
CPU	2 vCPUs

Services hébergés :

• Observabilité : Grafana (3000), Prometheus (9090), Loki (3100), Alertmanager (9093)
• Caddy : reverse proxy (*.univ-taaf.internal, bonus)

Accès :

vagrant ssh monitoring

http://IP_VM1:3000     # Grafana   (admin / AdminTAAF2024!)
http://IP_VM1:9090     # Prometheus

Datasource Grafana → PostgreSQL (cross-VM)

Depuis le split, postgres-af vit sur la VM apps, pas avec Grafana : la datasource PostgreSQL pointe donc sur l’IP de la VM apps IP_APPS:5432 (jamais localhost, jamais un nom de service Docker — ils sont sur des VMs différentes). Prometheus/Loki/Alertmanager, eux, restent joignables par nom de service Docker puisqu’ils sont co-localisés avec Grafana sur monitoring. C’est l’objet du TP Grafana · données.

---

VM SOC : TAAF-SOC-001

Rôle : le SOC Grafana-natif — VM nue que l’étudiant monte à l’Acte 2.

Paramètre	Valeur
Machine Vagrant	soc
Hostname	taaf-soc-001
IP	IP_VM2
OS	Ubuntu 22.04
RAM	3 GB (Wazuh bonus : +4 GB)
CPU	2 vCPUs

Services à monter :

• Détection : Falco, Suricata, Zeek (capteurs), règles Sigma → LogQL
• Alerting : Grafana Alerting → Discord
• Bonus : Wazuh (Manager/Indexer/Dashboard) pour qui veut l’EDR-like

Accès :

vagrant ssh soc
http://IP_VM2:3000     # Grafana SOC

---

VM audit : TAAF-AUDIT-001

Rôle : toolbox d’audit / Purple Team (Acte 3).

Paramètre	Valeur
Machine Vagrant	audit
Hostname	taaf-audit-001
IP	IP_VM3
OS	Ubuntu 22.04
RAM	2 GB
CPU	2 vCPUs

Outils : nmap, lynis, OpenSCAP, nikto, syft, grype, hydra…

vagrant ssh audit
docker exec -it taaf-audit-toolbox bash

---

VM bonus : Active Directory (Windows)

Montée uniquement pour le TP d’intégration Windows (Acte 2).

Paramètre	Valeur
Hostname	TAAF-AD-001
IP	IP_AD
OS	Windows Server 2019/2022
Domaine	univ-taaf.internal

---

Configuration Réseau

Configuration /etc/hosts (optionnel)

Pour utiliser des noms plutôt que des IP, ajoutez sur les VMs Linux :

sudo bash -c 'cat >> /etc/hosts <<EOF
# Infrastructure TAAF
IP_APPS    taaf-apps-001        cloud.univ-taaf.internal
IP_VM1     taaf-monitoring-001  grafana.univ-taaf.internal prometheus.univ-taaf.internal
IP_VM2     taaf-soc-001          soc.univ-taaf.internal
IP_VM3   taaf-audit-001
IP_AD      taaf-ad-001          ad.univ-taaf.internal
EOF'

---

Flux de Communication

Observabilité (Acte 1) — deux VMs, saut inter-VM par IP

VM apps (IP_APPS)                    VM monitoring (IP_VM1)
─────────────────                    ─────────────────────
PostgreSQL (postgres-af:5432)
    ↓ metrics
postgres-exporter (9187) ───scrape (IP_APPS:9187)──►  Prometheus (9090)
cAdvisor (8082) ───────────scrape (IP_APPS:8082)──►        ↓ query
node-exporter (9100) ──────scrape (IP_APPS:9100)──►   Grafana (3000)

Logs (app, Falco, NextCloud)
    ↓ collect
Alloy ─────────────────────push (IP_MONITORING:3100)─►  Loki (3100)
                                                            ↓ query
                                                       Grafana (3000)

Le SI observé et ses collecteurs (exporters, Alloy) sont sur TAAF-APPS-001 ; le plan de contrôle (Prometheus, Loki, Grafana) est sur TAAF-MONITORING-001. Prometheus scrape les exporters d’apps par IP, et Alloy pousse vers Loki par IP : le saut inter-VM existe dès l’Acte 1.

Détection (Acte 2) — la VM SOC joint la VM monitoring

Sources (Loki sur monitoring, IP_VM1:3100)
    ↓ datasource Loki distante
SOC Grafana (IP_VM2:3000)  — règles Sigma→LogQL
    ↓ Grafana Alerting
Discord (webhook)

C’est ici que la connectivité inter-VM par IP est cruciale : la VM SOC doit joindre Loki de la VM monitoring (IP_VM1:3100) — jamais localhost.

Communication inter-VM

Source	Destination	Port	Usage
TAAF-SOC-001	TAAF-MONITORING-001	3100	Datasource Loki (Sigma→LogQL)
TAAF-SOC-001	TAAF-MONITORING-001	9090	Datasource Prometheus (corrélation)
TAAF-AUDIT-001	TAAF-MONITORING-001	22/80/5432…	Scans, nmap, audit
Administrateur	TAAF-MONITORING-001	3000	Accès Grafana
Administrateur	TAAF-SOC-001	3000	Accès Grafana SOC

---

Vérification de l’Infrastructure

#!/bin/bash
# test-infrastructure.sh — connectivité de base

echo "=== Test Infrastructure TAAF ==="

# VM monitoring
echo "[monitoring] TAAF-MONITORING-001..."
ping -c 2 IP_VM1 && echo "✅ accessible" || echo "❌ inaccessible"
curl -s -o /dev/null -w "%{http_code}" http://IP_VM1:3000 | grep -q "200\|302" && echo "✅ Grafana OK" || echo "❌ Grafana KO"
curl -s -o /dev/null -w "%{http_code}" http://IP_VM1:9090 | grep -q "200" && echo "✅ Prometheus OK" || echo "❌ Prometheus KO"
curl -s -o /dev/null -w "%{http_code}" http://IP_APPS:8081/status.php | grep -q "200" && echo "✅ NextCloud OK" || echo "❌ NextCloud KO"

# VM SOC (Acte 2)
echo "[soc] TAAF-SOC-001..."
ping -c 2 IP_VM2 && echo "✅ accessible" || echo "❌ inaccessible"

# VM audit (Acte 3)
echo "[audit] TAAF-AUDIT-001..."
ping -c 2 IP_VM3 && echo "✅ accessible" || echo "❌ inaccessible"

echo "=== Fin des tests ==="

---

Références

• Acte 0 — Setup Vagrant — démarrage des VMs nues
• Acte 0 — Installer les services — déploiement monitoring
• SIEM — Consignes — cahier des charges SOC
• Configuration Docker Compose

---

Document de référence — Formation TAAF · Kodetis