How protection works

WardPane does not put a separate firewall or a web application firewall in front of your sites. The web server that answers on ports 80 and 443 is WardPane itself, so every protection rule runs inside it, before a single line of PHP or Node.js code is started. A request from a blocked bot does not reach your application at all, so it costs no database connection and does not appear in the application’s logs.

All protection settings are per site. You find them in the site’s settings, on the Advanced tab: DDoS protection, Bot Fight Mode, Geo-blocking, Allowed devices, Required URL parameters, Password protection, Hotlink protection and Security headers. The panel-wide parts (the global list of blocked IPs, the crawler IP ranges, the public blocklists and the IP lookups) are under Advanced > Security in the main menu.

The order of checks

Every request to a site goes through the same steps. The first step that refuses the request ends it, and the later steps do not run.

1. Let’s Encrypt challenges. Requests under /.well-known/acme-challenge/ are answered first, so certificate issuance works whatever the protection settings are.
2. Cloudflare. If the site is marked Behind Cloudflare, the real visitor IP is taken from CF-Connecting-IP (only when the connection really comes from a Cloudflare address). With “Allow traffic only through Cloudflare” on, a request that did not come through Cloudflare gets a 404 here.
3. Request protection, in this order:
   1. the global blocklist (applies to every site, even with all protection off);
   2. the site’s allow list: a listed address skips everything below up to the device filter;
   3. active bans: a banned visitor gets a 404 straight away;
   4. the rate limit (DDoS protection);
   5. Bot Fight Mode: the public IP feeds, the honeypot path, request methods, attack payloads in the URL, User-Agent rules (your own list, crawler verification by IP, crawler IP ranges, bot categories, the strict browser check), and finally probes for files like /.env or /wp-login.php.
4. Geo-blocking: the browser language, hosting and cloud networks, your AS numbers, then countries and groups of countries.
5. Allowed devices.
6. Security headers are added to the response, then hotlink protection is checked.
7. Required URL parameters (“Link only”).
8. Password protection (HTTP Basic).
9. The generated robots.txt, the HTTP to HTTPS redirect, the site’s .htaccess rules (if turned on, see .htaccess) and finally the handler: static files, PHP or Node.js.

Scan detection works from the response side instead: it counts the 404 answers the site gives to each visitor and bans one that collects too many.

The password check comes after the filters, so bots and blocked visitors do not get the password prompt at all and cannot make the server spend CPU on checking passwords.

What a blocked visitor gets

By default every refusal looks the same: a plain 404 Not Found, sent with Cache-Control: no-store. A scanner cannot tell such a 404 from a missing page, so it learns nothing about the block and has no reason to try harder.

Bot Fight Mode, Geo-blocking, Allowed devices and Required URL parameters can each show your own page instead, with status 404, 403 or 200, if you prefer. See Block pages. Visitors who hit the rate limit or are banned always get the cheap plain 404, and the connection is closed.

Bans only for clear attacks

A ban is a temporary block of one visitor on one site. WardPane bans only when the request leaves no doubt:

• the visitor went over the rate limit (if the ban time is not 0);
• it asked for a path only a vulnerability scanner asks for (and that file does not exist on your site);
• it sent an unmistakable attack in the URL, such as <script>, ${jndi: or ../../../;
• it used the name of a known crawler (Googlebot, GPTBot, …) from an address that crawler’s operator does not own;
• it requested the honeypot path;
• it requested many missing paths in a short time (scanning).

Anything that only looks odd, for example a search for {{7*7}} or a link with ?next=../page, is refused for that one request, without a ban. A person who typed something unusual can carry on browsing.

Bans and counters are kept in memory and cleared when the panel restarts. For a permanent block, use the global blocklist.

IPv6 visitors are counted per /64

An IPv4 visitor is counted and banned by its address. An IPv6 visitor is counted and banned by its /64 network: a home or mobile subscriber usually gets a whole /64 and could otherwise get around a ban by switching to another address in it. The list of banned visitors shows such entries as 2001:db8:1:2::/64.

What protection cannot do

WardPane protects against floods from a limited number of addresses, scanners, scrapers and automated attacks. It cannot protect against a volumetric DDoS attack: hundreds of megabits per second, or a large botnet, fill your server’s network link before any software on the server sees a request. Against that, only your hosting provider or a CDN in front of the server helps, for example Cloudflare.

Filters that look at headers (User-Agent, browser language, device) are easy to fool, because a client can send any header it likes. They keep out ordinary bots and casual visitors you do not want, but a determined attacker will get past them.

Statistics and the log

At the top of the Advanced tab the site shows what its protection has blocked since the panel started: requests over the rate limit, bots, vulnerability probes, geo-blocking, required URL parameters, path scanning, blocklisted addresses, requests from banned visitors, and how many visitors are banned right now. From there you can show the list of banned IPs (with the reason and the end time of each ban) and lift all bans of the site with Unban all.

The activity log gets a summary per site, for example “blocked 240 requests in the last 1h (bots 200, vulnerability probes 40), 3 IP(s) banned”. A site’s summary is written at most once an hour, so that routine bot traffic does not push everything else out of the log. It comes sooner when someone was banned or 200 or more requests were blocked.

Presets

Protection presets are planned for 2.3 (see the roadmap). These are ready sets of settings ranging from no protection to strict, plus one for a landing page that should open only from your ad links. In 2.0 new sites start with safe defaults, and you adjust each check on the site’s Advanced tab.

Simple and Expert mode

Simple and Expert modes are planned for 2.3. In 2.0 the panel shows every option described in these pages; the detailed settings (thresholds, ban times, block pages, payload rules) are on the site’s Advanced tab. See Simple and Expert mode.