Site Access by IP

What this solution does

The module restricts access to the site, administrative sections, or specific pages based on the visitor's IP address. It supports white and black lists, IPv4 and IPv6 protocols, as well as rules for CIDR ranges and specific address ranges. Features include filtering by user groups, access control, access logging, and protection against accidental self-blocking.

Validation occurs at the very beginning of request processing, before page generation, saving server resources by rejecting unsuitable visitors immediately. Rules are flexible: you can specify an address or subnet, an action (allow or deny), priority, site binding, path masks, validity period, and user group restrictions. The first matching rule with the lowest priority is decisive, so allow rules act as exceptions to broader deny rules.

Login validation is configured separately: the site remains open to all visitors, but employees can only authenticate from an allowed network. Access denial is displayed directly in the login form, not as an error on a subsequent page.

The blocked visitor's page settings allow full control over displayed content, including HTTP status, text, colors, font, logo, and additional CSS. A preview mode lets administrators view the block page without actually restricting access for any visitors.

The module is designed to prevent administrators from accidentally locking themselves out of their own site.

Key features

Access rules

The module supports multiple address formats: single IP addresses, CIDR subnets (e.g., 10.0.0.0/8), ranges specified with a hyphen (192.168.0.10-192.168.0.50), wildcard patterns (192.168.0.*), and an asterisk to match any address.

Full support is provided for both IPv4 and IPv6. Addresses in the format ::ffff:192.168.0.1 are automatically mapped to IPv4, allowing a single mask to cover both representations.

Rule priority is determined by their order in the list: allow rules take precedence over deny rules.

Each rule can be bound to a specific site, restricted by path patterns, and assigned an active time period.

Access can be limited for specific user groups or excluded from the rule's scope.

Each rule displays a trigger counter and the date of the last activation, making it easy to identify active rules versus those that are no longer in use.

Bulk entry is supported: a list of addresses can be pasted into a single field, with a separate rule created for each address using shared settings.

Rules can be exported to a CSV file, respecting any currently applied filters.

Modes and control zone

Module for managing site access by IP address. It supports three modes: disabled, black list (specified addresses are blocked), and white list (only specified addresses are allowed). The control zone can be configured for the entire site, the administrative section only, or an arbitrary list of paths. An exception list, checked before the control zone, includes payment handlers, webhooks, and service addresses.

User verification settings include an 'authenticated users only' mode: anonymous visitors, search bots, payment systems, and delivery services pass without checking. A list of exceptions by ID is provided for service accounts used in integrations (1C, MySklad, order exchange). A separate option allows preventing the blocking of authenticated administrators.

The login check mode operates independently from the main mode: the site is open to everyone, but login is permitted only from trusted networks. The same access rules apply, with groups determined by the user entering the login. The denial message text can be customized directly in the login form.

Upon blocking access, an HTTP status can be selected: 403, 404, 401, or 503. Status 503 signals to search engines that the closure is temporary, preventing pages from being dropped from the index. Alternatively, users can be redirected to a specified page.

The module provides site access control based on IP addresses. A 403 error page styled to match your template is generated with a single click.

Customize the block page appearance: title, text, visitor IP display, link button, selection of six colors, font, alignment, block width and border radius, shadow, logo upload, and additional CSS. Text messages support placeholders #IP# and #DATE#. A preview of the block page opens in a new tab. For full control, you can insert your own complete HTML code.

The access log records the date, IP address, check result, triggered rule, requested page, request method, User-Agent, and user. Filters are available by address, result, page, and time period. Repeated requests from the same IP are merged into a single record with an incremented attempt counter, preventing table bloat during scanning. Automatic log cleanup based on storage depth is performed by a background agent once daily. You can navigate from the log to create a rule for a specific address.

When operating behind a proxy or load balancer, the module determines the real client IP via X-Forwarded-For, X-Real-IP, and Client-IP headers. These headers are accepted only from trusted subnets, which are configured separately. If no trusted subnet list is defined, headers are ignored to prevent IP spoofing via a single request.

Individual pages can be protected using a dedicated component.

The Site Access by IP module is added to a page via the visual editor. It allows defining a custom rule list, specific IP addresses, and the action to take upon denial. This enables content managers to restrict access to a landing page without needing access to the module's settings.

Diagnostics

The built-in checker lets you select an address, path, and user group to see the decision based on active rules without actually blocking anything. The rule list and settings always display your current IP address and warn if active rules would block it.

Self-Blocking Protection

The primary risk for modules of this class is enabling a whitelist and losing access to the admin panel. Four independent mechanisms prevent this.

1. The module is installed in a disabled state. Installation does not block access; the mode is enabled manually after verifying the rules.

2. Bypass key. An arbitrary string is set in the configuration. Opening any page with this key in the URL sets a cookie and removes the restriction for the browser for a specified duration. The key is immediately removed from the address bar to prevent it from being saved in browser history or the Referer header.

3. The option to not block administrators is enabled by default.

Emergency shutdown. Adding a single line to the /bitrix/php_interface/dbconn.php file completely disables the module, even if settings are incorrect.

The interface continuously displays the current IP address and the decision made for it. This information is visible in the rules list and in settings before the mode is activated.

Admin panel interfaces:

Section «Services → Site Access by IP».

Section «Settings → Product Settings → Module Settings → Site Access by IP».

General iT can connect “Site Access by IP”, install and configure the module, and make sure the integration works correctly.