Restricting access to your site

Sometimes you don't want the whole internet looking at a site. Maybe it's an intranet for your team, a staging copy you're still working on, or an admin-only area you'd rather nobody stumbles into. This page covers three things you can set up yourself, from your own files, with no support ticket needed: keeping the admin pages quiet against bots, locking a whole site down to just your own IP addresses, and locking only the login/admin area to your own IPs while the rest of the site stays public. All are safe to turn on and easy to undo, and none can accidentally lock you out.

Everything here you do from your own account — either by editing a small text file over SFTP, or with nano in your shell. You never touch the server itself.

Which one do you want

It helps to know which of these you actually want before you start, because they protect different things:

  • Admin-page protection — a setting that's already on by default for every site. It quietly bounces anonymous bots away from your /admin pages so they can't hammer your login. Most people never need to think about it — but occasionally it gets in the way, and then you'll want to know how to switch it off. This one is a line in your site's INI file.
  • Whole-site IP lock — an opt-in you set up when you want a site reachable only from a short list of IP addresses (yours, your office, your team). Everyone else gets a plain "403 Forbidden". This one is a line in a control file.
  • Login/admin-only IP lock — an opt-in like the whole-site lock, but scoped to just the /user and /admin pages: the public site stays open to everyone, while only your listed addresses can reach the login and admin area. Ideal for a public site where you still want the back office reachable only from your own connections. Also a line in a control file.

Pick whichever matches what you're trying to do. They're independent — you can use any, all, or none.

The admin-page protection (and how to opt out)

By default, when someone who isn't logged in asks for one of your admin-ish URLs — anything starting with /admin, plus /logout, /privatemsg, and /approve — the platform sends them straight back to your homepage instead of letting the request reach Drupal.

Why it does this: those pages are never cached, so every hit lands directly on Drupal. Bots love to pound the login page, and this stops them cheaply, before they get anywhere. It costs you nothing and you didn't have to set it up. For nearly every site, leave it exactly as it is.

There's just one situation where you'd want it off. Every so often it can catch a real person: if your own browser is holding an expired session or a stale cookie, you might click something under /admin and find yourself bounced to the homepage even though you thought you were logged in. If that keeps happening and clearing your cookies doesn't settle it, you can turn the protection off for that one site.

Turning it off

You do this with a single line in your site's INI file. That file lives at:

sites/<your-domain>/modules/boa_site_control.ini

Open it over SFTP (create it if it isn't there yet), and add:

disable_admin_dos_protection = TRUE

Save, and you're done. There's nothing to click and nothing to run — the change is picked up on its own, usually within about a minute. (The full details of how to find and edit these INI files, and why the short wait, live on the INI settings page — this is just the one setting you need.)

Turning it back on

Either delete that line, or set it back to the default:

disable_admin_dos_protection = FALSE

Same short wait, and the protection is active again. Because the default is "on", even just removing the line restores it — you can't leave your admin pages exposed by forgetting to tidy up.

Careful with this one. Switching it off removes only the homepage bounce. It does not fling your admin pages wide open: there's a second, separate guard at the web-server layer that always refuses a /admin request from a client carrying no session cookie at all (a plain "403 Forbidden") and blocks known bots outright — and that guard stays on no matter what you set here. So turning the setting off mainly lets a stale-cookie browser (which is the case you're fixing) reach /admin, where Drupal's own "Access denied" then takes over. It's still a small extra bit of exposure, so only turn it off if you actually have the browser-session problem above, and turn it back on once you've sorted it out.

Locking a whole site to your own IP addresses

This is the stronger control. Instead of protecting just the admin pages, it makes an entire site reachable only from IP addresses you list. Everyone else — every page, not just the admin area — gets a "403 Forbidden". It's exactly what you want for a private intranet, a staging site you're not ready to show, or an admin-only tool.

You set this up in a control file inside your own account:

static/control/ip/access.txt

On a typical account that's ~/static/control/ip/access.txt in your shell (the folder may not exist yet — just create it). Add one line per site: the site's name, then a space, then the IP addresses you want to let in, separated by spaces:

# static/control/ip/access.txt

intranet.example.com   203.0.113.10 203.0.113.0/24 2001:db8::/32
staging.example.com    198.51.100.42 2001:db8:1::1

A few things worth knowing as you fill this in:

  • Use each visitor's real public address — the one a site like https://ifconfig.co shows them, not a home/office LAN address like 192.168.x.x.
  • You can list IPv4 or IPv6 addresses, and either single addresses or whole ranges in CIDR notation (203.0.113.0/24, 2001:db8::/32), separated by spaces.
  • The lock covers the whole site, not just certain paths.
  • Lines starting with #, and blank lines, are ignored — so you can leave yourself notes.
  • If your sites sit behind Cloudflare, this still works on the visitor's real address — the platform recovers it for you — so enter the real client IP just the same.

You don't run anything or click Verify. The change is noticed on its own and takes effect within about two minutes.

You can't lock yourself out

This is the part that makes it safe to try. On top of whatever IPs you list, three addresses are always allowed, automatically, so a typo can never strand you or the site:

  • the loopback address (127.0.0.1),
  • the server's own address, and
  • any address currently connected over SSH — which includes you, right now, if you're working in your shell.

You never have to add those yourself, and you can't accidentally leave them out. Worst case, if you fat-finger an address and lock out the people you meant to let in, you fix the line and it corrects itself within a couple of minutes.

Opening the site back up

To lift the restriction, just delete that site's line from access.txt and save. On the next pass (again, within about two minutes) the site is open to everyone again. To remove all restrictions, empty the file or delete its lines. There's no separate "undo" step — removing the line is the undo.

Locking just the login and admin area to your own IPs

Sometimes you want the public site open to everyone, but the login and admin pages (/user and /admin) reachable only from your own connections — to keep bots and strangers away from the back office without hiding the site itself. That's this control. It works exactly like the whole-site lock above, but it only guards /user and /admin (and the pages under them); everything else stays public. Anyone else who opens /user or /admin gets a plain "403 Forbidden".

Edit (or create) this file in the instance that hosts the site:

# static/control/ip/user_admin.txt

intranet.example.com   203.0.113.10 203.0.113.0/24 2001:db8::/32
staging.example.com    198.51.100.42 2001:db8:1::1

One line per site — the site name, then the addresses allowed to reach /user and /admin. As with the whole-site lock you can list IPv4 or IPv6 addresses, single or as CIDR ranges, separated by spaces; use each visitor's real public address. # comments and blank lines are ignored.

The same safety nets apply: changes take effect within about two minutes, your own address (loopback, the server, and anything you're logged in from over SSH) is always allowed so you can't lock yourself out of the admin area, and deleting a site's line lifts the restriction. You can use this together with the whole-site lock or on its own.

When it's not something you can set

The controls above are entirely yours — you own the files, so you own the change. But some access questions live at a level below your account, on the server itself: a firewall block, a country-level ban, blocking a specific abusive IP across all sites on the box, or anything that isn't one of your own sites. Those aren't things you can reach from your account. If you need one of them, open a support request with your host — that's who has the access to do it.

Related pages

  • INI settings — how to find and edit your boa_site_control.ini file, and the rest of the per-site settings you can change.
  • Which file do I edit? — a quick guide to the site vs. platform files, if you're not sure which one you're looking at.
  • Shell and SFTP access — how to connect so you can edit these files in the first place.
  • Managing your sites — the day-to-day site tasks in your control panel.
  • HTTPS for your sites — a private site should still be served over HTTPS.