Безопасная авторизация в WordPress: 2FA, SSO, reCAPTCHA и защита от брутфорса Введение: почему форма входа – постоянная мишень ботов WordPress работает примерно на 43% всех сайтов интернета, и это...

Безопасная авторизация в WordPress: 2FA, SSO, reCAPTCHA и защита от брутфорса

Введение: почему форма входа – постоянная мишень ботов

WordPress работает примерно на 43% всех сайтов интернета, и это делает его форму входа объектом постоянного автоматизированного обстрела. Ботнеты круглосуточно перебирают пароли к /wp-login.php и xmlrpc.php, а по данным отчёта Verizon DBIR около 60% взломов связаны с использованием скомпрометированных учётных данных. Атакующему не нужен эксплойт под вашу тему – достаточно подобрать пароль к логину admin.

Отдельный крупный вектор – уязвимости в плагинах и темах (по отчётам Wordfence, это причина №1 взломов WordPress в целом), но он закрывается регулярными обновлениями, а не настройкой входа. Эта статья – про то, что обновления не закрывают: кражу и перебор учётных данных.

Цена вопроса для бизнеса конкретная: простой сайта на часы или дни, утечка персональных данных клиентов (со всеми последствиями по 152-ФЗ и GDPR), попадание в чёрные списки поисковиков из-за размещённого дорвея и репутационный ущерб, который дороже любого технического восстановления.

Ключевой принцип статьи – defense in depth, многоуровневая защита. Ни один плагин не закрывает проблему wordpress authentication security целиком: плагин 2FA не спасает от нагрузки брутфорса на PHP, а смена URL входа не помогает, если пароль qwerty123. Нужна связка мер «от периметра к ядру»:

Периметр – смена URL входа и ограничение доступа на уровне веб-сервера.
Лимиты – блокировка после N неудачных попыток, отключение XML-RPC.
2FA – второй фактор через TOTP.
SSO – единый вход команды через корпоративный OAuth-провайдер.
reCAPTCHA v3 – невидимая фильтрация ботов.
Гигиена ядра – пароли, роли, сессии, настройки wp-config.php.

Схема многоуровневой защиты входа в WordPress: шесть уровней от периметра до гигиены ядра

Дальше – пошаговое внедрение каждого уровня с готовыми сниппетами и чек-листом проверки в конце.

Как атакуют страницу входа WordPress: модель угроз

Прежде чем строить защиту, нужно понимать, от чего именно защищаемся.

Брутфорс и credential stuffing. Классический перебор по словарям – и более опасный credential stuffing, когда боты прогоняют базы утёкших паролей (миллиарды пар «логин:пароль» из старых утечек) в надежде, что кто-то переиспользовал пароль. Атаки распределённые: запросы идут с тысяч IP с ротацией, поэтому простая блокировка по IP после первой же ошибки малоэффективна.

Перебор логинов. Половина успеха атакующего – узнать логин. WordPress сам облегчает задачу: логин admin до сих пор встречается на огромном числе сайтов, а переход по адресу /?author=1 редиректит на страницу автора и раскрывает его логин в URL. Дальше остаётся подобрать только пароль.

XML-RPC как скрытый вектор. Файл xmlrpc.php – legacy-интерфейс удалённого доступа. Метод system.multicall позволяет проверить сотни паролей одним HTTP-запросом, обходя плагины лимита попыток, которые считают запросы, а не попытки аутентификации внутри них. Если вы не используете мобильное приложение WordPress или Jetpack – XML-RPC вам не нужен.

Сканеры стандартных адресов. Автоматизированные сканеры в первую очередь стучатся в /wp-admin и /wp-login.php. Смена URL входа отсекает этот шум и разгружает логи, но важно понимать: это мера против ботов, а не против целевой атаки. Она снижает поверхность, но не заменяет реальную защиту.

Уровень 1. Периметр: смена URL входа и ограничение доступа на сервере

Смена адреса входа

Самый простой способ – плагин WPS Hide Login: он меняет /wp-login.php на произвольный адрес вида /my-secure-entry/ и отдаёт 404 на стандартный URL. По нашим наблюдениям, после смены адреса количество попыток входа в логах падает на 85–95%: массовые боты просто не находят форму.

Правила безопасной смены URL:

Выбирайте нетривиальный адрес (/enter-2024 – плохо, /portal-x7kq – хорошо).
Зафиксируйте новый URL в корпоративной вики и менеджере паролей до активации.
Не полагайтесь на это как на единственную меру – целевой атакующий найдёт форму через редиректы и REST API.

Ограничение доступа к wp-login.php по IP (nginx)

Если у команды статические IP (офис, VPN), самый надёжный вариант – закрыть доступ к странице входа на уровне веб-сервера. Запросы блокируются до запуска PHP, что снимает нагрузку даже при массовом брутфорсе.

nginx

# /etc/nginx/sites-available/example.com

# Rate limiting: не более 1 запроса в секунду с одного IP
limit_req_zone $binary_remote_addr zone=wp_login:10m rate=1r/s;

server {
    # ... основные настройки ...

    location = /wp-login.php {
        # Whitelist: офис и VPN
        allow 203.0.113.10;
        allow 198.51.100.0/24;
        deny all;

        # Rate limiting для разрешённых IP
        limit_req zone=wp_login burst=5 nodelay;
        limit_req_status 429;

        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    # ВАЖНО: исключение для admin-ajax.php.
    # Это стандартная точка входа для AJAX в WordPress: её используют
    # формы, корзины и фильтры для НЕавторизованных посетителей.
    # Без этого блока правило allow/deny ниже сломает фронтенд для всех,
    # кто не в whitelist. Exact match (=) обрабатывается раньше
    # префиксных location, поэтому порядок блоков не важен.
    location = /wp-admin/admin-ajax.php {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    # Модификатор ^~ обязателен: без него запросы к /wp-admin/*.php
    # попали бы в общий regex-location ~ \.php$ сервера и обошли
    # allow/deny. С ^~ regex-location'ы уровня серверного блока
    # для этого префикса не проверяются, а PHP обрабатывается
    # во вложенном location внутри защищённой зоны.
    location ^~ /wp-admin/ {
        allow 203.0.113.10;
        allow 198.51.100.0/24;
        deny all;

        location ~ \.php$ {
            include fastcgi_params;
            fastcgi_pass unix:/run/php/php8.2-fpm.sock;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        }

        try_files $uri $uri/ /index.php?$args;
    }
}

Два нюанса, которые ломают сайт, если их забыть. Во-первых, исключение для admin-ajax.php из конфига выше обязательно – иначе перестанут работать фронтенд-формы и корзины. Во-вторых, некоторые плагины форм и подписок отправляют данные через /wp-admin/admin-post.php – если у вас такие есть, добавьте для него аналогичное исключение. После правки конфига всегда проверяйте его nginx -t и только потом перезагружайте (nginx -s reload).

limit_req_zone – это защита от брутфорса, работающая даже без единого плагина: сервер начнёт отдавать 429 Too Many Requests при частых запросах к форме входа.

Вариант для Apache (.htaccess)

apache

<Files wp-login.php>
    Require ip 203.0.113.10
    Require ip 198.51.100.0/24
</Files>

Дополнительно на уровне ОС полезен fail2ban: он парсит логи веб-сервера и банит по iptables IP-адреса с повторяющимися 401/403 на wp-login.php.

Когда периметр неприменим

Whitelist по IP не работает, если команда разъезжается, работает с мобильного интернета или с динамических IP. В этом случае оставляем только rate limiting и переходим к следующим уровням – они не зависят от адреса пользователя.

Уровень 2. Лимит попыток входа и блокировка ботов

Плагин лимита попыток

Стандарт де-факто – Limit Login Attempts Reloaded (или модуль защиты от брутфорса в Wordfence). Рекомендуемые настройки:

Блокировка после 4 неудачных попыток;
Время блокировки – 20–60 минут, после 3–4 блокировок – 24 часа;
Уведомления на email администратора при серии блокировок (так вы увидите начало атаки, но не утонете в спаме).

Где считать попытки: плагин vs сервер

Важный нюанс, который часто упускают. Плагин считает попытки внутри PHP: каждый запрос бота всё равно запускает WordPress, грузит БД и CPU. При массовом брутфорсе (тысячи запросов в минуту) сайт может лечь не от взлома, а от нагрузки – получается DoS своими руками. Поэтому связка из Уровня 1 (rate limiting в nginx) и плагина лимита – не дублирование: nginx отсекает объём, плагин ловит медленный распределённый перебор, который проходит под порогом rate limiter.

Отключение XML-RPC

Если не используете Jetpack и мобильное приложение WP – отключайте полностью. Два способа: через сервер (лучше, запросы не доходят до PHP) или через фильтр.

php

<?php
// functions.php дочерней темы

// Полное отключение XML-RPC
add_filter('xmlrpc_enabled', '__return_false');

// Скрытие версии WordPress из head, RSS и скриптов
remove_action('wp_head', 'wp_generator');
add_filter('the_generator', '__return_empty_string');

Блокировка на nginx – одна строка: location = /xmlrpc.php { deny all; }

Проверка результата: GET-запрос к /xmlrpc.php даже у здорового сайта возвращает 405 (интерфейс принимает только POST), поэтому проверяйте именно POST: curl -s -d '' https://site.ru/xmlrpc.php. При блокировке на nginx вернётся 403, при отключении фильтром – ответ с сообщением «XML-RPC services are disabled on this site». Если в ответ на POST приходит XML с перечнем доступных методов – интерфейс всё ещё открыт.

Логирование неудачных входов

Убедитесь, что плагин лимита пишет журнал: IP, время, использованный логин. В логе смотрите на паттерны: перебор логинов по словарю (admin, test, administrator, домен сайта) – признак разведки; повторяющиеся попытки с одним логином и разными паролями с разных IP – credential stuffing. Алерты на email стоит настроить так, чтобы они приходили при серии блокировок, а не при каждой – иначе ящик превратится в спам и вы перестанете их читать.

Уровень 3. Двухфакторная аутентификация (2FA): TOTP как стандарт

Сегодня пароль без второго фактора для администратора – это приглашение к взлому. Даже сложный пароль утекает через фишинг, кейлоггеры и утечки сторонних сервисов, где его переиспользовали. Второй фактор делает украденный пароль бесполезным.

Выбор плагина

Плагин	Ключевая особенность	Кому подходит
WP 2FA	Принудительные политики по ролям, grace-период	Команды, где 2FA обязателен для всех
Two Factor	Плагин от core-команды WordPress	Минималистичные сайты без лишних зависимостей
Wordfence Login Security	Отдельный модуль без полного Wordfence	Те, кому нужен только 2FA без файрвола

Критичный критерий выбора – принудительная политика: возможность требовать 2FA по ролям (администраторы и редакторы – обязательно, подписчики – нет) и задавать grace-период, за который пользователь должен настроить фактор.

Настройка TOTP пошагово

TOTP (Time-based One-Time Password, RFC 6238) – это шестизначные коды, которые приложение генерирует из общего секрета и текущего времени; код меняется каждые 30 секунд и не передаётся по сети.

Настройка двухфакторной аутентификации в WordPress: сканирование QR-кода приложением-аутентификатором

Установите и активируйте плагин (например, WP 2FA).
В мастере настройки включите TOTP (коды из приложения) как основной метод и резервные коды как запасной.
Откройте приложение-аутентификатор: Google Authenticator, Яндекс.Ключ, 2FAS – любое с поддержкой TOTP.
Отсканируйте QR-код из профиля WordPress, введите код подтверждения.
Сразу сохраните резервные коды – об этом отдельный раздел ниже.
В политиках плагина включите обязательный 2FA для ролей «Администратор» и «Редактор», задайте grace-период 3–7 дней для остальных.

Отдельно проверьте время на сервере: TOTP привязан к 30-секундным окнам, и если часы сервера расходятся с реальным временем больше чем на минуту, валидные коды начнут отклоняться. Убедитесь, что включена синхронизация по NTP (timedatectl status на Linux должен показывать System clock synchronized: yes).

Почему не SMS и не email

SMS-коды уязвимы к SIM-swapping (перевыпуск симки по поддельному паспорту – реальная практика, а не теория), а email-коды – к компрометации почты, которая у большинства и так является центром восстановления всех паролей. TOTP живёт только на устройстве пользователя и не передаётся по сети. Если нужен уровень выше – аппаратные ключи FIDO2/WebAuthn, поддерживаемые частью плагинов.

Уровень 4. SSO для команды: единый вход через OAuth

Когда SSO оправдан

Если сайтом управляют 3–5 и более человек и компания уже живёт в Google Workspace или Microsoft Entra ID – SSO решает сразу несколько проблем. До этого порога связка «менеджер паролей + 2FA» проще и дешевле.

Протоколы: OAuth 2.0 / OIDC против SAML

Для WordPress практичнее OAuth 2.0 с OpenID Connect: настройка сводится к созданию приложения в консоли провайдера и вводу трёх значений (Client ID, Client Secret, discovery URL). SAML мощнее (атрибуты, группы, enterprise-интеграции), но требует в разы больше возни с сертификатами и метаданными – он оправдан, когда WordPress входит в зрелую корпоративную инфраструктуру с IdP вроде Keycloak или ADFS.

Настройка входа через Google (miniOrange OAuth Client)

Установите плагин miniOrange OAuth Client (или Nextend Social Login).
В Google Cloud Console создайте проект → «Credentials» → «OAuth client ID» типа Web.
В поле «Authorized redirect URIs» укажите callback-URL из настроек плагина (вида https://site.ru/wp-admin/admin-ajax.php?action=mo_oauth_callback – скопируйте точное значение из плагина).
Скопируйте Client ID и Client Secret в настройки плагина, укажите scope: openid email profile.
Включите опцию «связывать по email с существующими пользователями» – иначе плагин создаст дубликаты аккаунтов. Убедитесь, что email в Google-аккаунте каждого сотрудника совпадает с email его пользователя в WordPress: связывание идёт именно по этому полю.
Протестируйте вход под тестовой учёткой, не закрывая сессию администратора в другом браузере.

Маппинг ролей: принцип минимальных привилегий

Самая частая ошибка при внедрении SSO – плагин выдаёт всем вошедшим роль администратора или, наоборот, создаёт пользователей без роли. Настройте явный маппинг: по умолчанию новый пользователь получает минимальную роль (Подписчик), а повышение до Редактора делает администратор вручную. Контент-менеджеру не нужны права на установку плагинов, а SEO-специалисту – на смену темы.

Второй шаг, который почти все пропускают: после стабилизации SSO отключите обычный вход по логину и паролю для ролей, переведённых на SSO (в miniOrange есть опция принудительного SSO-входа). Иначе форма входа остаётся открытой параллельно с SSO, периметр не сужается, и весь смысл затеи теряется.

Что SSO даёт для безопасности

Централизованный offboarding: уволили сотрудника – отключили аккаунт в Google Workspace, и доступ к WordPress (и ко всему остальному) умер автоматически. Не нужно помнить, где ещё у него были пароли.
Единый журнал входов у провайдера: видно все аутентификации команды в одном месте.
Политика паролей и 2FA провайдера распространяется на WordPress автоматически – Google или Microsoft тратят на это больше ресурсов, чем любой плагин.

Уровень 5. reCAPTCHA v3: защита от ботов без раздражения пользователей

reCAPTCHA v2 с её «выберите все светофоры» убивает конверсию форм. Версия v3 работает иначе: она невидима, анализирует поведение пользователя и возвращает score от 0.0 до 1.0 (0 – точно бот, 1 – точно человек). Решение о допуске принимаете вы на сервере.

Получение ключей

Зарегистрируйте сайт в Google reCAPTCHA Admin Console, тип – reCAPTCHA v3, укажите домен. Получите Site Key (публичный, идёт в JS) и Secret Key (приватный, только на сервере).

Подключение вручную

Плагины (например, Advanced Google reCAPTCHA) закрывают задачу в пару кликов, но ручная интеграция прозрачнее и не тащит лишний код. Два фрагмента.

Клиентская часть – получение токена на странице входа:

javascript

// Подключаем API и добавляем токен в форму входа
// Site Key вставляется при выводе страницы
grecaptcha.ready(function () {
  grecaptcha.execute('SITE_KEY', { action: 'login' }).then(function (token) {
    var input = document.createElement('input');
    input.type = 'hidden';
    input.name = 'g-recaptcha-response';
    input.value = token;
    document.getElementById('loginform').appendChild(input);
  });
});

Серверная часть – проверка токена через хук wp_authenticate_user:

php

<?php
// functions.php дочерней темы

add_action('login_enqueue_scripts', function () {
    wp_enqueue_script(
        'google-recaptcha',
        'https://www.google.com/recaptcha/api.js?render=SITE_KEY',
        [],
        null,
        true
    );
});

add_filter('wp_authenticate_user', function ($user) {
    // Не ломаем вход через XML-RPC/REST, там reCAPTCHA нет –
    // они у нас уже закрыты на предыдущих уровнях
    if (defined('XMLRPC_REQUEST') || defined('REST_REQUEST')) {
        return $user;
    }

    $token = isset($_POST['g-recaptcha-response'])
        ? sanitize_text_field(wp_unslash($_POST['g-recaptcha-response']))
        : '';

    $response = wp_remote_post('https://www.google.com/recaptcha/api/siteverify', [
        'body' => [
            'secret'   => 'SECRET_KEY',
            'response' => $token,
            'remoteip' => $_SERVER['REMOTE_ADDR'] ?? '',
        ],
    ]);

    $result = json_decode(wp_remote_retrieve_body($response), true);

    // Сверяем не только success и score, но и hostname с action –
    // это рекомендация Google: так токен, выпущенный для чужого сайта
    // или другого действия, нельзя переиспользовать на нашем
    $valid = !empty($result['success'])
        && ($result['score'] ?? 0) >= 0.5
        && ($result['hostname'] ?? '') === wp_parse_url(home_url(), PHP_URL_HOST)
        && ($result['action'] ?? '') === 'login';

    if (!$valid) {
        return new WP_Error(
            'recaptcha_failed',
            'Проверка на бота не пройдена. Обновите страницу и попробуйте снова.'
        );
    }

    return $user;
}, 10, 1);

Настройка порога score

Начинайте с 0.5 – это значение по умолчанию у Google. Если легитимные пользователи жалуются на блокировки (часто это корпоративные сети с NAT и VPN, которые выглядят подозрительно) – снижайте до 0.3. Если боты продолжают проходить – поднимайте до 0.7. Логируйте score каждой попытки первую неделю: по распределению значений сразу видно, где проходит граница между людьми и ботами на вашем трафике.

И не прячьте значок reCAPTCHA через display: none: условия Google требуют информировать пользователей о её работе. Если badge мешает дизайну, Google разрешает заменить его видимой текстовой пометкой рядом с формой.

Российский контекст: альтернативы

Доступность сервисов Google из РФ нестабильна, а для части аудитории недоступна и клиентская часть reCAPTCHA. Рабочие альтернативы:

Yandex SmartCaptcha – российский сервис, аналогичная модель с проверкой на сервере, интеграция через https://smartcaptcha.yandexcloud.net/validate;
Cloudflare Turnstile – бесплатная, не требует Google, отлично работает в РФ, есть готовые плагины для WordPress.

Для сайтов с преимущественно российской аудиторией мы рекомендуем SmartCaptcha или Turnstile как основной вариант.

Дополнительные меры ядра: пароли, роли, сессии

Политика паролей

Минимум 12 символов для администраторов (плагины вроде Solid Security умеют требовать сложность принудительно).
Менеджер паролей для всей команды – это не совет из области гигиены, а способ убрать переиспользование паролей, которое делает credential stuffing успешным.
Принудительная смена пароля раз в 90 дней для администраторов; для остальных ролей – по факту инцидентов.

Запрет логина admin и скрытие авторов

Убедитесь, что ни у одного пользователя нет логина admin (создайте нового администратора, переназначьте контент, удалите старого). Затем закройте перебор логинов через ?author=N:

php

<?php
// functions.php дочерней темы

// Перебор ?author=N: ядро вешает redirect_canonical на тот же хук
// template_redirect с приоритетом 10 и регистрирует его раньше
// functions.php, поэтому без явного приоритета наш колбэк не успеет
// сработать – запрос ?author=1 уже уйдёт в 301 на /author/<логин>/.
// Приоритет 1 ставит нас первыми, и логин не раскрывается.
add_action('template_redirect', function () {
    if (is_author()) {
        wp_safe_redirect(home_url(), 301);
        exit;
    }
}, 1);

// Убираем логины из REST API для неавторизованных
add_filter('rest_endpoints', function ($endpoints) {
    if (!is_user_logged_in()) {
        unset($endpoints['/wp/v2/users']);
        unset($endpoints['/wp/v2/users/(?P<id>[\d]+)']);
    }
    return $endpoints;
});

Application Passwords и REST API

Application Passwords (встроены в WP с версии 5.6) нужны для интеграций – например, когда внешняя система публикует или забирает данные через REST API, как в нашей интеграции WordPress с российскими CRM. Если интеграций нет, отключите их фильтром add_filter('wp_is_application_passwords_available', '__return_false');. Если используются – регулярно ревизуйте список в профилях пользователей: забытый ключ старого сервиса – это постоянный обходной путь мимо 2FA.

Управление сессиями

Принудительный logout неактивных сессий (авто-logout по таймауту есть в Solid Security Pro и в отдельных плагинах вроде Inactive Logout): администратор, забывший выйти на чужом компьютере, не должен оставлять вечную сессию.
Ограничение одновременных сессий: для административных ролей разумно 2–3 устройства; обнаружение входа с двух десятков IP – сигнал компрометации.
Периодически нажимайте «Завершить все остальные сессии» в профилях – особенно после смены пароля.

Настройки wp-config.php

php

// wp-config.php

// Принудительный HTTPS для wp-admin и страницы входа
define('FORCE_SSL_ADMIN', true);

// Отключаем редактор файлов тем и плагинов из админки:
// при взломе аккаунта атакующий не сможет внедрить код через админку
define('DISALLOW_FILE_EDIT', true);

DISALLOW_FILE_EDIT – одна из самых недооценённых констант: встроенный редактор файлов – первое место, куда идёт атакующий после получения доступа к админке.

Как не заблокировать самого себя: аварийный доступ

Усиление защиты входа имеет обратную сторону: можно отрезать доступ самому себе. Превентивные меры дешевле восстановления.

Резервные коды 2FA. При настройке любого TOTP-плагина сгенерируйте резервные коды (обычно 10 одноразовых). Храните их офлайн: распечатка в сейфе или запись в менеджере паролей – не в заметках на том же телефоне, что и аутентификатор. Потерянный телефон без резервных кодов – самый частый сценарий самоблокировки.

Whitelist IP – до строгих правил. Перед включением allow/deny в nginx или жёстких лимитов в плагине убедитесь, что ваш текущий статический IP (офис, домашний, VPN-выход) внесён в whitelist. Проверьте, что IP действительно статический – позвоните провайдеру, не гадайте.

Запасной администратор. Создайте вторую учётную запись администратора со своим 2FA и сохраните её данные отдельно. Если основной аккаунт заблокирован или 2FA-плагин сломался после обновления, восстановить доступ можно через wp-cli:

bash

# Сброс пароля пользователя
wp user update admin --user_pass='НовыйСложныйПароль123!'

# Создание запасного администратора, если доступа нет совсем
wp user create reserve_admin reserve@example.com --role=administrator --user_pass='СложныйПароль456!'

# Деактивация проблемного плагина без доступа к админке
wp plugin deactivate wp-2fa

Крайняя мера – FTP. Если сайт падает после установки защитного плагина и админка недоступна: переименуйте каталог плагина в wp-content/plugins/ (например, wp-2fa → wp-2fa-off) – WordPress деактивирует его автоматически. После входа не забудьте вернуть плагин и перенастроить: отключённая защита, о которой забыли, хуже её отсутствия.

Чек-лист проверки после настройки

Пройдите по списку в инкогнито и с «чужого» устройства – не из своей авторизованной сессии.

Заключение

Итоговая схема wordpress authentication security выглядит так: периметр (смена URL, allow/deny и rate limiting на nginx) → лимиты (блокировка попыток, отключённый XML-RPC) → 2FA через TOTP → SSO для команды → reCAPTCHA v3 → гигиена ядра (пароли, роли, сессии, wp-config.php). Каждый уровень закрывает свой класс атак, и снятие любого одного не обнуляет остальные.

Итоговая схема защиты авторизации WordPress: периметр, лимиты, 2FA, SSO, reCAPTCHA и гигиена ядра

Если ресурсов мало, минимальный набор за один вечер: смена URL входа + плагин лимита попыток + обязательный 2FA для администраторов. Эти три меры закрывают подавляющее большинство автоматизированных атак и требуют пары часов без остановки сайта.

Самостоятельное внедрение разумно до тех пор, пока речь идёт о плагинах и стандартных сниппетах. Передавайте задачу специалистам, когда нужны SSO на SAML с корпоративным IdP, интеграция с SIEM, расследование уже случившегося инцидента или аудит после взлома – здесь цена ошибки выше стоимости настройки, а восстановление доверия клиентов после утечки обходится дороже любой защиты. А если параллельно развиваете сайт как канал продаж, посмотрите наш гайд по интеграции WordPress с российскими CRM – там разбираем связку с Битрикс24, amoCRM и МойСклад.

Автор: Данила Пантелеев · 2026-07-21

Безопасная авторизация в WordPress: 2FA, SSO, reCAPTCHA и защита от брутфорса

Безопасная авторизация в WordPress: 2FA, SSO, reCAPTCHA и защита от брутфорса

Введение: почему форма входа – постоянная мишень ботов

Как атакуют страницу входа WordPress: модель угроз

Уровень 1. Периметр: смена URL входа и ограничение доступа на сервере

Смена адреса входа

Ограничение доступа к wp-login.php по IP (nginx)

Вариант для Apache (.htaccess)

Когда периметр неприменим

Уровень 2. Лимит попыток входа и блокировка ботов

Плагин лимита попыток

Где считать попытки: плагин vs сервер

Отключение XML-RPC

Логирование неудачных входов

Уровень 3. Двухфакторная аутентификация (2FA): TOTP как стандарт

Выбор плагина

Настройка TOTP пошагово

Почему не SMS и не email

Уровень 4. SSO для команды: единый вход через OAuth

Когда SSO оправдан

Протоколы: OAuth 2.0 / OIDC против SAML

Настройка входа через Google (miniOrange OAuth Client)

Маппинг ролей: принцип минимальных привилегий

Что SSO даёт для безопасности

Уровень 5. reCAPTCHA v3: защита от ботов без раздражения пользователей

Получение ключей

Подключение вручную

Настройка порога score

Российский контекст: альтернативы

Дополнительные меры ядра: пароли, роли, сессии

Политика паролей

Запрет логина admin и скрытие авторов

Application Passwords и REST API

Управление сессиями

Настройки wp-config.php

Как не заблокировать самого себя: аварийный доступ

Чек-лист проверки после настройки

Заключение

Нужна помощь с реализацией?