Вы ведь слышали о DDoS? Вкратце, стресс-тестирование DDoS - это специальная услуга, которая помогает вашей организации понять, насколько хорошо вы подготовлены к различным векторам DDoS-атак, которые, к сожалению, могут прийти к вам. Услуга заключается в имитации DDoS-атак или высокой нагрузки на ваши ИТ-системы и проводится в строго контролируемом и заранее запланированном режиме. Вы получаете подробный отчет, в котором говорится о проблемах сети и серверов, связанных с устойчивостью к DDoS. Вы также получите рекомендации по устранению и смягчению последствий, как укрепить ваше решение по защите от DDoS или как внедрить его, если у вас его еще нет.
ЗАЧЕМ ВАМ ПРОВОДИТЬ СТРЕСС-ТЕСТИРОВАНИЕ DDOS?
Сегодня DDoS так же легко нанести жертве, как купить пиццу в Интернете. К тому же это дешево и эффективно. Проведя стресс-тестирование своей ИТ-инфраструктуры, вы сможете выявить и спланировать меры по смягчению проблем, связанных с DDoS, до того, как атаки произойдут и нанесут вам ущерб. Вы также сможете получить представление о своих процедурах реагирования на инциденты и усовершенствовать их, или просто получить лучший контроль над имеющимся у вас решением по борьбе с DDoS. Если вы хотите приобрести такое решение, стресс-тестирование может помочь вам выбрать подходящего поставщика.
КАК ЭТО РАБОТАЕТ?
Процесс стресс-тестирования обычно начинается с процедуры проверки и настройки. Векторы DDoS-атак в реальном времени направляются на ИТ-инфраструктуру организации, обращенную к общественности, извне (реальный сценарий) или в закрытой среде (имитация на месте). Имитация DDoS-атак должна проводиться на всех применимых уровнях модели OSI в мелкозернистой контролируемой манере с возможностью "Стоп" в любое время. Процесс должен постоянно контролироваться сотрудником службы поддержки поставщика услуг и представителем тестируемой организации.
МЕСТО В ПРОЦЕССЕ ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ
Конфиденциальность, целостность и доступность, также известные как триада CIA (или AIC, если вы хотите избежать ассоциации с определенным разведывательным агентством), являются основой информационной безопасности и работают вместе, чтобы обеспечить безопасность ваших данных и систем. Ошибочно полагать, что одна часть триады важнее другой. Каждая ИТ-система требует разной приоритетности этих трех составляющих, в зависимости от данных, сообщества пользователей и своевременности, необходимой для доступа к данным. Существуют противоположные триаде понятия - раскрытие, изменение и уничтожение. Раскрытие - это когда вы сталкиваетесь с несанкционированным раскрытием информации, изменение - это несанкционированная модификация данных, а уничтожение - это вывод систем из строя.
В концепции триады есть противоположные силы: раскрытие, изменение и уничтожение. Раскрытие - это когда вы сталкиваетесь с несанкционированным раскрытием информации, изменение представляет собой несанкционированную модификацию данных, а уничтожение - делает системы недоступными.
Доступность позволяет получить информацию, когда она необходима. Все системы должны быть пригодны (доступны) для работы в обычном режиме. Типичными атаками на доступность являются атаки типа "Отказ в обслуживании" (DoS) или "Распределенный отказ в обслуживании" (DDoS), целью которых является отказ в обслуживании (или доступности) системы. Быть готовым и информированным о слабых местах вашей системы против DDoS-атак предполагает проведение стресс-тестирования.
КАКОЙ ОХВАТ СТРЕСС-ТЕСТИРОВАНИЯ ВАМ НЕОБХОДИМ?
Определение готовности ИТ-инфраструктуры вашей организации к DDoS-атакам с помощью стресс-тестирования должно включать все известные векторы атак и возможные источники. Помните, что DDoS сегодня дешев и эффективен, поэтому метод и подход к тестированию должны иметь следующие характеристики:
Векторы атак, имитирующие потоки, генерируемые реальными известными ботнетами;
Объемные атаки с неограниченным размером и регулируемым приращением;
Сервис-ориентированный выбор флудов на уровне приложений;
Гибкое определение времени атаки и возможность комбинированного вектора;
Объем атаки очень важен и должен (i.) быть в состоянии показать по крайней мере фундаментальные слабости целевых серверов и (ii.) соответствовать вашей политике и стратегии безопасности.
Хороший поставщик услуг стресс-тестирования будет обладать опытом и возможностями для использования широкого спектра векторов атак, включая, но не ограничиваясь различными методами и комбинациями HTTP/HTTPS (GET, POST, HEAD, PUT, DELETE, TRACE, CONNECT, OPTIONS, PATCH и др. ), различные атаки на протокол WebDAV, флуды SYN-ACK, флуды ACK или ACK-PUSH, фрагментированные флуды ACK, флуды RST/FIN, флуды с одинаковым источником/назначением (атака LAND), атаки на поддельные сессии, флуды UDP, фрагментация UDP, флуды ICMP, флуды фрагментации ICMP, флуды Ping, флуды TOS, атаки IP NULL/TCP NULL, атаки Smurf/Fraggle, DNS Floods, NTP Floods, различные усиленные (отраженные) атаки, Slow Session Attacks, Slow Read Attacks, Slowloris, HTTP Fragmentation, различные типы Excessive Verb (HTTP/HTTPS GET Flood), Excessive Verb - Single Session, Multiple Verb - Single Requests, Recursive GET, Random Recursive GET, различные Specially Crafted Packets и т.д.
ВНУТРЕННЕЕ И ВНЕШНЕЕ ТЕСТИРОВАНИЕ ВНЕШНЕЕ ТЕСТИРОВАНИЕ
Для создания устойчивости периметра к DDoS-атакам, с точки зрения управления рисками, необходимо правильно определить и перечислить активы, находящиеся под угрозой, после чего должна последовать оценка уязвимости критически важных активов. Как правило, DDoS-стресс-тестирование проводится либо внешним, либо внутренним способом.
Как следует из названия, внешний подход имитирует DDoS-атаку путем развертывания ресурсов, очень близких по своей природе к реальной атаке, то есть исходящих из Интернета. Атакующая "бот-сеть" имитируется из облачной платформы для стресс-тестирования. Максимальный объем имитируемых тестовых атак должен быть обсужден с клиентом и согласован до начала тестов. Как правило, реализуется типичная топология для внешних тестов, включая образец легитимного клиента (машина, используемая для проведения тестов доступности):
В отличие от внешнего тестирования, внутреннее стресс-тестирование DDoS подразумевает проведение симуляции в месте, находящемся внутри периметра клиентской сети. Флуд-трафик генерируется внутри сети и направляется на ресурсы, которые обычно являются частью специально созданной тестовой среды. Ниже показана типичная топология сети для внутреннего тестирования, где Интернет имитируется локальной сетью и включает в себя сегментированные тестовые цели и имитированный легитимный клиентский ПК:
При проведении DDoS-стресс-тестирования необходимо, чтобы подробный план тестирования был предоставлен заранее и предварительно одобрен всеми участвующими сторонами. Все тесты должны проводиться поэтапно, причем каждый этап должен длиться достаточно долго, чтобы выполнить тест доступности и измерить приблизительную скорость загрузки с целевого сервера путем подключения к нему с имитированного клиентского ПК. Тесты должны быть разработаны таким образом, чтобы их можно было остановить в любое время и на любом этапе по вашему запросу. Настоятельно рекомендуется не проводить тесты в производственной среде, поскольку их поведение и возможные последствия зависят от конкретных настроек целевого сервера.
В отличие от внешнего тестирования, внутреннее стресс-тестирование DDoS означает проведение симуляции в месте, находящемся внутри периметра клиентской сети. Трафик флуда генерируется внутри сети и направляется на ресурсы, которые обычно являются частью специально созданной тестовой среды. Ниже показана типичная топология сети для внутреннего тестирования, где Интернет имитируется локальной сетью и включает в себя сегментированные тестовые цели и имитированный легитимный клиентский ПК:
При проведении DDoS-стресс-тестирования необходимо, чтобы подробный план тестирования был предоставлен заранее и предварительно одобрен всеми участвующими сторонами. Все тесты должны проводиться поэтапно, причем каждый этап должен длиться достаточно долго, чтобы выполнить тест доступности и измерить приблизительную скорость загрузки с целевого сервера путем подключения к нему с имитируемого клиентского ПК. Тесты должны быть разработаны таким образом, чтобы их можно было остановить в любое время и на любом этапе по вашему запросу. Настоятельно рекомендуется не проводить тесты в производственной среде, поскольку их поведение и возможные последствия зависят от конкретных настроек целевого сервера.