Wp-admin — это первое, куда ломятся боты и скрипты, как только находят WordPress-сайт. У меня за 10 лет работы было несколько случаев, когда клиент приходил с взломанным сайтом именно через брутфорс админки, и каждый раз оказывалось, что элементарные меры защиты просто не были приняты.
Почему wp-admin всегда под ударом
Адрес /wp-admin знают все. Это не секрет, это стандарт. Любой сканер уязвимостей, любой бот-загрузчик первым делом идёт именно туда. По моим наблюдениям, на среднестатистическом WordPress-сайте без защиты попытки подбора пароля к /wp-login.php начинаются уже через несколько часов после публикации.
Был у меня клиент — небольшой интернет-магазин на WooCommerce, PHP 8.1, MySQL 8.0. Сайт работал без проблем несколько месяцев. Потом пришёл с жалобой: сайт тормозит, хостинг ругается на нагрузку. Открываю логи — 40 000 запросов к /wp-login.php за сутки. Один IP? Нет, распределённый брутфорс с сотен адресов. Сайт не взломали, но положили на лопатки нагрузкой. После настройки защиты нагрузка упала в 20 раз буквально за час.
Другая история — клиент с блогом, посещаемость 200 человек в день. Думал, что он никому не нужен, зачем его ломать. Взломали. Поставили редиректы на фарму, Google пометил сайт как опасный, позиции рухнули. Восстанавливались два месяца. Если бы закрыли wp-admin нормально — ничего этого бы не было. Кстати, про общую защиту от взлома я писал подробно в статье Как защитить сайт от взлома: 10 правил безопасности — там много чего полезного.
Грубо говоря, wp-admin — это входная дверь вашего сайта. И если вы оставляете её с замком на честном слове, рано или поздно кто-то войдёт.
Ограничение доступа по IP: самый надёжный способ
Это однозначно лучший метод, если у вас статический IP или хотя бы небольшой пул адресов. Суть простая: разрешаем доступ к wp-admin только с конкретных IP, всем остальным — 403.
На nginx конфигурация выглядит вот так:
location ~* ^/wp-admin {
allow 195.168.1.100;
allow 195.168.1.101;
deny all;
}
location = /wp-login.php {
allow 195.168.1.100;
allow 195.168.1.101;
deny all;
}
Обратите внимание: нужно закрывать не только /wp-admin, но и /wp-login.php отдельно — это разные точки входа. Многие забывают про wp-login.php и потом удивляются, что брутфорс продолжается.
Если сайт на Apache, то через .htaccess в папке wp-admin:
# /wp-admin/.htaccess
AuthType Basic
Order Deny,Allow
Deny from All
Allow from 195.168.1.100
Allow from 195.168.1.101
# И в корневом .htaccess для wp-login.php
<Files wp-login.php>
Order Deny,Allow
Deny from All
Allow from 195.168.1.100
Allow from 195.168.1.101
</Files>
На деле у большинства клиентов нет статического IP — они работают из дома, из офиса, с телефона. В таком случае я рекомендую использовать VPN с фиксированным выходным адресом. Это решает проблему раз и навсегда. Стоит такой VPN копейки, а безопасность даёт серьёзную.
Базовая HTTP-аутентификация поверх формы входа
Это второй эшелон защиты, который я ставлю почти всегда — особенно когда IP-ограничение не подходит. Суть: перед тем как увидеть форму входа WordPress, пользователь видит системный диалог браузера с запросом логина и пароля. Бот обычно не умеет работать с таким диалогом, а если и умеет — ему нужны два набора учётных данных вместо одного.
Создаём файл паролей командой:
htpasswd -c /etc/nginx/.htpasswd admin_user
# Система попросит ввести пароль дважды
# Файл создастся примерно такого содержания:
# admin_user:$apr1$xyz...$hashedpassword
Для nginx добавляем в конфиг:
location ~* ^/wp-admin {
auth_basic "Restricted Area";
auth_basic_user_file /etc/nginx/.htpasswd;
# Важно: разрешаем admin-ajax.php без аутентификации
# иначе перестанет работать куча плагинов
location = /wp-admin/admin-ajax.php {
auth_basic off;
}
}
location = /wp-login.php {
auth_basic "Restricted Area";
auth_basic_user_file /etc/nginx/.htpasswd;
}
Вот этот момент с admin-ajax.php — я один раз забыл его исключить, и у клиента перестала работать корзина WooCommerce, живые поиск, AJAX-фильтры товаров. Час разбирался, пока не вспомнил. Так что всегда исключайте admin-ajax.php из базовой аутентификации.
Для Apache всё делается через .htaccess в папке wp-admin:
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /home/user/site/.htpasswd
Require valid-user
# Исключение для admin-ajax.php
<Files admin-ajax.php>
Satisfy Any
Allow from All
AuthType None
</Files>
Пароль для HTTP-аутентификации должен быть другим, не таким же, как у WordPress-аккаунта. Разные пароли — разные уровни защиты. Это базовая гигиена.
Смена адреса wp-admin: помогает или нет
Честно говоря, я отношусь к этому методу неоднозначно. С одной стороны, переименование /wp-admin на что-то вроде /secret-panel-2024 действительно снижает количество автоматических атак — боты идут по стандартным путям. С другой стороны, это security through obscurity, то есть безопасность через неизвестность. Если атакующий целенаправленно ищет вашу панель, он её найдёт.
Для смены адреса обычно используют плагин WPS Hide Login. Он работает стабильно, не ломает обновления WordPress и совместим с большинством тем и плагинов. Устанавливается за минуту, в настройках указываете новый URL.
Но тут есть подводные камни. Во-первых, некоторые плагины жёстко прописывают /wp-admin в своём коде и начинают глючить. Во-вторых, если кто-то из пользователей сохранил старую ссылку в закладках — он получит 404 и придёт к вам с вопросами. В-третьих, при некоторых конфигурациях nginx этот плагин работает криво.
Мой подход: смена адреса — это дополнение к основным мерам, не замена им. Если уже стоит ограничение по IP или базовая HTTP-аутентификация, то смена URL даёт небольшой дополнительный эффект. Как самостоятельная мера — слабовата.
Ограничение попыток входа и защита от брутфорса
Даже если вы не можете закрыть wp-admin по IP, можно существенно затруднить брутфорс ограничением количества попыток входа. После 3-5 неудачных попыток IP блокируется на определённое время.
На уровне сервера это делается через fail2ban. Вот конфигурация для nginx:
# /etc/fail2ban/filter.d/wordpress.conf
[Definition]
failregex = ^<HOST> .* "POST /wp-login.php
ignoreregex =
# /etc/fail2ban/jail.local
[wordpress]
enabled = true
port = http,https
filter = wordpress
logpath = /var/log/nginx/access.log
maxretry = 5
findtime = 300
bantime = 3600
Это означает: 5 попыток за 5 минут — бан на час. Можно ужесточить: 3 попытки — бан на 24 часа. По моей практике, такая настройка отсекает 95% автоматических атак.
На уровне WordPress есть плагины: Limit Login Attempts Reloaded (бесплатный, надёжный, работает на PHP 8.1 и 8.2), WP Cerber Security. Я чаще использую Limit Login Attempts Reloaded — он не тяжёлый, не лезет куда не надо и делает ровно то, что от него требуется. Настройки простые: 4 попытки, потом блокировка на 20 минут, после 4 блокировок — на 24 часа.
Если хостинг поддерживает ModSecurity (а большинство нормальных хостингов это поддерживают), то стоит включить правила OWASP Core Rule Set — они закрывают большой класс атак на wp-login.php автоматически. Подробнее про настройку файрвола для сайта я рассказывал в статье Настройка Firewall для защиты сайта: полное руководство 2026.
Двухфакторная аутентификация для wp-admin
Это то, что я рекомендую абсолютно всем клиентам с WordPress. Даже если пароль утечёт, без второго фактора злоумышленник не войдёт. Настраивается за 10 минут, стоит ноль рублей.
Плагины на выбор: Google Authenticator, WP 2FA, Two Factor Authentication от плагина miniOrange. Я обычно ставлю WP 2FA — у него нормальный интерфейс, поддержка TOTP-приложений (Google Authenticator, Authy, Microsoft Authenticator) и возможность настроить обязательную 2FA для всех пользователей с определёнными ролями.
Важный момент: настройте 2FA только для ролей администратор и редактор. Для подписчиков это излишне и только создаёт трение. Если у вас интернет-магазин на WooCommerce — для покупателей 2FA не нужна категорически.
Подробную инструкцию по настройке двухфакторной аутентификации — не только для WordPress, но и в целом — я разбирал в отдельной статье Двухфакторная аутентификация на сайте: настройка 2026.
Ещё один момент, который часто игнорируют: XML-RPC. Это старый интерфейс WordPress для удалённого управления, и он тоже позволяет аутентифицироваться. Многие плагины безопасности фокусируются на wp-login.php, но забывают про xmlrpc.php. Если вы не используете приложения типа Jetpack или мобильное приложение WordPress — отключите XML-RPC полностью.
# Блокируем xmlrpc.php в nginx
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
# В .htaccess для Apache
<Files xmlrpc.php>
Order Deny,Allow
Deny from All
</Files>
Настройка паролей и учётных записей
Технические меры — это хорошо, но слабый пароль их все перечёркивает. По опыту скажу: больше половины взломов, с которыми ко мне приходят клиенты, произошли из-за простых паролей или использования логина "admin".
Логин admin — это плохая идея. Всегда. Это первое, что пробует любой брутфорс. Создайте пользователя с нестандартным логином, назначьте ему права администратора, удалите пользователя admin. Если у вас уже есть записи или комментарии от пользователя admin — при удалении WordPress предложит переназначить их на другого пользователя.
Пароль администратора должен быть минимум 16 символов, содержать буквы разного регистра, цифры и спецсимволы. WordPress генерирует надёжные пароли автоматически — используйте эту функцию. Храните пароль в менеджере паролей (Bitwarden, 1Password, KeePass — на ваш выбор), не в блокноте на рабочем столе и не в телеграме.
Регулярно проверяйте список пользователей в WordPress. Особенно после установки плагинов или тем из сомнительных источников — некоторые вредоносные темы создают скрытых администраторов. Я видел такое не раз: клиент устанавливает "бесплатную" премиум-тему с какого-то варез-сайта, и через неделю в базе данных появляется пользователь wp_admin_backup с правами администратора.
Периодически смотрите таблицу wp_users в базе данных — там должны быть только те пользователи, которых вы создавали:
SELECT ID, user_login, user_email, user_registered
FROM wp_users
ORDER BY user_registered DESC;
-- Также проверьте метаданные на права администратора
SELECT u.user_login, u.user_email, um.meta_value
FROM wp_users u
JOIN wp_usermeta um ON u.ID = um.user_id
WHERE um.meta_key = 'wp_capabilities'
AND um.meta_value LIKE '%administrator%';
Мониторинг подозрительной активности и логи
Защита — это не разовое действие, это процесс. Нужно видеть, что происходит с вашим wp-admin в реальном времени. Для этого я настраиваю несколько вещей.
Во-первых, плагин WP Activity Log (раньше назывался WP Security Audit Log). Он пишет в базу данных все действия в админке: входы, выходы, изменения настроек, установку плагинов, редактирование файлов. Если что-то пошло не так — вы увидите когда и кто что делал. Это бесплатно и работает без нареканий на PHP 8.1, 8.2, 8.3.
Во-вторых, мониторинг логов сервера. Настройте алерт на количество POST-запросов к /wp-login.php — если за 5 минут их больше 50, это уже атака. Можно сделать через простой bash-скрипт с cron или через готовые решения типа Grafana + Loki. Подробнее о работе с логами сайта написано в статье Настройка логов сайта: мониторинг и анализ ошибок в 2026 — там есть практические примеры.
В-третьих — регулярные бэкапы. Это не прямо про защиту wp-admin, но если что-то всё-таки пошло не так и сайт взломали — бэкап позволяет откатиться к чистому состоянию за минуты, а не восстанавливать всё вручную неделями. Про правильную настройку бэкапов есть отдельный материал: Бэкапы сайта: как делать правильно и не терять данные.
Комплексная защита через Wordfence
Если не хочется настраивать всё руками по отдельности — Wordfence Security закрывает большинство описанных задач в одном плагине. Я использую его на проектах, где нет возможности настраивать сервер напрямую (shared-хостинг, клиенты которые хотят управлять всем через плагины).
Wordfence умеет: ограничивать попытки входа, блокировать IP по геолокации, сканировать файлы на вредоносный код, показывать попытки входа в реальном времени, отправлять уведомления на почту при подозрительной активности. Бесплатная версия покрывает 80% потребностей. За платную версию (около 99 долларов в год) получаете обновления сигнатур в реальном времени — для бесплатной задержка 30 дней.
Но честно говоря, Wordfence — это довольно тяжёлый плагин. На слабом хостинге он может заметно влиять на скорость работы сайта. Если у вас VPS с нормальными ресурсами — ставьте смело. Если shared-хостинг с 512 МБ RAM — подумайте дважды. В таком случае лучше использовать лёгкие специализированные плагины: Limit Login Attempts Reloaded для брутфорса, WPS Hide Login для смены URL, и настроить базовую HTTP-аутентификацию через панель хостинга.
Чек-лист: минимальный набор защиты wp-admin
По итогам всего сказанного — вот что я считаю минимально необходимым для любого WordPress-сайта, будь то маленький блог или интернет-магазин с тысячами товаров:
- Ограничение попыток входа (Limit Login Attempts Reloaded или fail2ban на уровне сервера)
- Двухфакторная аутентификация для администраторов
- Смена логина admin на что-то уникальное
- Надёжный пароль 16+ символов, хранится в менеджере паролей
- Блокировка xmlrpc.php если не используется
- Базовая HTTP-аутентификация или ограничение по IP (если есть возможность)
- Регулярные бэкапы (минимум раз в день для активных сайтов)
- Мониторинг пользователей и активности в админке
- Актуальные версии WordPress, тем и плагинов
Про обновления — это отдельная большая тема. Устаревшие плагины с известными уязвимостями — это открытая дверь, которую не закроет никакая защита wp-admin. Ставьте обновления регулярно, это не обсуждается. Если боитесь что-то сломать обновлением — настройте тестовую среду и сначала проверяйте там.
Вся эта настройка занимает от силы пару часов. Но она даёт реальную защиту. Я видел сайты, которые стояли без единой проблемы по 5 лет именно потому, что в начале кто-то потратил время и настроил всё правильно. И видел сайты, которые ломали по несколько раз в год, потому что хозяин считал, что "у меня маленький сайт, кому он нужен". Нужен. Не лично вы нужны атакующим, а ресурс вашего сервера, возможность рассылать спам или накручивать трафик. Не давайте им такой возможности.
Если нужна помощь с настройкой безопасности — обращайтесь, занимаюсь поддержкой WordPress-сайтов и настройкой защиты под ключ. Провожу аудит текущего состояния, нахожу слабые места и закрываю их. Также если нужна доработка сайта в комплексе с настройкой безопасности — это тоже реально сделать в рамках одного проекта.
Хотите надёжно защитить свой сайт на WordPress?
Свяжитесь с нами, и мы настроим комплексную защиту вашей панели администратора, чтобы исключить несанкционированный доступ.