Modèle de menace et couverture Fortress

Comment les attaques web atteignent votre site, ce que Fortress bloque à chaque couche, et ce qu'il vous reste à gérer en dehors de Fortress.

Fortress est un système de défense en profondeur : cinq couches indépendantes, chacune interceptant ce que la précédente a laissé passer. Un seul interrupteur Fortress active les cinq pour le conteneur sélectionné.

Comment les attaquants atteignent un site web PHP

Les attaques réelles exploitent rarement une seule vulnérabilité. La chaîne ressemble généralement à ceci :

1. Reconnaissance — un bot scanne votre site à la recherche de plugins connus, de fichiers .env exposés, de pages de connexion, d'URL courantes.
2. Point d'entrée — exploite l'un des éléments suivants : plugin/thème vulnérable, mot de passe admin faible, formulaire d'envoi de fichiers, cœur de CMS non patché, API exposée.
3. Prise de pied — téléverse un webshell ou un fichier PHP de porte dérobée dans wp-content/uploads/, images/, ou tout autre emplacement accessible en écriture.
4. Élévation de privilèges — exécute des commandes en tant que www-data pour lire la base de données, extraire des identifiants, installer un rootkit.
5. Persistance — modifie le code du CMS pour implanter une porte dérobée de long terme qui survit aux mises à jour de plugins.
6. Exfiltration — envoie les données volées (dump de la base, informations clients, code source) vers un serveur distant.
7. Monétisation — revend les données, plante du spam, redirige le trafic, mine de la cryptomonnaie, rançonne le site.

Fortress brise cette chaîne à chaque étape.

Les 5 couches de Fortress

Couche 1 — WAF (filtre HTTP nginx)

Filtre les requêtes HTTP malveillantes avant qu'elles n'atteignent PHP. Chaque règle peut être activée ou désactivée individuellement dans Fortress → WAF :

Couche 2 — Durcissement PHP (disable_functions + open_basedir)

Si un attaquant parvient à exécuter du code PHP (via un plugin vulnérable ou une RCE), les fonctions dangereuses sont neutralisées. Configurable dans Fortress → PHP → Fonctions bloquées :

• Exécution de code — exec, shell_exec, system, passthru, proc_open, popen, pcntl_exec
• Webshells classiques — eval, assert (mode Strict)
• Exfiltration réseau — fsockopen, stream_socket_client, socket_*
• Introspection système — phpinfo, posix_uname, dl(), putenv
• open_basedir — PHP est confiné au docroot + chemins explicites (ne peut pas lire /etc/, /home/other-clients/, les journaux système)

La liste est consciente du CMS : WordPress, Joomla, PrestaShop, Drupal et Laravel ont chacun leurs fonctions requises auto-autorisées, afin que le site continue de fonctionner.

Couche 3 — Durcissement des binaires (chmod 700)

Si l'attaquant contourne disable_functions (bug PHP rare, extension FFI), il ne peut toujours pas exécuter de binaires externes. Appliqué automatiquement lorsque Fortress est activé :

• Dump de base de données — mysqldump, pg_dump, pg_dumpall, mysql, psql
• Interpréteurs alternatifs — php (CLI), python3, perl, ruby, node
• Transfert réseau direct — ssh, scp, sftp, ftp
• Le mode Strict ajoute — curl, wget, nc, socat, tar, gzip, base64

Ces binaires sont en chmod 700 et chown root:root — invisibles pour www-data même avec un accès shell.

Couche 4 — Pare-feu de sortie (iptables sortant)

Restreint ce à quoi le conteneur peut se connecter sur Internet :

• Standard — autorise les CDN connus, le DNS, le NTP, le SMTP. Bloque les connexions sortantes brutes vers des IP aléatoires.
• Strict — liste blanche d'IP explicites uniquement. L'attaquant ne peut pas exfiltrer les données volées vers evil.com, même avec curl.

Couche 5 — Shield (système de fichiers en lecture seule)

Le docroot est monté en lecture seule au niveau du noyau. Seuls certains dossiers restent accessibles en écriture (wp-content/uploads, répertoires de cache, sessions). Même avec une RCE complète, l'attaquant :

• Ne peut pas modifier les fichiers du cœur du CMS
• Ne peut pas implanter une porte dérobée persistante dans les fichiers de plugins/thèmes
• Ne peut pas modifier wp-config.php pour voler de futurs identifiants
• Ne peut écrire que dans les dossiers de téléversement, où nginx est configuré pour ne pas exécuter de PHP

Scénarios d'attaque concrets

Scénario A : Plugin WordPress vulnérable (LFI)

1. Attaquant : GET /wp-content/plugins/buggy/file.php?page=../../etc/passwd
2. Le WAF bloque le motif ../ → 403
3. Si le WAF est contourné (%2e%2e/ encodé en URL) : open_basedir empêche PHP de lire /etc/

Scénario B : Téléversement de webshell via un formulaire de contact

1. L'attaquant téléverse evil.php déguisé en evil.jpg
2. Le WAF upload_php détecte l'extension PHP dans /wp-content/uploads/ → 403
3. Si le fichier passe : le scanner de téléversement exécute YARA + entropie → fichier mis en quarantaine
4. Si la quarantaine le manque : Shield garde wp-content/uploads accessible en écriture mais nginx refuse d'exécuter du PHP depuis cet emplacement

Scénario C : Injection SQL tentant de dumper la base

1. Attaquant : ?id=1 UNION SELECT user_pass FROM wp_users
2. Le WAF sqli bloque → 403
3. Si contourné : le PHP vulnérable ne renvoie que les résultats de la requête — fuite limitée, pas de dump complet
4. L'attaquant essaie system("mysqldump -uroot --all-databases") : disable_functions l'en empêche
5. L'attaquant contourne via FFI : mysqldump en chmod 700 → Permission refusée

Scénario D : Porte dérobée persistante après une RCE

1. L'attaquant dispose d'une RCE ponctuelle et veut écrire backdoor.php pour un accès ultérieur
2. Shield en lecture seule → fwrite() échoue sur tous les chemins du CMS
3. Le seul emplacement accessible en écriture est wp-content/uploads, où nginx renvoie un 404 pour tout .php

Scénario E : Force brute sur l'administration

1. Attaquant : 10 000 tentatives de connexion sur /wp-login.php
2. Le WAF rate_limit → 5 req/min par IP, renvoie un 429 sur les 9 995 autres
3. Imunify360 (si installé) bannit l'IP après des 429 répétés
4. Des identifiants valides restent un risque → la 2FA au niveau de WordPress est indispensable (hors périmètre de Fortress)

Ce que Fortress ne couvre PAS

Certains vecteurs d'attaque sont en dehors de toute couche de durcissement web — ils nécessitent des outils dédiés ou de la discipline humaine :

Couches recommandées par CMS

L'assistant Fortress présélectionne des valeurs par défaut sensées par CMS, mais voici la logique :

• WordPress — Fortress + Wordfence (2FA + Login Security) + mise à jour automatique de WP Toolkit + Imunify360 en hébergement mutualisé
• Joomla — Fortress + Akeeba Admin Tools (équivalent de Wordfence) + 2FA sur /administrator/
• PrestaShop — Fortress + liste blanche d'IP sur /adminXXX/ + mode Strict désactivé (le back-office a besoin de proc_open pour les factures PDF)
• Drupal — Fortress Strict + module Security Kit + mises à jour uniquement via Composer (ne jamais modifier le cœur)
• Laravel — Fortress Strict + APP_DEBUG=false en production + Telescope pour la détection d'anomalies + ne jamais exposer php artisan via HTTP

Comment valider votre protection

Le simulateur Fortress (Fortress → Simulateur → Lancer l'analyse) exécute ~17 attaques réalistes contre les 5 couches et indique lesquelles sont bloquées. Lancez-le :

• Après avoir activé Fortress pour la première fois
• Après une mise à niveau du CMS ou de plugins majeurs
• Après un changement de niveau de sécurité (Standard ↔ Strict)
• Mensuellement, en contrôle de routine

Un message vert « X/X tests réussis — défense en profondeur OK » signifie que toutes les couches sont opérationnelles. Tout résultat rouge pointe vers une couche spécifique à ajuster.

Synthèse de la couverture

Fortress couvre environ 80 % des attaques applicatives réelles — l'intégralité de l'OWASP Top 10 (Injection, défaut d'authentification indirectement via le rate-limit, exposition de données sensibles via les en-têtes, XXE, contrôle d'accès défaillant via le WAF, mauvaise configuration de sécurité via le durcissement, XSS, désérialisation non sécurisée, atténuation des vulnérabilités connues, journalisation insuffisante via les en-têtes).

Les 20 % restants — vol d'identifiants, 0-days, ingénierie sociale, DDoS volumétrique — doivent être traités par des outils complémentaires : 2FA, patching automatisé, protection DDoS en amont et sensibilisation humaine.

Fortress est nécessaire mais pas suffisant. Combinez-le avec les recommandations ci-dessus pour atteindre un niveau de sécurité de production.