На одном проекте для финтех-компании мы согласовали стресс-тест на 50k RPS, запустили генерацию трафика с пяти нод - и через 40 секунд получили звонок от upstream-провайдера. Он отключил канал целиком: наш трафик не отличался от реальной атаки. Тест продолжался меньше минуты, разбор инцидента с провайдером - три дня. Причина банальна: никто не предупредил провайдера и неправильно замаршрутизировали тестовый трафик.
С тех пор каждое DDoS стресс тестирование у нас начинается не с выбора инструмента, а с юридического и организационного пакета. Эта статья - для тех, кто понимает, зачем нужна нагрузочная проверка, но хочет провести её без последствий для бизнеса и для собственной свободы.
Юридическая граница между стресс-тестом и атакой
Разница между легальным нагрузочным тестированием DDoS и уголовно наказуемым деянием - один документ. Без подписанного Rules of Engagement (ROE) любая генерация аномального трафика в адрес чужого IP формально подпадает под статью 272 или 273 УК РФ. Даже если "чужой" IP принадлежит вашему заказчику.Минимальный пакет ROE:
- Перечень целевых IP-адресов и доменов - только то, что входит в scope. Поддомены, CDN-адреса, API-шлюзы перечисляются явно. Что не указано - не тестируется.
- Временное окно - конкретные даты и часы. Провайдеры и SOC заказчика должны знать точное расписание.
- Максимальные параметры нагрузки - потолок по RPS, Mbps, количество одновременных соединений. Превышение = нарушение scope.
- Процедура экстренной остановки (Kill Switch) - кто принимает решение, по какому каналу связи, за сколько секунд трафик должен прекратиться.
- Уведомление третьих сторон - upstream-провайдер, облачный хостинг, CDN-вендор. Без уведомления провайдер имеет полное право заблокировать канал - как в кейсе из вступления.
Отдельная история - Cloudflare и аналогичные CDN. Если тестируемый ресурс стоит за CDN, а вы генерируете трафик на edge-сервер без уведомления вендора, вы фактически атакуете инфраструктуру третьей стороны. Это уже выходит за рамки ROE, даже если заказчик подписал разрешение на свой домен.
Архитектура стенда и подготовка к тесту
Требования к окружению
Прежде чем запускать первый пакет, убедитесь, что инфраструктура тестирования тянет:- Генераторы трафика: минимум 2-5 виртуальных машин (4 vCPU, 8 ГБ RAM, SSD, сетевой интерфейс 1 Gbps каждый). Для волюметрических тестов свыше 10 Gbps - выделенные bare-metal серверы или облачные инстансы c10-класса.
- ОС: Ubuntu 22.04 LTS или Debian 12 - стабильные ядра с предсказуемым поведением сетевого стека.
- Сетевая связность: генераторы в отдельном сегменте от production, с маршрутизацией трафика через контролируемый канал. Тестировать "через интернет" можно, но только после уведомления всех транзитных провайдеров.
- Мониторинг: отдельный стек (Prometheus + Grafana или аналог) для сбора метрик с целевой инфраструктуры в реальном времени. SIEM заказчика настроен на запись всех событий в период теста.
- Канал связи с заказчиком: отдельный чат или голосовая линия для экстренной координации. Не email - время реакции на kill switch не должно превышать 30 секунд.
Базовые замеры (baseline)
Согласно NIST CSF 2.0 (DE.AE-01), перед любым стресс-тестом нужно зафиксировать baseline - нормальное состояние инфраструктуры: латентность, утилизацию CPU и RAM, пропускную способность, количество активных соединений, среднее время отклика приложения. Без baseline вы не сможете оценить деградацию - только зафиксируете момент полного отказа. А это куда менее информативно.Baseline снимается в рабочие часы с реальной пользовательской нагрузкой. Идеально - 24-часовой срез с разбивкой по часам.
L3/L4: волюметрическое и протокольное тестирование
Тестирование на сетевом уровне моделирует два класса атак из MITRE ATT&CK:
- Direct Network Flood (T1498.001, Impact) - прямое насыщение канала объёмом трафика: UDP flood, ICMP flood, фрагментированные пакеты.
- Reflection Amplification (T1498.002, Impact) - отражённые атаки через DNS, NTP, SSDP, Memcached. На стенде вы не используете чужие рефлекторы, а эмулируете amplified-трафик напрямую.
Инструменты и команды:
Для SYN flood -
hping3, утилита из стандартного набора Kali Linux (последнее обновление: 2014, проект неактивен, но стабилен и используется повсеместно):
Bash:
# SYN flood на порт 80 с рандомизацией source IP
hping3 -S --flood -V -p 80 --rand-source <target_ip>
# SYN flood с контролируемой скоростью (100 пакетов/сек)
hping3 -S -p 443 -i u10000 --rand-source <target_ip>
# UDP flood на DNS-порт
hping3 --udp -p 53 --flood --rand-source <target_ip>--rand-source генерирует spoofed source IP. Для реалистичности - отлично. Но работает только в средах без BCP38 (anti-spoofing) на маршрутизаторах. В облаке spoofing заблокирован на уровне гипервизора - тест с --rand-source на AWS EC2 просто не отправит пакеты. Для облака используйте реальные IP нескольких генераторов без спуфинга.Для более тонкого контроля над пакетами - Scapy (Python-библиотека). Scapy позволяет конструировать произвольные пакеты: фрагментированные UDP, malformed TCP с нестандартными флагами, пакеты с определённым TTL для тестирования поведения маршрутизаторов.
Ограничения L3/L4-тестирования
Волюметрический тест показывает поведение сетевой инфраструктуры, но у него есть фундаментальные ограничения, и о них нужно знать заранее:- Stateful firewall (Palo Alto, FortiGate, Check Point) - отбрасывает SYN flood до приложения. Тест покажет предел самого firewall, но не приложения за ним.
- Cloud-based Anti-DDoS (Cloudflare, AWS Shield Advanced, Qrator) - scrubbing-центры поглощают волюметрический трафик на периметре. Тестировать L3/L4 на ресурсе за scrubbing-центром без координации с вендором бессмысленно: вы увидите предел канала до scrubbing-центра, а не защищённую инфраструктуру.
- Пропускная способность тестового стенда - 5 машин по 1 Gbps = потолок около 5 Gbps. Рекордная DDoS-атака 2025 года достигла 31.4 Tbps (по данным UZCert). Для тестирования на таких объёмах нужны коммерческие платформы с собственной инфраструктурой.
L7: тестирование прикладного уровня
Прикладной уровень - самый опасный в реальных атаках и самый информативный при тестировании. Здесь моделируются техники MITRE ATT&CK:
- Endpoint Denial of Service (T1499, Impact) - общий класс.
- Service Exhaustion Flood (T1499.002) - исчерпание пула соединений, переполнение очередей.
- Application Exhaustion Flood (T1499.003) - атака на логику приложения: тяжёлые запросы к БД, запросы к ресурсоёмким endpoint'ам (поиск, фильтрация, генерация отчётов).
Главное отличие от L3/L4: для Application Exhaustion Flood (T1499.003) не нужна огромная полоса. Достаточно найти эндпоинт, обращение к которому вызывает тяжёлый SQL-запрос или ресурсоёмкие вычисления. Один запрос в секунду может положить сервис, который спокойно выдерживает 10 Gbps чистого SYN flood. Я видел такое на трёх проектах - и каждый раз проблема была в неиндексированном полнотекстовом поиске.
Инструменты:
k6 (Grafana Labs, активный проект, последний релиз - 2025) - генератор HTTP-нагрузки с JavaScript-описанием сценариев:
JavaScript:
import http from 'k6/http';
import { check } from 'k6';
export const options = {
stages: [
{ duration: '2m', target: 500 }, // ramp-up до 500 VU
{ duration: '5m', target: 5000 }, // удержание 5000 VU
{ duration: '1m', target: 0 }, // ramp-down
],
};
export default function () {
const res = http.get('https://target.example.com/api/search?q=test');
check(res, { 'status 200': (r) => r.status === 200 });
}stages реализует градуальное наращивание нагрузки - один из ключевых принципов безопасного DDoS стресс тестирования. Вы не бьёте максимумом сразу, а поднимаете трафик ступенчато, фиксируя деградацию на каждом шаге.Locust (Python, активный проект) - альтернатива k6 для тех, кто предпочитает Python. Удобен для сложных сценариев с авторизацией и многоступенчатой логикой. Мне он нравится за читаемость сценариев, но k6 быстрее в чистой генерации RPS.
Slowloris-подход - удержание максимального количества открытых соединений с минимальным трафиком.
slowhttptest моделирует это: slowhttptest -c 5000 -H -g -o results -i 10 -r 200 -t GET -u https://target.example.com. Техника работает против серверов без ограничений на количество keep-alive соединений - Apache с mod_prefork в дефолте, nginx без limit_conn.Когда L7-тест не даёт реальной картины
- WAF с rate limiting (ModSecurity, Cloudflare WAF, AWS WAF) - фильтрует однотипные запросы. Для обхода нужно варьировать User-Agent, query-параметры, пути. Но это уже не стресс-тест, а проверка WAF-правил - другая задача.
- CDN-кеширование - если endpoint кешируется на edge, нагрузка не доходит до origin. Для проверки origin-сервера тестируйте некешируемые эндпоинты: POST-запросы, страницы с авторизацией, API с динамическим ответом.
- Автоскейлинг (Kubernetes HPA, AWS Auto Scaling) - инфраструктура масштабируется под нагрузку, и тест покажет стоимость масштабирования, а не точку отказа. Тоже полезная информация, но отвечает на другой вопрос. (На одном проекте заказчик узнал, что его автоскейлинг при DDoS жрёт $12k/час в AWS - после этого резко захотел настроить rate limiting.)
Метрики мониторинга во время DDoS стресс теста
Согласно NIST CSF 2.0 (RS.AN-01), каждое уведомление от систем детекции должно быть зафиксировано и расследовано. Во время стресс-теста мониторинг ведётся по двум осям: инфраструктура цели и поведение защитных средств.Инфраструктурные метрики:
| Метрика | Что показывает | Критический порог |
|---|---|---|
| CPU utilization | Исчерпание вычислительных ресурсов | >90% устойчиво более 60 секунд |
| RAM utilization | Утечка памяти под нагрузкой | >85% с трендом роста |
| Время отклика (p95, p99) | Деградация для конечного пользователя | >3x от baseline |
| Packet loss | Потеря пакетов на уровне сети | >1% |
| Количество активных соединений | Исчерпание пула соединений | >80% от max_connections |
| Ошибки 5xx | Отказ приложения | >5% от общего числа ответов |
Метрики защитных средств:
- False positive rate - сколько легитимных запросов заблокировано WAF/Anti-DDoS во время теста. Если false positive > 2%, защита настроена слишком агрессивно.
- Время детекции - через сколько секунд после начала теста сработал алерт в SIEM/SOC. Если SIEM не зафиксировал аномалию за 60 секунд - проблема с правилами детекции. Это, кстати, один из самых ценных результатов стресс-теста: не "выдержал ли сервер", а "заметил ли SOC".
- Время автоматической митигации - для систем с автоматическим реагированием (Cloudflare Under Attack Mode, AWS Shield Advanced auto-mitigation): сколько секунд от начала аномалии до активации фильтрации.
Open-source и коммерческие платформы: что выбрать
Выбор инструмента определяется масштабом теста, бюджетом и требуемым реализмом. Trade-off таблица:| Критерий | Open-source (hping3, k6, Locust) | Коммерческие (BreakingPoint, Red Button, RedWolf) |
|---|---|---|
| Максимальный объём трафика | Ограничен мощностью ваших серверов (типично до 10 Gbps) | Десятки-сотни Gbps с глобально распределённых нод |
| Реализм multi-vector атак | Требует ручной оркестрации нескольких инструментов | Готовые сценарии с комбинацией L3/L4/L7 |
| Стоимость | Бесплатно (+ стоимость инфраструктуры) | От $5,000 за разовый тест до $50,000+ за годовую подписку |
| Kill Switch | Ручной (kill процесса, SIGTERM) | Аппаратный / программный с гарантированным временем |
| Отчётность | Ручная сборка из логов и метрик | Автоматический отчёт с графиками и рекомендациями |
| Когда достаточно | Внутренняя проверка, тест конкретного endpoint, small/medium бизнес | Compliance-тестирование, финтех, критическая инфраструктура, страховые требования |
| Когда не подходит | Волюметрические тесты > 10 Gbps, регуляторные требования к отчётности | Бюджет < $5,000, ad-hoc проверка одного сервиса |
По данным обзора UZCert, среди коммерческих платформ для DDoS-симуляции в 2026 году выделяются Red Button (управляемые тесты с экспертной поддержкой), RedWolf Security (self-service с крупномасштабной инфраструктурой), NimbusDDOS (обучение SOC-команд), Keysight BreakingPoint / CyPerf (лабораторное тестирование) и Cyttack.ai (SMB-сегмент). Keysight BreakingPoint - аппаратная платформа, которую я использую на стендах для тестирования пограничных устройств: она генерирует трафик на уровне line rate (40/100 Gbps) с точным контролем протоколов. Дорого, но для тестирования NGFW ничего лучше пока не встречал.
Для большинства задач нагрузочного тестирования DDoS на L7 связки k6 + Grafana + Prometheus хватает за глаза. L3/L4 с реалистичным объёмом - территория коммерческих решений.
Структура отчёта по результатам тестирования
Отчёт - единственный артефакт, который останется после теста. Без структурированного отчёта стресс-тест превращается в потраченные деньги без actionable выводов.Минимальная структура:
- Резюме для руководства - 1 страница. Цель теста, ключевой результат (например: "приложение деградирует до неприемлемого уровня при 3,200 RPS на endpoint /api/search"), критичность (высокая/средняя/низкая).
- Параметры тестирования - scope, временное окно, используемые инструменты, максимальные параметры нагрузки.
- Результаты по сценариям - для каждого вектора (SYN flood, HTTP flood, Slowloris, multi-vector): графики деградации, точки отказа, поведение защитных средств, время детекции.
- Обнаруженные уязвимости - конкретные weak points с привязкой к компоненту: "балансировщик nginx: пул соединений исчерпан при 12,000 одновременных TCP-сессий, конфигурация worker_connections=1024". Привязка к OWASP A05:2021 (Security Misconfiguration) - если проблема в конфигурации, а не в архитектуре.
- Рекомендации - приоритизированный список. Формат: проблема -> рекомендация -> ожидаемый эффект. Пример: "увеличить worker_connections до 16384, настроить limit_conn_zone в nginx -> повысит порог отказа с 12,000 до ~50,000 одновременных соединений".
- Baseline-сравнение - таблица "было до теста / стало под нагрузкой / стало после восстановления". Время восстановления (recovery time) - критически важный показатель, который упускают в большинстве отчётов.
Непрерывное тестирование vs разовые проверки
Разовый стресс-тест даёт snapshot устойчивости на конкретную дату. Через месяц деплоится новый микросервис, меняется конфигурация nginx, обновляется WAF-правило - и результаты теста теряют актуальность. Red Button прямо указывает: configuration drift между ежегодными тестами - основная причина, по которой инфраструктура, прошедшая тест в январе, ложится от реальной атаки в сентябре.Для критичных систем (финтех, e-commerce, SaaS):
- L7-тесты - после каждого значимого деплоя (автоматизируются через CI/CD с k6 или Locust).
- L3/L4-тесты - ежеквартально или после изменений сетевой топологии.
- Полный multi-vector тест - раз в 6–12 месяцев, с привлечением коммерческой платформы для реалистичного объёма.
Чеклист перед запуском DDoS стресс теста
Пункт 7 пропускают чаще всего - и зря. На одном из проектов kill switch представлял собой SSH-сессию на генератор с командой
killall hping3. Когда понадобилось экстренно остановить тест, SSH-сессия отвалилась из-за перегрузки того же канала, по которому шёл тестовый трафик. С тех пор kill switch у нас всегда работает через out-of-band канал: отдельный VPN, мобильная сеть, IPMI. Без вариантов.Семь лет в нагрузочном тестировании научили одной вещи: инженеры обожают обсуждать инструменты - hping3 vs Scapy, k6 vs Locust, BreakingPoint vs Red Button. Но 80% провалов стресс-тестов, которые я видел, не связаны с выбором инструмента. Никто не уведомил провайдера, не настроил kill switch, не зафиксировал baseline, не согласовал scope с юристами. Инструмент - последние 20% задачи.
Ещё один неудобный факт: большинство компаний, которые заказывают стресс-тест, хотят не проверить устойчивость, а получить бумагу для комплаенса. И когда тест показывает, что приложение ложится при 2,000 RPS на эндпоинт поиска, реакция чаще всего - "давайте не будем включать это в отчёт". Полноценное DDoS стресс тестирование имеет смысл только когда заказчик готов действовать по результатам, а не прятать их. Проверьте свой kill switch прямо сейчас - если он работает через тот же канал, что и тестовый трафик, у вас та же проблема, что была у нас.
Последнее редактирование модератором:
