🛡️ Architecture de défense multicouche
La « protection contre les attaques » n'est pas un module unique de trois couches : c'est la combinaison de tous les modules de défense qui travaillent ensemble en couches successives. Chaque couche couvre les failles de la précédente. Aucune ne protège seule ; ensemble, elles forment une véritable défense en profondeur.
| Couche | Ce qu'elle bloque | Documentation |
|---|---|---|
| 1. Early Shield (PRO) | Méthodes HTTP inhabituelles, octets nuls, URL trop longues, motifs d'exploit (path traversal) et accès à des fichiers sensibles — avant même le chargement de WordPress | Early Shield |
| 2. Firewall WAF | Fuzzing, pollution de paramètres, injection de redirections, signatures WAF (3 modes) | Firewall · Modes |
| 3. Anti-Bot (6 couches) | Bots automatisés, scrapers, navigateurs headless, faux crawlers, IP falsifiée | Anti-Bot |
| 4. Anti-Injection | SQLi, XSS, LFI/RFI, Injection de commandes, Désérialisation, XXE, LDAP, SSRF, Open Redirect dans les URLs, formulaires, cookies et en-têtes | Bouclier Anti-Injection |
| 5. Sanitisation des Redirections | Fuite de jetons, clés API et données sensibles dans les URLs de redirection | Sanitisation |
| 6. Referer Context | CSRF basique, POST critiques sans origine légitime, bots sans Referer | RCP |
| 7. Rate Limiting | Force brute, scraping intensif, requêtes excessives par IP | Rate Limiting |
| 8. Géo-blocage | Trafic des pays à haut risque et flux automatisés géolocalisés | Géo-blocage |
| 9. Protection des Téléversements | Shells PHP, exécutables, MIME falsifiés, double extension, octet nul | Uploads |
| 10. En-têtes de sécurité | XSS réfléchi, clickjacking, MIME sniffing, MITM, CSP, SRI | Headers |
| 11. Résilience DDoS | Saturation de requêtes et mode d'urgence au niveau applicatif | Résilience DDoS |
| 12. Hardening | Énumération d'utilisateurs, listage de répertoires, exposition de fichiers, API | Durcissement |
| 13. Réseau de protection | IP confirmées par plusieurs sites (flux collaboratif, PRO uniquement) | Réseau · Threat Intel |
| 14. Login Security + 2FA | Force brute de connexion, CAPTCHA, comptes restreints, second facteur | Login · 2FA |
| 15. Scanner + Sauvegardes | Malware, vulnérabilités, intégrité des fichiers et restauration d'urgence | Scanner · Backups |
🔀 Sanitisation des URLs de Redirection
Nettoie automatiquement les paramètres des URLs de redirection pour supprimer les données sensibles comme les emails, les clés API, les jetons d'authentification, les mots de passe et autres informations confidentielles avant que l'utilisateur ne soit redirigé.
🎯 Ce qu'il protège
- Divulgation d'informations : Empêche les données sensibles d'apparaître dans les URLs, journaux, en-têtes Referer ou l'historique du navigateur.
- Fuite de jetons : Supprime les clés API, les jetons d'authentification et les secrets avant la redirection.
- Collecte d'e-mails : Supprime les adresses e-mail exposées dans les paramètres d'URL.
🧹 Données supprimées
🛡️ Bouclier Anti-Injection (SQL/XSS/LFI/Commandes/XXE/SSRF)
Détecte et bloque les tentatives d'injection dans les URLs, formulaires, cookies et en-têtes HTTP. Agit comme un filet de sécurité qui arrête les attaques même si un plugin ou un thème présente des vulnérabilités. Couvre 9 classes d'attaques : SQL Injection, XSS, LFI/RFI, Injection de commandes, Désérialisation PHP, XXE, Injection LDAP, SSRF et Open Redirect.
Attack types it blocksTypes d'attaques qu'il bloque
SQL Injection
Tente de lire, modifier ou supprimer des données de la base de données (utilisateurs, articles, configuration) à l'aide de caractères spéciaux comme ', -- ou UNION dans les paramètres.
XSS
Injecte des scripts malveillants dans les pages pour voler des sessions, des cookies ou rediriger les utilisateurs. Détecte les balises <script>, les événements onerror, onload et les schémas javascript:.
LFI / RFI
Tente de charger des fichiers locaux (/etc/passwd) ou distants pour exécuter du code malveillant. Détecte les motifs comme ../, file://, php://filter et les chemins système absolus.
Command Injection
Tente d'exécuter des commandes sur le système d'exploitation du serveur lui-même (pas la base de données) via un paramètre, en combinant des caractères spéciaux (guillemets obliques, points-virgules, &&, tubes |) avec une commande connue. Exemple : ?id=1; cat /etc/passwd ou ?file=photo.jpg`whoami`.
Deserialización PHP
Envoie un objet PHP "sérialisé" fabriqué à la main dans un paramètre, pour tenter de manipuler la logique interne du site lors de sa reconstruction (peut parfois mener à l'exécution de code). Reconnaissable à un format très caractéristique comme O:8:"stdClass":1:{...}.
XXE
Envoie un document XML avec une "entité externe" qui tente de faire lire au serveur des fichiers internes (comme /etc/passwd) ou de contacter un autre serveur. Reconnaissable à un <!DOCTYPE> avec une <!ENTITY> pointant vers file:// ou un autre schéma. Exemple : <!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>.
LDAP Injection
Manipule un filtre de recherche LDAP (utilisé par les systèmes d'authentification d'entreprise) en ajoutant des parenthèses et des opérateurs pour contourner la validation ou extraire des données de l'annuaire. Exemple : *)(uid=*))(|(uid=*.
SSRF
Tente de faire faire au SERVEUR LUI-MÊME une requête sortante vers une destination interne ou interdite (localhost, le réseau interne, ou le endpoint de métadonnées du cloud), généralement en passant une URL comme valeur de paramètre. Exemple : ?url=http://169.254.169.254/latest/meta-data/ ou ?image=http://127.0.0.1:6379/.
Open Redirect
Manipule un paramètre de redirection (comme ?redirect_to=) pour que, après une action légitime (par ex. la connexion), l'utilisateur se retrouve sur un site externe contrôlé par l'attaquant — utilisé surtout dans les campagnes de phishing. Exemple : ?redirect_to=https://site-malveillant.com ou ?next=//evil.com.
🔍 Où il agit
Inspecte le trafic à trois points clés :
- URLs et paramètres GET/POST : Recherches, formulaires, filtres, pages.
- Cookies : Surtout les sessions manipulées avec des charges utiles malveillantes.
- En-têtes HTTP : User-Agent, Referer et autres avec des charges utiles d'injection.
⚙️ Options de configuration
Action
Off : détecte et journalise comme Monitor, mais ne bloque jamais (c'est l'interrupteur "Activé" ci-dessus qui allume ou éteint la détection elle-même).
Challenge : bloque avec 403 + enregistre l'IP pendant 2h.
Block : bloque avec 403 + enregistre l'IP pendant 2h.
Bloquer uniquement la requête : renvoie un 403 ponctuel mais N'enregistre PAS l'IP dans les "IP bloquées" — utile pour tester la protection ou pour du trafic légitime derrière un NAT/proxy partagé.
Monitor : enregistre seulement, ne bloque pas.
Sensibilité
Basse : Schémas très clairs seulement. Faux positifs minimes.
Moyenne (recommandée) : Équilibre entre détection et faux positifs.
Haute : Détection maximale. Peut générer des faux positifs.
Listes blanches
Chemins : URLs non inspectées (ex : /wp-json/, /admin-ajax.php).
Paramètres : Noms de paramètres à ignorer (ex : s, paged, rest_route).
Protection du Contexte Referer (RCP)
Valide l'origine des requêtes HTTP à l'aide de l'en-tête Referer. Si une requête POST critique (connexion, soumission de formulaire) n'a pas de Referer ou provient d'un domaine externe non autorisé, elle est bloquée. C'est une couche légère et rapide qui agit avant que la requête n'atteigne PHP.
✅ Avantages
- 🚀 Léger et rapide : valide uniquement les en-têtes HTTP, impact nul sur les performances
- 🤖 Arrête les bots automatisés qui envoient rarement un Referer valide
- 🛡️ Détecte les CSRF basiques : requêtes cross-site sans Referer légitime
- 🔒 Protège wp-admin contre l'accès direct depuis des domaines externes
⚠️ Considérations
- 🔍 Faux positifs : les navigateurs/extensions peuvent bloquer le Referer pour des raisons de confidentialité
- 🔌 Les API/webhooks doivent être ajoutés aux exceptions (ex : /api/*, /webhook/*)
- ⚖️ Sécurité non absolue : le Referer peut être falsifié, mais arrête les attaques de base
📋 Implémentation recommandée
- Mode "Log" pendant 24-48h — Identifiez les faux positifs sans bloquer personne.
- Examinez les journaux et ajoutez des exceptions — Ajoutez /wp-json/*, vos API, webhooks.
- Passez en mode "Challenge" — Une fois les exceptions confirmées, activez le blocage.
- Utilisez "Block" seulement si vous êtes sûr à 100% — Aucune marge pour les faux positifs.
🌐 Réseau de protection (Flux)
En plus des couches locales, SeenSecure dispose de son réseau de protection : le composant collaboratif qui partage les blocages entre tous les clients PRO. Lorsque votre site bloque une attaque, il peut la signaler anonymement au service central ; le serveur recoupe les signalements de tous les sites et publie un flux avec les IP confirmées par au moins deux sites distincts. Votre WordPress consomme ce flux et bloque à l'avance des IP qui n'ont pas encore attaqué votre site mais ont déjà été détectées par la communauté.
🔁 Flux
- Votre site bloque une attaque et la signale anonymement.
- Le serveur évalue l'IP et la publie si ≥2 sites la confirment.
- Tous les clients PRO reçoivent l'IP dans le flux et la bloquent à l'avance.
🔒 Confidentialité
Seule la preuve d'un blocage déjà exécuté est partagée. Les visiteurs ne sont pas suivis et aucune donnée personnelle n'est envoyée ; le domaine du site n'est jamais publié dans le flux. Le flux voyage chiffré et les IP sont distribuées hachées avec une clé rotative quotidienne plus des filigranes par site (détection de fuite).
📄 Documentation complète
Guide complet du réseau de protection (comment signaler, consommer le flux, consentement RGPD, dépannage) sur Réseau de protection. Les listes tierces (AbuseIPDB, AlienVault, Spamhaus) sont expliquées sur Renseignement sur les menaces.
🏗️ Architecture
La défense est organisée en cinq niveaux, chacun avec plusieurs couches :
1️⃣ Niveau réseau
Filtrage d'IP, géo-blocage, listes blanches/noires, flux du réseau de protection et renseignement sur les menaces.
2️⃣ Niveau applicatif
Règles WAF, anti-injection, sanitisation des redirections, contexte Referer, rate limiting et anti-bot.
3️⃣ Niveau système de fichiers
Protection des téléversements, surveillance de l'intégrité, détection de malware et protection des fichiers critiques.
4️⃣ Niveau utilisateur
Sécurité de connexion (force brute, CAPTCHA), 2FA et gestion des comptes restreints.
5️⃣ Niveau données
Sécurité de la base de données, sauvegardes et restauration d'urgence.
⚡ Performances
Les couches d'attaque sont conçues pour avoir un impact minimal :
✅ Coût imperceptible
La sanitisation des redirections et le contexte Referer n'inspectent que les en-têtes/chaînes : des microsecondes, zéro requête supplémentaire en base de données.
✅ Mise en cache et listes en mémoire
La blocklist du réseau est mise en cache en mémoire (au plus une lecture d'option par requête), et les signatures WAF ne sont compilées qu'une seule fois.
✅ Traitement asynchrone
Les signalements au réseau sont mis en file d'attente et envoyés par lots (cron), jamais pendant la requête du visiteur.
🔧 Dépannage
🚫 Ça me bloque / bloque un utilisateur
1) Vérifiez dans Surveillance → Trafic la raison exacte (anti_injection, referer_context, rate_limiting…).
2) Si Referer : ajoutez le chemin ou domaine aux exceptions.
3) Si anti-injection : réduisez la sensibilité ou ajoutez le paramètre/chemin à la liste blanche.
4) Ajoutez votre IP à la liste blanche (Listes d'IP) pendant le réglage.
5) Utilisez le mode d'urgence uniquement en cas de perte totale d'accès.
🔌 Mon API/webhook ne fonctionne pas
Ajoutez le chemin aux exceptions du contexte Referer (/api/*, /webhook/*) et aux listes blanches anti-injection. Les paiements (WooCommerce, PayPal, Stripe) sont protégés par défaut sans casser le paiement.
❌ Le flux du réseau indique 0 / ne se synchronise pas
1) Confirmez la licence PRO active et le signalement activé avec consentement.
2) Appuyez sur « Synchroniser » dans l'onglet Réseau de protection.
3) Les IP n'apparaissent que lorsque le serveur les publie (≥2 sites). Votre propre signalement apparaît comme « IP propre » (compte comme bloquée par votre site même avant publication).
4) Consultez le journal ssc_log si la récupération échoue.
⭐ Bonnes pratiques
- Augmentez le mode progressivement : Monitor → Challenge → Block. Ne passez jamais directement à Block en production sans examiner les journaux.
- Gardez les couches « sans friction » actives : sanitisation des redirections, anti-injection en mode Challenge, en-têtes de sécurité et anti-bot de base.
- Utilisez des listes blanches, pas des désactivations : si quelque chose de légitime est bloqué, ajoutez-le à la liste blanche. Désactiver une couche la rend inutile aussi contre les vraies attaques.
- Activez le réseau de protection (PRO) : signalez et consommez le flux collaboratif : plus les sites contribuent, plus la blocklist est rapide et précise pour tous.
- Examinez le tableau de bord chaque semaine : les badges de couches, les blocages récents et les rapports du réseau vous indiquent si quelque chose doit être ajusté.
- Combinez avec le durcissement et la 2FA : la défense en profondeur est complétée par le durcissement du site et un second facteur sur tous les admins.