Attack Protection | SeenSecure Help

🛡️ Multi-Layer Defense Architecture

"Attack Protection" is not a single three-layer module: it is the combination of all defense modules working together in successive layers. Each layer covers the failures of the previous one. None protects alone; together they form real defense in depth.

Layer	What it blocks	Documentation
1. Early Shield (PRO)	Unusual HTTP methods, null bytes, oversized URLs, exploit patterns (path traversal) and sensitive-file access — before WordPress even loads	Early Shield
2. Firewall WAF	Fuzzing, parameter pollution, redirect injection, WAF signatures (3 modes)	Firewall · Modes
3. Anti-Bot (5 layers)	Automated bots, scrapers, headless browsers, fake crawlers, spoofed IPs	Anti-Bot
4. Anti-Injection	SQLi, XSS, LFI/RFI, Command Injection, Deserialization, XXE, LDAP, SSRF, Open Redirect in URLs, forms, cookies and headers	Anti-Injection Shield
5. Redirect Sanitization	Token leakage, API keys and sensitive data in redirect URLs	Sanitization
6. Referer Context	Basic CSRF, critical POSTs without legitimate origin, bots without Referer	RCP
7. Rate Limiting	Brute force, intensive scraping, excessive requests per IP	Rate Limiting
8. Geo-Blocking	Traffic from high-risk countries and geolocated automated flows	Geo-Blocking
9. Upload Protection	PHP shells, executables, fake MIME, double extension, null byte	Uploads
10. Security Headers	Reflected XSS, clickjacking, MIME sniffing, MITM, CSP, SRI	Headers
11. DDoS Resilience	Request saturation and application-level emergency mode	DDoS Resilience
12. Hardening	User enumeration, directory listing, file exposure, APIs	Hardening
13. Protection Network	IPs confirmed by multiple sites (collaborative feed, PRO only)	Network · Threat Intel
14. Login Security + 2FA	Login brute force, CAPTCHA, restricted accounts, second factor	Login · 2FA
15. Scanner + Backups	Malware, vulnerabilities, file integrity and emergency restore	Scanner · Backups

💡 How to read this table: You don't need to enable everything at once. Start with the Firewall in Monitor mode, review logs for 24-48h and gradually move up to Protect. Layers 4, 5 and 6 (anti-injection, sanitization and Referer) are what this page documents in detail.

🔀 Redirect URL Sanitization

Automatically cleans redirect URL parameters to remove sensitive data such as emails, API keys, authentication tokens, passwords, and other confidential information before the user is redirected.

🎯 What it protects

Information Disclosure: Prevents sensitive data from appearing in URLs, logs, Referer headers, or browser history.

Token Leakage: Removes API keys, auth tokens, and secrets before redirecting.

Email Harvesting: Removes email addresses exposed in URL parameters.

🧹 Data it removes

▪ Emails:    user@example.com, admin@site.com
▪ API Keys:  ?api_key=abc123, &apikey=xyz789
▪ Tokens:    ?token=secret123, &auth=bearer_token
▪ Passwords: ?password=mypass, &secret=confidential

⚡ Recommended setting: Keep it ENABLED. It is an extra security layer with no impact on functionality. It only cleans URLs when redirecting, without affecting normal parameter processing.

🛡️ Anti-Injection Shield (SQL/XSS/LFI/Commands/XXE/SSRF)

Detects and blocks injection attempts in URLs, forms, cookies, and HTTP headers. Acts as a safety net that stops attacks even if some plugin or theme has vulnerabilities. Covers 9 attack classes: SQL Injection, XSS, LFI/RFI, Command Injection, PHP Deserialization, XXE, LDAP Injection, SSRF, and Open Redirect.

Attack types it blocks

SQL Injection

Attempts to read, modify, or delete database data (users, posts, configuration) using special characters like ', --, or UNION in parameters.

XSS

Injects malicious scripts into pages to steal sessions, cookies, or redirect users. Detects <script> tags, onerror, onload events, and javascript: schemes.

LFI / RFI

Attempts to load local (/etc/passwd) or remote files to execute malicious code. Detects patterns like ../, file://, php://filter, and absolute system paths.

Command Injection

Attempts to run commands on the server's own operating system (not the database) through a parameter, combining special characters (backticks, semicolons, &&, pipes |) with a known command. Example: ?id=1; cat /etc/passwd or ?file=photo.jpg`whoami`.

Deserialización PHP

Sends a hand-crafted "serialized" PHP object in a parameter, trying to manipulate the site's internal logic when it gets reconstructed (can sometimes lead to code execution). Recognizable by a very distinctive format like O:8:"stdClass":1:{...}.

XXE

Sends an XML document with an "external entity" that tries to make the server read internal files (like /etc/passwd) or contact another server. Recognizable by a <!DOCTYPE> with an <!ENTITY> pointing to file:// or another scheme. Example: <!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>.

LDAP Injection

Manipulates an LDAP search filter (used by corporate authentication systems) by adding parentheses and operators to bypass validation or extract directory data. Example: *)(uid=*))(|(uid=*.

SSRF

Tries to make the SERVER ITSELF issue an outbound request to an internal or forbidden destination (localhost, the internal network, or the cloud metadata endpoint), usually by passing a URL as a parameter value. Example: ?url=http://169.254.169.254/latest/meta-data/ or ?image=http://127.0.0.1:6379/.

Open Redirect

Manipulates a redirect parameter (like ?redirect_to=) so that, after a legitimate action (e.g. login), the user ends up on an external site controlled by the attacker — mainly used in phishing campaigns. Example: ?redirect_to=https://malicious-site.com or ?next=//evil.com.

🔍 Where it acts

Inspects traffic at three key points:

URLs and GET/POST parameters: Searches, forms, filters, pages.

Cookies: Especially sessions manipulated with malicious payloads.

HTTP Headers: User-Agent, Referer, and others with injection payloads.

⚙️ Configuration options

Action

Off: detects and logs the same as Monitor, but never blocks (the "Enabled" switch above is what turns detection itself on or off).
Challenge: blocks with a 403 + logs the IP for 2h.
Block: blocks with a 403 + logs the IP for 2h.
Block request only: serves a one-off 403 but does NOT log the IP in "Blocked IPs" — useful while testing the protection or for legitimate traffic behind shared NAT/proxies.
Monitor: only logs, never blocks.

Sensitivity

Low: Only very clear patterns. Minimal false positives.
Medium (recommended): Balance between detection and false positives.
High: Maximum detection. May generate false positives.

Allowlists

Paths: URLs that are not inspected (e.g., /wp-json/, /admin-ajax.php).
Parameters: Parameter names to ignore (e.g., s, paged, rest_route).

💡 Recommendation: Start with Challenge + Medium. If there are false positives, lower the sensitivity or add the exact path to the allowlist. DO NOT add attack payloads to the allowlist.

⚠️ Important if you turn it off: if you switch off this Shield's "Enabled" toggle, SQLi/XSS/LFI/command injection stop being blocked — unless you have the Security Headers toggle enabled (Firewall → Headers), which acts as a fallback engine for those same attacks. If both toggles are off at the same time, those attempts are only logged, not blocked. The panel warns you with a red message on this same tab when it detects that situation.

Referer Context Protection (RCP)

Validates the origin of HTTP requests using the Referer header. If a critical POST request (login, form submission) lacks a Referer or comes from an unauthorized external domain, it is blocked. It is a lightweight and fast layer that works before the request reaches PHP.

✅ Advantages

🚀 Lightweight and fast: only validates HTTP headers, zero performance impact

🤖 Stops automated bots that rarely send a valid Referer

🛡️ Detects basic CSRF: cross-site requests without a legitimate Referer

🔒 Protects wp-admin against direct access from external domains

⚠️ Considerations

🔍 False positives: browsers/extensions may block the Referer for privacy

🔌 APIs/webhooks must be added to exceptions (e.g., /api/*, /webhook/*)

⚖️ Not 100% security: the Referer can be spoofed, but it stops basic attacks

📋 Recommended implementation

"Log" mode for 24-48h — Identify false positives without blocking anyone.
Review logs and add exceptions — Add /wp-json/*, your APIs, webhooks.
Switch to "Challenge" — Once exceptions are confirmed, enable blocking.
Only use "Block" if 100% sure — No margin for false positives.

💡 Tip: RCP works best combined with the other protections. Use it alongside the Anti-Injection Shield and Redirect Sanitization for defense in depth.

🌐 Protection Network (Feeds)

In addition to the local layers, SeenSecure has its Protection Network: the collaborative component that shares blocks among all PRO clients. When your site blocks an attack, it can report it anonymously to the central service; the server cross-checks reports from all sites and publishes a feed with IPs confirmed by at least two different sites. Your WordPress consumes that feed and blocks in advance IPs that have not yet attacked your site but have already been detected by the community.

🔁 Flow

Your site blocks an attack and reports it anonymously.
The server scores the IP and publishes it if ≥2 sites confirm it.
All PRO clients receive the IP in the feed and block it in advance.

🔒 Privacy

Only evidence of an already executed block is shared. Visitors are not tracked and no personal data is sent; the site's domain is never published in the feed. The feed travels encrypted and IPs are distributed hashed with a daily rotating key plus per-site watermarks (leak detection).

📄 Full documentation

Complete guide to the Protection Network (how to report, consume the feed, GDPR consent, troubleshooting) at Protection Network. Third-party lists (AbuseIPDB, AlienVault, Spamhaus) are explained at Threat Intelligence.

⚠️ Requirement: The Network feed is only delivered to PRO licenses (or trial) with active reporting and explicit administrator consent (Art. 6.1.a GDPR). Without a PRO license, your site remains protected by all the local layers on this page.

🏗️ Architecture

The defense is organized into five levels, each with several layers:

1️⃣ Network Level

IP filtering, geo-blocking, allow/block lists, Protection Network feed and Threat Intelligence.

2️⃣ Application Level

WAF rules, anti-injection, redirect sanitization, Referer Context, rate limiting and anti-bot.

3️⃣ File System Level

Upload protection, integrity monitoring, malware detection and critical file protection.

4️⃣ User Level

Login security (brute force, CAPTCHA), 2FA and restricted account management.

5️⃣ Data Level

Database security, backups and emergency restore.

💡 Before PHP: The Early Shield, Referer Context and early rate limiting capture layers run BEFORE WordPress loads (at file level), so that even an attack that saturates PHP loading cannot disable them.

⚡ Performance

The attack layers are designed to have minimal impact:

✅ No noticeable cost

Redirect sanitization and Referer Context only inspect headers/strings: microseconds, zero extra database queries.

✅ Caching and in-memory lists

The Network blocklist is cached in memory (at most one option read per request), and WAF signatures are compiled only once.

✅ Asynchronous processing

Network reports are queued and sent in batches (cron), never during the visitor's request.

🔧 Troubleshooting

🚫 It blocks me / a user

1) Check Monitoring → Traffic for the exact reason (anti_injection, referer_context, rate_limiting…).
2) If Referer: add the path or domain to exceptions.
3) If anti-injection: lower sensitivity or add the parameter/path to the allowlist.
4) Add your IP to the allowlist (IP Lists) while tuning.
5) Use Emergency Mode only if you lose total access.

🔌 My API/webhook fails

Add the path to Referer Context exceptions (/api/*, /webhook/*) and to the anti-injection allowlists. Payments (WooCommerce, PayPal, Stripe) are protected by default without breaking checkout.

❌ The Network feed says 0 / won't sync

1) Confirm active PRO license and reporting enabled with consent.
2) Press "Sync" in the Protection Network tab.
3) IPs only appear once the server publishes them (≥2 sites). Your own report appears as "own IP" (counts as blocked by your site even before publication).
4) Check the ssc_log log if fetching fails.

⚠️ Golden rule: Before disabling a protection, open its tab, look at the latest blocks and adjust the configuration (sensitivity, allowlists, exceptions). Disabling all protection "because it's annoying" is exactly what an attacker hopes for.

⭐ Best Practices

Raise the mode gradually: Monitor → Challenge → Block. Never jump straight to Block in production without reviewing logs.
Keep the "frictionless" layers on: redirect sanitization, anti-injection in Challenge, security headers and basic anti-bot.
Use allowlists, not disablement: if something legitimate gets blocked, add it to the allowlist. Disabling a layer makes it useless for real attacks too.
Enable the Protection Network (PRO): report and consume the collaborative feed: the more sites contribute, the faster and more accurate the blocklist is for everyone.
Review the dashboard weekly: layer badges, recent blocks and Network reports tell you if something needs tuning.
Combine with hardening and 2FA: defense in depth is completed with site hardening and a second factor on all admins.

🎯 Bottom line: With all layers active and the Protection Network connected, your WordPress stops attacks your site has never seen, without relying on a single line of defense.