Такой разный «отказ в обслуживании»
Среди огромного количества сценариев DDoS-атак «трендом» в последнее время становится метод усиления атаки посредством некорректно настроенных ресурсов Сети. Например, злоумышленник может отправить 100 байт (условно) специальным образом сформированного запроса к DNS-резолверу, и тот, в свою очередь, отправит 1 Кб ответа на ресурс жертвы. Можно только представить, что будет, если злоумышленник отправит подобные запросы от своего небольшого ботнета к огромному списку DNS-резолверов. Кстати, данный ботнет не обязательно может состоять из зараженных станций — в него также могут входить инстансы какого‑нибудь публичного облака. Добавим сюда публичные веб‑сервисы нагрузочного тестирования, с помощью которых можно реализовать атаку типа SaaS Amplification (о ней мы писали в статье «Любой стресс за ваши деньги», выпуск #175), и получим довольно увесистую «кувалду» для веб‑приложения.
Точка отказа
Задача владельца любого веб‑проекта, успешность которого прямо зависит от его аптайма, — определить точку отказа веб‑приложения. Знание данного значения позволит подобрать соответствующие защитные решения и выделить для этого нужный бюджет. Для поиска точки отказа необходимо периодически проводить процедуру стрессового тестирования. Или, другими словами, DDoS’ить себя.
Условно процедуры определения реакции информационной системы на ту или иную нагрузку можно разделить на три варианта:
- нагрузочное тестирование (load-testing) — определение реакции системы и ее работоспособности при некоторой заранее заданной (планируемой, рабочей) нагрузке;
- тестирование отказоустойчивости (stress-testing) — анализ поведения информационной системы при аномальной нагрузке (например, при DDoS-атаках);
- тестирование производительности (performance testing) — комплексный подход, сочетающий в себе два предыдущих метода тестирования.
Данная классификация весьма условна, поэтому под термином «стрессовое тестирование» будет пониматься процедура проверки отказоустойчивости информационной системы при DDoS-атаках.
Ключевая особенность данной процедуры, в отличие от типичной DDoS-атаки, — обязательно должна быть методика проведения тестов. Кроме того, у стрессового тестирования есть несколько важных нюансов:
- тесты проводятся на информационной системе, компоненты которой находятся в Сети и доступны ее пользователям;
- сценарии проведения тестов включают в себя нагрузку, которая имитирует действия нарушителя;
- планирование и учет аспектов проведения процедур тестирования выполняются до этапа реализации сценариев атак. Тесты проводятся сериями, с постепенно нарастающей нагрузкой (10, 25, 50, 75%) от предполагаемого предельного уровня нагрузки (обращений в секунду). В ходе тестирования измеряется время отклика тестируемых ресурсов, позволяющее определить, как работы влияют на информационную систему.
Система стрессового тестирования
Средство реализации методики мы назовем системой стрессового тестирования и попробуем дать ей слегка «академическое» определение, чтобы не путать ее с ботнетом.
Система стрессового тестирования (ССТ) — программный комплекс, обеспечивающий проверку информационной системы на устойчивость к атакам типов «отказ в обслуживании» и «распределенный отказ в обслуживании» с целью выявить предельную нагрузку, которую способна принять на себя данная система от легитимных пользователей, а также от потенциальных нарушителей.
Наш программный комплекс должен решать следующие задачи:
- Реализация DDoS-сценариев. С целью комплексной оценки отказоустойчивости ИС в полной мере должны быть реализованы сценарии распределенных атак для исчерпания канальных и вычислительных ресурсов.
- Централизованное управление. По аналогии с бот‑сетями: клиенты получают задание из единого центра, что очень удобно. Не нужно беспокоиться о своевременном получении команды конкретным клиентом. Факты получения, выполнения, успешного или неуспешного завершения задачи легко фиксируются, что позволяет вести детальную статистику.
- Распределенная архитектура. Распределенная архитектура позволит фактически разделить функциональные роли системы и соответствующим образом организовать установку и настройку каждого компонента с учетом особенностей конкретной вычислительной среды.
- Поддержка модульности архитектуры ПО. Возможность расширения функциональности компонентов, непосредственно отвечающих за реализацию сценариев атак, при помощи модулей позволяет сохранять актуальность базы сценариев проведения атак.
- Наличие механизмов мониторинга состояния целевой информационной системы и предотвращения ее выхода за пределы пиковой нагрузки. Для принятия соответствующих мер при оценке текущего уровня нагрузки и построения прогнозов развития атаки необходимо получать актуальную информацию о состоянии целевой ИС от индикатора нагрузки, компонент которого должен быть частью СНТ.
- Формирование статистической информации в процессе стрессового тестирования. С целью оценки функционирования средств защиты целевой ИС на различные типы сценариев стрессового тестирования ССТ должна обладать механизмами ведения статистики в процессе проведения тестов.
Теперь перейдем к компонентам ССТ.
Компонент нагрузки (Load Component) — клиентская часть системы, основная функция которой — генерировать нагрузку в соответствии с полученной задачей. Задачи поступают от административного центра сети, а соответственно, компонент нагрузки должен обладать средствами переконфигурирования в реальном времени, то есть иметь возможность:
- запустить задачу;
- передать свое текущее состояние административному центру;
- прекратить выполнение задачи.
Компонент администрирования/распределения (Distribution Component) — административная часть сети, выполняющая следующие функции:
- получение команд от оператора;
- прием данных о текущем состоянии компонентов загрузки;
- формирование задачи на основе данных, поступающих от оператора и компонентов нагрузки;
- передача заданий компонентам нагрузки;
- демонстрация оператору результатов выполнения заданий.
Индикатор — компонент ССТ, который отвечает за сбор и анализ статистической информации о тестируемой информационной системе и выполняет следующие действия:
- формирование статистической информации в процессе стрессового тестирования;
- приведение статистической информации в удобочитаемый вид;
- передача статистической информации оператору;
- определение реакции целевой ИС на попытки ее легитимного использования;
- передача компоненту распределения запроса на остановку текущей задачи, в случае приближения нагрузки целевой ИС к пиковым показателям.
Система имеет в основе клиент‑серверную архитектуру с так называемым «толстым» клиентом — то есть клиентская часть берет на себя все необходимые данные для расчетов у сервера и затем обращается к нему только с определенным результатом. Задача сервера: корректно обработать запросы клиентов и синхронизировать имеющиеся данные между ними, при этом правильно демонстрировать результаты администратору сети.
Согласно перечисленным требованиям и описанной концепции была разработана система стрессового тестирования и успешно показала себя в ходе тестирования веб‑приложения крупного спортивного мероприятия. К сожалению, масштабы колонки не позволяют рассказать о практической части данного исследования, поэтому мы подготовили видео, на котором зафиксирован процесс «поиска точки отказа». Видео, а также комментарии к нему ты найдешь по ссылкам.