But de l’article
Ce guide explique comment utiliser la fonctionnalité de quarantaine du module Securantis pour PrestaShop : quand isoler un fichier ou un élément, comment le restaurer en toute sécurité, comment gérer et corriger les faux positifs, et quelles précautions prendre pour ne pas perturber la boutique en production.
Public concerné et prérequis
- Administrateur de boutique PrestaShop (accès back-office avec droits suffisants pour gérer le module Securantis).
- Module Securantis installé et activé sur PrestaShop 1.7 à 9.
- Licence Securantis active et synchronisation vers le cloud opérationnelle (pour recevoir alertes et rapports).
- Sauvegarde récente disponible (fichiers et base de données) — la quarantaine et la restauration sont des opérations irréversibles sans sauvegarde fiable.
Quand utiliser la quarantaine
- Détection d’un fichier identifié comme malveillant ou modifié de façon anormale (ex. code inconnu dans un override, exécutable dans uploads).
- Risque immédiat pour l’intégrité ou la confidentialité (ex. rootkit, webshell) et besoin d’isolation rapide pour limiter l’impact.
- Analyse en cours où les responsables veulent isoler l’élément en attendant une décision humaine.
Important : la mise en quarantaine isole le fichier mais ne le supprime pas définitivement. Toute suppression définitive doit être décidée par un humain après analyse.
Procédure recommandée — mise en quarantaine (étapes)
- Vérifier l’alerte dans l’interface Securantis du back-office PrestaShop : lire le contexte fourni (type d’alerte, fichier ou élément affecté, gravité, horodatage).
- Exporter ou copier l’alerte et le hash fourni vers votre dossier d’investigation (ne pas envoyer de mots de passe par email).
- Confirmer qu’une sauvegarde récente couvre le fichier et la base de données. Si ce n’est pas le cas, faites une sauvegarde avant toute modification.
- Si la décision est d’isoler, activez la quarantaine manuelle depuis le panneau d’actions Securantis pour l’élément ciblé. L’opération déplace l’élément dans un emplacement sécurisé non exécutable et journalise l’événement.
- Documenter la décision : motif, personne ayant autorisé la quarantaine et mesures prises.
- Surveiller le fonctionnement de la boutique et les logs après quarantaine (pour détecter tout effet secondaire sur le site ou règles déclenchées).
Résultat attendu
- Le fichier ou l’élément est déplacé en quarantaine et rendu non exécutable.
- Un enregistrement d’audit est généré avec le motif, l’auteur de l’action et le hash.
- La boutique reste accessible si le module est configuré en mode fail-open ; seules les fonctionnalités liées directement à l’élément isolé peuvent être affectées.
Prudence sur les réglages
- Autorisations de quarantaine : vous pouvez restreindre la quarantaine aux types d’éléments souhaités (fichiers, modules, thèmes). Limitez les opérations automatiques sur éléments critiques du cœur ou des modules de paiement.
- Mode fail-open : assurez-vous que la configuration de secours est active pour éviter qu’une erreur interne bloque la boutique.
- Garder la fonctionnalité de quarantaine manuelle activée uniquement pour des comptes administrateurs de confiance.
Traiter un faux positif — procédure détaillée
- Lorsque l’alerte semble légitime (ex. nouveau module, override d’un développeur), récupérer le message complet et le hash enregistré.
- Comparer le fichier isolé au dépôt source légitime (thème, module ou code fourni par le développeur) et aux sauvegardes.
- Si le fichier est attendu et propre :
- Restaurer depuis la quarantaine vers son emplacement d’origine via l’action de restauration du module.
- Mettre à jour la liste d’exclusions ou marquer l’alerte comme « légitime » pour éviter de nouvelles quarantaines pour ce même motif.
- Documenter la raison du faux positif et le justificatif (log du développeur, hash connu, version du module).
- Si l’alerte est ambiguë :
- Prélever une copie de quarantaine pour analyse (via l’export d’audit) et la transmettre à l’équipe en charge de votre sécurité interne ou à un prestataire pour examen approfondi (sans communiquer de mots de passe).
- Laisser le fichier en quarantaine jusqu’à décision claire.
Restauration — étapes et vérifications
- Vérifier que le chemin de restauration est sûr, que l’arborescence d’origine n’a pas été modifiée de façon malveillante depuis l’isolation.
- Restaurer depuis le gestionnaire de quarantaine du module.
- Après restauration : vider le cache de PrestaShop, reconstruire les indices nécessaires (si applicable) et vérifier les logs d’erreur.
- Tester les fonctionnalités liées (parcours commande, paiement, back-office) pour s’assurer qu’aucun effet indésirable n’apparaît.
- Si le fichier restauré posait réellement problème, remettez-le immédiatement en quarantaine et basculez vers la procédure de suppression ou de correction manuelle après analyse.
Erreurs fréquentes et comment les corriger
- « Dossier de quarantaine non accessible en écriture » : vérifier les permissions filesystem du dossier de quarantaine et l’utilisateur PHP exécutant PrestaShop. Ne donnez pas de permissions excessives (évitez 777).
- « Quarantaine désactivée » : activer explicitement la quarantaine dans les réglages Securantis, puis retenter.
- Restauration impossible car le chemin original a changé : restaurer manuellement la copie hors ligne, comparer, puis replacer l’élément en utilisant un protocole de déploiement sûr.
- Effet sur la boutique après quarantaine : vérifier si l’élément isolé était utilisé au runtime (module de paiement, override du front). Si oui, restaurer temporairement et planifier une fenêtre de maintenance.
Dépannage avancé
- Vérifier les journaux Securantis et les logs PrestaShop/PHP pour toute erreur liée à la quarantaine ou à l’accès fichier.
- Confirmer que le module Securantis a accès à l’espace disque et au dossier de quarantaine (espace libre, SELinux/AppArmor, quotas).
- Si la quarantaine a été exécutée automatiquement et vous semble abusive, exportez l’alerte complète (horodatage, règle déclenchée, hash) et ajoutez l’entrée aux exclusions après vérification.
- Pour restaurations répétées échouant, effectuez une restauration manuelle depuis la sauvegarde et comparez les permissions et propriétaires de fichiers.
Précautions légales et opérationnelles
- Ne supprimez jamais définitivement un fichier suspect sans l’avoir archivé et documenté.
- Si des données clients sont potentiellement compromises, suivez vos obligations réglementaires et process internes avant toute communication publique.
- Toute transmission d’accès à des prestataires doit se faire via l’espace client sécurisé après accord commercial ; ne transmettez jamais de mots de passe par email ou chat.
Quand contacter le support Securantis
Contactez le support si :
- La quarantaine ne fonctionne pas et affiche des messages d’erreur bloquants après vérifications de base.
- Vous suspectez un cas de compromission avancée (présence d’un webshell confirmé, comportements persistants après restauration).
- Vous avez des difficultés à configurer les exclusions de scan ou les règles pour éviter des faux positifs massifs sans mettre la boutique en danger.
Ce que le support pourra demander
- Description détaillée de l’alerte, horodatage, niveau de gravité et hash du fichier isolé.
- Accès contrôlé et temporaire (fourni uniquement via l’espace client sécurisé après accord commercial si une intervention payante est nécessaire).
- Logs d’application et captures d’écran de l’interface Securantis montrant l’alerte (jamais de mots de passe).
Conclusion
La quarantaine est un outil puissant pour isoler rapidement des éléments suspects tout en conservant la maîtrise humaine des décisions sensibles. Priorisez toujours les sauvegardes avant toute action, documentez chaque intervention et utilisez la restauration et les exclusions seulement après vérification. En cas de doute sur la nature d’un fichier ou sur l’impact opérationnel, conservez l’élément isolé et sollicitez une expertise avant suppression définitive.