image

Привет, Хабр! В сентябре команда #CloudMTS отразила масштабную DDoS-атаку на клиентов одного из наших коммерческих дата-центров в Москве. На пике мы зафиксировали 30 млн flows per second, что для данной площадки в 300 раз превышало привычные значения. Атака длилась несколько дней подряд, в ходе которых злоумышленники использовали комбинацию из трех распространенных видов DDoS-атак и информацию из общедоступной базы данных IP-адресов. Для тех, кто хочет узнать, как все было – добро пожаловать под кат.

Отмечу, что отражение DDoS-атак в #CloudMTS – это рутинный, отработанный и задокументированный процесс. Часть атак митигируется стандартными средствами в автоматическом режиме, а специалисты подключаются лишь в случае выявления аномалий. Так, 31 августа наши системы мониторинга зафиксировали повышение утилизации одного из аплинков:

image

Рис. 1. График атаки 31 августа

Анализ дальнейших событий показал, что это была тестовая атака на одного из наших заказчиков. Как видно по иллюстрации, первый аномальный всплеск трафика произошел примерно в 13.30, дальше было еще несколько волн. В данной ситуации действовали по типовому сценарию, предусматривающему максимально автоматизированную обработку инцидента. Примерно в 4.00 следующего дня ситуация стабилизировалась. Попытки атаковать заказчика периодически возобновлялись, но негативного эффекта не оказывали.

Вторая фаза атаки началась 14 сентября. Вот как это выглядело на графике:

image

Рис. 2. График атаки 14 сентября

image

Рис. 3. География атаки 14 сентября

Использовались три вида атак:

  • UDP-amplification. Основан на многократно больших по размеру ответах по сравнению с размером запросов у ряда сервисов, использующих в качестве транспорта протокол UDP. Атака емкостная, ориентирована на забивание канала, из-за чего её зачастую называют атакой канального уровня несмотря на то, что реализуется она на транспортном.
  • ICMP-flood, или Smurf-атака – метод забивания полосы пропускания и создания нагрузок на сетевой стек через посылку большого числа запросов ICMP ECHO (ping) от имени множества IP-адресов.
  • Syn-flood. Один из способов ввести сетевой стек операционной системы в такое состояние, когда он уже не сможет принимать новые запросы на подключение. Основан на попытке инициировать большое количество одновременных TCP-соединений. Для этого злоумышленник отправляет SYN-пакеты с, как правило, несуществующим обратным адресом. При отправке ответа с подтверждением готовности установить соединение атакуемая система выделяет необходимые ресурсы для обслуживания нового соединения и ставит его в очередь на подключение в ожидании подтверждения установления соединения от инициатора. Так как поток SYN-пакетов очень велик, вскоре очередь оказывается заполненной, и установить новые соединения не получается. Система становится недоступной. Продвинутые DoS-боты анализируют систему перед началом атаки, чтобы слать запросы только на открытые жизненно важные порты.

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

Параллельно договорились с атакуемым клиентом о том, какой трафик можно считать заведомо нелегитимным, чтобы отфильтровать его как можно раньше: не допускать его в ЦОД, не загружать им систему очистки, расположенную до ЦОД, а избавиться от него ещё раньше, на магистральной сети.

В течение этого дня мы заметили, что amplification-атака сопровождается перебором IP-адресов. Стало понятно, что злоумышленник анализирует доступность атакуемых сервисов и наличие мер противодействия. Было видно, что атакующие взаимодействуют с базами региональных интернет-регистраторов.

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

На следующий день атака пошла по TCP-протоколу, и боролись уже с Syn-флудом. Source порты и Destination порты менялись перебором. Если в начале второго дня можно было выявлять паразитный трафик по характерному размеру пакета, то под конец дня и этот параметр стал варьироваться. Объект атаки был понятен, Destination-адреса всегда были из диапазона, выделенного конкретному клиенту.

В течение двух дней атаки мощность Syn-flood'а выросла в 15 раз.

Злоумышленники наблюдали за объектом и стали корректировать свои действия не только в части атакуемых адресов, но и по портам: если сначала атаковались случайные порты, то затем только открытые. То есть, проводилось постоянное сканирование с целью акцентировать усилия на разведанных данных.

Следующим шагом стало использование алгоритмов преодоления систем очистки путём установления легитимных сессий. Это уже достаточно глубокая стадия атаки: злоумышленники раскрывают свою бот-сеть, так как им нужно установить TCP-соединение с реального адреса, чтобы система очистки зафиксировала у себя его как допустимый. После этого в цель прилетает большое количество запросов на установление соединений от имени этого адреса.

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

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

Какие выводы мы сделали


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

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

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

По результатам анализа сделали выводы о целесообразности модернизации не только элементов инфраструктуры и средств защиты информации, но и архитектурных решений.

Доработали и дополнили алгоритм, по которому мы действуем в случае подобных происшествий.

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

Хотя было тяжело и местами болезненно, в целом это был полезный опыт.

Комментарии (8)


  1. K_Tsarevich
    11.11.2022 14:19
    +1

    Как команда отразила крупную DDoS-атаку на инфраструктуру клиента

    Так как отразила в итоге ? Обращением к провайдеру ?


    1. CloudMTS Автор
      11.11.2022 14:55
      -2

      В статье достаточно подробно описали все стадии отражения: мы отнюдь не лежали до организации совместной с провайдером работы.


  1. Gansterito
    11.11.2022 14:41

    Простите, 14,5 Гбит/с атаки? Вы серьезно?


    1. CloudMTS Автор
      11.11.2022 15:25
      +1

      Это иллюстрация первого дня «тестовой» атаки. Мы акцентировали внимание не на Amplification (это обычное дело), а на продолжении.


  1. ZeroBot-Dot
    11.11.2022 14:44
    -3

    Статья может быть в одну строку.

    "Подключили Cloudflare".


    1. CloudMTS Автор
      11.11.2022 15:25
      +1

      Смотрите внимательно текст. Нет, мы не подключали Cloudflare. Да и писали не про то…


  1. AlexGluck
    11.11.2022 20:54
    +2

    Когда то выражал уже похожую мысль: уважаемый менеджер компании, уволь копирайтера, отдай свою премию какому нибудь вашему классному инженеру и пусть он в выходные напишет нормальный материал. А то здесь вы сказали ровным счётом ничего.


  1. imotorin
    12.11.2022 16:30

    что за клиент то такой (тип бизнеса и public сервисов)
    у которого голой жо в интерент выставлен диапазон адресов
    с сервисами UDP & TCP и зачем-то открытым ICMP

    выглядит как классическая лекция про "спамы, куки, троянские кони"
    пересказанная для подросших малышей