Sito non disponibile dopo l'attivazione di Securantis — fail‑open, disattivazione sicura e raccolta dei log

But de l’article

Ce guide explique comment rétablir rapidement l’accès à un site devenu indisponible suite à l’activation de Securantis, comment appliquer un « fail‑open » (comportement permissif), comment désactiver proprement l’agent/module et quels journaux et informations collecter pour un diagnostic efficace.

Pour qui et prérequis

• S’applique aux sites protégés par Securantis : plugin agent WordPress/WooCommerce, module PrestaShop (1.7 → 9) ou intégration SaaS côté serveur.
• Accès SSH/FTP/SFTP au site ou accès au backoffice (administrateur).
• Possibilité de consulter les journaux web (Apache/Nginx), journaux PHP et les fichiers du module/plugin.

Résultat attendu

• Site restauré en production (accès public ou backoffice) sans suppression automatique de fichiers suspects.
• Collecte d’un ensemble de journaux et métadonnées prêts à être fournis au support Securantis via l’espace client sécurisé.

Principes de sécurité et règles à respecter

• Securantis n’efface ni ne restaure automatiquement des fichiers : toute quarantaine, suppression ou restauration requiert une décision humaine.
• Ne communiquez jamais de mots de passe par email/chat. Les accès demandés pour une intervention payante ne sont transmis que via l’espace client sécurisé après paiement.
• Si vous doutez, faites une sauvegarde complète (fichiers + base de données) avant toute modification.

1. Règle générale : tenter un mode « fail‑open » avant de désactiver

Pourquoi ? Le blocage survient souvent parce que le pare‑feu, une règle ou une vérification stricte empêche le chargement. Le comportement « fail‑open » (permissif) consiste à rendre le site accessible rapidement tout en conservant les données pour diagnostic.

Procédure :

1. Si vous avez accès à l’interface SaaS Securantis (console en ligne), désactivez temporairement toute option de blocage automatique (notifications/remote block) ou placez la protection en mode observation/learning. Si l’interface n’expose pas ces contrôles, passez aux actions locales ci‑dessous.
2. Si le site utilise un WAF externe ou reverse proxy (Cloudflare, autre WAF), placez ce WAF en mode « permissif / disable rules » ou bypass pour votre IP.

Remarque : si vous ne pouvez pas modifier ces éléments rapidement, passez à la désactivation locale du module/agent.

2. Désactivation sûre — WordPress / WooCommerce

Méthodes sûres (par ordre de préférence si vous avez accès) :

A. Via WP‑CLI (rapide et réversible)

1. Connectez‑vous en SSH.
2. Exécutez : wp plugin deactivate securantis
3. Videz le cache (si vous utilisez un cache plugin) : wp cache flush

B. Via FTP/SFTP (si pas d’accès backoffice)

1. Renommez le dossier du plugin : wp-content/plugins/securantis → wp-content/plugins/securantis.disabled
2. Cela empêche WordPress de charger le plugin au prochain chargement.

C. Via base de données (en dernier recours)

1. Dans la table wp_options, repérez l’option qui active les plugins et modifiez‑la uniquement si vous savez manipuler ces enregistrements. (Préférez WP‑CLI ou renommage de dossier.)

Actions complémentaires :

• Désactivez temporairement tout module Securantis lié à la protection des connexions, blocage IP ou pare‑feu.
• Purgez les caches serveur et CDN.

3. Désactivation sûre — PrestaShop (1.7 → 9)

Méthodes sûres :

A. Via le backoffice PrestaShop

1. Connectez‑vous au backoffice.
2. Ouvrez la liste des modules et désactivez le module Securantis (utilisez l’action de désactivation fournie par PrestaShop).

B. Via FTP/SFTP

1. Renommez le dossier du module : modules/securantis → modules/securantis.disabled
2. Ensuite, dans le backoffice, purgez le cache si nécessaire.

C. Via la base de données (si backoffice inaccessible)

1. Dans la table ps_module (ou équivalente), repérez la ligne du module et mettez le champ active à 0.
2. Videz le cache PrestaShop (dossier var/cache ou /app/cache selon version).

Remarques spécifiques :

• Ne transposez jamais des menus WordPress vers PrestaShop : suivez l’interface PrestaShop ou la méthode FTP/DB appropriée.

4. Journaux et collecte de diagnostic — que collecter

Collectez ces éléments et conservez‑les dans un dossier zippé à remettre au support via l’espace client :

Essentiels :

• Journal d’erreurs PHP (date/heure de l’incident).
• Journal d’accès et d’erreur du serveur web (Nginx/Apache) couvrant l’heure du blocage.
• Journaux du plugin/module Securantis (si présents dans le dossier du plugin/module).
• Capture d’écran de l’erreur affichée (page blanche, 403, 503, redirection boucle, etc.).
• Version de PHP, extensions activées et version MySQL/MariaDB.
• Version du CMS (WordPress/PrestaShop), liste des plugins/modules actifs principaux (surtout ceux modifiant les règles d’accès).

Avancé (si possible) :

• Logs du WAF externe (Cloudflare, reverse proxy) et règles récemment appliquées.
• Logs de sécurité du serveur (fail2ban, iptables) indikant des blocages IP.
• Capture d’en‑têtes HTTP (via curl -I ou outil navigateur) pour vérifier redirections et en‑têtes Securantis.

Format recommandé : regrouper les fichiers dans un ZIP nommé site-diagnostic-YYYYMMDD.zip.

5. Erreurs fréquentes et leur signification

• Erreur 403 pour tous : souvent blocage par pare‑feu ou règle IP. Vérifiez WAF, iptables, fail2ban et liste d’IP bloquées dans le plugin.
• Page blanche/erreur 500 : souvent une erreur PHP causée par conflit d’extensions ou limite mémoire. Vérifiez PHP error log et augmentez temporairement memory_limit si nécessaire.
• Boucle de redirection : règle de protection sur l’URL admin ou réécritures incorrectes ; vérifiez règles de redirection et paramètres URL dans la configuration du CMS.
• Backoffice accessible mais front‑office non : règles frontales de protection ou contenu mis en quarantaine empêchant le rendu ; collectez les logs de scan et liste des fichiers isolés.

6. Dépannage pas à pas si le site reste indisponible

1. Réalisez une sauvegarde immédiate (fichiers + base de données).
2. Passez le WAF externe en mode permissif.
3. Désactivez le module/plugin Securantis (méthodes ci‑dessus).
4. Vérifiez et corrigez les erreurs PHP/serveur relevées dans les journaux.
5. Si le blocage vient d’une règle précise (IP ou chemin), ajoutez temporairement une règle allowlist pour votre IP ou chemin critique.
6. Redémarrez le service web si nécessaire et purgez tous les caches.

7. Réglages prudents et bonnes pratiques post‑rétablissement

• Après rétablissement, ne réactivez pas toutes les protections d’un coup : activez‑les une à une en observant le comportement du site.
• Activez les notifications de sécurité pour être alerté avant que des mesures automatiques ne bloquent le site.
• Maintenez des sauvegardes régulières et testez-les.
• Placez un compte administrateur sûr (2FA) avant d’activer les protections critiques.

8. Quand et comment contacter le support Securantis

Contactez le support si :

• Vous avez désactivé le module/plugin mais ne pouvez pas identifier la cause.
• Les journaux montrent des signes de compromission ou de fichiers suspects (ne supprimez rien sans avis).
• L’incident concerne la licence ou l’intégration SaaS.

Préparez avant contact :

• Le ZIP de diagnostics (voir section journaux) et une description précise des actions déjà réalisées (renommer dossier, désactivation via WP‑CLI, etc.).
• Vos identifiants de licence et domaine (ne transmettez pas vos mots de passe).

Remarques sur la confidentialité et l’accès

• Le support peut demander des accès pour une intervention : ces accès ne sont transmis que via l’espace client sécurisé et éventuellement après validation d’un contrat d’intervention payant.
• N’envoyez jamais vos mots de passe par email ou chat. Utilisez des identifiants temporaires que vous révoquerez après l’intervention.

Annexe rapide — commandes utiles

• WP‑CLI : wp plugin deactivate securantis
• Renommage FTP : mv securantis securantis.disabled (dans wp-content/plugins ou modules)
• Curl pour en‑têtes : curl -I https://votre-site.example
• Archive des journaux : zip -r site-diagnostic-YYYYMMDD.zip /chemin/vers/logs /chemin/vers/plugin/logs

Conclusion

La priorité est de restaurer l’accès par un mode permissif ou en désactivant proprement le module/ plugin. Conservez tous les journaux et métadonnées : ils sont indispensables pour diagnostiquer l’origine du blocage et prendre des mesures correctives sûres. Si vous avez besoin d’aide, rassemblez le diagnostic demandé et contactez le support via l’espace client sécurisé.