Архитектура защиты от DDoS-атак нового поколения

Автор: Василий Сошников, заместитель технического директора EdgeЦентр

Сложность DDoS-атак с каждым годом растёт, а их объёмы исчисляются терабитами. Традиционные решения — аппаратные фильтры или программные межсетевые экраны — чаще всего не справляются с пиковыми нагрузками, а те, что справляются, стоят очень дорого. Кроме того, как показывает опыт, именно традиционные инструменты защиты падают первыми.

Мы в EdgeЦентр искали компромисс между производительностью, гибкостью и стоимостью. Эти поиски привели к появлению нового подхода, основанного на использовании технологии eBPF и её сетевого подвида — XDP (eXpress Data Path). Именно эту технологию мы используем в нашей CDN и в нескольких уровнях защиты от DDoS-атак.

Наша архитектура защиты построена на принципе многоступенчатой распределённой фильтрации от L2 до L7. И этот принцип позволил нам отразить серию масштабных кибератак нового поколения — подробнее об этом можно прочитать в нашем кейсе.

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

Какой должна быть современная защита от кибератак

Основные требования к современной системе защиты:

1. Основной мусорный трафик должен блокироваться до того, как он дойдёт до защиты на уровне L7, и, как следствие, до SSL-терминации. Защита L7 всегда дороже L2-L4.
2. Трафик должен непрерывно анализироваться на предмет атак. Хороший пример такого мониторинга — протокол sFlow. Самое главное — реакция на атаку должна быть быстрее, чем атака достигнет своей цели.
3. Для управления всеми подсистемами и контрмерами обязательно должен быть Control Plane.

Ключевые элементы современной защиты:

• Непрерывно обновляемая база JA-отпечатков (JA hash) и база скоринга для L2-L7.
• Kernel space (XDP, eBPF) для обработки трафика на уровне L2-L4 и user space (зрелый прокси-сервер) для L7.
• Анализатор трафика и сложная система алертов.
• Возможность в приемлемое время поставлять новые контрмеры. 

Это самые основные моменты. Каждый из пунктов можно расширять.

Фильтрация состоит из 4 последовательных этапов:

1. Обязательная транзитная фильтрация на уровне L2-L4 (относительно грубая). Важно, чтобы она умела работать на сервере, без дополнительных инструментов и решений, например, на CDN-сервере.
2. Тонкая фильтрация с отслеживанием состояния на уровне L4. Этот этап в некоторых случаях можно пропустить. Но для отражения современных сложных кибератак он важен.
3. Фильтрация на пограничных серверах (Edge) с учётом глобального контекста. Это фактически транзитная защита, но с упрощённой логикой работы.
4. Глубокая фильтрация на прикладном уровне (L7).

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

На базе этих же этапов строится DDoS-защита веб-сервисов на уровне L7. Но там есть свои нюансы. Об этом мы поговорим в отдельной статье.

Теперь давайте разберём каждый этап фильтрации подробнее.

Этап 1. Транзитная грубая фильтрация на L2–L4

Первый рубеж обороны размещается на входных узлах или на точках присутствия CDN (или и там, и там). Здесь важно не задерживать поток, поэтому фильтрация опирается на максимально простые правила. Но уже на этом уровне некоторое состояние распространяется между узлами. 

Задачи уровня:

• Блокировка пакетов с недопустимыми IP-адресами (например, source address 0.0.0.0 или multicast в неположенных диапазонах).
• Проверка корректности контрольных сумм заголовков TCP/UDP.
• Фильтрация по протоколу (например, разрешены только TCP, UDP и ICMP) и по портам (закрытие неиспользуемых).
• Блокировка по заранее заданным правилам.

Также есть множество других проверок, суть которых сводится к работе с данными на уровнях L2-L4, но без TLS-терминации.

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

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

Правила фильтрации (чёрные списки, разрешённые протоколы и т.п.) хранятся в BPF-картах (hash-таблицах) и обновляются управляющей программой без перезагрузки XDP-кода. Фактически поток сетевых данных не прерывается ни для реконфигурирования, ни для обновлений кода.

Этот подход применяется и для других XDP/eBPF-фильтров. Таким образом, администратор может мгновенно реагировать на новые угрозы и моментально доставлять изменения до серверов.

Этап 2. Тонкая фильтрация на L4 с отслеживанием состояний

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

Задачи уровня:

• Отслеживание состояния TCP-соединений: верификация SYN-ACK, фиксация таймаутов и т.п.
• Ограничение числа новых соединений в единицу времени с одного источника (rate limiting и другие подобные механизмы).
• Выявление аномалий на основе статистики и анализа трафика: резкий всплеск числа пакетов определённого типа, большое количество фрагментированных пакетов, повторяющиеся поля в заголовках и другие отступления от нормы.
• Проверка по белым и чёрным спискам.
• Более тонкие проверки, о которых я, возможно, расскажу в других статьях.

Реализация данного уровня уже более комбинированная. Часть берёт на себя kernel space, используя те же подходы, что я описал ранее. Часть проходит на уровне L7, в WAF и WAAP.

Важной особенностью является обмен информацией между всеми уровнями. Здесь мы стараемся отсекать до 80% типовых атак: SYN-флудов с подменёнными адресами, UDP-амплификационных атак, сканирующих ICMP-эхо-запросов и других подобных.

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

Этап 3. Edge-серверы: распределённая фильтрация на L2-L4 для CDN

Мы выделили этот уровень в отдельный, но в некоторых случаях он может заменять первый этап.

Уровень реализуется на группе пограничных территориально распределённых серверов (Edge). Эти серверы выполняют двойную функцию: фильтруют трафик с учётом глобальной и локальной картины атак.

Задачи уровня:

• Защита инфраструктуры CDN
• Защита клиентов наших сервисов
• Сбор аналитических данных

Каждый Edge-сервер запускает набор XDP-программ, которые выполняют проверку аналогично первым двум уровням, но с учётом специфики CDN.

Если на этом уровне трафик признаётся чистым, он передаётся далее в нашу инфраструктуру. Всё остальное блокируется либо по всей сети, либо на Edge-серверах в конкретном регионе. Кроме этого, может подключаться L7-защита на CDN.

Этап 4. L7-фильтрация

Последняя линия обороны и, наверное, самая тяжёлая и тонкая очистка трафика — анализ на уровне прикладных протоколов (HTTP/HTTPS). Она уже не может выполняться средствами XDP, поскольку требует глубокого разбора содержимого и часто расшифровки TLS-сессий. Тем не менее, её архитектурная роль критически важна: она защищает бизнес-логику и данные от «умных» атак, обходящих низкоуровневые фильтры.

Задачи уровня:

• Анализ и блокировка вредных запросов с помощью реверсивных прокси с модулями WAF, WAAP и антибот. Модули работают на основе сигнатур, поведенческих правил и некоторых других факторов.
• Обнаружение различных отклонений с помощью специализированных анализаторов HTTP-трафика.
• Обнаружение ботов с помощью капчи, текстурной капчи, JS Challenge, анализа поведенческих факторов и других систем.

На этом уровне также ведётся детальное логирование всех событий c сэмплированием. Это необходимо для расследования инцидентов и совершенствования правил фильтрации.

Инструментарий: анализатор трафика и алерт-менеджер

Для успешной работы описанной системы нужна развитая система мониторинга и оповещения. Два ключевых её компонента: анализатор трафика и алерт-менеджер.

Анализатор трафика

Часто его ещё называют Traffic Inspector. Он принимает адаптивно-сэмплированные данные от отдельной XDP-программы: IP-адреса, протоколы, размеры, временные метки.

Дальше анализатор делает следующее:

• Агрегирует статистику за временные промежутки.
• Вычисляет производные метрики: PPS (количество пакетов в секунду), BPS (количество бит в секунду), количество различных протоколов, распределение по странам (по GeoIP) и т.п.
• Сохраняет историю во временных рядах.
• Поставляет готовые данные для алерт-менеджера и для интерфейса оператора.

Сбор данных происходит непосредственно из XDP. Результат — максимально точные показатели, которые не искажены буферизацией в сетевом стеке. 

Также анализатор получает информацию от L7. Система работает по похожей логике, но данных больше.

Алерт-менеджер

Сердце и операционный центр системы. Тесно связан с Control Plane, работает на данных, производимых Data Plane.

Что фактически делает алерт-менеджер:

• Получает метрики от анализатора трафика, логи и сигнатуры от L7.
• Применяет набор правил для обнаружения аномалий.
• Генерирует оповещения разных уровней критичности: информационные, предупреждения, критические.
• Отправляет уведомления через различные каналы.
• В автоматическом режиме может инициировать изменение правил фильтрации.

Масштабирование и отказоустойчивость

Масштабирование системы не сводится к простому наращиванию количества экземпляров. Если говорить коротко, оно берёт своё начало от наших Anycast-сетей и GSLB. Но устройство масштабирования — это тоже довольно обширная тема. Если интересно, мы можем разобрать её в следующей статье — пишите в комментариях.

Подведём итоги

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

• Строиться на базе XDP для уровней L2-L4.
• Сочетать в себе высокую производительность и гибкость за счёт динамически обновляемых eBPF-программ и управляющего слоя.

Поэтапное уменьшение трафика позволяет эффективно использовать ресурсы каждого уровня, а обратная связь между L7-анализом и XDP-фильтрацией обеспечивает мгновенную адаптацию к новым угрозам.

Уверен, что в будущем системы защиты от кибератак будут развиваться в этом направлении. Однако их дальнейшее развитие лежит в том числе в плоскости DNS и рекомендательных систем.