But de l’article
Le scanner Securantis détecte des anomalies dans les fichiers, le cœur du CMS, les extensions/modules et les médias. Un « faux positif » est une détection légitime d’un comportement inhabituel ou d’une signature inhabituelle qui n’est pas malveillante. Cet article explique comment vérifier une alerte, ajouter une empreinte (allowlist) de manière réversible et pourquoi il ne faut jamais « ignorer » un signal sans analyse complète.
Pré-requis
- Accès administrateur à l’interface Securantis (plugin WordPress ou module PrestaShop) ou à l’espace client SaaS selon votre installation.
- Pour WordPress/WooCommerce : accès FTP/shell au site pour examiner les fichiers détectés et capacité à lancer ou poursuivre un scan depuis l’interface.
- Pour PrestaShop : accès FTP/shell et accès au back office PrestaShop où le module Securantis affiche les alertes.
- Sauvegarde récente complète du site (fichiers + base de données) avant toute modification.
- Ne jamais transmettre de mots de passe par email ou chat ; si une intervention payante est requise, les accès sont fournis uniquement via l’espace client sécurisé après paiement.
Vue d’ensemble du processus
- Examiner l’alerte : lire la description, le niveau (info/alerte/critique), les fichiers et l’empreinte regroupée.
- Reproduire le contexte : ouvrir le fichier en question en local, vérifier l’auteur du thème/extension, date de modification, et comparer aux sources officielles.
- Décider : confirmer que c’est propre, ajouter une empreinte autorisée (liste d’autorisation) ou isoler / mettre en quarantaine manuellement si suspect.
- Documenter la justification et conserver la sauvegarde avant toute suppression.
Vérification détaillée (tâches à réaliser)
- Lire l’information complète fournie par l’alerte : emplacement du fichier, type de détection (signature heuristique, code obfusqué, exécution dans uploads), score et contexte (scan progressif ou historique).
- Comparer le fichier avec une version propre : récupérer la version d’origine du thème/extension depuis le dépôt officiel ou l’archive fournie par l’éditeur.
- Rechercher les changements légitimes : modifications connues par une personnalisation, plugin métier généré par un développeur interne, ou fonctionnalités spécifiques propres au site.
- Vérifier la timeline : date/heure de modification, utilisateur qui a modifié, logs de déploiement ou système de CI/CD.
- Exécuter une analyse statique locale : ouvrir le fichier dans un éditeur, chercher présence d’URL externes non attendues, fonctions d’exécution dynamique (eval, base64_decode), injections HTML/JS inline.
- Si l’alerte concerne le dossier uploads (fichiers exécutables dans médias), vérifiez si l’analyse uploads est activée. Si non, activez-la temporairement pour investiguer plutôt que d’ignorer la règle.
Autoriser une empreinte (allowlist) — bonnes pratiques
- Principe : permettre explicitement une empreinte uniquement après vérification complète et documentation. L’autorisation doit être la dernière action, réservée aux détections clairement non malveillantes.
- Étapes :
- Sauvegarder le fichier et la base avant toute modification.
- Documenter la raison (ex. : « fonction X ajoutée par intégrateur Y le JJ/MM/AAAA — version du plugin Z »).
- Ajouter l’empreinte dans la liste d’autorisation depuis l’interface Securantis (option correspondante dans le module) en précisant la portée (site unique, chemin spécifique, durée limitée si possible).
- Relancer un scan progressif pour vérifier que l’empreinte est bien reconnue et que l’alerte ne réapparaît pas.
- Conserver la justification dans vos notes de sécurité ou ticket interne.
- Règles prudentes : n’autorisez jamais une empreinte globalement pour des signatures à haut risque (ex. code d’exécution dynamique) ; restreignez-la au chemin exact ou à la version spécifique.
Comportements spécifiques par plateforme
WordPress / WooCommerce
- Le scanner effectue une analyse progressive et peut marquer des fichiers modifiés, thèmes, extensions et médias exécutables. Si l’alerte vient d’un plugin WooCommerce (vérifiez l’étiquette de sécurité WooCommerce), comparez systématiquement avec la version officielle.
- Si l’alerte concerne le dossier uploads, sachez que l’analyse des uploads peut être désactivée dans les réglages. Activez-la pour investiguer, mais attention : un scan complet du dossier uploads peut être long sur de grandes bibliothèques.
- Utilisez le contrôle de version (si disponible) pour comparer les modifications. Si vous devez autoriser une empreinte, documentez-la et limitez la portée (ex : URL ou dossier précis).
PrestaShop (1.7 à 9)
- Le module PrestaShop affiche les alertes dans le back office avec état et historique. Les mêmes principes s’appliquent : comparer le module/thème avec l’archive officielle, vérifier modifications et logs d’installation.
- Le module propose l’isolement manuel des éléments. Préférez la quarantaine manuelle lorsque l’origine est incertaine et ne restaurez qu’après analyse humaine approfondie.
- Ne transposez pas les libellés d’interface WordPress : cherchez l’action équivalente dans votre back office PrestaShop (activer/quarantaine/autoriser) et suivez la documentation locale du module.
Résultat attendu après autorisation
- L’alerte validée ne doit plus générer d’alerte répétée pour la même empreinte et portée, et votre scan doit afficher la justification.
- La fonctionnalité du site reste intacte et les logs ne montrent pas d’activités réseau ou exécutions suspectes liées au fichier autorisé.
- Toute autorisation doit être réversible : conservez la copie de sauvegarde et la justification pour pouvoir retirer l’autorisation si nécessaire.
Erreurs fréquentes et pièges
- Autoriser globalement une signature obfusquée : risque d’exposer le site si la signature devient réellement malveillante via mise à jour.
- Ignorer une alerte par habitude sans investigation : une menace peut évoluer et contourner des contrôles si on n’analyse pas l’origine.
- Supposer qu’un fichier « personnalisé » est sûr sans vérifier l’auteur et l’historique : des fichiers injectés peuvent être renommés pour sembler légitimes.
- Ne pas activer l’analyse des uploads quand nécessaire : certains malwares logent des webshells dans ce dossier.
Dépannage
- Si l’alerte persiste après autorisation : vérifiez que l’empreinte ajoutée correspond exactement (empreinte de contenu, chemin) et que le cache du scanner a été invalidé ; relancez un scan progressif et observez les phases (découverte, analyse, finalisation).
- En cas d’impossibilité à récupérer la version propre : restaurez depuis une sauvegarde connue propre avant autoriser l’empreinte.
- Si le scan s’interrompt ou échoue : consultez les logs du module (ou de l’agent) pour erreurs de timeout, limites PHP ou permission de fichiers ; augmentez temporairement la limite si le serveur le permet et relancez la phase.
Précautions supplémentaires
- Ne supprimez pas automatiquement des fichiers détectés : la suppression ou la mise en quarantaine doit être une décision humaine et documentée.
- Limitez la durée des autorisations temporaires et planifiez une révision périodique.
- Conservez des sauvegardes hors site et testez la restauration régulièrement.
Quand contacter le support Securantis
Contactez le support si :
- Vous doutez de la légitimité d’une détection après vos vérifications.
- Le scan signale des traces d’exécution réseau ou de comportement actif (callbacks, exécutions programmées) que vous ne pouvez pas expliquer.
- Vous observez des erreurs répétées du scanner (échecs de job, phase « failed ») malgré relances et vérification des ressources serveur.
- Vous avez besoin d’une intervention approfondie (intervention payante) : les accès vous seront demandés via l’espace client sécurisé après confirmation et paiement.
Conclusion
Vérifier une alerte de scanner exige méthode et prudence : analyser le contenu, comparer aux sources officielles, documenter la décision et restreindre toute autorisation. Ne jamais ignorer une alerte sans investigation complète. En cas d’incertitude, isolez le fichier et contactez le support Securantis pour assistance.