PT AF и UserGate WAF против L7 DDoS: тестируем новые фичи и дополняем балансировщиком

Оба вендора - PT AF и UserGate WAF - в начале этого года объявили об усиленной защите от L7 DDoS и HTTP/2-атак. Для нас это был хороший повод наконец проверить новые возможности в контролируемых условиях, а не ждать, пока что-нибудь произойдёт на продакшне клиента. Провели серию тестов на синтетических паттернах, результаты получились неоднозначными - и это, пожалуй, самое честное резюме.

Что именно тестировали и почему

Контекст: у нас несколько клиентов из КИИ, где WAF стоит в управляемом режиме. После осеннего пилота 2025 мы развернули оба продукта на разных объектах. Оба вендора с января заявляют про L7 DDoS Protection и улучшенную работу с HTTP/2 - это появилось в release notes, подтверждено демо на партнёрских мероприятиях. Мы решили потрогать руками.

Синтетические паттерны для теста - три основных сценария:

• Slowloris-вариации под HTTP/2 - медленные соединения, которые держат поток открытым и не дают серверу его закрыть. HTTP/2 multiplexing добавляет интересный поворот: атакующий может держать один коннект и открывать сотни стримов.
• HTTP Flood с валидными заголовками - высокочастотные запросы, которые выглядят как легитимный трафик. Распределённый источник, реальные User-Agent'ы, случайные URL из sitemap.
• Resource exhaustion через тяжёлые POST - запросы с большими телами на поисковые и форм-эндпоинты, которые вызывают нагрузку на БД.

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

PT AF: хорошо, но не без оговорок

PT AF справился с Slowloris под HTTP/2 уверенно. Новый движок детектирования L7 DDoS действительно видит аномалии на уровне стримов - это не просто rate-limiting по IP, а анализ поведения соединения. Атака на 200 параллельных стримов с одного IP была заблокирована в течение нескольких секунд после начала. Хорошо.

С HTTP Flood история сложнее. PT AF правильно поднял алерты, но при распределённом паттерне (50+ IP, каждый с небольшой частотой запросов) автоматическая блокировка не срабатывала достаточно быстро. Продукт предлагает challenge-механизмы - JavaScript challenge, задержку ответа, - и они работают, но только после того, как аномалия накопилась достаточно, чтобы система её распознала. В нашем тесте это занимало от двух до пяти минут. Для реального DDoS с целью положить сервис - это долго.

Resource exhaustion - здесь PT AF оказался, пожалуй, слабее всего. Он умеет ограничивать размер тела запроса и частоту запросов на эндпоинт, но специфической логики для «тяжёлых POST» без очевидного сигнатурного совпадения нет. Это скорее задача для application-уровня.

UserGate WAF: неожиданно хорошо в одном, слабее в другом

UserGate WAF по HTTP/2 Slowloris показал себя немного хуже PT AF - детектирование работает, но с большей задержкой. Зато на HTTP Flood с распределённым источником UserGate сработал интереснее: у него есть адаптивное ограничение по поведенческому паттерну сессии, которое работает быстрее, чем ML-детекция PT AF на нашем сценарии. Не потому что алгоритм лучше - просто эвристика оказалась точнее для конкретного паттерна.

Resource exhaustion - примерно та же история, что и у PT AF. Оба продукта не были созданы для этого класса защиты.

Где мы дополнили балансировщиком

Честный вывод из тестов: для распределённого HTTP Flood оба WAF на нашем стенде не давали нужной скорости реакции. Пришлось добавить rate-limiting на уровне балансировщика - у клиентов это nginx или HAProxy перед WAF.

Схема получилась двухуровневой. Балансировщик держит грубый rate-limit по IP и по connection rate - это быстро и дёшево, срабатывает за секунды. WAF берёт на себя более тонкие паттерны: сигнатурное обнаружение, поведенческий анализ, challenge-механизмы. Разделение по скорости реакции и глубине анализа.

Настройка rate-limit на nginx - несложная, но с HTTP/2 надо учитывать: limit_req_zone считает запросы, но один HTTP/2-коннект порождает множество стримов, каждый из которых выглядит как отдельный запрос от того же IP. Если атакующий держит мало коннектов с множеством стримов - стандартный nginx rate-limit по IP не поможет. Для этого нужен http2_max_concurrent_streams с разумным значением плюс limit_conn по IP. В нашем случае это закрыло сценарий, который оба WAF обрабатывали медленнее, чем хотелось бы.

Что из этого следует

Новые возможности в PT AF и UserGate WAF по L7 DDoS - это реальный шаг вперёд относительно того, что было год назад. Slowloris под HTTP/2 оба продукта теперь закрывают нормально. Но на более сложных распределённых паттернах полагаться только на WAF - наивно.

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

Мы ещё не закончили с тестами - хотим прогнать slowHTTP-атаки и посмотреть на поведение при HTTPS-терминации на балансировщике. Когда будут новые данные - напишем. Пока методология и первые выводы такие.