В сентябре команда #CloudMTS отразила масштабную DDoS-атаку на клиентов одного из наших коммерческих дата-центров в Москве. На пике мы зафиксировали 30 млн flows per second, что для данной площадки в 300 раз превышало привычные значения. Атака длилась несколько дней подряд, в ходе которых злоумышленники использовали комбинацию из трех распространенных видов DDoS-атак и информацию из общедоступной базы данных IP-адресов. Для тех, кто хочет узнать, как все было – добро пожаловать под кат.
Отмечу, что отражение DDoS-атак в #CloudMTS – это рутинный, отработанный и задокументированный процесс. Часть атак митигируется стандартными средствами в автоматическом режиме, а специалисты подключаются лишь в случае выявления аномалий. Так, 31 августа наши системы мониторинга зафиксировали повышение утилизации одного из аплинков:
Рис. 1. График атаки 31 августа
Анализ дальнейших событий показал, что это была тестовая атака на одного из наших заказчиков. Как видно по иллюстрации, первый аномальный всплеск трафика произошел примерно в 13.30, дальше было еще несколько волн. В данной ситуации действовали по типовому сценарию, предусматривающему максимально автоматизированную обработку инцидента. Примерно в 4.00 следующего дня ситуация стабилизировалась. Попытки атаковать заказчика периодически возобновлялись, но негативного эффекта не оказывали.
Вторая фаза атаки началась 14 сентября. Вот как это выглядело на графике:
Рис. 2. График атаки 14 сентября
Рис. 3. География атаки 14 сентября
Использовались три вида атак:
Первые два метода использовались 14 сентября. Они были отработаны, по большей части, в автоматическом режиме: система защиты анализирует исходящий и входящий трафик, и пропускает легитимный. Но, так как сигнатуры для автоматизированных систем защиты формируются производителями и разные системы по-разному ведут себя применительно к тем или иным атакам, рассчитывать на то, что она и в дальнейшем будет полностью перекрывать активность атакующих, не приходилось.
Параллельно договорились с атакуемым клиентом о том, какой трафик можно считать заведомо нелегитимным, чтобы отфильтровать его как можно раньше: не допускать его в ЦОД, не загружать им систему очистки, расположенную до ЦОД, а избавиться от него ещё раньше, на магистральной сети.
В течение этого дня мы заметили, что amplification-атака сопровождается перебором IP-адресов. Стало понятно, что злоумышленник анализирует доступность атакуемых сервисов и наличие мер противодействия. Было видно, что атакующие взаимодействуют с базами региональных интернет-регистраторов.
Для затруднения действий злоумышленников мы стали принимать меры, мешающие определению принадлежности адресного пространства к объекту атаки.
На следующий день атака пошла по TCP-протоколу, и боролись уже с Syn-флудом. Source порты и Destination порты менялись перебором. Если в начале второго дня можно было выявлять паразитный трафик по характерному размеру пакета, то под конец дня и этот параметр стал варьироваться. Объект атаки был понятен, Destination-адреса всегда были из диапазона, выделенного конкретному клиенту.
В течение двух дней атаки мощность Syn-flood'а выросла в 15 раз.
Злоумышленники наблюдали за объектом и стали корректировать свои действия не только в части атакуемых адресов, но и по портам: если сначала атаковались случайные порты, то затем только открытые. То есть, проводилось постоянное сканирование с целью акцентировать усилия на разведанных данных.
Следующим шагом стало использование алгоритмов преодоления систем очистки путём установления легитимных сессий. Это уже достаточно глубокая стадия атаки: злоумышленники раскрывают свою бот-сеть, так как им нужно установить TCP-соединение с реального адреса, чтобы система очистки зафиксировала у себя его как допустимый. После этого в цель прилетает большое количество запросов на установление соединений от имени этого адреса.
Одновременно с происходившими событиями мы проработали перевод клиента на очистку к хорошо известному провайдеру услуг защиты от DDoS, который обожает интересные атаки.
Все закончилось в понедельник, 19 сентября. В 8.49 была последняя атака, с которой мы боролись уже с нашим партнёром. На сервисы клиентов она больше не влияла.
Атака была адаптивной, зрелой, управляемой, с использованием современных средств автоматизации, и эффективной за счет взаимодействия с открытыми внешними источниками для получения данных. Судя по объемам и географии, это был масштабный проект, направленный против конкретного клиента. На протяжении события мы постоянно были на связи с клиентом и действовали совместно, чтобы как можно быстрее митигировать атаку.
По итогам произошедшего получили дополнительный опыт по мониторингу метрик и корреляции событий в процессе атаки.
Проверили поведение оборудования в стрессовой ситуации, определили вероятные узкие места и получили понимание о пределах возможностей нашего оборудования и средств защиты: пропускной способности аплинков, межсетевых экранов при разных сценариях атак, эффективности автоматизированных систем.
По результатам анализа сделали выводы о целесообразности модернизации не только элементов инфраструктуры и средств защиты информации, но и архитектурных решений.
Доработали и дополнили алгоритм, по которому мы действуем в случае подобных происшествий.
Наладили взаимодействие с партнёром, узко специализирующимся на защите от DDoS-атак, как для того, чтобы получить возможность предоставлять заказчикам услуги постановки на защиту его силами, так и для максимально эффективной защиты собственной инфраструктуры.
Хотя было тяжело и местами болезненно, в целом это был полезный опыт.
habr.com
Отмечу, что отражение DDoS-атак в #CloudMTS – это рутинный, отработанный и задокументированный процесс. Часть атак митигируется стандартными средствами в автоматическом режиме, а специалисты подключаются лишь в случае выявления аномалий. Так, 31 августа наши системы мониторинга зафиксировали повышение утилизации одного из аплинков:
Рис. 1. График атаки 31 августа
Анализ дальнейших событий показал, что это была тестовая атака на одного из наших заказчиков. Как видно по иллюстрации, первый аномальный всплеск трафика произошел примерно в 13.30, дальше было еще несколько волн. В данной ситуации действовали по типовому сценарию, предусматривающему максимально автоматизированную обработку инцидента. Примерно в 4.00 следующего дня ситуация стабилизировалась. Попытки атаковать заказчика периодически возобновлялись, но негативного эффекта не оказывали.
Вторая фаза атаки началась 14 сентября. Вот как это выглядело на графике:
Рис. 2. График атаки 14 сентября
Рис. 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-атак, как для того, чтобы получить возможность предоставлять заказчикам услуги постановки на защиту его силами, так и для максимально эффективной защиты собственной инфраструктуры.
Хотя было тяжело и местами болезненно, в целом это был полезный опыт.
Как команда отразила крупную DDoS-атаку на инфраструктуру клиента
Привет, Хабр! В сентябре команда #CloudMTS отразила масштабную DDoS-атаку на клиентов одного из наших коммерческих дата-центров в Москве. На пике мы зафиксировали 30 млн flows per second, что для...
habr.com