В MITIGATOR реализована поддержка множества сценариев встраивания в сеть заказчика. Ниже описаны основные термины и способы внедрения в сеть, а также примеры внедрения.
Логически MITIGATOR подключается к двум сетям:
MITIGATOR может работать при симметричной и ассиметричной маршрутизации трафика.
При симметричной схеме внедрения трафик из внешней сети во внутреннюю и обратно проходит через MITIGATOR.
При асимметричной схеме внедрения через MITIGATOR проходит трафик из внешней сети, а трафик из внутренней сети проходит мимо. При использовании асимметричной схемы внедрения не расходуются ресурсы на обработку трафика внутренней сети.
Способы постановки на защиту можно разделить на:
Преимущества способа «Always-on»:
Недостатки «Always-on»:
В MITIGATOR для уменьшения влияния на легитимный трафик и фоновой нагрузки каждая контрмера по отдельности может включаться только в момент детектирования аномалии. Скорость активации контрмеры от 1 секунды.
Преимущества способа «On-demand»:
Недостатки способа «On-demand»:
Во избежание сброса ранее установленных сессий при способе «On-demand» в контрмеры MITIGATOR реализован режим мягкого старта.
На физическом уровне MITIGATOR может быть подключен в сеть тремя способами:
При подключении «Inline» сеть, из которой прибыл кадр, определяется физическим портом, с которого кадр принят: порты «ext» – внешняя сеть, порты «int» – внутренняя сеть. Внутри системы «ext» и «int» порты скоммутированы попарно – кадр отправляется с порта с таким же номером, какой был у порта получения. Обрабатывается как трафик с VLAN ID так и без него.
При выборе способа подключения «On-a-stick» задается таблица перетэгирования трафика, состоящая из пар внешнего и внутреннего VLAN ID. Принятый с любого физического порта кадр с внешним VLAN ID считается поступившим из внешней сети. Обработанный кадр отправляется во внутреннюю сеть через тот же порт, через который был получен, а его VLAN ID заменяется соответствующим внутренним. Если пришедший кадр содержит VLAN-тэг с внутренним VLAN ID, он заменяется соответствующим ему внешним VLAN ID, и кадр отправляется через тот же порт.
Способ подключения «Common LAN» применяется, когда внешний и внутренний роутеры и экземпляр MITIGATOR находятся в одной L2 и L3 сети. Если принятый с любого физического порта кадр имеет MAC-адрес внешнего роутера, он считается поступившим из внешней сети. MAC-адрес получателя заменяется на MAC-адрес внутреннего роутера, и кадр отправляется через тот же порт. Обратный трафик из внутренней сети может идти через экземпляр MITIGATOR, в этом случае выполняется обратная подстановка MAC-адресов, или следовать напрямую во внешнюю сеть. Поддерживается работа одновременно в нескольких сегментах сети, разделенных при помощи VLAN ID. В этом случае для каждого VLAN ID задаются собственные L3 настройки. Данный способ подключения может быть задан только если установлен режим «L3-роутер» на сетевом уровне.
На сетевом уровне MITIGATOR может быть L2-прозрачным или выступать как L3-устройство ограниченной функциональности.
В режиме «L2-прозрачность» MITIGATOR невидим для окружающих сетевых устройств и никак не влияет на взаимодействие на сетевом уровне. Кадр, проходящий через MITIGATOR, не изменяется.
В режиме «L3-роутер» система выполняет ряд базовых функций L3-устройства, что позволяет роутерам в присоединенных сетях использовать MITIGATOR как next-hop и выступать next-hop для MITIGATOR по протоколам IPv4 и IPv6.
Предполагается, что во внешней сети находится роутер, к которому подключен MITIGATOR. Со стороны внутренней сети находится внутренний роутер. Когда прибывает кадр из внешней сети, MAC-адрес отправителя кадра заменяется на MAC-адрес внутреннего интерфейса MITIGATOR, а MAC-адрес получателя — на MAC-адрес внутреннего роутера. Для кадров из внутренней сети производится обратная замена MAC-адресов.
Для каждой пары VLAN ID в режиме «L3-роутер» возможно указать собственные параметры маршрутизации.
Для определения MAC-адресов соседних роутеров в системе реализована поддержка
функций протоколов ARP и NDP. Задаются IP-адреса интерфейсов MITIGATOR и IP-адреса
внутреннего и внешнего роутеров. Запросы для разрешения MAC-адресов роутеров MITIGATOR
отправляет раз в 30 секунд. Параметры опроса задаются в конфигурационном файле
data-plane.conf
(описание). MAC-адреса внешнего
и внутреннего интерфейсов MITIGATOR могут быть заданы вручную. Также обработчик
пакетов MITIGATOR может отвечать на ICMP Echo Request.
Пока процесс разрешения MAC-адресов соседних роутеров не завершен, все кадры сбрасываются. Кадры, адресованные не внутреннему или внешнему MAC-адресам MITIGATOR, сбрасываются всегда.
MITIGATOR может быть подключен к сети пятью способами:
Inline L2-прозрачный:
On-a-stick L2-прозрачный:
Inline L3-роутер:
On-a-stick L3-роутер:
Common LAN L3-роутер:
Для способа внедрения Inline L2-прозрачный возможна балансировка трафика между экземплярами MITIGATOR за счет LACP между R1 и R2.
Для способа внедрения L3-роутер возможна балансировка трафика между экземплярами MITIGATOR с помощью ECMP.
Во всех случаях балансировка по экземплярам MITIGATOR должна быть настроена так,
чтобы пара src_ip + dst_ip всегда попадала на одно и то же устройство.
Централизованное управление множеством экземпляров MITIGATOR возможно в режиме
кластера. Принципиальные схемы кластера и настройки описаны в
отдельном разделе.
Для обеспечения сетевой связности при авариях и плановых работах можно использовать:
MITIGATOR поддерживает сетевые интерфейсы с аппаратным Bypass. Их применение позволяет сохранить сетевую связность в случае отключения питания или возникновения программной ошибки в обработчике пакетов. Для плановых работ можно управлять режимом работы Bypass через Web-интерфейс.
Если при отсутствии атаки трафик не проходит через MITIGATOR, то для детектирования требуется получение телеметрии по трафику от сетевого оборудования. Телеметрия с вышестоящего роутера передается на Collector по flow-протоколам. Collector передает статистику по трафику на MITIGATOR. Подсистема детектирования в MITIGATOR, зафиксировав аномалию, отправляет BGP-анонс для перенаправления трафика на очистку.
Подобное взаимодействие может быть настроено также и с flow-коллекторами сторонних производителей.
GRE-туннелирование может применяться в MITIGATOR в двух сценариях:
Для поставщика услуги защиты от DDoS-атак.
Поставщик оказывает услугу потребителю, который находится за пределами его сети,
либо доставка очищенного трафика до защищаемого ресурса осложнена особенностями
маршрутизации в сети поставщика. В этом случае трафик поступает на MITIGATOR из
внешней сети, подвергается очистке, после чего запаковывается в GRE-туннель и
отправляется на защищаемый ресурс во внешнюю сеть. Исходящий трафик защищаемого
сервера может упаковываться в GRE-туннель
или направляться напрямую пользователю через Internet.
Для потребителя услуги защиты от DDoS-атак.
Потребитель не имеет прямого подключения к сети поставщика услуги, либо у
поставщика услуги возникают сложности в доставке трафика. В этом случае трафик
поступает на MITIGATOR через GRE-туннель, распаковывается и подвергается очистке,
после чего отправляется на защищаемый ресурс во внутреннюю сеть. Исходящий трафик
защищаемого сервера может упаковываться в GRE-туннель
или направляться напрямую пользователю через Internet.
Рассмотрим асимметричную схему внедрения нескольких экземпляров MITIGATOR, при которой одновременно могут использоваться оба сценария нахождения под защитой.
На маршрутизаторе R1 задан маршрут, согласно которому префикс IPs/24 доступен через маршрутизатор R2, включена поддержка ECMP, балансировка настроена так, что пара src_ip + dst_ip попадает на один и тот же next-hop. MITIGATOR собран в кластер. С менеджмент-интерфейса каждого экземпляра MITIGATOR установлена BGP-сессия с R1. На R2 задан маршрут по умолчанию, ведущий на R1.
Таким образом, при отсутствии необходимости защиты трафик на защищаемый ресурс поступает напрямую от R1 к R2, минуя MITIGATOR. В момент, когда необходимо активировать защиту, экземпляры MITIGATOR отправляют на R1 BGP-анонс, сообщающий, что защищаемый префикс IPs1/32 доступен через IPm1 и IPm2. За счет балансировки по ECMP трафик будет распределяться между двумя устройствами.
Такой вариант внедрения позволяет:
В вышеописанной схеме в случае нештатного отключения сервера с MITIGATOR снятие BGP-анонсов займет некоторое время, в течение которого R1 продолжит отправлять трафик на MITIGATOR, что приведет к потере этого трафика. Для минимизации времени обновления маршрутов можно использовать протокол BFD.
Для этого требуется настроить взаимодействие по BFD между R1 и R2 и установить два BGP-соединения:
BGP-соединение между R1 и R2.
В рамках этого соединения R2 сообщает R1, что некий IPnh доступен
через MITIGATOR;
BGP-соединение между менеджмент-интерфейсом MITIGATOR и R1.
В рамках этого соединения MITIGATOR сообщает R1, что защищаемый префикс
доступен через IPnh.
Малое время опроса линков по протоколу BFD позволит в случае нештатного отключения сервера с MITIGATOR быстро удалить неработающие маршруты из таблицы маршрутизации R1, и трафик защищаемого префикса будет перенаправлен по прямому маршруту от R1 к R2 в случае с одним экземпляром MITIGATOR, или перестанет балансироваться на неработающий экземпляр при работе в кластере.