Разбор атаки: сканер уязвимостей против прокси Multify

29 мая 2026 года, 17:04. К прокси-серверу Multify подключились два IP-адреса из Кот-д'Ивуара. За следующие 90 секунд они перебрали почти 100 URL и получили 100 отказов.

Это типичная работа сканера уязвимостей. Не целенаправленный взлом, а автоматическая разведка. Такие сканеры работают непрерывно, обходя миллионы сайтов в поисках одного: открытого файла с ключами, паролями или конфигурацией, либо известной уязвимости в CMS. Неважно на чём стоит сайт — WordPress, Drupal, Joomla или самописный движок. Сканер проверяет всё подряд по стандартному словарю.

Multify как обратный прокси принимает весь входящий трафик на себя. Сканер стучится в инфраструктуру Multify, а не напрямую к сайту клиента. Защита прокси — это и есть защита клиентских сайтов.

Вот список из реального лога:

`` /.env /.env.production /.env.local /.env.bak /wp-config.php /config/database.php /config/secrets.yml /azure-credentials.json /gcp-credentials.json /private.key /database.sql /dump.sql ``

Это не случайный набор, а стандартный словарь, составленный из реальных утечек. Каждый файл в этом списке когда-то нашли в открытом доступе на чьём-то продакшн-сервере.

Переменные окружения — файлы .env и их варианты. В них разработчики хранят ключи API, пароли к базам данных, токены платёжных систем. Один такой файл даёт атакующему полный доступ к инфраструктуре без каких-либо следов взлома. По данным GitGuardian, в 2024 году секреты в публичных репозиториях обнаруживались более 12 миллионов раз, .env в тройке самых частых. Разработчик добавляет файл в .gitignore, но на сервере после деплоя он остаётся в публичной директории, и никто не проверяет.

Конфиги CMS и фреймворков — wp-config.php (WordPress), конфиги Joomla, Drupal, файлы Laravel, Symfony, Rails. Сканер не знает, на чём написан сайт, поэтому проверяет все популярные варианты подряд.

Облачные ключи — gcp-credentials.json, azure-credentials.json, service-account.json, terraform.tfvars. Попадание означает доступ к облачному аккаунту со всеми данными и потенциальными счетами на десятки тысяч долларов.

Ключи шифрования — private.key, server.key, rails/master.key. Открытый приватный ключ позволяет расшифровать весь трафик или подделать подписи.

Логи и дампы — error.log, debug.log, database.sql, dump.sql. Логи часто содержат данные пользователей, пути к файлам, иногда пароли в открытом виде.

Конфиги инфраструктуры — nginx.conf, docker-compose.yml, web.config. Из них можно узнать внутреннюю топологию сети и найти следующую точку входа.

Уязвимости CMS — отдельная категория. Как только публикуется новый CVE, сканеры начинают проверять все сайты подряд, часто в течение нескольких часов. По данным Google Project Zero, медиана от публикации CVE до первых атак — 15 дней, но для уязвимостей с публичным PoC это время сократилось до нескольких часов. Пример, который сейчас в активной эксплуатации: CVE-2026-9082, SQL-инъекция в Drupal Core на PostgreSQL (версии 8.0 до 11.3.9). Уязвимость в том, как Drupal строит SQL-запросы через JSON:API: атакующий передаёт в параметре фильтра ключ массива с вложенным SQL, Drupal вставляет его в запрос без санитизации. Без авторизации, через обычный HTTP-запрос. Результат: выгрузка базы данных, создание admin-аккаунта, в некоторых конфигурациях выполнение произвольного кода. CVSS 9.8, критическая (для сравнения: Log4Shell, который положил половину интернета в 2021 году, получил 10.0). Патч вышел 20 мая, рабочий PoC появился на GitHub менее чем через час. 22 мая уязвимость добавили в каталог CISA Known Exploited Vulnerabilities. За первые 48 часов зафиксировано более 15 000 попыток эксплуатации на почти 6 000 сайтах в 65 странах.

Атака 29 мая была именно такой. WAF отработал по сигнатурам OWASP CRS, CrowdSec добавил оба IP в список заблокированных. Клиент об этом не узнал.

Сканер прошёлся по всем категориям сразу, за 90 секунд.

Сканер запустился с двух адресов одновременно. Современные сканеры распределяют нагрузку по нескольким IP, чтобы оставаться ниже порога простых rate-limit правил. Если защита срабатывает на «больше 10 запросов в минуту с одного IP», сканер просто делает по 5 с каждого. При этом сами IP чаще всего не имеют отношения к реальному атакующему — это арендованные VPS, взломанные серверы или ботнет-машины по всему миру. Кот-д'Ивуар здесь случайная география, а не место откуда реально работает человек.

Любопытная деталь из лога: первый запрос второго IP вернул 200 — сканер сначала проверил главную страницу, убедился что сайт живой, и только потом начал перебор. Это признак инструмента, а не случайного трафика.

WAF (Web Application Firewall) — файрвол уровня приложения. В отличие от сетевого файрвола, который смотрит на IP и порты, WAF читает содержимое HTTP-запроса: URL, заголовки, тело. Он анализирует каждый запрос до того, как тот доходит до сайта.

Основа правил — OWASP Core Rule Set (CRS), открытый набор сигнатур атак, который поддерживает некоммерческий фонд OWASP. CRS покрывает перебор файлов конфигурации, SQL-инъекции, XSS и другие распространённые векторы. Запросы к .env, .sql, .key, wp-config.php и десяткам других расширений блокируются сразу. WAF не знает, существует ли файл на сервере — он блокирует по имени запроса, и сканер получает отказ до того, как успевает что-либо узнать.

CrowdSec — открытый движок поведенческого анализа. WAF работает с каждым запросом отдельно, CrowdSec смотрит на последовательность: что именно запрашивает этот IP на протяжении последних минут.

Один запрос к .env может быть ошибкой в ссылке. Десять запросов к .env, .env.production, .env.local, .envrc за 30 секунд — это уже не пользователь. CrowdSec распознаёт этот паттерн по сценариям (поведенческим правилам) и блокирует IP. Заблокированные адреса попадают в общую базу угроз, которой пользуются тысячи серверов по всему миру. Сканер, засечённый на одном сайте, сразу становится нежелательным гостем везде.

Сканер отработал стандартный словарь за полторы минуты и ушёл ни с чем. Сайт клиента не получил ни одного вредоносного запроса.

Когда сайт подключается к Multify, весь входящий трафик идёт через прокси. Клиент подключал Multify для локализации, а не для защиты. Но поскольку прокси стоит перед сайтом, вся защита инфраструктуры Multify автоматически распространяется на него.

Утечки через открытые файлы — один из самых частых векторов взлома. Происходят не из-за сложных эксплойтов, а из-за банальных ошибок: разработчик задеплоил проект и забыл убрать .env. Поставил тестовый дамп базы в публичную папку. Оставил конфиг с паролями на сервере. Сканеры находят такие файлы в течение нескольких часов, задолго до того как кто-то из команды заметит ошибку.

Если сайт клиента работает на Drupal с PostgreSQL — WAF на уровне прокси блокирует характерные паттерны запросов: сложные filter-параметры к /jsonapi, запросы к /user/login?_format=json с нестандартными телами. Сканер не добирается до сайта. Но это не замена патчу: если сайт доступен напрямую в обход прокси, защиты нет.

Современные сканеры распределяют запросы по нескольким адресам, чтобы оставаться ниже порога простых rate-limit правил. CrowdSec смотрит на поведение, а не на количество запросов с одного IP, поэтому такая техника не помогает.

Нет. WAF блокирует запросы по имени пути до того как они доходят до приложения. Сканер не знает, существует ли файл на сервере — он получает отказ на уровне прокси.

Целенаправленная атака сложнее: атакующий знает цель, использует нестандартные векторы и работает медленно, чтобы не попасть в поведенческие паттерны. WAF и CrowdSec снижают поверхность атаки, но не дают стопроцентной гарантии. Для критичных сайтов нужен penetration test и мониторинг аномалий.

Нет. Геолокация IP сканера — это геолокация машины, которую используют, а не атакующего. Блокировка по стране бессмысленна: следующая атака придёт из Бразилии, Нидерландов или России.