Почему нельзя полноценно протестировать защиту от DDoS, не нарушив закон

CISO Forum прошел, появилось несколько идей для поста по итогам обсуждений и вопросов из зала.

Как правильно тестировать защиту от DDoS?

Технически всё просто. С точки зрения закона – есть вопросы. Давайте разбираться.

Чтобы понять, как тестировать, нужно определиться, какие цели могут быть у злоумышленника:

1. Пропускная способность ваших аплинков. Забиты каналы – доступа для пользователей нет. Способы известны: различные виды амплификации, DDoS со спуфингом с dedicated-серверов или ботнета. Естественно, это L3-L4 стейтлесс-флуд, тупой, но мощный.

2. Атаки на сетевой стек и сетевое оборудование/сервер. Допустим, аплинк не забили, но количество пакетов наш условный маршрутизатор переварить не может. Чаще это L3-L4 stateless-flood: syn-flood и подобные флады маленькими пакетами. Тут же, но отдельно, connection-flood, так как устанавливается сессия и нельзя использовать спуфинг. Тут либо в принципе слабое оборудование, либо атака на переполнение таблицы сессий или другого механизма, если оборудование не предназначено под высокие нагрузки (pps, соединения).

3. Атаки на приложение (всё, что выше 4-го уровня). Атаки на SSL/TLS-согласование и разнообразные атаки на HTTP. Тут можно положить как фронтящий реверс-прокси, так и приложение на бэкенде, так и БД, если при формировании ответа на запрос выполняется тяжелый SELECT.

4. Атаки на бюджет. Все атаки отбили, всё работает, но платим за потраченный ресурс: количество нелегитимного трафика/запросов, мощности в облаке и т.п. Не частая история, но бывает.

Проблемы при тестировании защиты от атак на сетевом и транспортном уровне

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

Проблемы при тестировании защиты от атак на прикладном уровне (+ connection-flood)

Если в первом случае полноценный генератор трафика может быть ваш и полностью белый, то тут сложнее. Да, для имитации атаки можно обойтись автоматизацией в облаке и сотней адресов, но это синтетика. Во-первых, по адресам будет видно, что они принадлежат облакам/ДЦ. Во-вторых, эта сотня очень быстро попадет в чёрный список из-за RPS, которое им придется генерировать, чтобы создать какой-никакой значимый пакетрейт. Такие синтетические атаки хороши для общего понимания работы защиты, посмотреть, как работает аналитика, пройти smoke-тест и т.п. Но к реальности они имеют мало отношения.

Что же делать? Выход есть – настоящий ботнет!

Да-да. Сгенерировать максимально релевантный трафик атаки на уровне приложения можно, только используя зараженные устройства и серые схемы.

Тут и старые роутеры, которые давно не обновлялись, и ПК пользователей, которые не следят за цифровой гигиеной, и IoT-устройства, и просто взломанные серверы с несколькими десятками Гб/с пропускной способности. К серым схемам относятся покупка проксей, которые также существуют на взломанных устройствах и мобильных фермах.

В итоге тема имитации атак оказывается очень скользкой, и странно слышать заявления некоторых компаний (которые тем более при этом занимаются защитой от DDoS), что они могут помочь с тестированием и организовать любую атаку и эффективно протестировать защиту других поставщиков (что такое «эффективно» и какие последствия – см. выше).

Любая компания, которая делает защиту, должна обладать компетенцией в имитации атак, иметь свои тестовые полигоны, генераторы трафика и т.д. Но переходить грань и использовать серые/чёрные методы, платить за ботнет, фермы мобильных, прокси и так далее – значит потакать киберпреступникам.

Мне кажется, что в индустрии не зря придумали термины про белые/чёрные шляпы, и вы не можете относить себя к белым, если используете незаконные методы в своей работе.