Каким угрозам подвержены сети доставки контента и как объединить возможности CDN и защиты от DDoS, чтобы быстро останавливать атаки и не разориться на трафике.

Многим нравится «коробка» Cloudflare, в которой есть и CDN, и защита. Но вот американского провайдера то блокируют, то не блокируют, и непонятно, что делать, куда податься. Поэтому в компании со знающими людьми решили разобраться на подкасте linkmeup, можно ли повторить решение Cloudflare и совместить CDN и DDoS-защиту в одном флаконе. В этой статье собраны основные моменты, о которых мы говорили.

Особенности трафика на CDN

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

При этом для любого ресурса трафик на прикладном уровне можно разделить на две категории.

Статический: контент, который не изменяется при показе юзеру независимо от того, где человек находится, с какого устройства пришел, в какой момент времени и т.д. Это наша разметка, тексты, картинки, видео, прямые трансляции и прочее.
Динамический: контент, который генерируется по запросу. Если нужно что-то лукапить в базе, значит, запрос динамический. Это API, формы и пр. — все, куда пользователи адресуют свои запросы.

То, как трафик проходит через инфраструктуру CDN, обрабатывается и отдается, сильно отличается в зависимости от его категории. Когда речь о статике, задача решается просто: неизменяемый контент кешируется в как можно большем количестве мест для как можно большего количества пользователей. А вот с динамикой история немного другая: насколько «разлапистой» и геораспределенной ни была бы CDN, каждый запрос пользователя нужно доставить до бэкенда.

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

Чтобы лучше разобраться, почему совместить CDN и защиту довольно сложно, рассмотрим, чем отличаются такие решения.

Различия между строительством CDN и сети фильтрации трафика

1. Архитектура сети

Основные элементы, которые участвуют в процессе доставки контента, — origin и edge ноды. Origin — это клиентский узел или несколько узлов для разного трафика. В качестве origin могут выступать виртуальные машины, хранилище S3 со статическим контентом или, например, endpoint на стороне клиента, которые заводятся частично или полностью за CDN.

В свою очередь edge-ноды кешируют запросы и при необходимости ходят к origin за недостающей частью данных.

Между origin и edge можно также поставить shield-сервер (шилд) — промежуточный кеш. Тогда edge-ноды обращаются за отсутствующим контентом к шилд-серверам, которые могут балансировать трафик между собой. И только если ни на одном из шилд-серверов нет нужного контента, шилды обращаются к origin.

Что касается сервисов DDoS-защиты, их можно сравнить с большой воронкой, раструб которой направлен в интернет. Для максимальной эффективности эта воронка должна быть широкой, и в горловине у нее должно быть много «железа», которое принимает большую полосу и способно отсмотреть каждый запрос и сказать: пускаем или нет.

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

2. Балансировка и перенаправление трафика

Поскольку CDN провайдеры соревнуются в скорости доставки контента, для маршрутизации трафика используется GeoDNS. В этом случае точку выдачи контента корректируется с учетом местоположения IP-адреса пользователя. Некоторые CDN используют только GeoDNS, другие — совмещают эту технологию с Anycast, третьи — предоставляют GeoDNS как платную услугу для тонкой настройки скорости доставки.

Сервисы защиты от DDoS, наоборот, не любят GeoDNS. Подавляющее большинство из них используют технологию Anycast. То есть диапазоны адресов — их клиентский контур в контексте BGP — одинаково доступны на всех точках присутствия. Это нужно, чтобы направлять трафик как можно ближе к ближайшему центру очистки, уменьшать количество хопов, сокращать Round Trip Time (RTT), а также гибко управлять потоками трафика, которые заходят в сеть очистки из разных концов света. 

Казалось бы, в мире есть места, где можно с одинаковым успехом ставить и CDN, и защиту от DDoS. Например, на российском М9 можно было бы и фильтровать трафик, и с помощью операторов связи и точек обмена раздавать контент на всю европейскую часть страны (и не только). Но дальше в игру вступают деньги в виде затрат на присоединение сети провайдера к внешнему миру — аплинки.

3. Стоимость

Операторы связи очень любят CDN, потому что это исходящий — из их сети — трафик, за который заплатят клиенты, либо уменьшение входящего — платного для операторов — трафика. И очень не любят сервисы DDoS-защиты, потому что это забитая входящая полоса, повышение расходов на аплинки, разбирательства с ноками (сетевиками) клиента и т.д. Поэтому CDN-провайдеры могут договориться об эффективных тарифах и подключать большую емкость, а сервисы защиты платят по полному прайсу.

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

Основные типы DDoS-атак, связанных с CDN

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

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

Атаки на транспортные протоколы — самый популярный тип DDoS на протяжении последних 30 с лишним лет. Это все атаки, связанные с протоколом TCP: флуд SYN, SYN-ACK-пакетами, а также производные от таких векторов.

Сила атак на транспортные протоколы продолжает расти вместе с производительностью ботнетов, которые могут состоять из заражённых серверов, виртуальных машин, клиентских компьютеров, роутеров и даже устройств «умного дома».

Атаки на прикладном уровне сети, то есть на уровне протоколов HTTPS, HTTP/2, HTTP/3. Эти атаки можно разделить на:

обычные атаки, которые либо не делают различий, либо целятся непосредственно в динамику, например, в API.
те, которые эксплуатируют статический контент и принципы работы CDN.

Например, зловреды могут представиться CDN-нодами, чьи IP-адреса добавлены в доверенные списки или в ACL (Access Control List), и создать сотни тысяч запросов, чтобы положить origin сервер. Или злоумышленники делают так, чтобы запросы не получали ответа из кеша и заставляли CDN ходить в origin за контентом. Самый примитивный вариант — атака на несуществующие файлы.

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

Если картинок много и они весят не по 10 кб каждая, то можно нагенерить солидный объем исходящего трафика. И здесь появляются риски уже не только по процессорному (вычислительному) ресурсу, но и по полосе самого origin. Плюс возникают вопросы биллинга, потому что операторы выставляют CDN счета по количеству отданного контента. Поэтому такие атаки еще называют атаками на кошелек.

Как сами CDN противостоят атакам

Чтобы бороться с DDoS-атаками, CDN используют инструменты защиты на прикладном уровне. Сеть доставки контента может частично отсекать трафик. Например, шилдинг защищает origin от массовых запросов несуществующего контента. При такой атаке шилд-серверы будут обращаться к основному источнику гораздо реже, чем если бы запросы поступали напрямую с edge-нод.

Кроме того, для «самозащиты» CDN использует шардирование, когда происходит ребалансировка кешей между серверами в одной локации, а также базовую фильтрацию трафика, например, по GeoDNS или по user agent, заголовку и др.

Еще для очень крупных клиентов можно сделать многоуровневый кеш, когда «горячие» данные хранятся на edge-нодах, «менее горячие» — на шилдах (промежуточных кеш-серверах), а «холодные» — на origin. Если у вас глобальный сервис, то можно добавить «суперкеши» и расположить, допустим, по одному на континент, но это применяется достаточно редко.

Также CDN используют такой механизм, как подпись запросов. Он позволяет удостовериться, что запрос пришел от настоящей CDN-ноды, а не от злоумышленника — ведь ничего не стоит подменить адрес отправителя и запросить данные как бы от имени CDN. Одна из самых известных реализаций этого механизма — G2O (global to origin) от Akamai. В этом случае каждый запрос от ноды подписывается специальным токеном, который состоит из публичной части и секретного ключа.

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

Почему сложно совместить CDN и защиту от DDoS

Представьте, мы наливаем воду в канистру через воронку. Это удобно. Теперь давайте перевернем воронку — будет не так удобно.

CDN, по сути, и есть воронка, развернутая в обратную сторону. Она отдает много трафика без каких-то манипуляций над ним.

Сравните пути трафика:

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

Как видите, пути сильно отличаются друг от друга.

Поэтому в случае совмещения веб-защиты и CDN архитектура может выглядеть так:

У клиента есть некий origin-сервер или хранилище статики, доступное для внешних систем. И есть его бэкенд, который обрабатывает API-запросы, общается с фронтом, отдает на него динамический контент.
Кеш в статике забирается на инфраструктуру CDN.

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

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

Как подружить CDN и WAF

Основным инструментом анализа запросов в реальном времени является файрвол (WAF). Если коротко, WAF умеет:

детально анализировать каждый запрос на прикладном уровне: заголовки, тело, параметры — все это он может сопоставить, сравнить, найти, нет ли «злых» кавычек и прочих эксплоитов.
анализировать поведение каждого пользователя: какой по счету запрос, куда стремится тренд пользования этого юзера и т.д. И может принять решение — банить или нет.

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

В то же время просто поставить WAF модулем к CDN тоже не лучшая идея. Проблема в том, что WAF на том же объёме трафика требует гораздо — на порядки — больше вычислительных ресурсов, чем работа кеша.

На внешний периметр CDN можно выносить только самую простую часть функциональности WAF: статические правила анализа заголовков, размера запроса, количества запросов в секунду. Это связано с тем, что CDN-ноды тоже могут подвергаться атакам на отказ в обслуживании. И если произойдет реально большая атака, лучше пожертвовать быстродействием и пустить трафик в защищенный периметр на фильтрующую сеть, чем потерять трафик вообще.

На что обратить внимание при выборе CDN и защиты от разных провайдеров

Если вы используете сервисы CDN и DDoS-защиту от разных провайдеров, то самая популярная опция — защита только динамического бэкенда.

Первый вариант выглядит так:

Подключаете защиту от DDoS

Получаете IP-адреса (для изменения DNS-записи вашего ресурса на серверы защиты)
Настраиваете проксирование или подключаетесь по BGP, заводите префикс за DDoS-защитника

Сервер статики (или S3-хранилище) подключаете к CDN-провайдеру и раздаете через его кеш.

В результате потоки трафика не пересекаются. Но остаются риски атаки напрямую на сервер статики либо атаки через CDN.

Второй вариант — когда вы прячете все за DDoS-защиту. Любые внешние системы — и запросы пользователей, и CDN-ноды контент-провайдера — обращаются к origin через DDoS-зонтик.

Обе схемы рабочие и активно используются в самых разных сферах — от ecomm до финансов и пр.

Что касается WAF, их сейчас много, и среди них есть очень крутые — как в облачном исполнении, так и в виде виртуального или «железного» appliance, которые живут на инфраструктуре заказчика. Выбирать стоит с точки зрения ресурсов, которые вы подключаете, затрат и требований регулятора, если такие есть.

Как видите, успешно совмещать CDN, защиту от DDoS и WAF можно. Главное — включать голову.

CDN и DDoS-защита: взболтать, но не смешивать?