What are firewall modes?
SeenSecure's firewall has three operating modes that determine how it reacts to incoming traffic: what it detects, what it blocks, and what it merely logs. You can switch between them at any time from the Mode tab in the Firewall & WAF panel, and the change applies instantly across the whole site, with no cache to clear or anything to restart.
These three modes are independent from the master SeenSecure Protection Status switch (on the Summary tab of the Firewall & WAF panel, right below the stat cards). That switch is a fourth position, but it is not "a gentler mode than Monitoring" — it is the complete shutdown of the firewall, explained in detail at the end of the next section.
The 3 operating modes
🔍 Monitoring
Detects and logs threats without blocking anything. All traffic passes through without restrictions. Ideal for the first hours after installation.
🛡️ Protection
Detects and blocks real threats (SQL, XSS, LFI). Optimal balance between security and usability. Recommended for production sites.
🔒 Strict
Maximum security with strict validations. Blocks even suspicious traffic. May cause false positives. Only for high-risk sites.
| Mode | Detects | Blocks | False Positives | Recommended Use |
|---|---|---|---|---|
| Monitoring | ✅ | ❌ | None | Testing / Observation |
| Protection | ✅ | ✅ | Low | Production |
| Strict | ✅ | ✅ | ⚠️ High | High-risk sites |
🔍 Monitoring in detail
What it does: it runs every detection engine in the firewall — SQL injection, XSS, file inclusion, bot patterns, and so on — against every incoming request, exactly like Protection or Strict do. The only difference is that when it spots something suspicious, it never acts on it: no block, no challenge, it just writes the event to the Traffic Log and the Incidents panel. The visitor never knows they were analyzed.
When to use it: during the first 24-48 hours after installing the plugin; after a major site change (new theme, new payment gateway, hosting migration); or when you suspect a specific rule is generating false positives and want to confirm it without risking blocking real traffic while you investigate.
Risk: the danger is not the mode itself, but forgetting it is on. A production site left permanently in Monitoring shows activity on the dashboard — it looks like "something is happening" — but no real attack is actually being stopped.
🛡️ Protection in detail
What it does: it enables real blocking. When a request matches a high-confidence threat pattern (SQL injection, XSS, remote or local file inclusion, and equivalent categories), SeenSecure responds with HTTP 403 and stops the request before it ever reaches WordPress. Ambiguous traffic, which doesn't meet the attack criteria with enough certainty, is let through to minimize false positives.
When to use it: it's the recommended default mode for any production site with real traffic, every day of the year. It offers effective protection without the friction of frequent false positives.
Risk: low if you already validated the site in Monitoring, but a major change (new theme, a new plugin with unusual forms) can introduce patterns Protection hasn't seen before. Review the Traffic Log after any significant change.
O'Brien's "Deluxe" Kit with legitimate single and double quotes. Protection recognizes it as normal text and lets it through. On the other hand, it immediately blocks a POST request to /wp-login.php carrying a payload like ' OR '1'='1, typical of an authentication-bypass attempt — the malicious visitor gets a 403 and the attempt is logged in the Traffic Log.
🔒 Strict in detail
What it does: it applies the same detection categories as Protection, but with a much lower tolerance for ambiguity. Where Protection lets dubious traffic through "in case it's legitimate", Strict blocks it "in case it's an attack". It is a change in posture, not a different detection engine: it prioritizes not letting anything suspicious through over not inconveniencing any legitimate visitor.
When to use it: during a confirmed active attack (a wave of login attempts, aggressive vulnerability scanning from multiple IPs), on very high-value sites (payments, health or legal data) where the cost of letting a real attack through is much higher than blocking a legitimate visitor, or temporarily after detecting a campaign targeting your domain specifically.
Risk: it is the mode most likely to block legitimate traffic. An unconventional plugin, a theme with heavily parameterized URLs, or even a user with an unusual browser extension can trigger a block that wouldn't have happened in Protection. It is not recommended as a permanent setting without testing it first.
wp-login.php from dozens of different IPs. You switch to Strict for the duration of the attack — the borderline requests that Protection would have let through "just in case they were legitimate" are now also blocked, closing the gap the attackers were exploiting. Once the attack subsides, you review the Traffic Log, confirm no real customers were affected, and switch back to Protection.
⏻ The Off switch (complete shutdown)
Off is not a fourth, "gentler" mode than Monitoring — it is the complete shutdown of the firewall via the SeenSecure Protection Status switch, on the Summary tab. With the firewall off, SeenSecure doesn't even run threat analysis on the request: nothing is detected, nothing is logged to Incidents, and no individual protection (Geo-Blocking, Anti-Bot, ASN rules, payment gateway bypass) acts, even if it's configured as "Block" on its own tab. Rate Limiting is a separate module and may keep logging traffic independently, but the rest of the firewall is completely inactive.
Which mode should you choose?
🆕 You just installed the plugin
Use Monitoring for at least 24-48 hours. Check the logs in the Incidents panel to see what threats the firewall detects.
🌐 Production site with real traffic
Protection mode is your best choice. It offers the ideal balance between security and user experience.
🎯 Site under active attack
Switch directly to Strict. It blocks even suspicious traffic, not just confirmed malicious traffic. Return to Protection once the attack subsides.
💳 High-value site (payments, health, legal data)
If your site processes payments, medical records, or sensitive legal data, the cost of a single successful attack far outweighs the cost of an occasional false positive. In these cases, some administrators opt for Strict permanently on the most critical paths (login, checkout) and only Protection on the rest of the site, but this requires thorough testing in Protection first and a clear process for managing whitelists as false positives appear.
Practical tips
- Monitoring → Protection: If after 48 hours in Monitoring you see no false positives, switch to Protection with confidence.
- Protection → Strict: Only if your site receives frequent attacks or handles critical data.
- Revert changes: If a mode causes issues, switch to another immediately. Changes are instant.
- Before enabling Strict, whitelist yourself: if you're going to test Strict on a site with sensitive data, add your own IP to the firewall whitelist first. That way you avoid locking yourself out of your own dashboard if Strict blocks something related to your admin session.
- Check the Traffic Log after every mode change: filter by
Status = 403during the first hours after switching to Protection or Strict to quickly spot if any legitimate traffic started getting blocked.