Protecting your site — Cheat Sheet

Your sites come protected out of the box — nothing to set up. This page is the quick primer: what the server already refuses for you, the locks you can add yourself, which AI bots may read each site, and how to load-test without testing the shield instead. Everything here links to the full story.

The protections in 30 seconds

1. Attacks are refused at the door — probes for other systems' admin pages, .env and .git fishing, injection payloads, known scrapers and flood shapes are closed before Drupal or Backdrop runs, so they never show up in your site's own watchdog log. → Attacks that never reach your site
2. Offenders are judged by what they do — an address that crosses the line is blocked at the firewall for 15 minutes on the web ports, or persistently if it keeps coming back; the search engines' published ranges are whitelisted. → Caught by behaviour
3. Admin pages are guarded — an anonymous visitor asking for /admin is bounced to the homepage, and an /admin request with no session cookie at all gets a 403. → Access control
4. AI training crawlers are turned away by default — AI search and assistant fetches stay open and gently rate-limited, so your site stays visible to AI tools without the bulk harvesting. → AI crawlers
5. The locks are yours — one plain text file restricts a whole site to your addresses, another just its login and admin pages. → Site IP lock

Already on: what never reaches your site

Nothing to set. Requests that match known attack shapes get a closed connection (logged as 444) before any PHP runs, and a probably harmless request that is never worth a render, like a PHP file that doesn't exist, gets a plain 404. The probe match is on exact path segments, so a page of yours called /wp-content-strategy is not caught.

During a swarm each site has a ceiling on simultaneous uncached renders for anonymous visitors; logged-in editors are never counted, so you keep working. A site behind Cloudflare is protected the same way. What this doesn't cover is abuse inside the site itself — comment spam, a compromised editor account — which Drupal's and Backdrop's own tools handle.

→ Attacks that never reach your site · your own address got blocked?

Lock a whole site to your own addresses

The single most useful move for a staging site. Create ~/static/control/ip/access.txt (create the ip folder if it isn't there), one line per site: its main name, then the allowed addresses — IPv4 or IPv6, single or CIDR:

# ~/static/control/ip/access.txt
staging.example.com    198.51.100.42 2001:db8:1::1

Everyone else gets a 403 Forbidden, over HTTP and HTTPS alike, within about two minutes — nothing to run, no Verify. The loopback, the server's own address and any address connected over SSH right now are always let in. To lift a lock, delete the site's line; deleting the whole file lifts nothing.

→ Site IP lock · opening the site back up

Lock only the login and admin pages

Same format, different file: ~/static/control/ip/user_admin.txt guards /user and /admin (and the pages under them) while the rest of the site stays public. It matches those paths only as they start: the language-prefixed forms a multilingual site also answers on, such as /de/user, stay open. On a Grav 2 site it guards /admin and the whole /api route (add the keyword api-open to keep a public headless API open); on a Textpattern site it guards /txpadmin.

# ~/static/control/ip/user_admin.txt
example.com    203.0.113.10 203.0.113.0/24

Both files take effect within about two minutes, carry the same safety nets, and work on their own or together.

→ Login/admin IP lock · Grav and Textpattern

Choose which AI bots may read each site

The defaults are already in force on every site: training crawlers are blocked, search and assistant bots are allowed and rate-limited, the evasive assistant is blocked, utility bots are allowed. To change them for one site, add a line to ~/static/control/ai/policy.txt (create the folder if needed) — the site's name, then any of five flags: train-allow, evasive-allow, search-block, user-block, utility-block:

# ~/static/control/ai/policy.txt
news.example.com    train-allow
shop.example.com    search-block user-block utility-block

It's picked up within about two minutes; delete the site's line to go back to the defaults. The web server enforces this on every request, whatever your robots.txt says.

→ AI crawlers and assistants · the flags

The admin-page bounce, and when to switch it off

On by default: an anonymous visitor asking for anything under /admin (or /logout, /privatemsg, /approve) goes back to the homepage instead of reaching Drupal. The one reason to switch it off is a stale session cookie that keeps bouncing you although you're logged in. One line in the site's INI file does it:

; sites/example.com/modules/boa_site_control.ini
disable_admin_dos_protection = TRUE

That removes only the bounce: an /admin request with no session cookie at all still gets a 403. Delete the line once the browser problem is sorted.

→ The admin-page protection · INI control files cheat sheet

Load testing that measures your site, not the shield

A load test fired from one address measures the DoS protection, not your site: it's blocked almost at once, and there's no per-site opt-out. For "will it survive launch day?" use a professional service that sends realistic traffic from many addresses, tell your host first (the date, the site, the service's address ranges), and point it at the production name — never a .dev. alias, where caching is effectively off.

→ Load testing your site

The files and switches most people touch

The two INI files carry four more access switches (one of them platform-only), each documented in the two INI files.

If something's weird

• You deleted access.txt and the lock is still on → deleting the whole file lifts nothing; remove the site's line, or leave the file empty. Opening the site back up.
• You listed your control panel's domain and now can't reach the panel → your address is missing from the list. Log in over SSH or SFTP (the address you connect from is let in within about two minutes), then fix the line. Setting it up.
• Search Console reports crawl errors on /user → the bot guard refuses those requests; add Disallow: /user to a copy of your live robots.txt and upload it as sites/<your-domain>/files/<your-domain>.robots.txt, which BOA never overwrites (a plain files/robots.txt is replaced within a week). Search engines and your login pages.

Going deeper

• The whole topic, in depth: Protecting your site — the built-in protections, both IP locks, the AI policy, load testing, and what the server refuses for you.
• Server-level blocks (a country ban, one abusive address across all sites) are a support request: When it's not something you can set.
• Related sheets: When something's wrong (a blocked address) · INI control files (the edit routine).
• The machinery (for operators): Abuse Guard · Edge policy · AI crawler policy · Site IP access.