Attacks that never reach your site

Open the log of almost any website for a night and most of what you find was never meant for that site at all: requests for wp-login.php on a site that has never run WordPress, for phpmyadmin, for .env and .git, for a thousand URLs that do not exist, from a thousand addresses that each ask once. None of it is aimed at you, and all of it costs something — on an ordinary shared server every one of those requests wakes up PHP just to render a "not found" page, until there are no PHP processes left and the real visitors get a "too many connections" error instead of your site.

On a BOA server that traffic is dealt with at the front door, in the web server itself, before PHP or the database hear a word. This page is what happens there, so you know what you are already getting, what you will see in your own logs, and what remains yours to decide.

Refused at the door

A request that matches one of these shapes is answered by closing the connection without a byte served (your access log shows it as status 444) and it never reaches your site:

• Probes for other systems' admin pages — WordPress, Joomla and phpMyAdmin paths that cannot exist on a Drupal or Backdrop site. The match is on the exact path segment, so a page of yours called /wp-content-strategy or /site-administrator is not caught.
• Secret-file fishing — requests for .env, .git, .aws, .ssh, config.json, settings.py and their cousins.
• Injection payloads — SQL injection, script injection and path-traversal patterns in the query string or the browser name, matched narrowly so that encoded content in a legitimate parameter does not trip them.
• Known scrapers and download tools, the mass-harvesting bad bots, plus requests wearing a forged identity — see AI crawlers for the AI classes and the opt-out tokens no real crawler ever sends.
• Recognisable flood shapes — self-mutating URLs that pile Drupal asset paths onto content paths, the cold-fetch and print floods that scraped-link botnets run, and a few more that only ever appear in attacks.

Where a request is probably harmless but never worth a full page render (a PHP file that does not exist, say), it gets a plain static 404 instead — still without touching PHP.

Caught by behaviour

The door handles what can be recognised per request. Everything else is judged by what an address does: a scorer reads the recent access log several times a minute and scores each real visitor address on its behaviour — errors and refusals, probes for PHP files that are not there, attempts on the login page, injection fingerprints. An address that crosses the line is blocked at the firewall for fifteen minutes on the web ports; one that keeps coming back is blocked persistently. Fleets are caught in aggregate too — many addresses sharing one forged browser name and collecting mostly errors, or many addresses hammering one expensive page — so the "one request per address" trick does not work here.

Three properties of this matter to you:

• It judges behaviour, not declarations. A bot that drops its name and looks like a browser is still scored on what it does.
• Legitimate crawlers are exempt. The search engines' own published address ranges are whitelisted, precisely so an anti-abuse rule can never eat your site out of the search results. A false block on genuine traffic is the one bug your host treats as worse than the abuse it was meant to stop.
• It acts after the fact, on purpose. A burst that finishes inside a few seconds is served cheaply and its source banned for the next visit. The door above is what keeps the burst itself cheap.

What keeps the site standing during a swarm

Some floods cannot be classified at all: hundreds of addresses, a request or two each, an ordinary browser name, every answer a normal page. For those, each site has a ceiling on how many uncached page renders it may hold at once for anonymous visitors; the excess is refused, the renders that are running finish quickly, and the front cache keeps serving everyone else. Logged-in editors and admins are never counted, so you keep working while a flood is being trimmed. Above that sit the server's own load controls, which shed declared crawlers first and ease the web stack off before the box falls over — see I'm blocked, or my site is slow for what that looks like from your side.

What you will see

Mostly nothing, which is the point: refused requests get no page, no error message and no byte of yours. In your own site's access log they appear as 444 (connection closed) or as static 404s that never reached Drupal or Backdrop; in the watchdog log of the site itself they do not appear at all, because they never ran it. There is no third-party bot-defence service in this chain and nothing to sign up for; the rules ship with the platform, run on the same server that serves your site, and are tuned as part of its ordinary updates. A site parked behind Cloudflare is protected the same way, because the server recovers the real visitor address from the edge and judges the visitor rather than the middleman.

What stays yours to decide

• Which AI bots may read each site — one small policy file per site.
• Who may reach a site at all, or its login and admin pages — Site IP lock and Login/admin IP lock.
• Load tests — a benchmark fired from one address looks exactly like an attack and is treated as one; read Load testing before you run one, and tell your host first.
• A genuine request that got caught — that is a conversation with your host, the same as any other server-level control; the checks you can do yourself before writing in are on the blocked or slow page.

What this does not cover

Abuse that happens inside your site — comment spam, a compromised editor account, a form being filled by a bot that behaves like a person — is your site's own business, and Drupal's and Backdrop's usual tools apply. Network floods aimed at the connection itself rather than at pages are the firewall's and the network's job (the server carries SYN-flood protection of its own; the details are on the operator side). And a rule that catches nothing new today may be added tomorrow: the maps and weights change with the traffic the whole fleet sees, which is why this page describes classes rather than lists.

For the curious

The operator's view of all of this — every map, weight, threshold and the ban pipeline — is in the Abuse Guard chapter, with the request-by-request rules on Request guards and the per-site policy layer on Edge policy.