But
Ce guide explique comment, en toute sécurité, repasser le pare‑feu en mode observation (monitor), identifier quelle règle a bloqué une requête légitime, puis ajouter l’exception la plus limitée possible pour rétablir l’action souhaitée tout en conservant une protection efficace.
À qui s’adresse cet article
- Administrateurs de site utilisant Securantis (agent WordPress/WooCommerce, module PrestaShop ou l’interface SaaS).
- Équipes qui souhaitent réagir rapidement à un blocage légitime sans ouvrir trop large le pare‑feu.
Prérequis
- Accès administrateur au panneau Securantis correspondant (plugin WordPress / module PrestaShop ou le tableau de bord SaaS selon votre configuration).
- Accès FTP/SFTP ou gestionnaire de fichiers si la modification de fichiers serveur est requise (rare).
- Informations sur la requête bloquée : URL, IP source, horodatage et type d’événement (ex. SQLi, XSS, rate limit). Le tableau d’événements doit contenir ces données.
Vue d’ensemble de la démarche
- Revenir en observation (mode monitor) pour éviter de bloquer d’autres requêtes pendant le diagnostic.
- Reproduire ou retrouver l’événement bloqué et collecter ses métadonnées.
- Identifier la règle et la condition précise qui a entraîné le blocage.
- Créer une exception minimale (IP, chemin, paramètre, en-tête ou règle d’exclusion ciblée).
- Tester et revenir au mode blocage si tout est correct.
Étapes détaillées (procédure applicable à WordPress, WooCommerce, PrestaShop et au SaaS)
- Passer temporairement en observation
- Dans l’interface du plugin/module ou du tableau de bord, basculez le pare‑feu en mode observation/monitor. Cela empêche le blocage actif tout en continuant à enregistrer les évènements.
- Conservez la durée de ce mode aussi courte que nécessaire pour le diagnostic (généralement quelques minutes à une heure).
Résultat attendu : le site n’est plus bloqué mais les événements continuent d’être journalisés.
- Rassembler les informations sur le blocage
- Reproduisez l’action légitime si possible (par exemple : soumettre le formulaire ou recréer la requête API).
- Notez ou exportez l’événement correspondant : horodatage, URL complète, méthode HTTP, corps/paramètres (si visibles), IP source, user‑agent, statut du pare‑feu (catégorie d’attaque : sqli, xss, etc.).
Conseil : si l’événement a été rapporté par un utilisateur, demandez-lui l’heure exacte et la page concernée pour retrouver l’entrée dans les logs.
- Identifier la règle responsable
- Dans la liste des détections du pare‑feu, recherchez l’événement par horodatage et URL.
- Examinez le détail : la plupart des journaux indiquent la règle (ou la signature) qui a déclenché l’alerte et la condition (paramètre, motif d’entête, payload détecté).
- Si le journal ne précise pas la règle, activez la journalisation détaillée temporairement pour la même fenêtre de reproduction puis répétez l’action.
Attention : évitez de désactiver des catégories entières (ex. toutes les signatures XSS) pour identifier une règle : préférez la journalisation et l’analyse ciblée.
- Composer l’exception minimale
Objectif : n’ouvrir que ce qui est nécessaire pour la requête légitime.
Types d’exceptions courantes
- Exception par IP : si la requête provient d’une adresse IP stable et de confiance. Limitez par durée et documentez la raison.
- Exception par chemin/route : cibler l’URL ou le préfixe uniquement (ex. /wp-json/your-endpoint).
- Exception par paramètre : exclure un paramètre spécifique connu pour contenir des caractères détectés comme malveillants.
- Exception par user‑agent ou en‑tête : rare, mais utile pour des intégrations d’API légitimes.
- Désactivation d’une règle spécifique : si le système identifie une signature précise, créez une exclusion pour cette signature uniquement.
Comment créer l’exception
- Choisissez le type d’exception le plus restrictif qui résout le problème.
- Dans l’interface du pare‑feu, ajoutez l’exclusion en précisant la portée (IP, chemin, paramètre, règle) et une durée d’expiration courte (ex. 24–72 heures) si possible.
- Documentez la raison dans le commentaire de l’exception.
Résultat attendu : l’action légitime passe sans déclencher le blocage, et le reste des protections continue de fonctionner.
- Tester et revenir au mode blocage
- Reproduisez l’action depuis l’environnement de l’utilisateur concerné (même IP / même application).
- Vérifiez que l’événement ne génère plus de blocage actif mais qu’il est éventuellement encore journalisé.
- Si tout est conforme, repassez le pare‑feu en mode blocage (block) pour restaurer la protection complète.
Réglages prudents et bonnes pratiques
- Limitez la durée des exceptions automatiques : préférez une exception temporaire plutôt qu’une exclusion permanente.
- Privilégiez les exceptions par chemin ou signature plutôt que par catégorie large.
- Documentez chaque exception (qui l’a créée, pourquoi, durée) pour audit ultérieur.
- Sur les boutiques WooCommerce et PrestaShop, excluez de préférence des routes spécifiques au checkout ou aux webhooks connus plutôt que d’exclure AJAX globalement.
Erreurs fréquentes
- Ajouter une exception trop large (ex. désactiver toute la catégorie XSS) qui expose la surface d’attaque.
- Oublier de restreindre l’exception dans le temps.
- Confondre blocage côté serveur (règles .htaccess, WAF réseau) et blocage au niveau de l’agent : vérifiez l’origine du blocage.
- Ne pas reproduire la requête depuis la même IP ou le même header, ce qui fausse le diagnostic.
Dépannage (si la requête est toujours bloquée)
- Vérifiez le journal immédiatement après une tentative de reproduction : y a‑t‑il une autre règle qui intervient ?
- Si l’événement a un identifiant de signature différent, créez une exception pour cette signature plutôt que d’élargir la précédente.
- Confirmez qu’aucun autre WAF (hébergeur, reverse proxy) n’applique une règle similaire.
- Sur WordPress/WooCommerce, assurez‑vous que les routes AJAX et REST sensibles ne sont pas globalement excluses ; ciblez l’endpoint exact.
Précautions de sécurité
- Ne demandez jamais de mot de passe pour effectuer ces actions via email ou chat.
- Les fichiers détectés comme malveillants ne doivent pas être automatiquement supprimés : la quarantaine, la restauration ou la suppression nécessitent une décision humaine.
- Si un changement d’exception implique une intervention sur le serveur (fichiers de configuration), sauvegardez les fichiers avant modification.
Quand contacter le support Securantis
Contactez le support si :
- Vous ne pouvez pas identifier la règle malgré la journalisation détaillée.
- L’exception minimale ne résout pas le blocage et le site est impacté en production.
- Vous avez un doute sur l’impact de l’exception (ex. route critique ou trafic important).
- Vous suspectez qu’il s’agit d’une attaque déguisée et non d’un faux positif.
Informations à fournir au support
- Horodatage précis des événements reproduits.
- URL complète, IP source et user‑agent utilisés lors de la reproduction.
- Capture d’écran du journal d’événements si possible.
- Description de la solution souhaitée (ex. autoriser temporairement IP X pour endpoint Y).
Conclusion
La règle d’or : n’ouvrir que ce qui est strictement nécessaire et pendant le temps nécessaire. En mode observation, vous pouvez diagnostiquer sans affecter les utilisateurs et, ensuite, mettre en place des exceptions ciblées qui rétablissent le fonctionnement légitime tout en conservant un niveau de protection élevé. Si vous hésitez, contactez le support avec les logs et les détails demandés pour une assistance guidée.