Страница входа WordPress — любимая цель ботов и брутфорсеров. Разбираем, как настроить защиту wp-login.php на уровне Nginx.
При этом важно учитывать конфигурацию VPS, чтобы ограничения по IP, капчи и лимиты запросов не мешали работе администратора. Грамотно настроенные правила в Nginx и файрволе позволят отсечь автоматические атаки, сохранив доступ только для доверенных пользователей.
Введение
Представьте, вы спокойно занимаетесь сайтом на WordPress, а в это время невидимые боты методично перебирают пароли от вашей админки. Стандартная страница входа wp-login.php — лакомый кусочек для злоумышленников. Они запускают брутфорс-атаки, пытаясь подобрать ваш пароль, и даже если им это не удаётся, сам процесс ощутимо нагружает сервер. Каждая такая попытка входа заставляет WordPress запускать PHP-скрипты и обращаться к базе данных, поэтому ресурсы расходуются впустую и сайт может замедлиться для реальных посетителей.
В статье рассказали, как защитить форму входа WordPress с помощью веб-сервера Nginx. Объяснили, какие у каждого метода есть плюсы, а какие подводные камни. Это поможет избежать ситуации, когда вместо хакеров от сайта отрезаны вы сами или ваши легальные пользователи.
Почему стоит защищать wp-login.php через Nginx
Многие администраторы WordPress полагаются на плагины безопасности, например, для ограничения числа попыток входа. Однако такой подход означает, что WordPress всё равно обрабатывает каждую попытку, то есть, запускает PHP и обращается к базе данных, даже если атака в итоге блокируется. Это всё равно что впустить злоумышленника в прихожую перед тем, как выставить за дверь: система уже потревожена. Гораздо эффективнее поставить преграду прямо на пороге.
Веб-сервер Nginx позволяет отсеивать нежелательные запросы ещё до того, как они попадут в WordPress. Благодаря этому снижается нагрузка и риск, что массовая атака перегрузит сайт.
Ограничение доступа по IP
Самый радикальный способ защиты — разрешить доступ к админке только с определённых адресов. Если вы точно знаете, с каких IP заходите в панель управления, имеет смысл открыть доступ только для них, а остальным сразу возвращать отказ. Тогда злоумышленники вообще не увидят страницу входа, ведь Nginx развернёт их на подступах.
Для этого откройте конфигурационный файл вашего сайта для Nginx, например, в каталоге /etc/nginx/sites-available/ или разделе server в основном nginx.conf. Прежде чем редактировать конфигурацию, сделайте бекап текущего файла, чтобы иметь возможность откатить изменения, если что-то пойдёт не так. Найдите секцию, где описаны правила для WordPress. Обычно там присутствует блок location ~ \.php с настройками fastcgi_pass для PHP. Внутри добавьте директивы, ограничивающие доступ по IP. Например, если ваш текущий IP-адрес 111.111.111.111, пропишите:
location /wp-admin {
allow 111.111.111.111;
deny all;
}
location = /wp-login.php {
allow 111.111.111.111;
deny all;
include fastcgi_params;
fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
Не забудьте заменить пример на свой фактический адрес и указать правильный сокет/порт PHP в fastcgi_pass. Он может отличаться в вашей конфигурации. Если нужно разрешить несколько адресов, добавьте дополнительные строки allow с каждым нужным IP. После правки сохраните файл и проверьте синтаксис командой nginx -t. Если ошибок нет, перезапустите Nginx командой:
sudo service nginx restart
для Ubuntu/Debian или:
sudo systemctl restart nginx
для CentOS.
Теперь любой, кто пытается зайти на wp-login.php с чужого IP, получит ошибку 403 Forbidden и даже не увидит форму авторизации. Зато вы сами, зайдя с разрешённого адреса, не заметите никаких изменений, админка откроется как обычно. Учтите только, что метод с белым списком IP хорош при статическом или редко меняющемся адресе. Если ваш IP непостоянный, вы рискуете однажды заблокировать и себя. В таком случае рассмотрите следующие методы либо будьте готовы внести свежий адрес в конфиг через SSH.
Защита страницы входа паролем
Если ограничение по IP вам не подходит, можно поставить на страницу входа дополнительный пароль. Речь идёт о базовой HTTP-авторизации, том самом всплывающем окне браузера с запросом имени и пароля, которое появится перед загрузкой wp-login.php. Этот дополнительный рубеж значительно усложняет жизнь ботам: даже добравшись до скрипта входа, они упрутся в неожиданное препятствие.
Чтобы включить Basic Auth, сначала нужно создать файл с паролями, так называемый .htpasswd. Проще всего воспользоваться утилитой htpasswd из пакета Apache. Установите её, если не установлена:
sudo apt-get update
sudo apt-get install apache2-utils
Сгенерируйте новый файл с именем пользователя и паролем. В примере имя пользователя admin:
sudo htpasswd -c /etc/nginx/.htpasswd admin
Команда два раза запросит придуманный пароль и сохранит его хеш. Файл .htpasswd теперь содержит одну запись. Если нужно добавить ещё пользователей, повторно выполните команду без флага -c, чтобы не перезаписывать файл, а добавить новую строку.
Далее подключите эту авторизацию в конфигурации Nginx. Добавьте в файл настроек вашего сайта блок для wp-login.php с директивами auth_basic:
location = /wp-login.php {
auth_basic "Restricted Area";
auth_basic_user_file /etc/nginx/.htpasswd;
include fastcgi_params;
fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
Эти строки заставят Nginx запрашивать у всех пользователей дополнительные учётные данные перед показом стандартной страницы логина WordPress. В примере realm назван Restricted Area. Вы можете указать любую фразу, она отобразится в диалоговом окне браузера. Если всё настроено правильно, при переходе на /wp-login.php появится окно с требованием ввести имя пользователя и пароль. Лишь после ввода корректных данных вы увидите обычную форму входа WordPress.
По желанию аналогичные директивы можно добавить и для директории /wp-admin, чтобы закрыть весь раздел администратора, а не только страницу авторизации. Тогда браузер будет требовать базовый пароль при любом обращении к админ-панели.
Преимущество такого метода в том, что до ввода правильного пароля запрос даже не доходит до WordPress. Сервер отвечает кодом 401 и отсекает лишнюю нагрузку. Большинство ботов не способны преодолеть эту преграду, они просто не запрограммированы на ввод пароля в всплывающем окне.
Конечно, появляется и новая обязанность, ведь нужно помнить ещё один логин/пароль. Если администраторов несколько, каждому можно завести отдельную запись в .htpasswd, хотя это уже менее удобно, ведь придётся сообщать коллегам новые учётные данные. Этот способ больше подходит для ситуаций, когда панелью управляете только вы или узкий круг лиц.
Учтите и такой момент: используйте HTTPS. Без SSL любое базовое имя/пароль передаются через сеть в открытом виде, они закодированы, но не зашифрованы, и злоумышленник при большом желании может их перехватить. Да и в целом, раз вы озаботились безопасностью, сайт наверняка должен работать по HTTPS. Ну и очевидно, если вы забудете этот дополнительный пароль, вам придётся лезть на сервер и убирать и менять настройки.
Дополнительные меры: ограничение методов и скорости
Описанные выше решения можно комбинировать с другими настройками Nginx, чтобы ещё больше снизить риски. Например, можно ограничить типы HTTP-запросов. Если ваш сайт не предусматривает сложных действий от неавторизованных посетителей, например, это блог или корпоративная страница без интерактивных форм, имеет смысл разрешить внешним пользователям только безопасные методы. Проще говоря, оставить всем полный доступ только на чтение (HTTP метод GET), а все запросы типа POST, PUT, DELETE и так далее блокировать, кроме тех случаев, когда запрос идёт с вашего IP или уже после авторизации. Обычным посетителям это не помешает, они всё просматривают через GET. Зато какой-нибудь скрипт, пытающийся отправить на ваш сайт данные или загрузить файл, сразу получит отказ.
Ещё один полезный приём — ограничение частоты запросов. Nginx умеет глушить трафик, то есть, снижать скорость обработки слишком частых обращений. Можно настроить правило, которое не даст одному IP вызывать wp-login.php более определённого числа раз в минуту. Реальному человеку этого хватит, вряд ли кто-то пытается войти десятки раз подряд, а бот, запустивший подбор пароля, начнёт получать отказы или задержки. Например, можно установить лимит в 5 попыток в минуту на IP. На шестую и далее сервер уже будет отвечать ошибкой 429 Too Many Requests. Такая мера не остановит атаку полностью, но существенно её замедлит и снимет пиковую нагрузку. Настраивается это директивами limit_req_zone и limit_req в конфиге Nginx. Если решите внедрить подобное ограничение, сначала изучите официальную документацию или готовые примеры, так вы точно не ошибётесь в синтаксе.
Для максимальной автоматизации можно подключить утилиту Fail2ban. Она отслеживает логи и умеет банить IP-адреса на уровне файрвола системы. Например, при включённой базовой авторизации Nginx пишет в error.log сообщение о неправильном логине или пароле при каждом неудачном вводе. Эти записи можно ловить Fail2ban. Настроив фильтр на такие ошибки и указав порог срабатывания, скажем, 3 неудачных попытки за 5 минут, вы можете автоматически добавлять IP нарушителя в бан-лист на несколько часов или дней. Если какой-то упорный бот будет без конца пытаться пробить вашу форму входа, он получит полный отпор, и сервер перестанет отвечать на его запросы вообще.
Не забывайте и про базовые, но не менее важные методы защиты. Сложный уникальный пароль администратора — ваша первая линия обороны. Никогда не используйте тривиальные комбинации вроде admin/admin или пароль, утёкший на другом ресурсе. А методы вроде reCAPTCHA на форме входа или смена URL страницы авторизации тоже могут повысить безопасность веб-ресурса. Их можно сочетать с настройками Nginx. Например, вы можете скрыть wp-login.php под другим адресом, а заодно закрыть прямой доступ к оригинальному файлу правилами, как описано выше. При этом важно не забыть свои новые пароли и URL, чтобы не оказаться в затруднительном положении.
Заключение
Когда сайт защищён уже на уровне веб-сервера, можно спать гораздо спокойнее. Боты могут стучаться сколько угодно, но дверь для них останется закрытой. WordPress работает шустрее и без лишней нагрузки, а вы сбережёте нервы и ресурсы. Каждая из описанных мер заметно повышает безопасность, а вместе они дают почти непробиваемый результат. При этом подходите к настройке с умом, проверяйте после изменений, что всё работает, и держите новые доступы под рукой. Тогда админка WordPress останется для злоумышленников недосягаемой, а вы сможете сосредоточиться на развитии проекта, не отвлекаясь на атаки.
Читайте в блоге:
- Интеграция WordPress с Nginx и MariaDB на Ubuntu 24.04: от базы данных до SSL
- Хостинг сайта на Ubuntu 24.04 LTS: NGINX, SSL и WordPress
- Установка и настройка LAMP-сервера на Ubuntu 24.04 LTS