Site unavailable after activating Securantis — fail‑open, safe deactivation and log collection

Goal of this article

This guide explains how to quickly restore access to a site that became unavailable after activating Securantis, how to apply a “fail‑open” (permissive) behavior, how to safely disable the agent/module and which logs and information to collect for an effective diagnosis.

Who this applies to and prerequisites

• Applies to sites protected by Securantis: WordPress/WooCommerce plugin agent, PrestaShop module (1.7 → 9) or server‑side SaaS integration.
• SSH/FTP/SFTP access to the site or backoffice access (administrator).
• Ability to consult web logs (Apache/Nginx), PHP logs and the plugin/module files.

Expected outcome

• Site restored to production (public access or backoffice) without automatic deletion of suspicious files.
• A collected set of logs and metadata ready to be provided to Securantis support via the secure client area.

Security principles and rules to follow

• Securantis does not automatically delete or restore files: any quarantine, deletion or restoration requires a human decision.
• Never share passwords by email/chat. Access requested for a paid intervention is only transmitted via the secure client area after payment.
• If in doubt, make a full backup (files + database) before any modification.

1. General rule: try a “fail‑open” mode before disabling

Why? The blockage often occurs because the firewall, a rule or a strict check prevents loading. The “fail‑open” (permissive) behavior is intended to make the site quickly accessible while preserving data for diagnostic purposes.

Procedure:

1. If you have access to the Securantis SaaS interface (online console), temporarily disable any automatic blocking options (notifications/remote block) or set protection to observation/learning mode. If the interface does not expose these controls, proceed to the local actions below.
2. If the site uses an external WAF or reverse proxy (Cloudflare, other WAF), set that WAF to “permissive / disable rules” mode or bypass it for your IP.

Note: if you cannot modify these elements quickly, proceed to local disabling of the module/agent.

2. Safe deactivation — WordPress / WooCommerce

Safe methods (in order of preference if you have access):

A. Via WP‑CLI (quick and reversible)

1. Connect via SSH.
2. Execute : wp plugin deactivate securantis
3. Clear caches (if you use a cache plugin) : wp cache flush

B. Via FTP/SFTP (if no backoffice access)

1. Rename the plugin folder: wp-content/plugins/securantis → wp-content/plugins/securantis.disabled
2. This prevents WordPress from loading the plugin on the next request.

C. Via the database (as a last resort)

1. In the wp_options table, locate the option that activates plugins and modify it only if you know how to handle these records. (Prefer WP‑CLI or folder rename.)

Additional actions:

• Temporarily disable any Securantis-related module handling login protection, IP blocking or firewall.
• Purge server and CDN caches.

3. Safe deactivation — PrestaShop (1.7 → 9)

Safe methods:

A. Via the PrestaShop backoffice

1. Log in to the backoffice.
2. Open the modules list and disable the Securantis module (use the disable action provided by PrestaShop).

B. Via FTP/SFTP

1. Rename the module folder: modules/securantis → modules/securantis.disabled
2. Then, in the backoffice, purge the cache if necessary.

C. Via the database (if backoffice inaccessible)

1. In the ps_module table (or equivalent), find the module row and set the active field to 0.
2. Clear the PrestaShop cache (var/cache or /app/cache depending on version).

Specific notes:

• Never transpose WordPress menus to PrestaShop: follow the PrestaShop interface or the appropriate FTP/DB method.

4. Logs and diagnostic collection — what to collect

Collect these items and keep them in a zipped folder to provide to support via the client area:

Essential:

• PHP error log (date/time of the incident).
• Web server access and error logs (Nginx/Apache) covering the time of the blockage.
• Securantis plugin/module logs (if present in the plugin/module folder).
• Screenshot of the displayed error (white page, 403, 503, redirect loop, etc.).
• PHP version, enabled extensions and MySQL/MariaDB version.
• CMS version (WordPress/PrestaShop), list of main active plugins/modules (especially those modifying access rules).

Advanced (if possible):

• External WAF logs (Cloudflare, reverse proxy) and recently applied rules.
• Server security logs (fail2ban, iptables) indicating IP blocks.
• HTTP header capture (via curl -I or browser tool) to check redirects and Securantis headers.

Recommended format: gather files into a ZIP named site-diagnostic-YYYYMMDD.zip.

5. Common errors and their meaning

• 403 for everyone: often a firewall or IP rule block. Check WAF, iptables, fail2ban and blocked IP lists in the plugin.
• White page/500 error: often a PHP error caused by extension conflict or memory limit. Check the PHP error log and temporarily increase memory_limit if necessary.
• Redirect loop: protection rule on the admin URL or incorrect rewrites; check redirect rules and CMS URL settings.
• Backoffice accessible but front‑end not: frontal protection rules or quarantined content preventing rendering; collect scan logs and list of isolated files.

6. Step-by-step troubleshooting if the site remains unavailable

1. Perform an immediate backup (files + database).
2. Set external WAF to permissive mode.
3. Disable the Securantis module/plugin (methods above).
4. Check and fix PHP/server errors found in the logs.
5. If the blockage is caused by a specific rule (IP or path), temporarily add an allowlist rule for your IP or critical path.
6. Restart the web service if necessary and purge all caches.

7. Cautious settings and best practices after recovery

• After recovery, do not re-enable all protections at once: enable them one by one while monitoring site behavior.
• Enable security notifications so you are alerted before automatic measures block the site.
• Maintain regular backups and test them.
• Create a secure administrator account (2FA) before enabling critical protections.

8. When and how to contact Securantis support

Contact support if:

• You disabled the module/plugin but cannot identify the cause.
• Logs show signs of compromise or suspicious files (do not delete anything without advice).
• The incident concerns licensing or the SaaS integration.

Prepare before contact:

• The diagnostics ZIP (see logs section) and a precise description of actions already taken (renamed folder, deactivation via WP‑CLI, etc.).
• Your license identifiers and domain (do not transmit your passwords).

Notes on confidentiality and access

• Support may request access for an intervention: such access is only transmitted via the secure client area and possibly after validation of a paid intervention agreement.
• Never send your passwords by email or chat. Use temporary credentials that you will revoke after the intervention.

Quick appendix — useful commands

• WP‑CLI : wp plugin deactivate securantis
• FTP rename : mv securantis securantis.disabled (in wp-content/plugins or modules)
• Curl for headers : curl -I https://votre-site.example
• Archive logs : zip -r site-diagnostic-YYYYMMDD.zip /chemin/vers/logs /chemin/vers/plugin/logs

Conclusion

The priority is to restore access by using a permissive mode or by safely disabling the module/plugin. Keep all logs and metadata: they are essential to diagnose the cause of the blockage and to take safe corrective measures. If you need help, gather the requested diagnostic information and contact support via the secure client area.