Skip to content

Как читать DDOS-отчёт

Эта страница помогает интерпретировать отчёт DDOS-тестирования в NRunner. Она ориентирована на специалистов ИБ и тех, кто анализирует устойчивость сервиса под нагрузкой.

С чего начать

Сначала смотрим блок Итоговые метрики. Он показывает общую картину за весь тест:

  • Запросы — сколько успешных сетевых попыток агенты смогли выполнить за весь тест. Это успешная отправка нагрузки на сетевом уровне.
  • Ошибки — сколько попыток не прошло. Это могут быть timeout, refused connection, reset, недоступность порта, фильтрация firewall/rate limit или перегрузка цели.
  • Мин./сред./макс. зап/с — диапазон фактической интенсивности нагрузки. Если средний RPS сильно ниже ожидаемого, надо смотреть агрессивность, диапазон портов, доступность цели и сетевые ограничения.
  • Мин./сред./макс. задержка — насколько быстро цель принимала или обрабатывала успешные сетевые попытки. Рост задержки обычно означает деградацию под нагрузкой.

Пример чтения итоговых метрик

Допустим, в отчёте указано:

  • всего успешных запросов: 477 176
  • ошибок: 7 964
  • средний RPS: 795 зап/с
  • максимальный RPS: 4 253 зап/с
  • средняя задержка: 4,11 мс
  • максимальная задержка: 111,64 мс

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

Как читать график «Метрики по секундам»

На графике важно смотреть не отдельную точку, а динамику.

  • Если линия RPS высокая и стабильная, а ошибок мало, цель выдерживает нагрузку.
  • Если RPS падает, а ошибки растут, цель, сеть или защитные механизмы начинают отбрасывать соединения.
  • Если RPS падает, но ошибок нет, возможно, агент упёрся в timeout/latency, широкий диапазон портов, ограничения ОС или сеть.
  • Если задержка растёт, но ошибки ещё не растут, это ранний признак деградации. Сервис пока отвечает, но уже медленнее.
  • Если есть резкие пики RPS, это нормальная картина для сетевой нагрузки, особенно если часть соединений быстро открывается и закрывается. Важно смотреть, сопровождаются ли пики ошибками и задержкой.

Как трактовать вкладки графика

Зап/с

Показывает интенсивность нагрузки. Нужен, чтобы понять, сколько нагрузки реально дошло от агента до цели.

Задержка

Показывает скорость успешных попыток. Если задержка большая или растёт, значит цель или сеть начинают отвечать медленнее.

Запросы и ошибки

Это самая полезная вкладка для анализа устойчивости. На ней видно, в какие секунды успешные попытки идут нормально, а где начинаются отказы.

Что считать проблемным сигналом

Проблема есть, если:

  • ошибки появляются регулярно, а не единичными всплесками;
  • ошибки растут ближе к концу теста;
  • средняя или максимальная задержка резко увеличивается;
  • RPS сначала высокий, потом проседает;
  • при росте нагрузки появляется много errors;
  • результаты сильно отличаются между портами или протоколами;
  • цель становится недоступной после теста или во время него.

Что не стоит считать проблемой автоматически

Не каждый error означает уязвимость или аварию. Ошибки могут быть ожидаемыми, если:

  • порт закрыт;
  • firewall режет соединения;
  • выбран слишком широкий диапазон портов;
  • нагрузка идёт на UDP;
  • агент физически не может создать больше соединений;
  • защита сработала штатно.

В таком случае это не обязательно означает, что сервис упал. Но это всё равно полезный результат: видно, где и как инфраструктура ограничивает нагрузку.

Короткая памятка для безопасников

Сначала смотрим итоговые метрики: общий объём успешных запросов, количество ошибок, средний и максимальный RPS, среднюю и максимальную задержку. Затем открываем график по секундам и ищем момент деградации: где начинает падать RPS, расти задержка или появляться ошибки. Высокая задержка означает, что цель отвечает медленнее под нагрузкой. Ошибки означают, что часть сетевых попыток не прошла: это может быть timeout, отказ соединения, фильтрация или перегрузка. Успешные запросы показывают, сколько сетевых попыток агент смог выполнить, но это не равно успешной бизнес-операции приложения.

Документация NRunner