Configure the Securantis firewall on WordPress: observation, blocking, rules, allowlists and fail-open

Goal and context

This guide explains how to cautiously use the application firewall (WAF) provided by Securantis for a WordPress/WooCommerce site. The objective is to start in observation to verify impact, then progressively switch to secure blocking while managing custom rules, allowlists and the "fail-open" behavior of protections that depend on external services (e.g. CAPTCHA providers). Decisions to quarantine, restore or delete malicious files remain human: Securantis does not delete anything automatically without your validation.

Prerequisites

• Securantis plugin installed and active license.
• WordPress administrator access (high capability required to modify protection).
• Recent backup of the site (files and database) before any WAF policy changes.
• If you use WooCommerce: low-traffic hours to switch to blocking if necessary.

How it works (quick summary)

• Observation ("learning" mode): the WAF logs events and generates alerts without blocking. This is the recommended initial mode.
• Blocking: the WAF rejects or quarantines malicious requests according to rules.
• Rules: combination of signatures, anomalies and heuristics that trigger an action.
• Allowlists (whitelist): IP addresses, paths or signatures excluded from filtering.
• Fail-open: option that allows traffic if an external dependency (e.g. CAPTCHA service) fails, to avoid service interruption.

Recommended steps (step by step)

1. Check initial state

   • In the Securantis interface in the WordPress dashboard, open the "Firewall" section or the corresponding page.
   • Confirm that the WAF is enabled and note whether it is in observation or blocking mode.

2. Run 7 to 14 days of observation

   • Enable (or keep) observation mode.
   • During this period, monitor event logs and alerts to spot false positives (legitimate blockers such as indexing robots, webhooks, third‑party integrations).
   • Export or note IP addresses and recurring patterns regularly.

3. Build cautious allowlists

   • For each legitimate service being blocked (email delivery platform, CRM integrations, APIs, known indexing robots), add an entry to the allowlist.
   • Prefer precise entries (CIDR for IPs, path patterns) rather than global allowlists.
   • Document each addition: reason, duration and owner.

4. Refine rules before blocking

   • Fix rules that are too broad identified during observation (e.g. rules that block legitimate POSTs on API endpoints).
   • If possible, test changes on a preproduction environment or outside peak hours.

5. Gradual move to blocking

   • Enable blocking for non‑critical categories first (e.g. comment spam). Monitor logs intensively.
   • Gradually extend to more sensitive categories (injection attempts, access to admin interfaces).
   • Keep a log of blocks and mitigation actions taken.

6. Configure fail-open carefully

   • If you use protections relying on external services (e.g. CAPTCHA), enable fail-open if continuity of service is a priority. This will allow traffic to pass if the provider fails, but increases the risk of unfiltered events.
   • For sensitive interfaces (login page, checkout), avoid fail-open unless you have other protections (2FA, access monitoring).

Prudent settings and recommendations

• Do not perform mass blocking from the start: a progressive ramp-up reduces interruptions.
• Favor specific rules over global rules.
• Limit the scope of allowlists (time‑limited, identified owner).
• For WooCommerce stores, test any change outside peak periods (promotions, sales).
• Keep full logging for at least 30 days to analyze incidents.

Common mistakes and how to handle them

• False positives on forms or webhooks: identify the pattern (URL, user‑agent, IP) and create a targeted allowlist.
• Blocking third‑party APIs: add the IP addresses/CIDR ranges or sign requests between servers.
• CAPTCHA blocked or unavailable: if fail-open is disabled, users may be blocked; enable fail-open temporarily during troubleshooting if continuity is the priority.
• Intermittent blocks after a plugin update: retest in observation mode and renew the baseline if needed.

Step-by-step troubleshooting

1. Identify the symptom: pages unavailable, forms not submitted, 403 errors.
2. Check WAF logs for the time and IP involved.
3. Reproduce the action from a browser with developer tools to capture the exact request (method, headers, payload).
4. If the rule seems excessive, switch the rule to observation or add a targeted exception rule.
5. For CAPTCHA: verify communication with the provider (API call logs). If the external API returns an error, decide between fixing the integration, switching providers, or temporarily enabling fail-open.
6. For frequent issues with legitimate IPs: add an allowlist entry (CIDR), then monitor.

Precautions and compliance

• Never request passwords via email or chat.
• Any invasive operation (restoring quarantined files, automated deletion) must have explicit authorization and a prior backup.
• Access for paid interventions is provided via the secure client area after payment.

When to contact Securantis support

Contact support if:

• You observe unexpected mass blocking during the transition to blocking.
• You identify a potential bypass behavior affecting security (e.g. rules being circumvented).
• You need help defining complex signatures or analyzing a critical incident.
• You cannot restore admin or payment access after enabling blocking.

Prepare the following when requesting assistance:

• Precise description of the problem, time and concerned URL.
• Example of a blocked request (headers and payload if possible).
• Screenshots of WAF logs and actions already taken.

Expected outcome after configuration

• A documented observation period leading to a progressive blocking policy with few false positives.
• Playbooks for allowlisting and escalation written for rapid response.
• Active monitoring and procedures to enable/disable fail-open according to context (e.g. CAPTCHA provider incident).

Final remarks

Security is a balance between strict protection and availability. Observation mode followed by progressive blocking allows you to calibrate the WAF without interrupting legitimate users. Keep backups and an audit trail of every rule or allowlist change. If in doubt, request Securantis assistance before applying global settings on a production site.