Cartographier sa surface d'attaque

Prérequis : cours précédents (CIA, STRIDE).

Pourquoi

On ne défend que ce qu'on connaît. La cartographie transforme « à peu près sécurisé » en inventaire vérifiable — et révèle toujours 2-3 expositions oubliées.

Concepts

• Inventaire externe : domaines, sous-domaines (subfinder, crt.sh — les certificats listent les sous-domaines !), ports (nmap), headers (curl -I : versions qui bavardent), fichiers sensibles (/.git/HEAD, /backup.sql, /admin).
• Inventaire interne : comptes (actifs ? dormants ? partagés ?), tokens/clés (où, expiry ?), dépendances (versions, CVE connues), backups (chiffrés ? testés ?).
• Rythme : à chaque déploiement (diff auto : nouveau port ? nouvel endpoint ?) + revue trimestrielle. Automatisé quand possible (scan planifié + diff).

Exemple : la passe de 30 minutes

nmap -Pn -F serveur                 # ports : 22/80/443 et rien d'autre ?
curl -sI https://app.fr | grep -i "server\|x-powered"  # versions bavardes ?
curl -s https://app.fr/.git/HEAD    # 200 = catastrophe (sources exposées !)
# crt.sh → sous-domaines oubliés (staging, vieux tests…) : chacun = surface

Cas réel

staging.app.fr oublié, sans auth, base clonée de prod avec vrais emails : découvert par un chercheur (poli). Même exposition trouvée par un bot 3 mois plus tôt ? On ne saura jamais — d'où : staging = auth systématique + données anonymisées.

Pièges

• .git, .env, backups exposés : les classiques qui tuent — tester explicitement à chaque audit.
• Sous-domaines wildcard DNS (* → serveur) : chaque nom inventé résout → surface infinie. Wildcard avec parcimonie.
• Comptes dormants (ex-stagiaires) : accès valides oubliés. Revue trimestrielle, désactivation auto (90 j sans login ?).

À retenir

Externe (ports, sous-domaines, fichiers) + interne (comptes, tokens, déps) ; diff à chaque deploy ; staging = auth + fake data.