Как оправится после DDoS-атаки?

Ничто не вечно — собственно как и продолжительсноть DDoS-атаки. Восстановление после DDoS-атаки не простое занятие, но по завершению атаки самое время оценить влияние, механизмы защиты и быть готовыми к следующему инциденту.

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

 

Анализ атаки.

 

Когда атака завершена попробуйте проанализировать её как можно детальней. Вы можете получить больше информации о инциденте у вашего провайдера безопасности(например cloudflare) или провайдера вашей внутренней сети(ЦОДа) и в логах ваших приложений и сервисов.

Ключевые вопросы которыми вы должны задаться следующие:

- Какие ресурсы были атакованы? Была ли это общая атака на всю сеть или атака была направлена на специфические серверы или сервисы?

- Какие основные характеристики атаки? Был ли это устойчивый(постоянный) флуд (single sustained flood) или использовалась мульти-векторная атак с использованием специфических методов, динамический IP-спуфинг или burst-атака?

- Какие протоколы и шаблоны атаки использовались?

- Каким была пиковая нагрузка сетевого трафика, как с точки зрения данных (бит в секунду), так и числа запросов (подключений в секунду)?

- Какой уровень модели OSI был затронут в атаке? L3 или L7?

- Был ли в атакуемом трафике шифрованный трафик и протоколы шифрования?

- Как долго продолжалась атака?

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

Оценка ущерба.

 

Следующим шагом после анализа атаки, вы должны понять как сильно она повлияла на вас. Затрагиваемые в этой главе вопросы помогут оценить потери от DDoS-атаки и как результат — как много вы можете позволить себе для предотвращения подобного инцидента в будущем.

Вот некоторые ключевые вопросы:

- Была ли атака остановлена или завершилась самостоятельно(полностью или частично)?

- Какие сервисы были затронуты, как сильно и как как долго?

- Какие были получены прямые денежные потери (такие как прямой доход, простой эффективных мощностей и другие)?

- Какие были получены не прямые финансовые потери, такие как плохие отзывы в прессе, репутационные потери, жалобы пользователей?

- Пользовательское влияние в результате такие, такие как непосредственно от атаки, но и результат от включения механизмов защиты (ложные срабатывания)?

Поиск слабых точек.

 

На этом этапе, после подсчёта потерь, необходимо определить слабые точки в вашей защите - какие они, почему вредоносный трафик смогу обойти защиту?

- Весь ли вредоносный трафик прошёл? Если частично, то насколько много?
- Какой из специфического вредоносного трафика был наиболее эффективен среди прочего?

В частности, были ли какие-либо виды трафика остановлены, почему другие при этом свободно прошли?

- Были ли ресурсы наиболее чувствительно воспринявшие атаку? Для примера, некоторые ресурсы (сеть, сервера, приложения и т. д.) смогли устоять при атаке, пока другие «легли» от воздействия атаки.

- Почувствовали ли легитимные пользователи негативный опыт работы с ресурсами? Каково было соотношении легитимного трафика по отношении к вредоносному, блокировался ли легитимный трафик?

Когда слабые точки были найдены вы должны понимать не только какие ресурсы подверглись атаке, но и в какой степени атака повлияла на их нормальную работу. Был ли особый тип атаки которому удалось повлиять на сервис или были какие-то сервисы влияние на которые было больше, чем на другие сервисы?

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

Выявление слабых точек в вашей защите поможет исключить негативные влияния в будущем.

Проверка SLA (service level agreement) вендора системы безопасности. 

 

Если у вас уже есть служба защиты от DDoS самое время проверит выполненные ими обязательства.

Когда речь идёт о защите от DDoS-атак, существует ряд ключевых показателей которые можно проверить и измерить:

SLA метрика	Пояснение
Время обнаружение	Как быстро DDoS-атака была обнаружена с момента ее начала?
Время оповщения	Как быстро вам было сообщено о обнаружении атаки?
Время перенаправления трафика	Как быстро было начато перенаправление трафика после обнаружения атаки? (Если механизм защиты имеет такую возможность)
Время до стабилизации работы сервисов	Как быстро после начала атаки сервисы находящиеся под защитой продолжат работать в штатном режиме?
Стабильность	Какой объем вредоносного трафика пропущено, сколько вредного трафика было остановлено?
Доступность сервисов	Сработала ли защита?

Любая система защиты от DDoS строится по этим шести показателей.

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

Вторым по важности показателем является «Стабильность», то насколько эффективно справляется система отражения атаки. Как результат это скажется на показателе доступности сервисов.

Рассмотрите возможность обновления ваше системы защиты от DDoS-атак.

После того как вы провели анализ атаки, выявили слабые места и провели оценку потерь наступает время задуматься, необходима ли вашей системе защиты обновление или замена?

Задайтесь вопросам:

- Сможет ли моя защита остановить атаку?

- Все ли атаки она остановит или некоторые смогут навредить?

- Почувствуют ли ваши пользователи результаты атаки? (прямо или косвенно)

- Предоставляет ли вендор полноценную защиту и гарантию их исполнения?

Если ответ «да», отлично, вы защищены. Но если один или более ответов «нет» может быть стоит присмотреться к альтернативным продуктам защиты?