PanelicaDocs
panelica.com
Docs / Security / ModSecurity WAF

ModSecurity WAF

Panelica 1.0.375 Verified 2026-07-24 Security

ModSecurity is the Web Application Firewall (WAF) that inspects every HTTP request before it reaches a site and blocks attacks: SQL injection, cross-site scripting, remote code execution, file inclusion, scanner probes and more. It runs in Apache using the OWASP Core Rule Set. This page is where you watch what it blocks and tune it when it gets in the way.

Panel locationSecurity → ModSecurityhttps://YOUR-SERVER-IP:8443/security/modsecurity
 ModSecurity WAF
CRS Rules
Active
OWASP 3.3.2
Total Blocked
1,284
WAF Status
Per Domain
blocked 203.0.113.9 · SQLi · rule 942100 · /wp-login.php

How WAF protection works here

The key thing to understand: the WAF is turned on and off per domain, not globally. Each domain has its own WAF setting in its editor, so you can protect one site and leave another (that a rule keeps tripping) in detection-only mode. This global page does the server-wide parts: it shows the blocked-request log across all domains, manages a global whitelist and custom rules, and sets rate limiting. The OWASP CRS itself is always active; there is no server-wide off switch, because turning protection off is a per-domain decision.

The security log

The Security Logs tab is the heart of the page: every request the WAF blocked or flagged, with the source IP (and its country), method, URL, the action taken (blocked or logged), the rule that fired, its severity, and an anomaly score. Search and filter by IP, URL, attack type, rule or severity, and expand any row for the full detail including the raw event. This is where you diagnose both real attacks and false positives.

Behind the scenes: the log is read live from each domain's own ModSecurity audit log, deduplicated and sorted, so what you see is the real, current record rather than a database copy. The WAF also raises admin notifications when blocked-attack volume spikes, so a sustained attack does not go unnoticed.

Fixing false positives

Sometimes a legitimate request looks like an attack (a page editor posting HTML, an API sending SQL-like text). Panelica gives you two ways to make an exception, both server-wide:

  • Whitelist: exempt a trusted IP or range, URL, User-Agent, or parameter from the WAF. This is the blunt, safe tool: whitelist your office IP or a specific admin URL and the WAF stops inspecting it.
  • Custom Rules: for surgical control, write your own ModSecurity rule (for example, disable one specific rule ID on one path) rather than exempting an entire request.
Behind the scenes, a real safety net: whenever you save a whitelist entry or a custom rule, Panelica writes the config and then runs Apache's own apachectl -t syntax test. If your rule is malformed, the change is rolled back to the previous config and rejected with an error, so a bad rule can never take Apache down. Whitelist and custom rules live in dedicated ID ranges so they never collide with the CRS.
Diagnosing a false positive, step by step: when a legitimate action is blocked, open Security Logs, find the entry (filter by the URL or the user's IP), and note the rule ID that fired. Then either whitelist the specific IP/URL if it is trusted, or write a custom rule that disables just that rule ID on just that path. Reach for the domain's detection-only mode only as a last resort, since it lowers protection for the whole site.

Rate limiting

The Configuration tab sets a request rate limit (requests per IP within a time window) enforced by the WAF, which throttles a single IP hammering your sites. A "clear all counters" action resets the tracked counts (releasing currently-throttled IPs) when you need a clean slate.

Access

Behind the modsecurity license feature and, at the backend, ROOT and ADMIN (see roles and permissions). Per-domain WAF enablement lives in each domain's Security tab; this page is the server-wide cockpit.

Panelica Documentation · Written and verified against the live panel. · Last verified 2026-07-24 on Panelica 1.0.375