But de l’article
Ce guide explique comment utiliser le pare‑feu applicatif fourni par le module Securantis pour PrestaShop (1.7 à 9). Vous apprendrez à choisir entre mode observation et blocage, activer les règles dédiées au commerce en ligne (commandes, paiements, webhooks, AJAX), autoriser des IP et des URL, et vérifier la compatibilité et le comportement « fail‑open » pour éviter toute interruption de boutique en production.
Public et prérequis
- Module Securantis installé et lié à votre compte Securantis.
- PrestaShop 1.7 à 9 ; PHP 7.2+ recommandé par l’éditeur.
- Accès administrateur au back‑office PrestaShop.
- Sauvegarde récente (fichiers et base de données) avant tout changement de configuration.
Comportement général et principes
- Modes du pare‑feu : observation (logs seulement) et blocage (interruption des requêtes malveillantes). Commencez toujours en observation sur une boutique active pour mesurer les faux positifs.
- Règles e‑commerce : ensembles de signatures et heuristiques conçues pour minimiser les blocages sur les actions sensibles (paiement, commande, panier, webhooks). Ces règles peuvent être activées séparément.
- Listes d’autorisation : vous pouvez déclarer des IP ou des URL exemptées du filtrage pour assurer l’accès aux fournisseurs tiers (IP de passerelle de paiement, IP de monitoring) ou certains endpoints internes.
- Fail‑open : en cas d’erreur interne du module ou de l’infrastructure, le mode de secours neutralise les blocages pour maintenir la boutique disponible.
Étapes recommandées (déploiement progressif en production)
- Passage en observation
- Activez le pare‑feu en mode observation. L’objectif : collecter les détections réelles et identifier les faux positifs sans impacter les clients.
- Laissez tourner pendant plusieurs jours couvrant vos pics d’activité (ex. semaine et weekend).
- Revue des événements et règles e‑commerce
- Examinez les journaux : priorisez les détections sur les parcours checkout, API et webhooks.
- Activez les règles « e‑commerce » ou « protection boutique » si disponibles : elles réduisent la sévérité sur opérations critiques tout en signalant les attaques.
- Autorisations (IP et URL)
- Liste d’IP autorisées : ajoutez les adresses IP de vos prestataires (passerelles de paiement, services de facturation, outils de monitoring) pour qu’elles échappent au filtrage.
- Liste d’URL autorisées : autorisez les endpoints connus (webhooks, endpoints d’API internes) si le pare‑feu signale des requêtes légitimes.
- Testez chaque autorisation en simulation (observation) avant d’entrer en blocage.
- Passage en blocage progressif
- Activez le blocage pour un sous‑ensemble de règles non critiques (ex. signatures XSS générales) pendant quelques heures en observant les incidents.
- Si aucun impact client n’est constaté, élargissez le blocage aux règles critiques tout en gardant les règles e‑commerce en mode plus permissif si nécessaire.
- Supervision continue
- Programmez des rapports et alertes pour suivre le taux de blocage, les règles les plus actives et les IP bloquées.
- Conservez des périodes régulières d’observation après modifications majeures (mise à jour de modules, lancement de promotions).
Réglages prudents et recommandations
- Ne bloquez pas immédiatement les signatures affectant les paiements ou webhooks. Favorisez une période d’observation et des actions graduelles.
- Préférez l’autorisation d’une IP à la désactivation globale d’une règle : c’est plus sûr et plus ciblé.
- Documentez chaque changement (qui, quand, pourquoi) afin de pouvoir revenir en arrière rapidement en cas de problème.
- Activez le mode « fail‑open » ou vérifiez sa présence : en cas d’erreur du module, cela évite la perte de ventes.
Erreurs fréquentes et causes
- Faux positifs sur les endpoints AJAX ou webhooks : souvent causés par des signatures trop strictes ou des payloads JSON non reconnus.
- Blocage des passerelles de paiement : absence des IP fournisseurs dans la liste d’autorisation.
- Perte d’accès back‑office pour certains employés : IP dynamique non autorisée ou règle trop restrictive sur les pages administratives.
- Alerte « module non connecté » ou impossibilité de vérifier la licence : problèmes réseau sortants ou informations de licence non encore activées.
Dépannage pas‑à‑pas
- Si la boutique subit des blocages clients
- Passez immédiatement le pare‑feu en observation ou activez le mode de secours pour rétablir l’accès.
- Identifiez les événements récents : URL bloquées, IP sources, règles déclenchées.
- Ajoutez en urgence les IP légitimes à la liste d’autorisation et testez les parcours affectés.
- Si des paiements échouent
- Vérifiez les logs pour repérer les requêtes envoyées vers la passerelle de paiement et ajoutez l’IP de la passerelle aux IP autorisées.
- Confirmez avec le fournisseur de paiement la liste de leurs IP ou domaines si nécessaire.
- Si le back‑office est inaccessible pour certains comptes
- Contrôlez si une règle ciblant les pages administratives est active ; désactivez‑la temporairement ou autorisez l’IP concernée.
- Vérifiez la présence d’un plugin tiers du back‑office qui modifie les routes et génère des signatures non reconnues.
- Si le module signale une mise à jour ou un problème de licence
- Vérifiez la connexion réseau du serveur vers les services Securantis et l’état de la licence dans l’espace client.
- Si une mise à jour est proposée, planifiez‑la hors pics d’activité et passez en observation après l’installation.
Précautions et bonnes pratiques
- Ne supprimez pas automatiquement des fichiers signalés comme malveillants : la suppression ou mise en quarantaine exige une décision humaine.
- Ne partagez jamais de mots de passe par email ou chat pour le support. Si un accès est nécessaire pour une intervention payante, il sera transmis via l’espace client sécurisé après règlement.
- Testez toujours les changements d’une règle sur une boutique de préproduction si possible.
- Conservez des sauvegardes avant toute modification majeure du pare‑feu ou mise à jour du module.
Compatibilité et limites
- Le module Securantis pour PrestaShop est conçu pour PrestaShop 1.7 à 9 et fonctionne sur PHP 7.2+. N’installez pas le module sur des versions non prises en charge.
- Le pare‑feu applique des règles générales pour SQLi, XSS, chemins sensibles et contrôles de débit, mais n’est pas une garantie d’arrêt de toutes les attaques. Certains outils tiers ou personnalisations de boutique peuvent nécessiter des exceptions spécifiques.
- En cas d’environnement d’hébergement atypique (reverse proxy, CDN, configuration d’en‑têtes X‑Forwarded‑For), ajustez la configuration pour que le module lise correctement l’IP d’origine.
Quand contacter le support Securantis
Contactez le support si :
- Blocages persistants qui impactent les ventes malgré l’ajout d’autorisations et le passage en observation.
- Comportement incohérent après une mise à jour du module ou de PrestaShop.
- Doutes sur une détection de fichier critique : vous voulez une aide pour analyser avant toute suppression ou quarantaine.
- Vous avez besoin d’une intervention plus poussée (audit ou résolution par nos techniciens). Notez que pour une intervention nécessitant des accès, ceux‑ci seront demandés via l’espace client sécurisé après accord commercial.
Résultat attendu
En suivant ce guide vous devriez :
- Avoir un pare‑feu actif en observation et des règles e‑commerce ajustées sans interruption de service.
- Réduire progressivement les faux positifs et, si souhaité, activer le blocage pour les signatures non critiques.
- Maintenir les paiements, webhooks et parcours clients fonctionnels grâce aux listes d’autorisation IP/URL et au mode fail‑open.
Annexe — Points rapides
- Toujours commencer en observation.
- Autoriser les IPs de prestataires de paiement et monitoring.
- Préserver la quarantaine et la suppression pour une décision humaine.
- Contacter le support pour blocages critiques ou analyse de fichiers douteux.
Mots‑clés : pare‑feu PrestaShop, WAF, règles e‑commerce, liste blanche IP, autorisation URL, fail‑open, PrestaShop 1.7–9, PHP 7.2+