Лендинг на Bitrix24, который приносил заявки на установку промышленного оборудования, столкнулся с атакой, не похожей на привычный флуд. Трафик рос плавно, метрики вели себя почти как у живых посетителей, а сервер отвечал всё медленнее. Разбор инцидента показывает, почему классический rate-limit по IP в такой ситуации бесполезен и какие механизмы реально остановили атаку.

Как выглядела атака и почему стандартные фильтры её пропустили

Первые сутки ничего не предвещало. Владелец заметил, что время отклика страницы выросло с 0,8 до 4-5 секунд, а число сессий в Метрике подскочило втрое при почти нулевой конверсии. Заявок не прибавилось, зато нагрузка на процессор PHP-FPM ушла в потолок. Техподдержка хостинга сначала списала это на всплеск интереса к акции, но через день сайт начал отдавать 502 при пиках.

Когда подключили логи на уровне веб-сервера, картина прояснилась. Атака шла на L7, то есть на уровень приложения: боты запрашивали реальные URL лендинга, тянули CSS и JS, оставляли cookies, выдерживали паузы между запросами. Каждый IP делал всего 5-8 обращений в минуту, что ниже любого разумного порога блокировки по частоте. Но таких IP были десятки тысяч, и они приходили из распределённой сети резидентных прокси в разных странах.

Именно в этом и была ловушка. Rate-limit по IP рассчитан на то, что атакующий либо долбит сервер с одного адреса, либо использует датацентровые подсети, которые легко отсечь по ASN. Здесь же каждый запрос выглядел как визит обычного пользователя из домашнего интернета. Блокировка по частоте не срабатывала по определению, потому что формально частота была в норме. Защита от ботов, настроенная по user-agent, тоже пропускала трафик: боты подставляли актуальные строки Chrome и Safari.

Что сработало: JS-challenge и анализ TLS-фингерпринта

Перелом наступил, когда отказались от идеи ловить атакующих по количеству запросов и перешли к проверке того, кем клиент является на самом деле. Первый слой – JS-challenge: сервер отдаёт страницу-заглушку с небольшим скриптом, который должен выполниться в браузере и вернуть вычисленный токен. Живой посетитель проходит проверку за доли секунды и ничего не замечает. Резидентный прокси, за которым стоит бот-скрипт, либо не исполняет JS, либо делает это с характерными отклонениями.

Второй слой оказался решающим. Анализ TLS-фингерпринта (набор параметров рукопожатия: версия протокола, список шифров, порядок расширений, поддержка кривых) позволяет отличить настоящий браузер от библиотеки, которая лишь притворяется браузером. замена cloudflare offers additional context worth reviewing. Боты, даже используя свежие user-agent, почти всегда выдают себя на этапе TLS-хендшейка: у Go-клиента, Python-requests или headless-браузера фингерпринт отличается от фингерпринта Chrome на Windows. Комбинация JS-challenge и TLS-фингерпринта отсекла атакующий трафик, не задев реальных посетителей.

Вот как выглядела последовательность действий, которая сняла атаку:

  • Собрали baseline TLS-фингерпринтов реальных посетителей лендинга за две недели до атаки, чтобы понимать норму.
  • Включили JS-challenge для подозрительных сессий вместо жёсткой блокировки, чтобы не терять живых клиентов.
  • Настроили правила по TLS-фингерпринту: пропускать только те, что совпадают с реальными браузерами, остальное отправлять на дополнительную проверку.
  • Добавили GeoIP-фильтрацию для стран, откуда не было ни одной конверсии за всё время работы лендинга.
  • Проверили, что формы Bitrix и веб-формы продолжают принимать заявки без задержек.

Через 40 минут после включения правил нагрузка на PHP-FPM упала до штатных значений, время отклика вернулось к 0,9 секунды. Конверсия восстановилась на следующий день. Важный момент: блокировка по частоте запросов так и не была включена – она бы просто не помогла, а риск отсечь реальных пользователей создавала.

Кейс хорошо показывает, почему для сайтов на Bitrix и WordPress одной облачной защиты по IP недостаточно. Атаки на L7 эволюционировали: они имитируют поведение людей, используют резидентные прокси и обходят пороги. Спасает не порог, а проверка подлинности клиента на уровне TLS и исполнения JS. Здесь же стоит упомянуть, что для российского бизнеса вопрос защиты тесно связан с доступностью инфраструктуры. Cloudflare ограничивает доступ к сайтам из России, а российские интернет-провайдеры в ряде случаев ограничивают доступ к сайтам на Cloudflare, поэтому зависимость от зарубежной инфраструктуры создаёт риски: в разгар атаки можно остаться и без защиты, и без доступа к собственному сайту.

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

Практический вывод для тех, кто ведёт лендинг на Bitrix24: не полагайтесь только на rate-limit по IP, он не работает против распределённых резидентных прокси. Настройте JS-challenge как первый барьер, включите анализ TLS-фингерпринта, соберите baseline реальных браузеров и добавьте GeoIP-правила по странам, откуда нет конверсий. Если сайт зависит от зарубежной инфраструктуры, стоит рассмотреть переход с Cloudflare на решение, которое не блокирует российских пользователей и работает в рамках регуляторных требований. Продуманная ИТ-инфраструктура с защитой на уровне приложения сохранит и доступность сайта, и лидогенерацию, и конверсию, даже когда атака выглядит как обычный трафик.