Посмотрели подробнее про 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.
Hyenae больше адаптирован под протоколы нижнего уровня. Предлагаемый подход позволяет при необходимости моделировать более сложное общение с сервисом и подстригаться под специфику конкретной реализации. Это особенно полезно при нагрузочном тестировании L7.
Одной из задач являлась имитация именно распределенной нагрузки. Не во всех проектах возможно поставить генератор непосредственно на «вход сервиса», где-то по техническим причинам, где-то по политическим (инфраструктура может быть гео-распредленная со сложными системами балансировки нагрузки). Инфраструктура AWS не дает подменять заголовки. В свою очередь, предложенный вами метод моделирования тоже имеет право на существование в жизненном цикле разработки продукта, а также при наличии отдельного стенда для тестирования, который может в достаточной степени контролироваться вами.
Касательно уменьшения доступных ресурсов. Идея хорошая, но если говорить о моделировании DDoS в отношении неконтролируемой инфраструктуры, то снова приходим к ограничениям на стороне владельца тестируемого сервиса и поставленной задаче. Например, это может быть «боевой» сервер интернет-магазина, а задача оценить максимальный поток пользователей без деградации сервиса (пример — Black Friday распродажи), или же сайт предвыборной политической кампании.
Кучу денег мы не выкинули, поставленные задачи решили. А благодаря автоматизации еще и сэкономили существенное количество средств, т.к. инстансы быстро поднимались/тушились и работали только в момент генерации трафика.
В целом статья рассматривает ряд отдельных кейсов и показывает один из возможных подходов их решения на основе AWS EC2.
Совершенно верно. Существует несколько способов фильтрации сетки (Mesh). Мы выбирали наиболее быстрый, исходя из ограничений, накладываемых "железом"
Можно и по BGP делать балансировку. В нашем случае источников нагрузки было всего 3. Задача больше стояла обеспечить балансировку tcp подключений.
Можно и по BGP делать балансировку. В нашем случае источников нагрузки было всего 3. Задача больше стояла обеспечить балансировку tcp подключений.
Посмотрели подробнее про 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.
Касательно уменьшения доступных ресурсов. Идея хорошая, но если говорить о моделировании DDoS в отношении неконтролируемой инфраструктуры, то снова приходим к ограничениям на стороне владельца тестируемого сервиса и поставленной задаче. Например, это может быть «боевой» сервер интернет-магазина, а задача оценить максимальный поток пользователей без деградации сервиса (пример — Black Friday распродажи), или же сайт предвыборной политической кампании.
Кучу денег мы не выкинули, поставленные задачи решили. А благодаря автоматизации еще и сэкономили существенное количество средств, т.к. инстансы быстро поднимались/тушились и работали только в момент генерации трафика.
В целом статья рассматривает ряд отдельных кейсов и показывает один из возможных подходов их решения на основе AWS EC2.