Firewall

What is it?

The Firewall is a built-in protection system that watches the traffic hitting your site, recognises the signs of scanning, brute-forcing, and other automated abuse, and automatically blocks the addresses responsible. It runs entirely inside your admin panel — there is nothing separate to install — and works alongside whatever other security measures you already have in place, such as a host-level firewall or a CDN.

What it does

Rather than inspecting every request as it happens, the firewall works from the request logs your site already keeps. On a schedule (once a minute, by default) it reviews recent traffic, scores anything suspicious, and — once an address crosses the threshold you've set — blocks it. Once an address is blocked, every further request from it is stopped immediately, before your site does any real work, and the visitor sees a blocked-access page instead.

• Rate limits — catches floods, brute-force attempts, and address-sweeping, based purely on how much traffic one address is sending.
• Automated attacks — catches obvious, unsubtle attackers: known scanning tools, requests with no browser identity, probes for common vulnerable paths (WordPress admin pages, .env files, and similar), and attack payloads sitting in the request itself.
• Endpoint attacks — catches the more careful attacker: requests that are perfectly well-formed but point at something that isn't theirs (someone else's account, file, or resource), reported by the site's own code as it processes the request.

How it works

The firewall operates in two separate steps that run at different times.

Every single request to your site passes through a very fast check: is this visitor's address currently on the block list? If the firewall is switched on and enforcing, and the address is listed, the request is stopped immediately with a blocked response — nothing else about the request is looked at. If the address isn't listed, the request proceeds completely normally, at essentially no added cost.

Separately, on a repeating schedule, the firewall's scanner reads through recent rows in your site's request logs and looks for evidence of abuse using the three detection engines above. Anything it finds is scored; scores are added up (or trigger immediately, if severe enough) until an address earns a block. That address is then added to the block list, and the fast check above starts catching it from its next request onward.

Every detection carries a score from 0 to 9, shown next to it in Hits. An address is blocked the moment either: a single detection reaches the score you've set as the minimum to block (7, by default), or its detections add up, within a time window you set, past a separate accumulated threat threshold. This is what lets the firewall treat five wrong login attempts in a few minutes as an attack, without treating any single wrong password as one.

Detection engines

Rate limits

Pure traffic-volume rules — the content of a request doesn't matter here, only how much of it there is. These catch floods, credential-stuffing, and the broad address-sweeping phase of automated probing, none of which look wrong one request at a time.

• Maximum requests per address per minute, per 10 minutes, and per 60 minutes — each set independently.
• Maximum "dead-end" requests per address — requests to pages or actions that don't exist or aren't allowed, which is almost all a wordlist-style attack produces. An ignore list keeps ordinary, harmless misses (like favicon.ico) out of this count.
• Maximum number of distinct site features (endpoints) one address can touch in a 10-minute window. A real visitor uses a handful; touching dozens is someone systematically mapping the site.

Automated attacks

The unsubtle attacker: tools and requests that announce what they are, and requests aimed at things that only exist on a different kind of site.

• Known scanning and attack tools that identify themselves in the request (things like sqlmap, nikto, or a bare curl script) — an editable list of patterns.
• Requests sent with no browser identity at all.
• Requests for paths only an attacker would ask for on a BOF site — WordPress admin pages, .env or .git files, phpMyAdmin, and similar.
• Attack payload structures (SQL injection, cross-site scripting, path traversal, command injection) found anywhere in the request — the URL, submitted form data, cookies, or headers.
• An optional, much more aggressive switch that treats every crawler as suspicious.

The blocked-agent list and the empty-user-agent check only apply to ordinary page requests. Your site's separate API traffic records device details instead of a browser identity, so these two checks can't run against it.

Endpoint attacks

Some attacks never look wrong in the traffic itself — the session is valid, the request is correctly formed, every value is exactly the right shape. The only thing wrong with it is that it's pointed at something that isn't the requester's: someone else's account, resource, or file. Only the code handling that specific action can recognise this, so throughout the site, that code reports it the moment it happens — a failed login, an attempt to edit someone else's item, a tampered price, and dozens of similar situations.

Each kind of report carries a fixed severity, shown to you as a read-only reference table on this settings tab — it isn't editable, on purpose, so a single setting can't quietly turn off the most valuable checks. A severe report can block an address on its own; smaller ones accumulate the same way as everything else.

The block itself

Once an address is blocked, it stays blocked for as long as you've configured — or permanently, if you prefer — until an admin removes it. Every request that address makes while blocked is stopped immediately and shown a blocked-access page; app/API clients get a clean error response instead of a web page.

• Whitelisted addresses are completely exempt — never blocked, and they never even generate a record.
• An address with a currently active admin login session is never blocked automatically. A block you add by hand is the one exception — you can block anyone on purpose, including yourself.
• Your own primary admin account's traffic is never scanned, so ordinary use of the site can't trigger a block against you.

Configuration / setup

All configuration lives in your admin panel, under the Firewall entry in the settings menu, which links to Statistics, Setting, Hits, Blocks, and PRO.

Scheduling the scanner

Detection depends on a scheduled job actually running — without one, the firewall won't record or block anything on its own (you can still trigger a one-off scan by hand; see Manual actions below). Point your server's scheduler at this, running every minute:

* * * * * php /path/to/site/app/admin/cronjob.php solojob=fw_scan

Giving the firewall its own dedicated entry, rather than folding it into a general scheduled job, keeps it running every minute even if something else your site does on a schedule takes a long time. If you already have a general scheduled job, exclude the firewall from it so the two don't run it twice:

php /path/to/site/app/admin/cronjob.php ignore=fw_

Recommended workflow

Admin panel pages

Manual actions

• Run scan now — runs the scanner immediately instead of waiting for the schedule. Useful right after changing a setting.
• Reset hits — permanently deletes every row in Hits.
• Reset blocks — permanently deletes every row in Blocks, including ones you added by hand, along with the turned-away request log.
• Unblock — removes a single address's block by typing its IP, if you'd rather not find it in the Blocks list.
• Add a block by hand — from the Blocks page, block any address directly, with your own reason and an optional expiry. A block added this way never expires automatically unless you set one, and is never removed or overwritten by an automatic or PRO block.

Alerts

The firewall writes everything down, but nobody reads a log until after the incident. Alerts turn the numbers the scanner already has into an actual notification, delivered through your admin panel's existing Admin Notifications system — the same place every other admin event is configured, with its own Email, Telegram, and WhatsApp switches per event.

• Attack detected — more blocks or threats were recorded in your alert window than the threshold you set. This is the "you're under attack" alert, and it works even in log-only mode, using recorded threats instead of blocks.
• Severe threat — a single finding scored at or above a severity you choose. Worth hearing about even if it's the only one all week.
• PRO sync failed — the shared-intelligence exchange with Busyowl stopped working.

Firewall PRO

The firewall itself is free and always will be. PRO is an optional shared-intelligence layer on top of it: every installation that turns it on reports the addresses it has blocked, Busyowl merges those reports with addresses it has identified independently from other sources, and hands the combined list back — so an address caught anywhere on the network is already blocked on your site before it arrives. The exchange runs hourly once switched on, and can also be triggered immediately from the PRO page. Addresses received this way are added with the reason "PRO" and never overwrite a block you made yourself.

Important limitations

• Detection is retrospective, not real-time content filtering: it works from the request logs on a schedule, so an attacker's very first requests happen before the scanner has had a chance to review them.
• Ongoing protection depends entirely on the scheduled job being installed correctly — without it, nothing is scanned or blocked automatically.
• The whitelist and Blocks list only accept single IPv4 or IPv6 addresses — address ranges (CIDR) aren't supported.
• The blocked user-agent list, the empty-user-agent check, and "block all bots" only apply to ordinary page requests, not to your site's separate API traffic.
• "Block all bots" also blocks every legitimate search-engine crawler, which will remove your site from search results.
• The severity scores behind the Endpoint attacks engine are fixed in code and can't be edited from the admin panel — only the block and accumulation thresholds around them can.
• An address with a currently active admin session is never blocked automatically; this exemption doesn't apply to a block you add by hand.
• Reset hits and Reset blocks remove every matching row, with no way to undo it, including anything added by hand.

Troubleshooting