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

Если вы ищете российский аналог Cloudflare, чтобы закрыть админку от брутфорса, начните с неприятной правды: капча и лимит попыток входа не спасают. Каждый такой запрос уже дошел до PHP, уже поднял ядро WordPress или Bitrix, уже потратил память и соединение с базой. Атакующий может слать тысячи попыток в час, и ваша CMS будет честно их обрабатывать, пока сервер не начнет задыхаться. Единственный способ реально остановить перебор – не пустить запросы к /wp-login.php и /bitrix/admin/ до приложения вообще.

Второй миф: “спрятать админку бесполезно, сканеры все равно найдут”. Найдут, если вы просто сменили URL в настройках CMS. Не найдут, если панель живет на отдельном домене или нестандартном порту за reverse proxy, а сам прокси отсекает все лишнее на сетевом уровне. Автоматические сканеры бьют по шаблонным путям и типовым портам. Как только админка уезжает на admin.example.ru или на порт 8443 с GeoIP-фильтрацией, 95 процентов ботов просто промахиваются мимо цели.

Замена Cloudflare нужна еще и по другой причине. Зарубежные сервисы ограничивают доступ к сайтам из России, а российские интернет-провайдеры в ответ режут маршруты до сайтов на Cloudflare. Админка, которая не открывается с рабочего ноутбука в Москве, – это не защита, а простой. Ниже разберем, как вынести панель за отдельный домен на reverse proxy, как настроить GeoIP-ограничение до входа в CMS и какие возможности дает TrafficVeil: он объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику, обеспечивает работу сайтов на территории РФ и по всему миру и не тарифицирует ботов, атаки и WAF-блокировки.

Почему стандартные админ-панели WordPress и Bitrix уязвимы для брутфорса

Брутфорс админки WordPress начинается не с подбора пароля, а со сканирования. Бот приходит на сайт, стучится по десятку известных адресов и по коду ответа понимает, где панель управления. Для WordPress это /wp-login.php, /wp-admin/, /xmlrpc.php, для Bitrix – /bitrix/admin/, /bitrix/php_interface/, /local/admin/. Ничего угадывать не нужно: эти пути одинаковы на сотнях тысяч установок, они записаны в любом публичном сканере вроде WPScan, а сам сканер стоит дешевле чашки кофе.

Дальше в дело вступает автоматика. Один и тот же словарь (admin, administrator, manager плюс десяток тысяч паролей из утечек) прогоняется по найденной форме со скоростью, до которой человеку далеко. Если на сайте нет лимита попыток, слабый пароль подбирается за минуты. Если лимит есть, бот просто замедляется и распределяет попытки по тысячам IP из ботнета, и каждый отдельный адрес выглядит как добропорядочный посетитель, который ошибся паролем два раза за сутки.

Вот здесь и начинается главный миф: что капча и лимиты закрывают вопрос. Они его не закрывают, они его откладывают. Смотрите, что происходит на самом деле. Запрос с попыткой входа доходит до веб-сервера, веб-сервер передает его интерпретатору PHP, PHP поднимает ядро WordPress или Bitrix, те подключаются к базе данных, ищут пользователя, считают хеш пароля и только потом отвечают “неверно”. Вся эта работа уже выполнена. Капча срабатывает тоже внутри приложения, то есть после того, как CMS проснулась и потратила ресурсы.

Посчитайте арифметику. Один запрос к /wp-login.php с полной проверкой пароля на слабом хостинге съедает 150-400 мс процессорного времени и открывает соединение с MySQL. Тысяча таких запросов в минуту – это уже отказ в обслуживании для живых посетителей, даже если ни один пароль не подошел. Сайт ложится не от взлома, а от самой попытки защиты. Плагины вроде Limit Login Attempts или капча от Bitrix пишут каждую неудачную попытку в таблицу опций или в лог, база пухнет, а боты продолжают долбить форму, потому что их задача – не обязательно войти, а занять ресурсы или найти брешь в самом плагине.

Есть и вторая проблема, о которой вспоминают реже. Стандартные пути админки видны всем и всегда. Пока /wp-login.php открыт миру, вы не можете отличить целевой брутфорс от фонового шума, а значит не можете нормально настроить правила. Хуже того, xmlrpc.php в WordPress позволяет перебирать пароли пачкой: один HTTP-запрос несет в себе сотни попыток. Лимиты, которые считают HTTP-запросы, такую пачку не видят вообще.

Вывод простой и слегка неудобный: любые меры внутри CMS – это борьба на последнем рубеже. Пока запрос доходит до приложения, вы платите за каждую атаку процессором, памятью и нервами. Правильнее не пускать его туда вообще: спрятать админку за отдельным доменом или портом и отсекать чужие страны на входе. Об этом дальше.

Как спрятать админку за отдельным доменом или портом на reverse proxy

Сканеры не взламывают сайты, они их перебирают. И ищут они не что-то уникальное, а то, что знают наизусть: /wp-login.php, /wp-admin/, /bitrix/admin/, /administrator/. Достаточно оставить админку на стандартном пути, и через сутки после публикации сайта в логах появятся тысячи запросов к этим адресам. Поэтому первый шаг к защите от брутфорса делается не в CMS, а на уровне reverse proxy: админку нужно убрать с публичного адреса.

Смысл простой. Если форма входа отвечает на /wp-login.php, то любой бот знает, куда стучаться. Если она отвечает только на admin.example.ru или на example.ru:8443, то сканер, который перебирает миллион сайтов по словарю типовых путей, получит 404 и пойдёт дальше. Поверхность атаки сокращается не потому, что вы поставили пароль сложнее, а потому что атакующий просто не находит цель.

Дальше пошагово, как это делается на Nginx. Логика такая: отдельный домен или порт принимает запросы к админке, а основной домен их не отдаёт вообще.

1. Заведите поддомен, например admin.example.ru, и направьте его A-запись на тот же сервер, где работает сайт. Отдельный порт тоже подойдёт, но домен удобнее для SSL-сертификата и для последующей GeoIP-фильтрации.
2. Откройте конфиг Nginx для основного домена. В блоке server для example.ru добавьте location, который закрывает доступ к админ-путям до того, как запрос уйдёт в PHP:

location ~* ^/(wp-login\.php|wp-admin|bitrix/admin|administrator) {
  return 404;
}

Именно return 404, а не 403. Запрет 403 честно сообщает сканеру, что путь существует, но закрыт. Ответ 404 не даёт никакой информации: для бота это выглядит как обычная несуществующая страница.

3. Теперь создайте отдельный блок server для admin.example.ru. Он будет проксировать запросы к тому же приложению, но уже с другого адреса:

server {
  listen 443 ssl;
  server_name admin.example.ru;
  ssl_certificate /etc/letsencrypt/live/admin.example.ru/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/admin.example.ru/privkey.pem;
  location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
  }
}

4. В самой CMS поменяйте адрес входа. В WordPress это делается либо плагином, либо правкой wp-config.php: задайте константу WP_ADMIN_URL или перенесите wp-login.php в защищённую директорию. В Bitrix админка живёт по пути /bitrix/admin/, и её проще всего закрыть на уровне прокси, оставив доступ только через admin.example.ru.

5. Перезагрузите Nginx: nginx -t, затем systemctl reload nginx. Проверьте, что example.ru/wp-login.php отдаёт 404, а admin.example.ru открывает форму входа.

Для Apache схема та же, только вместо location используется <LocationMatch> с директивой Require all denied для основного виртуального хоста и отдельный VirtualHost для admin.example.ru с проксированием через mod_proxy.

Порт вместо домена работает так же: listen 8443 ssl вместо 443, и админка доступна только по https://example.ru:8443/. Минус в том, что сертификат придётся выпускать на тот же домен, а часть корпоративных сетей режет нестандартные порты на выход, так что из офиса вход может не работать без VPN.

Что это даёт на практике. Автоматические сканеры, которые составляют 95 процентов трафика брутфорса, просто перестают находить форму входа. Остаются целевые атаки, но их уже в разы меньше, и с ними работает следующий уровень: GeoIP-фильтрация и лимиты на количество попыток. замена cloudflare offers additional context worth reviewing. Перенос админки на отдельный домен не заменяет пароли и двухфакторную аутентификацию, но снимает с приложения тот объём мусорных запросов, который иначе уходит в PHP, в базу и в логи.

Геоограничение доступа к админке: закрываем брутфорс до приложения

Скрытая админка на отдельном домене уже отсекает 80-90% автоматических сканеров. Остаются те, кто знает ваш секретный адрес: утёкшие логи, старая ссылка в поиске, партнёр с доступом. И вот тут начинается самое интересное. Большинство админов ставит капчу и лимит попыток прямо в WordPress или Bitrix. Плохая новость: к этому моменту запрос уже прошёл через веб-сервер, PHP, подключение к базе и выполнил код CMS. Капча защищает форму, а не сервер.

Брутфорс по своей природе распределённый. Атакующий не лупит 5000 паролей с одного IP, он берёт 5000 IP из ботнета и делает по одной попытке с каждого. Любой лимит по IP разваливается. Единственный признак, который у таких запросов общий и стабильный, это география. Живой админ заходит из России, из офиса или из дома. Ботнет на 90% состоит из зарубежных адресов: Нидерланды, США, Вьетнам, Бразилия. GeoIP-фильтрация на reverse proxy отсекает их до того, как запрос дойдёт до PHP.

Разница в цифрах ощутимая. Если пропускать трафик до CMS, каждый запрос к /wp-login.php стоит вам 40-80 мс процессорного времени, запись в лог, а иногда и в таблицу попыток входа. При 200 тысячах запросов в сутки это уже заметная нагрузка на диск и CPU. Фильтр на уровне Nginx отбрасывает такой запрос за 0.1 мс и не трогает ни PHP, ни MySQL. Брутфорс превращается в пустой лог, который вы даже не читаете.

Как настроить GeoIP-фильтр на Nginx

Схема простая: Nginx получает запрос, смотрит в базу GeoIP, сверяет код страны и либо отдаёт 403, либо проксирует дальше. Никакого кода CMS, никаких плагинов. Порядок действий такой:

1. Установите модуль ngx_http_geoip2_module или используйте встроенный geoip (сборка nginx-extras). База MaxMind GeoLite2-Country бесплатна, обновляется раз в неделю через cron.
2. Подключите базу в конфиге: geoip2 /etc/nginx/geoip/GeoLite2-Country.mmdb; и создайте переменную $geoip2_data_country_code.
3. Соберите map, где разрешённым странам присваиваете 1, всем остальным 0. В allow-лист логично добавить RU, BY, KZ и страну, где сидит ваш офис.
4. Настройте location для /wp-login.php, /wp-admin/, /bitrix/admin/ и /bitrix/ с условием: if ($allowed_country = 0) { return 403; }. Для WordPress добавьте исключение для admin-ajax.php, иначе сломается фронтенд.
5. Проверьте с зарубежного IP через VPN: должен прийти 403 без единой строчки в логах PHP. И зайдите сами из разрешённой страны, чтобы убедиться в отсутствии ложных срабатываний.

Главный подвох здесь не в конфиге, а в сопровождении. Базу GeoIP нужно обновлять, иначе через месяц-два точность падает. Список разрешённых стран надо пересматривать, когда у вас появляется подрядчик из Турции или фрилансер из Сербии. Если ваш сервер за рубежом, а вы в России, схема усложняется: фильтр надо ставить и на зарубежном узле, иначе запрос всё равно дойдёт до бэкенда. И самое неприятное: атакующий с российским IP спокойно пройдёт географический фильтр. GeoIP закрывает 95% массового брутфорса, но не заменяет остальные слои защиты.

Поэтому GeoIP-ограничение работает в связке с WAF и лимитами на частоту запросов в пределах разрешённых стран. И обязательно с двухфакторной аутентификацией: даже если кто-то из вашей географии подберёт пароль, второй фактор его остановит. Именно так выстраивается защита админ-панели на уровне reverse proxy, где каждый запрос фильтруется до того, как коснётся вашего кода.

Российский аналог Cloudflare для защиты админ-панелей: возможности TrafficVeil

TrafficVeil является российским аналогом Cloudflare, который решает задачу защиты админ-панелей без ручной возни с конфигами Nginx. Если вы вручную настраивали скрытие /wp-login.php и /bitrix/admin/, вы знаете цену этому: правки в конфигах, перевыпуск SSL-сертификатов, отдельные правила для каждого сайта. TrafficVeil объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одной веб-платформе, поэтому админка закрывается на уровне сети, а не внутри CMS.

Разберем по пунктам, что именно получает владелец сайта на WordPress или Bitrix.

Скрытие админки на отдельном домене. TrafficVeil позволяет вынести панель управления на отдельный поддомен, например admin.vashdomen.ru, и ограничить доступ к нему по IP, стране или токену. Автоматические сканеры, которые перебирают стандартные пути, видят только заглушку на основном домене. Запросы к скрытому адресу не доходят до приложения, если не проходят проверку на reverse proxy. Это принципиально другой уровень по сравнению с капчей и лимитом попыток: те работают уже после того, как запрос попал в PHP.

GeoIP-фильтрация. Большинство брутфорс-атак на российские сайты идет из-за рубежа. TrafficVeil позволяет разрешить доступ к административной панели только из России или из конкретных стран, где реально работают ваши администраторы. Запросы из недоверенных регионов блокируются до приложения, поэтому нагрузка на сервер и базу данных не растет. Для сравнения: плагин-лимитер пропускает запрос до CMS и только потом отсекает его, сжигая ресурсы на каждом обращении.

Защита от брутфорса и подбора паролей. TrafficVeil анализирует поведение на уровне L7: частоту обращений к формам авторизации, повторы с одного IP, признаки автоматизированного перебора. Подозрительные сессии блокируются через WAF-блокировки, а не через задержки ответа. Легитимные администраторы при этом не страдают: им не нужно вводить капчу по десять раз за смену.

Что это дает российскому бизнесу. Зависимость от зарубежной инфраструктуры создает риски: Cloudflare ограничивает доступ к сайтам из России, а российские интернет-провайдеры в свою очередь ограничивают доступ к сайтам на Cloudflare. Для интернет-магазина или корпоративного портала это означает потерю трафика и заявок. TrafficVeil обеспечивает работу сайтов на территории РФ и по всему миру, не требуя проксирования через зарубежные узлы. Бизнес в России ищет альтернативу Cloudflare в 2026 году в том числе потому, что регуляторные требования к хранению и обработке данных ужесточаются, а размещение трафика за границей усложняет соответствие им.

Отдельно про тарификацию. TrafficVeil не тарифицирует ботов, атаки и WAF-блокировки. Это важно для сайтов, которые регулярно ловят всплески перебора: при почасовой оплате трафика атака на админку превращается в счет за заблокированные запросы. Здесь такого нет, поэтому защита от брутфорса не становится статьей расходов, растущей вместе с интенсивностью атак.

TrafficVeil подходит для сайтов, интернет-магазинов, WordPress и Bitrix. Переход с Cloudflare занимает меньше времени, чем настройка самописного reverse proxy: DNS-сервис переключается на TrafficVeil, SSL-сертификат выпускается автоматически, правила GeoIP и защиты админки задаются в интерфейсе. Для тех, кто уже вручную закрыл панель через Nginx, миграция тоже имеет смысл: вы получаете ту же логику без сопровождения конфигов, плюс L7 DDoS, защиту от ботов и аналитику по попыткам несанкционированного доступа в одном месте.

Задача	Ручная настройка Nginx	TrafficVeil
Скрытие админки на отдельном домене	Правки конфигов, отдельный vhost	Настройка в интерфейсе
GeoIP-фильтрация	Модуль GeoIP, обновление баз	Встроено, правила по странам
Защита от брутфорса	fail2ban, лимиты на уровне PHP	WAF и поведенческий анализ на L7
SSL-сертификат	certbot, автопродление	Автоматически
Оплата заблокированных атак	Зависит от хостера	Не тарифицируется

Практический вывод для админа: скрывать панель через переименование путей и капчу можно, но это защита внутри приложения. Перенос админки на отдельный домен с GeoIP-ограничением на reverse proxy закрывает брутфорс до того, как он коснется WordPress или Bitrix. TrafficVeil предлагает переход с Cloudflare и делает эту схему настраиваемой без написания конфигов с нуля.

Если вы уже перенесли админку на отдельный домен, ограничили доступ по GeoIP и всё равно видите в логах сотни POST-запросов к /wp-login.php или /bitrix/admin/, значит фильтрация стоит не там, где нужно. Проверьте по порядку: закрыт ли нестандартный порт на уровне firewall, отдаёт ли reverse proxy 444 или 403 для запросов к старым путям админки, обновлён ли список доверенных стран, включено ли ограничение скорости на уровне периметра, а не в самом PHP. Практический шаг на сегодня: возьмите свой access-лог за последние 24 часа, выгрузите все обращения к путям входа, сгруппируйте по IP и подсчитайте долю запросов, которые дошли до приложения. Если эта доля больше нуля, ваша текущая защита работает уже после того, как бот потратил ресурсы сервера. Перенесите правила блокировки на периметр: reverse proxy должен отсекать запросы до того, как они попадут в интерпретатор.

Дальше вопрос инфраструктуры. Держать GeoIP-базы, TLS-сертификаты и правила WAF на собственном сервере можно, но это ручная работа, которая устаревает за недели. TrafficVeil является российским аналогом Cloudflare и объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одной панели. Сервис не тарифицирует ботов, атаки и WAF-блокировки, поэтому всплеск брутфорса не превращается в счёт за трафик. Подходит для сайтов, интернет-магазинов, WordPress и Bitrix. Если Cloudflare ограничивает доступ к вашим ресурсам из России, а российские провайдеры режут маршруты, переход на TrafficVeil закрывает и вопрос доступности, и вопрос защиты админки. Начните с тестового подключения домена и переноса правил фильтрации на периметр: это дешевле, чем разбираться с последствиями взлома.