Раньше DDoS-атаки могли успешно отбиваться на стороне ЦОДа атакуемой компании. Быстрые умные действия админа и хорошее фильтрующее железо гарантировали достаточную защиту от атак.Сегодня услуги ботнетов стремительно дешевеют, и DDoS становится доступен чуть ли не в малом бизнесе.

Около половины атак идут на интернет-магазины или коммерческие сайты компаний в духе «завалить конкурента», почти всегда атакуют сайты СМИ, особенно после «горячих» публикаций, намного чаще, чем кажется, бьют по госсервисам. В России главные цели – банки, розница, СМИ и тендерные площадки. Один из крупных российских банков, например, периодически блокирует трафик из Китая – атаки оттуда приходят с завидной регулярностью, одна из последних была больше 100 Гб/с.

Соответственно, когда атака переваливает, скажем, за 10 Гб/с, отражать её на своей стороне становится проблематично из-за банального забивания канала. Именно в этот момент нужно делать переключение на центр очистки данных, чтобы весь «плохой» трафик отсеивался ещё где-то около магистральных каналов, а не шёл к вам. Сейчас расскажу, как это работает у одного из наших вендоров защитных средств – Arbor, мониторящего около 90 Тбит/сек (45% мирового трафика Интернета).

Сценарий атаки

Сначала злоумышленник выбирает цели внутри инфраструктуры. Большая часть «глупых» атак идёт на HTTP, очень много атак на DNS, но основные «умные» атаки обычно направлены на заранее разведанные узлы внутри инфраструктуры цели. Нередко DDoS ставит целью не только и не столько отказ сервисов, сколько возможность пронести «под общий шум» через DMZ более серьёзную угрозу. Это нередко достигается с помощью «перегрузки» систем периметровой защиты, таких как межсетевые экраны, IPS/IDS и им подобных, основанных на отслеживании сессий (stateful inspection). Поэтому коллеги считают, что если у устройства есть таблица состояний (session table) – его следует рассматривать как часть инфраструктуры, нуждающейся в защите.

Основные точки атак:



Схема отражения атаки реализуется следующим образом:

1. На стороне защищаемой компании стоит устройство, «закрывающее» сеть. Как только начинается атака, устройство должно опознать её как аномалию, используя одну из механик, например, встроенные противомеры, ненормальное поведение источника трафика либо соответствие известному профилю атаки (сигнатуре из базы).
   
2. Если устройство справляется с атакой, работа продолжается в относительно штатном режиме: легитимный трафик пропускается, нелегитимный – режется. Есть несколько «уровней тревоги», отличающихся степенью сложности атаки и возможными потерями легитимного трафика.
   
3. Если канал связи начинает забиваться, то выполняется автоматическое перенаправление трафика с помощью штатного протокола 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), и в пару кликов сделать сигнатуру, блокирующую такую последовательность.