Преимущество масштаба

У 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 Мбит/с