Как организовать имитацию DDos-атаки при стресс-тестировании

Драйверы и задачи стресс-тестирования системы защиты

Основными поводами для стресс-тестирования отказоустойчивости сайта и информационной системы (ИС) чаще всего становятся требования регуляторов или инциденты информационной безопасности (ИБ). Хотя, по-хорошему организовывать DDoS-атаку и проверять устойчивость системы необходимо:

• перед запуском — для бизнес-приложений, веб-приложений, сервисов дистанционного банковского обслуживания, управления базами данных и пр.,
• регулярно — для уже используемых, критичных для бизнеса приложений,
• после внесения изменений — при добавлении новых настроек или изменении конфигурации работающих ИС.

В каждом конкретном случае перед стресс-тестированием системы защиты ставится определенная задача. Это может быть проверка «стрессоустойчивости» после внедрения новой функции или оценка отказоустойчивости сайта перед «Черной пятницей», однако в целом симуляция DDoS-атаки дает ответы на следующие вопросы:

1. Где заканчивается нормальный диапазон нагрузки? До какого предельного значения сервис сохранит устойчивость? 

2. Насколько эффективен текущий комплекс средств защиты против DDoS-атак?

3. Насколько эффективны действия провайдера и служб ИБ компании в плане обнаружения и блокировки DDoS-атак?

4. На каком уровне (канала связи, сетевого сервиса и веб-приложения) система наименее устойчива? Какие процессы выйдут из строя первыми?

5. Что сделать, чтобы повысить устойчивость к DDoS-атакам?

Методология тестовой DDoS-атаки

Для организации DDoS-атаки в первую очередь определяется объект тестирования. Допустим, сайт на 1С-Битрикс или виртуальный сервер VPC. Затем выбираются сценарии и средства мониторинга, устанавливаются критерии успешного стресс-теста. Обычно критерием успешного стресс-теста считается факт полного отказа ИС, зафиксированный несколькими инструментами, однако для критичных бизнес-систем могут быть установлены и другие критерии выхода из процесса. Здесь же, на этапе подготовки стресс-тестировании заранее определяется среда и ресурсы для DDoS-атаки.

Важно! DDoS-атаку можно смоделировать в тестовой или производственной среде. В тестовой проверку запускают для снижения рисков. В производственной — когда нет ресурсов для создания дублирующих сред специально под проверку. Или когда важно проверить сервис на бою, в условиях приближенных к реальным.

Для тестирования в производственной среде обязательно составляют график. Он определяет временные интервалы, в которые стресс-тестирование создаст минимум неудобств для пользователей. Например, в выходные или ночное время, если речь идет о проверке отказоустойчивости корпоративного сайта. 

Что касается ресурсов, то для генерации сетевого трафика, имитирующего DDoS-атаку, формируется тестовый кластер. Его составляют из N виртуальных машин, каждая из которых посылает максимально возможное число запросов к серверу. Чтобы рассчитать объем тестового кластера — то самое число N — еще на этапе планирования нужно оценить максимальное количество трафика, прикинуть мощность CPU и посмотреть реальную производительность каждой машины. В Nubes для стресс-тестирования и пентестов построен отдельный кластер. Его мощности хватает на любые виды DDoS-атак, включая HTTP Flood, SYN- Flood, Ping of death от L7 до L3&4 уровней.

Инструменты для организации и мониторинга DDoS-атаки

Выбор инструмента для стресс-тестирования системы защиты определяет сценарий и объект DDoS-атаки. В арсенале QA-инженеров несколько десятков сервисов и утилит: 

1. RadView для тестирования производительности серверных, веб, облачных и мобильных приложений.

2. Apache JMeter для оценки стабильности ИС с разными уровнями нагрузки.

3. Яндекс.Танк, который использует сам Яндекс для оценки производительности веб-сервисов и приложений.

4. LoadRunner для поиска и решения проблем производительности и др. 

У всех свои достоинства и недостатки, так что под каждое исследование сервис подбирается индивидуально. Для оценки производительности DNS-серверов, например, удобно использовать простую утилиту DNSPerf. Отказоустойчивость сайта хорошо тестирует Load Impact. Яндекс.Танк проще встраивать в CI, легко конфигурировать для создания собственных модулей, удобно использовать в системах, где нужна автоматическая остановка теста. LoadRunner хорош для комплексной оценки: с ним можно обнаружить слабые места ИС еще до того, как она будет развернута. Для информационных систем, которые требуют специфических тестов, мы используем специальные инструменты и генераторы трафика, индивидуально подбираем комплекты сервисов и скриптов.   

Мониторинг стресс-тестирования опирается на ключевые показатели процесса. Из базовых это:

• Время отклика как параметр оценки производительности под стрессовой нагрузкой,
• Объем транзакций, который показывает соотношение пройденных и неудачных транзакций за единицу времени тестирования,
• Загрузка процессора при пиковых значениях,
• Пропускная способность, определяющая количество данных, которые сервер под давлением атаки отдает пользователям,
• Использование памяти как метрика объема ресурсов, потребляемых приложением при обработке множественных запросов. 

Дополнительно могут устанавливаться и анализироваться второстепенные целевые индикаторы, например, данные по ошибкам при экстремальных рабочих нагрузках.

По итогам стресс-тестирования системы защиты QA-инженеры формируют отчет с указанием недостатков сервиса. В нашем случае в отчете отмечаются не только проблемные объекты, например, файловые серверы или приложения, но и конкретные узлы. Предельные параметры обозначаются с обязательной интерпретацией результатов и с приложением рекомендаций по устранению узких мест. Выполнив их, вы повысите устойчивость системы к реальным DDoS-атакам и будете уверены, что сервер не упадет, если нагрузка резко вырастет.