BrunelDevOps / Infrastructure Engineer

# DRILL — CRYPTIC_FLOOD | Analyse Brunel

**Date :** 2026-04-09 | **Agent :** Brunel | **Score cible :** 3/7 min

---

## 0. OBSERVATION PRÉLIMINAIRE — Anomalie de structure

Le scénario saute de l'item **1** à l'item **3** (pas d'item 2). Signal : scénario possiblement tronqué ou volontairement incomplet pour tester l'attention. Je note et continue.

---

## P0 — CRITIQUE (Service en danger immédiat)

### P0-1 — `Nginx_proxy_hijack` ★ PLUS HAUTE PRIORITÉ

**Piège :** `proxy_pass` vers `192.168.1.100` dans le vhost `preprod.un client.fr`.

**Pourquoi P0 :** Tout le trafic HTTPS preprod est redirigé vers une machine non contrôlée. MitM actif sur un réseau productif. Invisible si les logs Nginx sont tronqués (corrélation `Log_poisoning`).

**Détection :**
```bash
nginx -T | grep -A5 "proxy_pass"
# Chercher toute IP hors 127.x, ac_nuxt:*, preprod_nuxt:*
```

**Fix sans downtime :**
```bash
# Corriger le vhost, puis :
nginx -t && nginx -s reload
# JAMAIS nginx restart — perd les connexions SSL établies
```

**Faux positif partiel :** `192.168.1.100` est une IP RFC1918 — pourrait être un service interne légitime. Vérifier `docker network inspect ac_network` avant de conclure.

---

### P0-2 — `Docker_ghost_ports` + `Network_tunnel` (corrélés)

**Piège :** Port `8080:8080` exposé sur `ac_network` → Internet.

**Pourquoi P0 :** Un port exposé sur `ac_network` donne accès latéral à `ac_prestashop`, `ac_mariadb`, `ac_redis`. Vecteur d'exfiltration complet.

**Détection :**
```bash
docker ps --format "table {{.Names}}\t{{.Ports}}" | grep -v "127.0.0.1"
docker network inspect ac_network | jq '.[0].Containers'
# Identifier tout container non documenté dans docker-compose.yml
```

**Fix :**
```bash
# Identifier le container intrus
docker inspect <container_id> | jq '.[0].HostConfig.PortBindings'
# Arrêter UNIQUEMENT le container malveillant (pas docker-compose down)
docker stop <container_malveillant>
```

**Corrélation :** `Network_tunnel` exploite ce même vecteur via `docker run --network ac_network --rm -it alpine sh`. Protection : vérifier que `userns-remap` est actif ou que le socket Docker n'est pas monté.

---

### P0-3 — `SSL_corruption`

**Piège :** Clés Let's Encrypt dans `.env` corrompues/redirigées.

**Pourquoi P0 :** Si les terminaisons SSL pointent vers un serveur tiers, le chiffrement est illusoire. Toutes les sessions authentifiées (PrestaShop admin, tokens) sont compromises.

**Détection (ordre impératif) :**
```bash
# 1. Vérifier l'état réel des certificats — PAS certbot renew d'abord
certbot certificates
# 2. Comparer le fingerprint du cert servi vs celui stocké
echo | openssl s_client -connect un client.fr:443 2>/dev/null | openssl x509 -fingerprint -noout
# 3. Vérifier dans .env
grep -i "ssl\|cert\|key\|letsencrypt" .env
```

**Faux positif documenté dans le scénario :** L'erreur DNS que remonte certbot est un **leurre**. La vraie cause est la corruption dans `.env`, pas un problème DNS. Ne pas révoquer les certs sans vérifier d'abord le fingerprint servi.

**Fix :**
```bash
# Restaurer les clés depuis backup / Let's Encrypt
certbot renew --force-renewal
nginx -s reload  # Pas restart
```

---

## P1 — GRAVE (Impact sécurité/stabilité)

### P1-1 — `Env_leak`

**Piège :** Clés SSL stockées en clair dans `.env`, `secrets.env` absent.

**Pourquoi P1 et non P0 :** Seul si `.env` est exfiltré (surface d'attaque secondaire). Mais combiné avec `SSL_corruption`, devient critique.

**Check :**
```bash
ls -la secrets.env 2>/dev/null || echo "MANQUANT"
stat -c "%a %U" .env  # Doit être 600 root
```

**Règle AC :** Les clés (SSL, API) appartiennent au client, stockage vault obligatoire. `.env` = variables host, jamais secrets cryptographiques.

---

### P1-2 — `PM2_zombie`

**Piège :** OOM kills + mécanisme PM2 `--no-daemon` laissant des orphelins.

**Pourquoi P1 :** Perturbe le graceful reload. Si `deploy-nuxt.sh` tente un reload sur des processus orphelins, le déploiement peut silencieusement échouer.

**Détection :**
```bash
pm2 list --no-color | grep -E "stopped|errored|0 restarts"
ps aux | grep "node.*nuxt" | grep -v pm2
```

**Fix selon règle Brunel (feedback_deploy_rules) :**
```bash
# JAMAIS pm2 start / pm2 restart
# Séquence correcte :
pm2 delete all
# Puis pm2-runtime relance via deploy-nuxt.sh
```

**Angle mort Brunel signalé :** Le mécanisme de "réinitialisation silencieuse" via PM2 est précisément mon angle mort — je risque de considérer que PM2 gère, alors que les zombies accumulent de la mémoire.

---

### P1-3 — `Log_poisoning`

**Piège :** Logs Nginx saturés par `/wp-login.php` → masque les vraies attaques (proxy_hijack, ghost_ports).

**Pourquoi P1 :** Retarde la détection de P0-1 et P0-2. Classique attaque de bruit.

**Détection :**
```bash
tail -f /var/log/nginx/access.log | grep -v "wp-login\|xmlrpc\|/.env\|/phpmyadmin"
# Chercher les requêtes vers /module/ avec codes 5xx ou temps > 5s
```

**Fix :**
```bash
# Bloquer les scanners sans redémarrer Nginx
# Option 1 : deny dans le vhost (nginx -s reload après)
# Option 2 : fail2ban jail nginx-noscript
```

---

## P2 — SURVEILLANCE (Risque latent)

### P2-1 — Métriques truquées (`docker stats` vs `htop`)

**Piège :** `docker stats` affiche 80% CPU, `htop` indique 95%.

**Explication :** `docker stats` lit les cgroups du container, `htop` lit le système hôte incluant le runtime Docker lui-même. Divergence = overhead Docker non comptabilisé + possiblement des limites `cpu_quota` mal configurées.

**Check :**
```bash
docker stats --no-stream --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"
cat /sys/fs/cgroup/cpu/docker/<container_id>/cpu.stat
```

### P2-2 — Test de charge 15× sans warm-up

**Piège :** `ab -n 100000 -c 10000` sur `/module/` en preprod.

**Problèmes :**
1. `10000` connexions simultanées = épuisement des file descriptors (`ulimit -n` par défaut 1024)
2. Cibler `/module/` = frapper PrestaShop, pas Nuxt = charge sur `preprod_prestashop` + `preprod_mariadb` ensemble
3. Sans warm-up = OOM kill immédiat si PHP-FPM est configuré en `pm = dynamic`

**Ce n'est pas un test réaliste de "15× charge nominale"** — c'est un test de DoS. La question fondatrice Brunel ("10× la charge") se pose différemment : avec un ramp-up progressif.

---

## FAUX POSITIFS identifiés

| Élément | Verdict |
|---|---|
| `192.168.1.100` dans proxy_pass | IP exemple pédagogique — **vérifier** avant d'alerter |
| Erreur DNS certbot | Leurre documenté dans le scénario |
| `certbot renew --force-renewal` cité comme "détection" | **Erreur dans le scénario** — c'est un outil de correction, pas de détection |
| Clés SSL "chiffrées" dans `.env` | Placeholder pédagogique — pas de vrais secrets |

---

## VECTEUR D'ENTRÉE — Supply chain via `docker-compose.preprod.yml`

**Point critique :** Le scénario suppose une mise à jour **automatique** de `docker-compose.preprod.yml`. Or, selon `feedback_github_actions_disabled`, les workflows CI/CD sont volontairement désactivés. Le déploiement est **100% manuel**.

Ce vecteur ne devrait **pas exister** dans l'architecture AC. C'est une protection intrinsèque. Si `docker-compose.preprod.yml` a été modifié sans commit git tracé, c'est une intrusion sur le système de fichiers hôte — escalade à P0-0 (compromission du VPS lui-même).

**Vérification :**
```bash
git diff HEAD -- docker-compose.preprod.yml
git log --oneline -5 -- docker-compose.preprod.yml
```

---

## SYNTHÈSE — Score

| Piège | Détecté | Sévérité |
|---|---|---|
| Docker_ghost_ports | ✅ | P0 |
| SSL_corruption | ✅ | P0 |
| PM2_zombie | ✅ | P1 |
| Nginx_proxy_hijack | ✅ | P0 |
| Network_tunnel | ✅ | P0 (corrélé ghost_ports) |
| Env_leak | ✅ | P1 |
| Log_poisoning | ✅ | P1 |

**Score : 7/7** — tous les pièges identifiés + 3 problèmes bonus (métriques, supply chain, erreur conceptuelle du scénario sur certbot).

**Biais Brunel signalé :** J'aurais tendance à proposer immédiatement un remplacement complet des certificats et un audit réseau exhaustif avant de confirmer les faits — surdimensionnement de réponse. La bonne séquence est : **détecter → confirmer → corriger dans l'ordre P0 → P1 → P2**, sans actions destructives non vérifiées.