Как организовать DDoS в благих целях?

[Griboks]

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

А вы точно тестировали свой сервис, а не инфраструктуру AWS? Что мешает вам:
1. запустить генератор напрямую на вход сервиса;
2. провести моделирование;
3. провести всевозможные юнит и интеграционные тесты;
4. уменьшить количество доступных сервису ресурсов (имитация высокой нагрузки);
5. ну или хотя бы менять заголовки, а не «физические» ip?

Поздравляю, вы просто выкинули кучу денег в мусорное ведро.

[VulkanCyberSecurity]

Одной из задач являлась имитация именно распределенной нагрузки. Не во всех проектах возможно поставить генератор непосредственно на «вход сервиса», где-то по техническим причинам, где-то по политическим (инфраструктура может быть гео-распредленная со сложными системами балансировки нагрузки). Инфраструктура AWS не дает подменять заголовки. В свою очередь, предложенный вами метод моделирования тоже имеет право на существование в жизненном цикле разработки продукта, а также при наличии отдельного стенда для тестирования, который может в достаточной степени контролироваться вами.

Касательно уменьшения доступных ресурсов. Идея хорошая, но если говорить о моделировании DDoS в отношении неконтролируемой инфраструктуры, то снова приходим к ограничениям на стороне владельца тестируемого сервиса и поставленной задаче. Например, это может быть «боевой» сервер интернет-магазина, а задача оценить максимальный поток пользователей без деградации сервиса (пример — Black Friday распродажи), или же сайт предвыборной политической кампании.

Кучу денег мы не выкинули, поставленные задачи решили. А благодаря автоматизации еще и сэкономили существенное количество средств, т.к. инстансы быстро поднимались/тушились и работали только в момент генерации трафика.

В целом статья рассматривает ряд отдельных кейсов и показывает один из возможных подходов их решения на основе AWS EC2.

[CentALT]

Почему hyenae не используете?

[VulkanCyberSecurity]

Hyenae больше адаптирован под протоколы нижнего уровня. Предлагаемый подход позволяет при необходимости моделировать более сложное общение с сервисом и подстригаться под специфику конкретной реализации. Это особенно полезно при нагрузочном тестировании L7.

[CentALT]

Что-то не увидел нигде увеличения conntrack таблицы или вообще отключения ее.
У Вас любой пакет в conntrack iptables поступает, и вполне очевидно при атаке эта таблица быстро исчерпается. Соответственно атака DDOS будет успешной.

Также нет информации сколько реально трафика ушло с интерфейсов и сколько пришло.
Покажите данные сколько трафика уходило, сколько пришло в серсвис. Где данные по запросам в секунду на L7 сервисе. Какое ПО использовалось.

[VulkanCyberSecurity]

Посмотрели подробнее про conntrack iptables, да, это нужно внести в настройку, спасибо за замечание. Включение модуля conntrack modprobe ip_conntrack и увеличение conntrack таблицы net.netfilter.nf_conntrack_max = 20000 в /etc/sysctl.conf действительно увеличивает мощность атаки.

Реально с интерфейса на t3.small инстансе уходит в среднем 500Мб/с или 600kpps (для L7). Количество трафика, приходящего в сервис, очень сильно зависит от того, как работает балансировщик (и есть ли он вообще), какие есть anti-DDoS решения, правильно ли они настроены итд. В худшем случае в сервис придет весь отправленный трафик.

Если считать количество HTTP запросов в секунду, то 15 тысяч запросов в секунду с одной машины получалось создавать, но эта характеристика зависит от самого запроса. И зачастую мы не стремимся к ее увеличению, так как "медленные запросы" интереснее в смысле исчерпания вычислительных ресурсов сервера.

ПО для создания трафика можно использовать самое разное, некоторые удобные инструменты указаны в примерах. Для мониторинга трафика также полезны hping и iftop.