Проблемы и возможности «облачной сигнализации» в эшелонированной защите от DDoS-атак
Привет, Хабр! Меня зовут Вадим Солдатенков, мы с вами уже касались темы Anti-DDoS. Поскольку я по-прежнему отвечаю за продукт «Гарда Anti-DDoS», сегодня расскажу об одном из механизмов организации эшелонированной защиты, который органично дополняет концепцию безопасности с использованием Национальной системы противодействия DDoS-атакам (НСПА) и блокировкой трафика на технических средствах противодействия угрозам (ТСПУ).
В текущих условиях многоуровневая, эшелонированная защита де-факто становится насущной необходимостью и стандартом в организации обороны от DDoS-атак.
Разберем стандартную схему организации эшелонированной защиты, рассмотрим схему работы операторского комплекса, поговорим возможных факторах риска, об облачной сигнализации, ее минусах и плюсах, и возможностях для заказчика в усилении защиты с ее использованием.
Стандартная схема организации эшелонированной защиты
Обычно эшелонированная защита клиентских сервисов, расположенных в собственном ЦОДе или на корпоративной ИТ-площадке, обеспечивается на двух уровнях: оператором связи, который останавливает объемные атаки, и локальным комплексом Anti-DDoS для точной защиты.
Эшелонированная защита: услуга оператора плюс локальный комплекс
Как правило, эти два блока не имеют прямых пересечений. Отдельно работает операторский сервис под управлением дежурной смены оператора, когда заказчику предоставляют ограниченный доступ в личный кабинет для отчетов и настроек. А на стороне компании функционирует локальный клиентский комплекс под непосредственным контролем сотрудников заказчика.
Схема работы операторского комплекса
Для выявления DoS/DDoS-атак Анализатор непрерывно получает и обрабатывает данные о трафике (flow) с пограничного маршрутизатора, а также поддерживает с ним BGP-сессию (подключение по протоколу динамической маршрутизации). Собранные данные о трафике записываются в Хранилище для последующего ретроспективного анализа. В штатном режиме весь трафик к защищаемой сети приходит напрямую от пограничного маршрутизатора к внутреннему. При выявлении атаки маршрут прохождения прямого трафика в защищаемую сеть изменяется посредством отправки BGP-анонса на пограничный маршрутизатор и трафик перенаправляется на Очиститель. После очистки трафик возвращается в сеть. При такой схеме маршрут обратного трафика не меняется.
При подходе с фильтрацией по детектированию сначала атаки обнаруживаются на основе информации о трафике (то есть на основе анализа «флоу-записей»), и только потом происходит перенаправление на модули фильтрации операторского комплекса. Такой подход оправдан, так как позволяет оператору связи экономнее расходовать свои ресурсы. Объективный минус такого подхода только один — скорость. В зависимости от сетевой инфраструктуры оператора пауза перед началом фильтрации может достигать нескольких минут.
Альтернативный вариант — постоянная фильтрация трафика — приводит к повышенной утилизации сетевых ресурсов: загрузке роутеров (вычислительная мощность, оперативная память), каналов (так как через роутеры проходит больше трафика), а также повышенной утилизации мощностей операторского комплекса Anti-DDoS за счет постоянно работающих заданий очистки.
Поэтому операторы предпочитают использовать схему с фильтрацией на основе детектирования, а не постоянную фильтрацию.
Скорость важна. Технологические факторы риска
Когда атака направлена не на конкретный сервис, а на каналы в целом или сеть в целом (объемные атаки), все клиентские средства защиты от DDoS становятся неэффективны. В этом случае действенным средством становится подавление атак на уровне выше, где больше возможностей, то есть на уровне оператора связи. И здесь важна скорость.
Факторы, которые могут влиять на оперативность отражения атаки:
задержка при выявлении: трафик перенаправляется на фильтрацию не по первому признаку, а лишь после нескольких срабатываний, чтобы исключить ложную тревогу и получить подтверждение, что это именно атака, а не разовый всплеск трафика;
перегрузка сетевого оборудования по различным причинам (например, атака или авария), вследствие чего маршрутизаторы перестают отправлять информацию о трафике и детектирование не осуществляется;
отсутствие у клиента информации для принятия решений: если все каналы «забиты», заказчик может не попасть в свой личный кабинет на операторском комплексе Anti-DDoS. Для заказчика задержки в отражении могут быть решающим фактором.
Что делать в таких случаях? По аналогии с известным шоу, приходится последовательно перебирать три возможности.
«Отражать нельзя медлить»
Отражать нельзя медлить
Облачная сигнализация
Облачная сигнализация — это автоматизированная связь между нижестоящим клиентским защитным комплексом и инфраструктурой вышестоящего оператора связи для фильтрации объемных атак. Облачная сигнализация как раз и обеспечивает принудительное или автоматическое включение «защиты на уровне выше».
Типовая реализация облачной сигнализации заключается в использовании метода BGP FlowSpec (иногда его называют BGP Cloud Signaling). Работает это так: в рамках BGP-сессий клиентский комплекс отправляет провайдеру информацию о том, какой трафик блокировать.
Ограничения такого подхода:
не все можно заблокировать BGP FlowSpec. Подходит для объемных, но несложных атак;
не все оборудование поддерживает BGP FlowSpec. Например, ряд отечественных моделей маршрутизаторов «не умеют» работать с этим протоколом;
и принципиальный момент: при разрыве BGP-сессии защита отключается. Протокол BGP функционирует поверх TCP, который требует установки сессии для взаимодействия. В условиях атаки сессии рвутся (или не устанавливаются), а защита, соответственно, отключается.
Помимо BGP FlowSpec существует и соответствующий мировым стандартам подход облачной сигнализации, который применяется в том числе в нашем комплексе «Гарда Anti-DDoS». Для этого мы разработали собственный протокол pSignal. Рассмотрим подход подробнее на примере нашего решения.
Схема облачной сигнализации в «Гарда Anti-DDoS»
Для отражения атак, превышающих пропускную способность интернет-каналов, реализована возможность гарантированной облачной защиты: нижестоящий комплекс клиента отправляет запрос вышестоящему комплексу оператора связи, активируя защиту. Для связи между операторским и клиентским комплексами применяется шифрованный протокол облачной сигнализации pSignal. С его помощью реализованы следующие возможности:
1. Гарантированная передача команды о начале фильтрации на операторский комплекс Anti-DDoS за счет работы pSignal поверх протокола UDP, не требующего установки сессии соединения;
2. Установка защищенного соединения между клиентским устройством и операторским комплексом для отслеживания статусов и отправки команд;
3. Управление сегментами сети, которые защищает операторский комплекс, с клиентского устройства;
4. Отображение статистики фильтрации операторского комплекса (например, суммарный трафик и отброшенный трафик) в интерфейсе клиентского комплекса;
5. Создание индивидуальных черных и белых списков по каждому объекту защиты, и передача их в шифрованном виде под атакой на операторский комплекс;
6. Устойчивость к перехвату управления злоумышленниками за счет использования шифрования и меток времени для выполнения команд;
7. Поддержка связи одного клиентского комплекса сразу с несколькими операторскими защитными решениями.
Первая версия протокола была выпущена достаточно давно и ограничена возможностью задавать только одно задание подавления атаки для защиты на операторском комплексе всех клиентских объектов. А вот во второй версии pSignal реализована возможность ставить под защиту несколько объектов, описываемых как набор хостов или сетей — и каждый с индивидуальными настройками защиты.
Преимущества для компании с клиентским комплексом, использующим новую версию облачной сигнализации:
полноценная совместная защита. Не всегда те меры защиты, которыми клиент хотел бы защищаться на уровне выше, могут быть в полном составе применены оператором на своем комплексе, т.к. они повышают нагрузку на системы Anti-DDoS в ущерб другим клиентам. Использование pSignal позволяет организовать полноценную совместную защиту, когда методы для тонкой и умной фильтрации включены на клиентском комплексе без каких-либо ограничений, а операторский обеспечивает защиту прежде всего от объемных атак;
выбор нескольких защищаемых объектов, задаваемых IP-адресом или подсетью, каждый — со своим индивидуальным заданием подавления атаки. Это позволяет более эффективно защищать различные сервисы, находящиеся у клиента. Например, разные подходы требует защита веб- сервисов, DNS или SIP;
превентивные меры для объемных атак. Когда атака проходит только на один IP-адрес из блока адресов защищаемого объекта и операторский комплекс фильтрует трафик только к этому IP адресу, клиент может добавить в фильтрацию на операторском комплексе остальные адреса защищаемого объекта. Это превентивная мера, которая может оказаться решающей для эффективной защиты в условиях атаки.
Вывод
Механизм облачной сигнализации в рамках эшелонированной защиты от DDoS-атак предоставляет новые возможности для своевременной и гибкой защиты сетевой инфраструктуры от объемных атак. Этот подход, особенно с использованием обновленного протокола pSignal, позволяет заказчикам активировать защиту на уровне оператора связи с минимальной задержкой, устанавливать более надежное соединение и эффективно управлять защитой сразу нескольких объектов с учетом индивидуальных требований.
Преимущества облачной сигнализации заключаются в улучшенной совместной защите, способности устанавливать персонализированные настройки для разных ресурсов и возможностях превентивной фильтрации для минимизации последствий от крупных атак.
