Особенности отражения DDoS атак и история атаки на один крупный банк
- вторник, 21 октября 2014 г. в 03:10:43
geektimes
http://habrahabr.ru/company/croc/blog/240923/
Раньше DDoS-атаки могли успешно отбиваться на стороне ЦОДа атакуемой компании. Быстрые умные действия админа и хорошее фильтрующее железо гарантировали достаточную защиту от атак. Сегодня услуги ботнетов стремительно дешевеют, и DDoS становится доступен чуть ли не в малом бизнесе.
Около половины атак идут на интернет-магазины или коммерческие сайты компаний в духе «завалить конкурента», почти всегда атакуют сайты СМИ, особенно после «горячих» публикаций, намного чаще, чем кажется, бьют по госсервисам. В России главные цели – банки, розница, СМИ и тендерные площадки. Один из крупных российских банков, например, периодически блокирует трафик из Китая – атаки оттуда приходят с завидной регулярностью, одна из последних была больше 100 Гб/с.
Соответственно, когда атака переваливает, скажем, за 10 Гб/с, отражать её на своей стороне становится проблематично из-за банального забивания канала. Именно в этот момент нужно делать переключение на центр очистки данных, чтобы весь «плохой» трафик отсеивался ещё где-то около магистральных каналов, а не шёл к вам. Сейчас расскажу, как это работает у одного из наших вендоров защитных средств – Arbor, мониторящего около 90 Тбит/сек (45% мирового трафика Интернета).
Сначала злоумышленник выбирает цели внутри инфраструктуры. Большая часть «глупых» атак идёт на HTTP, очень много атак на DNS, но основные «умные» атаки обычно направлены на заранее разведанные узлы внутри инфраструктуры цели. Нередко DDoS ставит целью не только и не столько отказ сервисов, сколько возможность пронести «под общий шум» через DMZ более серьёзную угрозу. Это нередко достигается с помощью «перегрузки» систем периметровой защиты, таких как межсетевые экраны, IPS/IDS и им подобных, основанных на отслеживании сессий (stateful inspection). Поэтому коллеги считают, что если у устройства есть таблица состояний (session table) – его следует рассматривать как часть инфраструктуры, нуждающейся в защите.
Основные точки атак:
Схема отражения атаки реализуется следующим образом:
1. Потери легитимного трафика.
Борьба с DDOS атакой — это отбрасывание нелегитимных пакетов и пропуск легитимного трафика, между которыми порой проходит очень тонкая грань. Многие вендоры в своих проспектах любят писать, что эти потери близки к нулю. В моей практике они вполне могут доходить до 2% — это значит, что теоретически тот же директор, уехавший в командировку, не сможет попасть в корпоративную сеть из отеля или с конференции. Здесь очень важно, чтобы система поддерживала возможность разрешить конкретные соединения или протоколы «на лету». У ряда вендоров с момента начала атаки настройки, фактически, чуть ли хардкодятся в прошивку железа, и менять их крайне проблематично. У Арбора с этим всё обстоит совершенно иначе. Во-первых, для управления уровнем false-positive есть три «режима тревоги» — от «руби всё, что точно не наше» до «есть возможность покопаться детальнее». Во-вторых, есть удобный поиск по заблокированным хостам и возможность отменить блокировку трафика для конкретного хоста, протокола или страны в один клик. Отметим, что реальность наличия false positive при борьбе с DDoS признают все заметные игроки рынка. Александр Лямин (Qrator) однажды отметил: «любой, кто скажет, что false positive у него ноль, — шарлатан».
2. Возможность использования забитого канала связи для сигнализации об атаке.
Как же клиент запросит провайдера об атаке, если канал между ними забит из-за DDoS? Строго говоря, даже при близкой к 100% утилизации канала связи в направлении от провайдера к клиенту есть очень большой шанс, что запрос на очистку данных дойдет до провайдера. Для этого Cloud Signaling работает поверх UDP, а кроме того, протокол не требует получения ответа от провайдера. Таким образом, достаточно иметь хотя бы немного ёмкости в направлении от клиента к оператору. Для перестраховки рекомендуется организовать отдельный канал для обмена сообщениями Cloud Signaling. Тем не менее, обычно создаётся резервный канал, плюс тревога идёт при пороге около 70-80% канала.
3. Время переключения на центр очистки данных.
Задержка перенаправления трафика на центр очистки провайдера услуг защиты от DDoS атак может занять единицы и даже десятки минут. В основном, это связано с механизмом перенаправления — на основе записей DNS или анонсов BGP, а также с тем фактом, осуществляется ли принятие решения о перенаправлении в ручном или автоматическом режиме. В любом случае, если подавление атаки осуществляется в «облаке», то избежать задержки не удастся. Как минимум, она составляет несколько минут. Поэтому мы придерживаемся концепции многоуровневой защиты, когда большие атаки на каналы связи подавляются оператором, а медленные, малозаметные атаки уровня приложений – оборудованием, установленным у заказчика.
4. Использование SSL-сертификатов.
Анализировать трафик SSL/TLS на предмет атак уровня приложений достаточно проблематично — нужно расшифровывать каждый пакет. Здесь вы оказываетесь перед непростой дилеммой: или делиться своими сертификатами с провайдером услуг, или принимать риск того, что атака на уровне HTTPS может быть пропущена. Вендоры пробуют находить решения без вскрытия пакетов (что получается не всегда хорошо), либо используют специальный модуль дешифрации SSL/TLS трафика, встроенный в клиентское устройство:
В этом случае ваши сертификаты загружаются в устройство, находящееся под вашим же контролем, а задержки на дополнительную обработку пакетов составляют миллисекунды.
5. Ручное формирование сигнатур.
Большинство сигнатур формируется производителями решений по защите от DDoS-атак. Однако периодически возникают ситуации, когда ресурсы подвергаются новым типам атак.
В зависимости от вендора есть два возможных сценария действий в такой ситуации: либо запросить у производителя новую сигнатуру, либо создать сигнатуру самим. В первом случае, вам скорее всего придется доплатить за услугу, а также значительное время оставаться под атакой ожидая решения проблемы.
Во втором случае работает принцип «спасение утопающих – дело рук самих утопающих», ну или их партнёров. Здесь критически важным становится функционал оборудования, позволяющий быстро определить, перехватить и проанализировать зловредный трафик. А возможность автоматически сформировать сигнатуру на основе полученной информации становится спасением в критической ситуации. К примеру, возможность зайти в захват пакетов, выделить нужную битовую последовательность (bit pattern), и в пару кликов сделать сигнатуру, блокирующую такую последовательность.
У Arbor есть очень интересная «фишка», которая позволяет им очень эффективно использовать свою рыночную долю. Дело в том, что их оборудование стоит у всех TIER-I операторов связи и провайдеров и у большинства TIER-II операторов.
Позиция Arbor на рынке оборудования защиты от DDoS в сегментах Carrier, Enterprise, Mobile – 65% всего рынка — первая (Infonetics Research за декабрь 2013).
Через систему ATLAS проходит информация около 90 Тб/с. Как только где-то появляются признаки атаки, устройства начинают передавать по собственной сети связи данные о происходящем, и информация быстро распространяется по всему миру. К примеру, если «валят» мелкого провайдера, его железо сигналит по специальному протоколу уровнем выше. Если вышестоящий оператор имеет договоренность с нижестоящим, то сигнатура принимается и распространяется на все подсети крупного провайдера.
Сенсоры (honeypots) системы ATLAS расположены на основных узлах глобальной сети Интернет для обнаружения и классификации атак, активности бот сетей и различного зловредного софта. Информация отправляется в ЦОД ATLAS, где объединяется с данными полученными от инсталляция Arbor Peakflow и другими данными. Система анализирует в автоматическом режиме сотни тысяч элементов кода, и позволяет команде инженеров оперативно обновлять сигнатуры для клиентов компании по всеми миру.
Стоит сказать ещё пару слов про железо, которое ставится непосредственно к вам в ЦОД или на площадку. С ним тоже связано много реалий, о которых не всегда говорят.
1. Настройка и конфигурирование.
Как правило, устройству нужно время на профилирование трафика и оценку поведения сети. Но некоторые устройства поставляются в «боевом» режиме для работы с первой секунды после подключения – там уже есть готовые шаблоны, плюс устройство получает данные из «облака» своего вендора. С одной стороны, это хорошо в плане отражения идущей атаки, с другой – если вы привыкли тонко настраивать всё в своей инфраструктуре, здесь придётся частично положиться на опыт вендора.
2. Само защитное железо может стать точкой отказа.
Поэтому, во-первых, на серьёзных объектах оно дублируется или несколько устройств собираются в кластер (соответственно, нужны управляющие устройства). А во-вторых, такие устройства имеют аппаратные байпассы, позволяющие переключить интерфейсы на физическом уровне трафик напрямую в случае различных аварийных ситуаций – отключения питания, отказа программного обеспечения и так далее…
3.Защитное железо может стать и целью атаки.
Особенно, если оно является устройством с таблицей состояний (session table), например объединяет функционал защиты от DDOS, IPS, межсетевой экран, и т.д.). Каждый раз, когда на таких устройствах открывается новая сессия, устройство выделяет память для отслеживания сессии, заполняет лог и так далее – и чем умнее устройство, тем больше работы происходит. Много сессий – большая утилизация CPU и памяти. Поэтому, выбирая решение, стоит уделить внимание и этому аспекту.
4. Обычно в сети довольно много мусорного трафика, а в случае крупных организаций – ещё и регулярно бывают пики активности, которые могут сойти за «глупый» DDoS.
Понятно, что всё отпрофилируется по географии, по времени использования сервисов и так далее, но на первом этапе важно получить понимание, что включение устройства в сеть не убьёт сервисы. Для этого используется зеркальный режим подключения: устройство ставиться в сеть на байпасе и получает зеркальный трафик, показывая, что бы оно отклонило, а что бы пропустило. Это позволяет делать оценку до возникновения проблем. Я знаю заказчиков, где DDoS-защита стоит именно в таком режиме достаточно долго. Арбор считает, что построение baseline – это только один из методов борьбы с DDoS, но гораздо лучше использование специализированных противомер. То же самое коллеги говорят и о сигнатурах – насколько велика не была бы сеть сенсоров и сколько бы трафика в ней не анализировалось, полагаться только на сигнатуры нельзя. Сложные угрозы требуют сочетания разных механизмов защиты.
5. На уровне обмена трафиком между провайдерами иногда случается достаточно неприятная ситуация, когда подсеть передаёт сигнатуру атаки, а вышестоящий провайдер говорит: «Дааа, интересно, но мы у себя чистить не будем».
Принцип очень простой – пока канал справляется, весь DDoS-трафик билингуется. Не всегда вышестоящему провайдеру интересно тратиться и чистить его, когда можно просто отгрузить ниже, да ещё и за деньги потерпевшего. Такие ситуации неприятны для сервис провайдеров, однако никак не сказываются на пользователях услуг защиты от DDoS, поскольку операторы выполняют свои обязательства в полном объеме.
Одна из важных вещей – быстрое понимание того, что происходит. Давайте посмотрим на отчёты на примере двух атак на крупный российский банк. Почувствуйте, как у админов добавилось седых волос в комиксе ниже.
Эта атака началась с DNS-amplification. Трафик, зафиксированный на Arbor Peakflow TMS сервис провайдера: до 7.15 Гбит/с., 1.1 Мпакетов/с. С учетом фильтрации большей части атаки на FlowSpec суммарный трафик атаки оценен в 50 Гбит/с. Атака была продолжена HTTP-флудом.
Зафиксировав аномальный рост трафика, клиентское устройство автоматически запросило помощь от сервис провайдера в подавлении атаки.
Система защиты установленная у оператора, передавала информацию о ходе подавления атаки на Pravail APS в режиме реального времени.
Когда DNS-amplification атака сошла на нет, появилось большое количество HTTP-флуда.
Кроме HTTP-флуда также присутствовал и TCP SYN флуд.
В результате, большая часть DNS-amplification атаки была успешно подавлена с помощью Flowspec, остальная ее часть была подавлена средствами системы защиты, а HTTP и TCP SYN флуд был сброшен на Pravail APS.
Несколько минут в начале — HTTP-флуд. Виден всплеск числа иностранных хостов (красный график). Около 1000 хостов на домен «Крупного Российского Банка». Основные страны: США (672), Германия (141), Великобритания (82), Италия (30), Нидерланды (24), Франция (14).
Следующий сюрприз — NTP-amplification — до 125 Гбит/с.
После неудавшегося NTP amplification — SYN-флуд с подменными IP – до 300 Мбит/с
Атаки идут постоянно, и если вы ещё с этим не сталкивались – это всего лишь вопрос времени. Для иллюстрации, вот несколько событий в РФ:
Если у вас есть вопросы — с удовольствием отвечу здесь или на почте avrublevsky@croc.ru. Наше подразделение может предложить и различные решения, если вам потребуется иной вендор.
А ещё завтра, 21 октября, мы проводим вебинар на тему защиты от DDoS. Приходите, расскажем, что у нас в России сейчас происходит на этом фронте.
Раньше DDoS-атаки могли успешно отбиваться на стороне ЦОДа атакуемой компании. Быстрые умные действия админа и хорошее фильтрующее железо гарантировали достаточную защиту от атак. Сегодня услуги ботнетов стремительно дешевеют, и DDoS становится доступен чуть ли не в малом бизнесе.
Около половины атак идут на интернет-магазины или коммерческие сайты компаний в духе «завалить конкурента», почти всегда атакуют сайты СМИ, особенно после «горячих» публикаций, намного чаще, чем кажется, бьют по госсервисам. В России главные цели – банки, розница, СМИ и тендерные площадки. Один из крупных российских банков, например, периодически блокирует трафик из Китая – атаки оттуда приходят с завидной регулярностью, одна из последних была больше 100 Гб/с.
Соответственно, когда атака переваливает, скажем, за 10 Гб/с, отражать её на своей стороне становится проблематично из-за банального забивания канала. Именно в этот момент нужно делать переключение на центр очистки данных, чтобы весь «плохой» трафик отсеивался ещё где-то около магистральных каналов, а не шёл к вам. Сейчас расскажу, как это работает у одного из наших вендоров защитных средств – Arbor, мониторящего около 90 Тбит/сек (45% мирового трафика Интернета).
Сценарий атаки
Сначала злоумышленник выбирает цели внутри инфраструктуры. Большая часть «глупых» атак идёт на HTTP, очень много атак на DNS, но основные «умные» атаки обычно направлены на заранее разведанные узлы внутри инфраструктуры цели. Нередко DDoS ставит целью не только и не столько отказ сервисов, сколько возможность пронести «под общий шум» через DMZ более серьёзную угрозу. Это нередко достигается с помощью «перегрузки» систем периметровой защиты, таких как межсетевые экраны, IPS/IDS и им подобных, основанных на отслеживании сессий (stateful inspection). Поэтому коллеги считают, что если у устройства есть таблица состояний (session table) – его следует рассматривать как часть инфраструктуры, нуждающейся в защите.
Основные точки атак:
Схема отражения атаки реализуется следующим образом:
- На стороне защищаемой компании стоит устройство, «закрывающее» сеть. Как только начинается атака, устройство должно опознать её как аномалию, используя одну из механик, например, встроенные противомеры, ненормальное поведение источника трафика либо соответствие известному профилю атаки (сигнатуре из базы).
- Если устройство справляется с атакой, работа продолжается в относительно штатном режиме: легитимный трафик пропускается, нелегитимный – режется. Есть несколько «уровней тревоги», отличающихся степенью сложности атаки и возможными потерями легитимного трафика.
- Если канал связи начинает забиваться, то выполняется автоматическое перенаправление трафика с помощью штатного протокола Cloud Signalling. Сначала всё приходит на площадку крупного провайдера (это может быть Ростелеком, Orange, Транстелеком, Акадо), где данные чистятся оборудованием Peakflow SP. Уже очищенный трафик идёт на конечного клиента. При этом клиент обладает пониманием всего происходящего – может оперативно зайти в личный кабинет оператора связи и посмотреть текущий статус очистки, какие работают противомеры, какова эффективность подавления атак и так далее. Клиентское устройство также показывает эффективность происходящей в данный момент очистки и список заблокированных хостов. С обоих устройств при желании можно легко снять дамп трафика в формате pcap для последующего «разбора полетов».
Реальность, о которой не принято говорить
1. Потери легитимного трафика.
Борьба с DDOS атакой — это отбрасывание нелегитимных пакетов и пропуск легитимного трафика, между которыми порой проходит очень тонкая грань. Многие вендоры в своих проспектах любят писать, что эти потери близки к нулю. В моей практике они вполне могут доходить до 2% — это значит, что теоретически тот же директор, уехавший в командировку, не сможет попасть в корпоративную сеть из отеля или с конференции. Здесь очень важно, чтобы система поддерживала возможность разрешить конкретные соединения или протоколы «на лету». У ряда вендоров с момента начала атаки настройки, фактически, чуть ли хардкодятся в прошивку железа, и менять их крайне проблематично. У Арбора с этим всё обстоит совершенно иначе. Во-первых, для управления уровнем false-positive есть три «режима тревоги» — от «руби всё, что точно не наше» до «есть возможность покопаться детальнее». Во-вторых, есть удобный поиск по заблокированным хостам и возможность отменить блокировку трафика для конкретного хоста, протокола или страны в один клик. Отметим, что реальность наличия false positive при борьбе с DDoS признают все заметные игроки рынка. Александр Лямин (Qrator) однажды отметил: «любой, кто скажет, что false positive у него ноль, — шарлатан».
2. Возможность использования забитого канала связи для сигнализации об атаке.
Как же клиент запросит провайдера об атаке, если канал между ними забит из-за DDoS? Строго говоря, даже при близкой к 100% утилизации канала связи в направлении от провайдера к клиенту есть очень большой шанс, что запрос на очистку данных дойдет до провайдера. Для этого Cloud Signaling работает поверх UDP, а кроме того, протокол не требует получения ответа от провайдера. Таким образом, достаточно иметь хотя бы немного ёмкости в направлении от клиента к оператору. Для перестраховки рекомендуется организовать отдельный канал для обмена сообщениями Cloud Signaling. Тем не менее, обычно создаётся резервный канал, плюс тревога идёт при пороге около 70-80% канала.
3. Время переключения на центр очистки данных.
Задержка перенаправления трафика на центр очистки провайдера услуг защиты от DDoS атак может занять единицы и даже десятки минут. В основном, это связано с механизмом перенаправления — на основе записей DNS или анонсов BGP, а также с тем фактом, осуществляется ли принятие решения о перенаправлении в ручном или автоматическом режиме. В любом случае, если подавление атаки осуществляется в «облаке», то избежать задержки не удастся. Как минимум, она составляет несколько минут. Поэтому мы придерживаемся концепции многоуровневой защиты, когда большие атаки на каналы связи подавляются оператором, а медленные, малозаметные атаки уровня приложений – оборудованием, установленным у заказчика.
4. Использование SSL-сертификатов.
Анализировать трафик SSL/TLS на предмет атак уровня приложений достаточно проблематично — нужно расшифровывать каждый пакет. Здесь вы оказываетесь перед непростой дилеммой: или делиться своими сертификатами с провайдером услуг, или принимать риск того, что атака на уровне HTTPS может быть пропущена. Вендоры пробуют находить решения без вскрытия пакетов (что получается не всегда хорошо), либо используют специальный модуль дешифрации SSL/TLS трафика, встроенный в клиентское устройство:
В этом случае ваши сертификаты загружаются в устройство, находящееся под вашим же контролем, а задержки на дополнительную обработку пакетов составляют миллисекунды.
5. Ручное формирование сигнатур.
Большинство сигнатур формируется производителями решений по защите от DDoS-атак. Однако периодически возникают ситуации, когда ресурсы подвергаются новым типам атак.
В зависимости от вендора есть два возможных сценария действий в такой ситуации: либо запросить у производителя новую сигнатуру, либо создать сигнатуру самим. В первом случае, вам скорее всего придется доплатить за услугу, а также значительное время оставаться под атакой ожидая решения проблемы.
Во втором случае работает принцип «спасение утопающих – дело рук самих утопающих», ну или их партнёров. Здесь критически важным становится функционал оборудования, позволяющий быстро определить, перехватить и проанализировать зловредный трафик. А возможность автоматически сформировать сигнатуру на основе полученной информации становится спасением в критической ситуации. К примеру, возможность зайти в захват пакетов, выделить нужную битовую последовательность (bit pattern), и в пару кликов сделать сигнатуру, блокирующую такую последовательность.
Преимущество масштаба
У Arbor есть очень интересная «фишка», которая позволяет им очень эффективно использовать свою рыночную долю. Дело в том, что их оборудование стоит у всех TIER-I операторов связи и провайдеров и у большинства TIER-II операторов.
Позиция Arbor на рынке оборудования защиты от DDoS в сегментах Carrier, Enterprise, Mobile – 65% всего рынка — первая (Infonetics Research за декабрь 2013).
Через систему ATLAS проходит информация около 90 Тб/с. Как только где-то появляются признаки атаки, устройства начинают передавать по собственной сети связи данные о происходящем, и информация быстро распространяется по всему миру. К примеру, если «валят» мелкого провайдера, его железо сигналит по специальному протоколу уровнем выше. Если вышестоящий оператор имеет договоренность с нижестоящим, то сигнатура принимается и распространяется на все подсети крупного провайдера.
Сенсоры (honeypots) системы ATLAS расположены на основных узлах глобальной сети Интернет для обнаружения и классификации атак, активности бот сетей и различного зловредного софта. Информация отправляется в ЦОД ATLAS, где объединяется с данными полученными от инсталляция Arbor Peakflow и другими данными. Система анализирует в автоматическом режиме сотни тысяч элементов кода, и позволяет команде инженеров оперативно обновлять сигнатуры для клиентов компании по всеми миру.
Особенности подключения
Стоит сказать ещё пару слов про железо, которое ставится непосредственно к вам в ЦОД или на площадку. С ним тоже связано много реалий, о которых не всегда говорят.
1. Настройка и конфигурирование.
Как правило, устройству нужно время на профилирование трафика и оценку поведения сети. Но некоторые устройства поставляются в «боевом» режиме для работы с первой секунды после подключения – там уже есть готовые шаблоны, плюс устройство получает данные из «облака» своего вендора. С одной стороны, это хорошо в плане отражения идущей атаки, с другой – если вы привыкли тонко настраивать всё в своей инфраструктуре, здесь придётся частично положиться на опыт вендора.
2. Само защитное железо может стать точкой отказа.
Поэтому, во-первых, на серьёзных объектах оно дублируется или несколько устройств собираются в кластер (соответственно, нужны управляющие устройства). А во-вторых, такие устройства имеют аппаратные байпассы, позволяющие переключить интерфейсы на физическом уровне трафик напрямую в случае различных аварийных ситуаций – отключения питания, отказа программного обеспечения и так далее…
3.Защитное железо может стать и целью атаки.
Особенно, если оно является устройством с таблицей состояний (session table), например объединяет функционал защиты от DDOS, IPS, межсетевой экран, и т.д.). Каждый раз, когда на таких устройствах открывается новая сессия, устройство выделяет память для отслеживания сессии, заполняет лог и так далее – и чем умнее устройство, тем больше работы происходит. Много сессий – большая утилизация CPU и памяти. Поэтому, выбирая решение, стоит уделить внимание и этому аспекту.
4. Обычно в сети довольно много мусорного трафика, а в случае крупных организаций – ещё и регулярно бывают пики активности, которые могут сойти за «глупый» DDoS.
Понятно, что всё отпрофилируется по географии, по времени использования сервисов и так далее, но на первом этапе важно получить понимание, что включение устройства в сеть не убьёт сервисы. Для этого используется зеркальный режим подключения: устройство ставиться в сеть на байпасе и получает зеркальный трафик, показывая, что бы оно отклонило, а что бы пропустило. Это позволяет делать оценку до возникновения проблем. Я знаю заказчиков, где DDoS-защита стоит именно в таком режиме достаточно долго. Арбор считает, что построение baseline – это только один из методов борьбы с DDoS, но гораздо лучше использование специализированных противомер. То же самое коллеги говорят и о сигнатурах – насколько велика не была бы сеть сенсоров и сколько бы трафика в ней не анализировалось, полагаться только на сигнатуры нельзя. Сложные угрозы требуют сочетания разных механизмов защиты.
5. На уровне обмена трафиком между провайдерами иногда случается достаточно неприятная ситуация, когда подсеть передаёт сигнатуру атаки, а вышестоящий провайдер говорит: «Дааа, интересно, но мы у себя чистить не будем».
Принцип очень простой – пока канал справляется, весь DDoS-трафик билингуется. Не всегда вышестоящему провайдеру интересно тратиться и чистить его, когда можно просто отгрузить ниже, да ещё и за деньги потерпевшего. Такие ситуации неприятны для сервис провайдеров, однако никак не сказываются на пользователях услуг защиты от DDoS, поскольку операторы выполняют свои обязательства в полном объеме.
Отчёты
Одна из важных вещей – быстрое понимание того, что происходит. Давайте посмотрим на отчёты на примере двух атак на крупный российский банк. Почувствуйте, как у админов добавилось седых волос в комиксе ниже.
Атака ёмкостью порядка 50 Гбит/сек
Эта атака началась с DNS-amplification. Трафик, зафиксированный на Arbor Peakflow TMS сервис провайдера: до 7.15 Гбит/с., 1.1 Мпакетов/с. С учетом фильтрации большей части атаки на FlowSpec суммарный трафик атаки оценен в 50 Гбит/с. Атака была продолжена HTTP-флудом.
Зафиксировав аномальный рост трафика, клиентское устройство автоматически запросило помощь от сервис провайдера в подавлении атаки.
Система защиты установленная у оператора, передавала информацию о ходе подавления атаки на Pravail APS в режиме реального времени.
Когда DNS-amplification атака сошла на нет, появилось большое количество HTTP-флуда.
Кроме HTTP-флуда также присутствовал и TCP SYN флуд.
В результате, большая часть DNS-amplification атаки была успешно подавлена с помощью Flowspec, остальная ее часть была подавлена средствами системы защиты, а HTTP и TCP SYN флуд был сброшен на Pravail APS.
Атака ёмкостью порядка 125 Гбит/сек
Несколько минут в начале — HTTP-флуд. Виден всплеск числа иностранных хостов (красный график). Около 1000 хостов на домен «Крупного Российского Банка». Основные страны: США (672), Германия (141), Великобритания (82), Италия (30), Нидерланды (24), Франция (14).
Следующий сюрприз — NTP-amplification — до 125 Гбит/с.
После неудавшегося NTP amplification — SYN-флуд с подменными IP – до 300 Мбит/с
Резюме
Атаки идут постоянно, и если вы ещё с этим не сталкивались – это всего лишь вопрос времени. Для иллюстрации, вот несколько событий в РФ:
- Атаковали сайт Межпарламентской ассамблеи СНГ
- Атаковали сайт ЦБ РФ
- Атаковали сайт первого канала
- Атаковали сайт ВГТРК
- Атаковали сайт Кремля
- Атака на ВТБ24
- Атаковали сайт РИА
- Атаковали сайт Ленты
- Атаковали сайт газеты «Ведомости»
Если у вас есть вопросы — с удовольствием отвечу здесь или на почте avrublevsky@croc.ru. Наше подразделение может предложить и различные решения, если вам потребуется иной вендор.
А ещё завтра, 21 октября, мы проводим вебинар на тему защиты от DDoS. Приходите, расскажем, что у нас в России сейчас происходит на этом фронте.