Configurer le pare‑feu Securantis sur WordPress : observation, blocage, règles, allowlists et fail‑open

But et contexte

Ce guide explique comment utiliser prudemment le pare‑feu applicatif (WAF) fourni par Securantis pour un site WordPress/WooCommerce. L’objectif est de démarrer en observation pour vérifier l’impact, puis de basculer progressivement vers un blocage sécurisé, tout en gérant les règles personnalisées, les allowlists et le comportement "fail‑open" des protections dépendantes de services externes (ex. fournisseurs CAPTCHA). Les décisions de quarantaine, restauration ou suppression de fichiers malveillants restent humaines : Securantis ne supprime rien automatiquement sans votre validation.

Prérequis

• Plugin Securantis installé et licence active.
• Accès administrateur WordPress (capacité élevée requise pour modifier la protection).
• Sauvegarde récente du site (fichiers et base de données) avant toute modification de la politique WAF.
• Si vous utilisez WooCommerce : horaires de faible trafic pour basculer en blocage si nécessaire.

Principes de fonctionnement (résumé rapide)

• Observation (mode « learning ») : le WAF enregistre les évènements et génère des alertes sans bloquer. C’est le mode recommandé au départ.
• Blocage : le WAF rejette ou met en quarantaine les requêtes malicieuses selon des règles.
• Règles : combinaison de signatures, anomalies et heuristiques qui déclenchent une action.
• Allowlists (liste blanche) : adresses IP, chemins ou signatures à exclure du filtrage.
• Fail‑open : option qui autorise le trafic si une dépendance externe (ex. service CAPTCHA) échoue, pour éviter une interruption de service.

Étapes recommandées (pas à pas)

1. Vérifier l’état initial

   • Dans l’interface Securantis du panneau WordPress, ouvrez la section « Pare‑feu » ou la page correspondante.
   • Confirmez que le WAF est activé et notez s’il est en mode observation ou en blocage.

2. Lancer 7 à 14 jours d’observation

   • Activez (ou conservez) le mode observation.
   • Pendant cette période, suivez les journaux d’évènements et les alertes pour repérer faux positifs (bloqueurs légitimes comme des robots d’indexation, webhook, intégrations tierces).
   • Exportez ou notez les adresses IP et patterns régulièrement rencontrés.

3. Construire des allowlists prudentes

   • Pour chaque service légitime bloqué (plateforme d’envoi d’emails, intégrations CRM, API, robots d’indexation connus), ajoutez une entrée dans l’allowlist.
   • Préférez des entrées précises (CIDR pour IP, pattern de chemin) plutôt que des allowlists globales.
   • Documentez chaque ajout : pourquoi, durée et propriétaire.

4. Affiner les règles avant blocage

   • Corrigez les règles trop larges repérées pendant l’observation (ex. règles qui bloquent POSTs légitimes sur des endpoints d’API).
   • Si possible, testez les modifications sur un environnement de préproduction ou en dehors des heures de pointe.

5. Passage progressif au blocage

   • Activez le blocage pour des catégories non‑critiques (ex. commentaires spam) en premier. Surveillez les logs intensivement.
   • Étendez graduellement aux catégories plus sensibles (tentatives d’injection, accès aux interfaces d’administration).
   • Conservez un journal des blocages et des contremesures appliquées.

6. Configurer le fail‑open de façon prudente

   • Si vous utilisez des protections reposant sur des services externes (ex. CAPTCHA), activez le fail‑open si la continuité de service est prioritaire. Cela permettra au trafic de passer en cas d’erreur fournisseur, mais augmente le risque d’événements non filtrés.
   • Pour les interfaces sensibles (page de connexion, paiement), évitez le fail‑open sauf si vous avez une autre protection (2FA, surveillance d’accès).

Réglages prudents et recommandations

• Ne bloquez pas massivement dès le départ : une montée en charge progressive réduit les interruptions.
• Favorisez des règles spécifiques plutôt que des règles globales.
• Limitez la portée des allowlists (durée limitée, propriétaire identifié).
• Pour les boutiques WooCommerce, testez toute modification en dehors des pics (promotions, ventes).
• Conservez la journalisation complète pour 30 jours au minimum pour analyser les incidents.

Erreurs fréquentes et leur gestion

• Faux positifs sur formulaires ou webhooks : identifier le pattern (URL, user‑agent, IP) et créer une allowlist ciblée.
• Blocage d’API tierces : ajouter les adresses IP/Plages CIDR ou signer les requêtes entre serveurs.
• CAPTCHA bloqué ou indisponible : si fail‑open est désactivé, les utilisateurs peuvent être bloqués ; activez le fail‑open temporairement pendant le dépannage si la continuité prime.
• Blocages intermittents après mise à jour d’un plugin : retester en mode observation et renouveler la baseline si nécessaire.

Dépannage étape par étape

1. Identifiez le symptôme : pages indisponibles, formulaires non envoyés, erreurs 403.
2. Consultez les journaux WAF pour l’heure et l’IP concernée.
3. Reproduisez l’action depuis un navigateur en mode développeur pour capturer la requête exacte (méthode, headers, payload).
4. Si la règle semble excessive, passez la règle en mode observation ou ajoutez une règle d’exception ciblée.
5. Pour CAPTCHA : vérifiez la communication avec le fournisseur (logs d’appel API). Si l’API externe renvoie une erreur, décidez entre correction de l’intégration, bascule sur un autre fournisseur, ou activation temporaire du fail‑open.
6. Pour problèmes fréquents d’IP légitimes : ajoutez une entrée allowlist (CIDR), puis surveillez.

Précautions et conformité

• Ne demandez jamais de mots de passe par email ou chat.
• Toute opération invasive (restauration de fichiers en quarantaine, suppression automatique) doit faire l’objet d’une autorisation explicite et d’une sauvegarde préalable.
• Les accès pour interventions payantes sont fournis via l’espace client sécurisé après paiement.

Quand contacter le support Securantis

Contactez le support si :

• Vous observez blocages massifs imprévus durant le passage en blocage.
• Vous identifiez un comportement de bypass potentiel affectant la sécurité (ex. règles contournées).
• Vous avez besoin d’aide pour définir des signatures complexes ou pour analyser un incident critique.
• Vous n’arrivez pas à rétablir l’accès administrateur ou paiement après activation du blocage.

Préparez lors de la demande d’assistance :

• Description précise du problème, heure et URL concernée.
• Exemple de requête bloquée (headers et payload si possible).
• Copies d’écran des logs WAF et des actions déjà entreprises.

Résultat attendu après configuration

• Une période d’observation documentée conduisant à une politique de blocage progressive avec peu de faux positifs.
• Playbooks d’allowlisting et d’escalade rédigés pour une réaction rapide.
• Surveillance active et procédures pour activer/désactiver le fail‑open selon le contexte (ex. incident fournisseur CAPTCHA).

Remarques finales

La sécurité est un équilibre entre protection stricte et disponibilité. Le mode observation suivi d’un blocage progressif permet de calibrer le WAF sans interrompre les utilisateurs légitimes. Conservez des sauvegardes et une traçabilité de chaque changement de règle ou allowlist. Si vous avez des doutes, demandez l’assistance de Securantis avant d’appliquer des réglages globaux sur un site en production.