Geo & IP Access Control

Restrict who can reach your instance by country and by IP address. Every rule is checked on your own instance against an offline country database that ships with the product; no outside lookup service is called.

What It Does

Configure everything from Security & Compliance → Threat Defense → Configure. Pick a country policy, choose countries from the picker, and add specific IPs or ranges. Set the page to Dry-run first to watch what would be blocked before you switch to Enforce. Saving a change to the rules asks you to confirm your identity first, with your password or a passkey.

Two safeguards stop a bad rule from locking you out. Country rules never apply to the sign-in, MFA and single sign-on paths or to the access-control settings themselves, so an admin in a blocked country can still sign in and fix the rule. And an allowlist with no countries in it is treated as a mistake and blocks nobody. IP blocks are stricter: they do cover the sign-in page, and are lifted only for an already signed-in admin reaching the settings, re-authentication and session-refresh paths needed to undo them.

Auto-Block Engine

The auto-block engine bans addresses that behave like an attack. It has its own switch on the Configure tab, separate from the Off / Dry-run / Enforce banner, and it is off and in dry-run by default: it cannot block anyone until you turn it on and set its mode to Enforce. A ban is written into the IP blocklist marked AUTO with the time left, and lifts on its own when the ban time runs out (6 hours by default). Addresses on the Exclude list are never banned. Switching the engine off, or back to dry-run, stops existing bans from being enforced.

It has five detectors: credential stuffing, auth-endpoint flood, sensitive-path scan, unknown-geo probe, distributed attack. Each detector can be switched off and its threshold and window changed under Detection patterns. All five are on by default once the engine is on. The same list shows an SSH brute-force row; that one is enforced on the server itself, not by this engine.

If something here is not working as you expect, start with When something goes wrong.

The screen is at /dashboard/threat-defense.

Evaluation Order & Safety

The gateway middleware evaluates rules in a fixed precedence and caches them for 60 seconds. The address a rule is matched against is the one the network edge reports, falling back to the peer on the connection; the exact order is under How The Client Address Is Determined. Private/internal IPs are always exempt. If the offline country database fails to load, country and unknown-location rules stop being enforced, and the Threat Defense page says so with a “Country blocking is inert” banner. The IP blocklist, the Exclude list and auto-block do not depend on that database and keep working. Separately, an unexpected error inside the filter lets the request through rather than taking the gateway down.

The rules are read with GET /api/v1/auth/settings/security/access-control (manage_security) and written with POST to the same path, which needs manage_security and a fresh step-up. A missing or expired step-up is refused with "error": "SUDO_REQUIRED" in the response body. The status beside it is 400 on most routes, because the gateway turns a 401 from a service behind it into 400. It stays 401 on the routes the gateway passes through unchanged: removing a passkey, the diagnostics bundle, and in Security Lab starting an aggressive scan, changing a scan scope and archiving findings. Key on the error string, not the status. On this route the status is 400. A personal API token cannot perform a step-up, so it cannot change these rules.

Auto-Block Detectors And Defaults