Как закрыть нежелательным запросам доступ к WordPress через .htaccess
Каждый день на сайт с WordPress приходят сотни автоматических запросов: от поисковых роботов, сканеров уязвимостей, спам-ботов и просто случайных скриптов. Часть из них безобидна, но другие пытаются подобрать пароль к админке, загрузить вредоносные файлы или выкачать базу данных. Файл .htaccess, который читается веб-сервером Apache при каждом обращении, позволяет отсекать значительную долю такого трафика ещё до того, как запрос достигнет WordPress.
Грамотно настроенный .htaccess снижает нагрузку на хостинг, уменьшает количество спам-комментариев и затрудняет работу сканеров, ищущих устаревшие плагины. При этом важно помнить, что любое правило — это компромисс между безопасностью и риском случайно заблокировать легитимного посетителя или поискового робота. Ниже разберём, какие директивы работают, как их применять и где легко допустить ошибку.
Как работает файл .htaccess в Apache
.htaccess — это конфигурационный файл, который интерпретируется модулем mod_rewrite и другими модулями Apache при обработке каждого HTTP-запроса к каталогу, где он лежит. Правила из него действуют только в пределах той директории, где находится файл, и во всех вложенных папках. WordPress использует .htaccess для формирования «красивых» постоянных ссылок, поэтому файл обычно уже существует в корне сайта.
Механизм обработки запросов достаточно прост: сервер получает URL, заголовки и метод, затем последовательно применяет директивы из .htaccess, после чего передаёт управление ядру PHP и WordPress. Чем раньше удаётся отклонить нежелательный запрос, тем меньше ресурсов расходуется на его обработку. Именно поэтому блокировки на уровне веб-сервера эффективнее, чем плагины, работающие уже после запуска PHP.
Какие запросы стоит блокировать
Прежде чем писать правила, полезно заглянуть в логи доступа и посмотреть, кто вообще заходит на сайт. Среди типичных нежелательных гостей встречаются сканеры уязвимостей вроде masscan и nuclei, спам-боты, оставляющие «мусорные» комментарии, фермы, накручивающие счётчики, и скрипты, которые бездумно обходят чужие сайты в поисках прокси. Нередко в логах всплывают странные обращения, например, попытки открыть постороннюю страницу с постороннего домена — на такие запросы стоит реагировать одинаково: возвращать код 403 и не тратить ресурсы сервера.
К отдельной категории относятся обращения к заведомо уязвимым endpoint WordPress. Это может быть wp-login.php при попытке брутфорса, xmlrpc.php, который часто используют для DDoS, или readme.html, по которому определяют версию движка. Любые обращения к таким файлам от ботов, а не от реального пользователя — повод задуматься о дополнительной фильтрации на уровне веб-сервера.
Блокировка по IP-адресу через директиву Require
Самый прямой способ отсечь нежелательный источник — закрыть ему доступ директивами Require или связкой Order/Deny. В современных версиях Apache 2.4 предпочтительнее использовать Require: например, Require all denied с последующим Require all granted для всех, кроме перечисленных адресов. Это позволяет точечно запрещать конкретные IP или целые подсети, не задевая остальных посетителей.
На практике одного IP-адреса для блокировки бот-сети мало: злоумышленники быстро ротируют адреса. Поэтому блокировку по IP лучше сочетать с фильтрацией по User-Agent и обращениями к критичным файлам. Если вы настраиваете рабочую станцию и проверяете конфигурацию через браузер, удобно делать скриншоты служебных окон, например, с помощью инструмента «Ножницы» в Windows, чтобы потом сравнить поведение сайта до и после правок в .htaccess.
Фильтрация ботов по строке User-Agent
Заголовок User-Agent передаётся браузерами и ботами автоматически, и именно по нему чаще всего опознаются сканеры и спам-сети. В .htaccess можно проверять эту строку через RewriteCond и при совпадении отдавать код 403 или 410. Например, легко отсеять известных «пауков» вроде AhrefsBot, SemrushBot, MJ12bot, если их посещение нежелательно и они не нужны для SEO-мониторинга.
При составлении списка важно избегать слишком грубых шаблонов. Строка User-Agent легко подделывается, поэтому полагаться только на неё нельзя. Зато в связке с другими признаками — частотой обращений, Referer, запрашиваемым URL — она становится мощным фильтром. Если требуется комплексная диагностика сервера и настройка рабочего окружения, полезно заглянуть в раздел о компьютерах, где собраны материалы по инструментам для администратора.
Защита админки WordPress от подбора паролей
Два самых популярных файла у атакующих — wp-login.php и xmlrpc.php. Через первый пытаются подобрать логин и пароль администратора, через второй — выполнять пакетные запросы к сайту. Для них обычно создают отдельные файлы .htaccess внутри каталога wp-admin и рядом с xmlrpc.php, разрешая доступ только с доверенных IP. Если у сайта фиксированный административный IP, достаточно прописать Require ip с адресом, и любой вход с другой точки сразу будет отклонён на уровне сервера.
Когда IP-адрес администратора динамический, лучше использовать двухфакторную аутентификацию и плагин, ограничивающий число попыток входа, а в .htaccess добавить общую блокировку запросов без cookie WordPress к wp-login.php. Такая связка не даёт стопроцентной гарантии, но резко снижает поток автоматических попыток входа и разгружает сервер, отбрасывая большую часть запросов ещё до загрузки PHP.
Сравнение способов и итоговая настройка
| Метод блокировки | Уровень защиты | Сложность настройки | Ложные срабатывания | Нагрузка на сервер |
|---|---|---|---|---|
| Блокировка по IP | Высокая при статичном адресе | Средняя, списки растут | Минимальные | Низкая |
| Фильтрация User-Agent | Средняя | Средняя | Возможны у легитимных клиентов | Низкая |
| Закрытие wp-login.php по IP | Очень высокая | Низкая при фиксированном IP | Нет при статичном адресе | Очень низкая |
| Условные RewriteCond по Referer | Средняя | Высокая | Заметные | Низкая |
| Комплекс правил mod_rewrite | Высокая | Высокая | Умеренные | Низкая |
Видно, что комбинированный подход даёт лучший результат: ни один метод не закрывает все каналы атаки, но вместе они перекрывают основные пути. Хорошей отправной точкой служит связка из фильтрации User-Agent, защиты wp-login.php и точечной блокировки по IP, к которой постепенно добавляются более тонкие правила по мере изучения реальной картины трафика.
Перед сохранением изменённого .htaccess всегда проверяйте синтаксис: даже лишний пробел или отсутствующий флаг [L] может привести к ошибке 500 на всём сайте. Если доступ к сайту пропал, достаточно переименовать .htaccess через FTP или файловый менеджер хостинга, и сервер вернётся к работе. Для тех, кто только осваивает администрирование сайтов и хочет разобраться в смежных вопросах, полезно изучить пример блокировки нежелательных URL в контексте похожих задач на сторонних ресурсах, а затем вернуться к собственному .htaccess и расширить его под реальные нужды проекта.
Откройте файл .htaccess в корне сайта через любой редактор, добавьте первое правило из тех, что описаны выше, и проверьте работу сайта в режиме инкогнито. Когда базовая защита встанет на место, расширяйте её постепенно — и тогда нежелательный трафик перестанет быть повседневной проблемой.
