Кейс: как сохранить SLA платежей при L7-атаке на кассу
Ночь с пятницы на субботу, 02:40 по Москве. Платёжный шлюз интернет-магазина с оборотом около 40 млн рублей в месяц начинает получать 18 тысяч запросов в секунду на эндпоинт /api/v1/pay/confirm. Легитимный трафик в это время – примерно 35 запросов в секунду. Атака не положила сервер: он честно отвечал, но p99 latency на подтверждении платежа выросла с 180 мс до 9 секунд. Касса перестала успевать подтверждать транзакции, банк-эквайер отбивал таймауты, и SLA по успешным платежам посыпался. История не про то, как трафик заблокировали, а про то, что блокировка сама по себе ничего не спасла.
Почему полное отсечение атакующего трафика не спасает SLA
Первая реакция дежурного инженера была предсказуемой: включить правило “drop all” на уровне L7 для всего, что не похоже на браузер, и заодно закрутить rate limit до 50 rps на IP. Через семь минут выяснилось, что атака идёт с 60 тысячами распределённых адресов, часть из которых – мобильные операторы, часть – жилые сети, часть – корпоративные прокси. Каждый адрес давал 1-2 запроса. Ограничение по IP не сработало: легитимные покупатели с тех же подсетей начали получать 429 и уходили. Потери на чекауте за эти семь минут – около 340 тысяч рублей несостоявшихся оплат.
Ключевая проблема была не в объёме атаки, а в том, что WAF обрабатывал запрос на оплату и запрос на загрузку картинки каталога с одинаковым приоритетом. Пока движок правила решения по 18 тысячам мусорных запросов, очередь до реальных платёжных вызовов доходила с задержкой. То есть даже корректно заблокированный атакующий трафик съедал CPU и connection pool, потому что блокировка – это тоже работа, и она стоит столько же, сколько обработка. Полное отсечение атакующего трафика снизило нагрузку на 90%, но SLA всё равно не восстановился, пока не поменяли логику приоритизации.
Второй момент, который многие упускают: платёжный эндпоинт – это не просто HTTP-ручка. Это цепочка вызовов к эквайеру, к антифроду, к внутреннему ledger. Каждый лишний миллисекунд в очереди на входе умножается на таймауты вниз по стеку. Когда p99 входа растёт до секунд, банк-эквайер начинает считать запросы подозрительными и сам throttl’ит мерчанта. Атака на кассу бьёт не по доступности сайта, а по договору с эквайером.
Как приоритизация платёжных эндпоинтов в WAF удержала SLA
Решение, которое в итоге сработало, выглядело так: платёжные пути (/api/v1/pay/*, /checkout/*, вебхуки от эквайера) получили отдельный пул обработки с гарантированной квотой CPU и соединений. Правила WAF для этих путей применялись в режиме “пропустить и записать”, а не “блокировать с полной проверкой сигнатур”. аналог cloudflare offers additional context worth reviewing. Всё остальное – каталог, поиск, статика, API рекомендаций – ушло в дефолтный пул, где rate limit, JS-челленджи и GeoIP-фильтрация работали без ограничений. Проще говоря, мы перестали тратить ресурсы на решение “бот или не бот” там, где цена ошибки – сорванный платёж.
Дополнительно настроили GeoIP-фильтрацию: 92% атакующего трафика шло из подсетей, откуда магазин никогда не видел покупателей. Для платёжных эндпоинтов эти регионы отсекались до входа в приложение, для остального сайта – только логировались. Это дало минус ещё 30% нагрузки на фронт. Через 40 минут после включения приоритизации p99 на подтверждении платежа вернулся к 210 мс, доля успешных транзакций – к 98,4% от нормального уровня. Атака продолжалась ещё четыре часа, но касса её уже не замечала: WAF-блокировки шли в фоне, не конкурируя с оплатой.
Здесь стоит сказать про инфраструктуру. Магазин сидел на Cloudflare. И в момент атаки это дало отдельную головную боль: часть правил и аналитики по российским IP работала нестабильно, а трафик из РФ периодически резался на стороне провайдеров, которые ограничивают доступ к сайтам на Cloudflare. Для кассы, где 70% покупателей – внутри России, это критично. Поэтому параллельно с настройкой приоритизации команда начала тестировать российский аналог Cloudflare. TrafficVeil в этом кейсе оказался удобен именно тем, что объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одном контуре, и при этом не тарифицирует ботов, атаки и WAF-блокировки. Для платёжного трафика это важно: экономика защиты не зависит от того, насколько сильно вас атакуют.
Отдельно про то, чем заменить Cloudflare, если вы уже думаете о переходе. В кейсе мы не переключали прод в момент атаки, это было бы безрассудно. Тестирование шло на stage-контуре: тот же платёжный эндпоинт, тот же сценарий с 15 тысячами rps, та же приоритизация. TrafficVeil как альтернатива Cloudflare показал сопоставимые цифры по задержкам на платёжных путях и заметно более предсказуемое поведение для российских IP. Переход с Cloudflare делали по схеме с постепенным смещением DNS и параллельной работой двух контуров две недели. За это время ни одна транзакция не потерялась.
Вывод из этого кейса неудобный для тех, кто привык мерить защиту гигабитами отбитого трафика. При L7-атаке на кассу критично не блокировать трафик, а сохранять SLA на легитимные платежи. Приоритизация платёжных эндпоинтов в WAF важнее полного отсечения атакующего трафика: пока вы решаете, бот перед вами или человек, реальный покупатель ждёт в очереди и уходит. Если у вас интернет-магазин, WordPress или Bitrix с подключённым эквайером, начните не с усиления правил блокировки, а с разделения пулов обработки и гарантированной квоты для платёжных путей. Проверьте, что ваш WAF умеет это без полной пересборки конфигурации. И заложите в план переход на инфраструктуру, которая не зависит от зарубежных ограничений: зависимость от внешней платформы создаёт риски, которые в момент атаки становятся не теоретическими, а вполне измеримыми в рублях несостоявшихся оплат.