Web Application Firewall

CorePanel includes a web application firewall that inspects every HTTP request before it reaches a site. Attacks are stopped at the web server, so nothing reaches PHP, the database or a vulnerable plugin.

The engine is pxShield, and the panel’s WAF section is where you see what it is catching and decide how strict it should be.

Rule families

Rules are grouped into families, each of which can be set to a mode:

Family	Covers	Availability
BASE	Protocol integrity and catastrophic attack classes: null bytes, path traversal, CRLF injection, .sql file probing	Every edition — always blocking, never detect-only
SQLI	SQL and MS-SQL injection in GET and POST	Every edition
XSS	Cross-site scripting in GET, POST, User-Agent and headers	Every edition
WPE	WordPress Extended: login brute force, XML-RPC amplification, user enumeration, config/backup exposure, traversal, malicious uploads, comment spam	Pro and above

Modes

Mode	Behaviour
Block	Matching requests are refused
Detect	Matches are logged, the request goes through
Off	The family is not evaluated at all

The commercial model runs along that axis: Personal detects, Pro blocks. In the free Personal edition the managed families (SQLI, XSS) log attacks so you can see exactly what your server is being hit with; Pro turns the same detections into blocks.

The catastrophic class always blocks, in every edition

BASE is not part of that ladder. Path traversal, null-byte injection and CRLF injection are blocked on every server, including Personal, and cannot be set to detect-only. A free edition that let those through would not be a firewall.

Manage families under WAF → Overview → Protection packages. The setting is server-wide and applies to every site.

When the edition changes

The policy you configure is remembered separately from the policy the server applies, so a licence change is never a configuration loss:

• Losing Pro — because a subscription lapsed, or because the panel could not reach the licence server for longer than the grace window — lowers the managed families from block back to detect and switches WPE off. Your sites keep serving and attacks keep being logged; only the automatic blocking stops.
• Getting Pro back restores exactly the modes you had configured, with nothing to set up again.

The change is applied by the daily licence check-in, and immediately after any manual activation or deactivation.

The limit is enforced by the server, not by the panel

Blocking modes, the WPE package and per-domain rules are refused by CorePanel itself, so the API returns the same refusal the panel shows. A request that asks a Personal server for block gets an error naming the edition — it is never silently downgraded, and never quietly accepted.

Per-rule control

Rules lists every rule in the catalog with its ID, its family, its engine default and whether it is currently on. Most rules can be toggled individually — that is how you handle a rule that misfires on one application without disabling a whole family.

Some rules ship off by default and are opt-in, because they trade a higher false positive rate for extra coverage. Examples: XSS-001/XSS-002 (XSS in GET/POST), WPE-003 (wp-login POST without a Referer), WPE-021 (exposed database dumps), WPE-023 (installer lockout).

The protocol-integrity floor cannot be turned off

STD-004 through STD-008 — null bytes, path traversal and the CRLF injection rules — are fixed. The panel refuses to write an override for them, at any level. If one of these is firing on legitimate traffic, that traffic is malformed and the fix belongs in the application.

In Pro and above, rules can also be tuned per domain: a rule turned off for one site while every other site keeps it. Personal edits the server-wide layer, which every domain inherits.

Per-domain overrides are not removed when a server drops back to Personal: an override usually exists because a rule was breaking a working site, and deleting it during a billing event would break that site again. They stay in place, and you can still delete them on any edition — what Personal cannot do is add a new one.

The attack radar

The Overview is a live picture of what is hitting the server:

• attacks over time, so a spike is visible at a glance;
• the top attacking IP addresses;
• the most-triggered rules;
• a breakdown by domain, so you can see which site is the target.

This is also the fastest way to size a problem: one IP hammering wp-login is a different situation from a distributed scan across every domain you host.

The event log

Event log is the detailed record: timestamp, client IP, domain, request, rule that matched, and whether it was blocked or only detected. Opening an event shows the full request context that triggered it.

Two things it is for:

1. Confirming an attack was stopped — the answer to “were we affected?”.
2. Diagnosing a false positive — when a customer says “the panel of my site says 403”, the event log is where you see which rule fired and on which URL, which is exactly what you need to write an exception.

Trusted IPs and exceptions

Two escape hatches, documented in Tuning the WAF:

• Trusted IPs — addresses that skip rule inspection entirely.
• Exceptions — skip specific rules on a specific URL prefix, optionally narrowed by method and client IP.

Reach for an exception before a rule toggle, and for a rule toggle before turning off a family. The narrower the change, the less protection you lose.

If the WAF is unavailable

When the engine’s control socket cannot be reached, the security views degrade rather than failing the page: statistics and the event log are unavailable while the sites themselves keep being served. It is a monitoring outage, not a hosting one — but it does mean you are flying blind until it is back.