DoS-атаки на сети доставки контента, CDN Content Delivery Network
Благодаря способности значительно повышать производительность сети, сети доставки контента (Content Delivery Network, CDN) быстро набрали популярность, контролируя все большее количество трафика в интернете. Сети CDN работают путем сохранения статического контента в кэш-памяти своих собственных серверов и размещения его ближе к пользователям по всему миру, что позволяет ускорить доступ. Вероятно вследствие того, что большинство данных хранятся на серверах сети CDN, пользователи начали верить, что сети CDN, помимо всего прочего, обеспечивают защиту от DoS/DDoS-атак.
Содержание |
Действительно, сеть CDN может поглотить крупномасштабные атаки, превращая перегрузку центра обработки данных сетей CDN в сложную задачу. Сеть полностью контролирует сохраняемые данные и доступ к ним пользователей. Данные также защищены с помощью тестов для распознавания людей и машин (Captcha) или других методов аутентификации пользователей.
К сожалению, такие меры создают ложное чувство безопасности. Сети CDN не призваны и не оборудованы для полной защиты от DoS/DDoS-атак, и способны защитить только те данные, которые хранятся в пределах таких сетей; а данные в ЦОД клиентов остаются незащищенными. В сложных DDoS-атаках используются несколько векторов атак для того, чтобы направить атаку непосредственно на уязвимости ЦОД клиента в обход сети CDN. Вот несколько примеров того, как это может произойти.
Пробелы в безопасности сетей CDN, которые могут быть использованы для организации DoS-атак
Динамические данные – в сетях CDN хранятся только статические данные. Все динамические данные, такие как рыночные котировки, текущие погодные условия, заголовки последних новостей и другие, хранятся в ЦОД клиента. На практике запросы на динамический контент идут в обход сети CDN и направляются непосредственно в ЦОД клиента. На этом строятся DoS-атаки, обходя сети CDN и системы защиты. Злоумышленник также может получить доступ к динамическому контенту, изменяя параметры рекурсивных запросов и заставляя сеть CDN «приподнять занавес» и направить запрос непосредственно в ЦОД.
Директивы системы кэширования данных – директивы системы кэширования представляют собой особые параметры HTTP-заголовка, которые дают указания сети CDN передать запрос серверу баз данных или отправить ответ, используя кэш-память. Команда Radware ERT была свидетелем множества ситуаций, когда злоумышленники использовали директивы системы кэширования, такие как «cache-control: no-cache» или подобные им указания «Pragma: no cache» С помощью этих директив злоумышленники обходят защитный уровень сети CDN даже для статических данных.ИТ-директор «Роснефти» Дмитрий Ломилин выступит на TAdviser SummIT 28 ноября 
Особо распределенные атаки – распределенные в значительной степени атаки не достигают большого объема на любом из узлов сети CDN, и их мощность возрастает только по достижении атакуемого ЦОДа, в обход сети CDN вызвая отказ в обслуживании. Крупномасштабная сеть CDN не способна в реальном времени синхронизировать данные и статистику во всех ее точках, что мешает эффективно отследить распределенную атаку крупного или небольшого объема.
Примеры таких уязвимостей отчетливо показывают, что хотя сеть CDN дает надежную защиту от многих векторов атак, она, тем не менее, не может обеспечить полную защиту от DoS/DDoS-атак. Принцип 80/20 не может применяться в контексте обеспечения безопасности, поскольку хакеры всегда пользуются открытыми «дырами» или слабыми точками системы, эффективно используя те вектора атак, которые не покрываются системой защиты.
Анализ примера DDoS-атак на сети CDN
Проанализируем атаку на крупную корпорацию, которую назовем BCDN. BCDN размещала некоторую часть своего контента на серверах крупного CDN-провайдера, однако динамические данные хранились в ЦОД компании. В процессе DDoS-атаки, нацеленной на BCDN, хакеры использовали три различных вектора атак.
По первому вектору искаженные TCP пакеты отправлялись на публичный IP-адрес BCDN, в то время как по второму вектору «мусорные» UDP пакеты отправлялись на порт 53 (DNS-порт). Компания BCDN использовала надлежащую систему защиты, благодаря которой первые два вектора атак были успешно остановлены.
Хакеры были осведомлены, что BCDN хранит данные в сети CDN, и использовали третий вектор атак. Данный вектор – простая атака типа HTTP-флуд – могла бы быть легко заблокирована, если бы система защиты не была бы расположена за сетью CDN. Как бы то ни было, здесь была использована техника обхода CDN – отправление запросов на доступ к динамическим данным ЦОД. Такая тактика привела к тому, что CDN пропустила хакеров к ЦОД.
Поскольку данный вектор проходил через сеть CDN, IP-адрес источника всех запросов представлял собой IP-адрес CDN и был признан легальным. Серверы сети CDN, а также любой легальный пользователь за пределами CDN, легко проходили проверку запрос-ответ, отправляемую системой отражения атак. В контексте обеспечения безопасности, после прохождения всех проверок IP-адрес помечается как «безопасный» (временно добавленный в белый список) и ему разрешается доступ к серверам. Как только CDN IP был помечен, как безопасный, все запросы, как легитимные, так и отправленные злоумышленниками, достигли ЦОД, вызвав отказ в обслуживании.
Была предпринята попытка ограничить трафик, установив пороговую величину. Однако избирательно заблокировать определенных клиентов было невозможно, и ограничение было установлено для всех CDN соединений. Поскольку большая часть соединений относилась к атаке, легитимные пользователи, расположенные за CDN сетью, не могли получить доступ к серверам компании BCDN. Данный метод отражения атаки оказался неэффективным и не помог остановить DoS-атаку, поскольку как легитимный трафик, так и трафик злоумышленников исходили от одного и того же IP-адреса.
Единственным местом, где содержался фактический IP-адрес пользователя, являлся заголовок XFF (X-Forwarded-For) HTTP-пакета. Чтобы заблокировать атаку, на основе XFF данных был произведен офлайн анализ IP-адресов атакующих. Как только IP-адреса были идентифицированы, их заблокировали путем проверки XFF на IP-адреса злоумышленников. Данный пример наглядно демонстрирует тот факт, что отражение атаки, которая проходит в обход CDN, является сложной задачей, для решения которой требуется вмешиваться вручную, что занимает много времени.
См. также
