bgp collector collector flow signaling

Взаимодействие по BGP

Информация

Статья устарела и требует актуализации.

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

Памятка

Более подробно о всех аспектах настройки взаимодействия ниже.

Локальные параметры BGP

Выполняется определение локальных параметров экземпляров кластера и для каждого экземпляра персонально разрешается установка BGP-соединения с BGP-соседями.

BGP-соседи

Экземпляры MITIGATOR могут устанавливать BGP-соединение с другими устройствами сети, каждое из которых задается в системе как BGP-сосед. Любой из экземпляров может соединяться с одним или несколькими соседями.

При создании в системе BGP-соседа указывается, какой экземпляр взаимодействует с соседом, сетевые параметры соседа, nexthop, сообщаемый при отправке BGP-анонса, и другие параметры. Поддерживается атрибут MED, определяющий приоритет маршрута следования трафика от BGP-соседа на экземпляр MITIGATOR. При наличии нескольких равноправных маршрутов будет выбран маршрут с наименьшим значением MED.

Каждому BGP-соседу может быть присвоено свойство «Источник проверочного списка префиксов». Все префиксы, поступающие от такого BGP-соседа, будут считаться проверочными, что помогает избежать blackhole.

Также экземпляр MITIGATOR может получать от BGP-соседа префиксы, трафик которых должен быть направлен на очистку, если для BGP-соседа активирована функция «Принимать префиксы под защиту». Подробнее о настройке связки по передаче и приему префиксов, трафик на которые должен очищаться, в статье.

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

Также для каждого BGP-соседа предусмотрена персональная политика анонса.

Политика анонса

Политика анонса это параметры рассылки, адресованной конкретному BGP-соседу. Значения в политику анонса добавляются из списков, которые пользователь заранее задает в карточках «Списки префиксов», «Списки FlowSpec» и «Списки Community».

Также в политике анонса может быть задан персональный nexthop для конкретного списка префиксов.

Если экземпляр MITIGATOR, с которого устанавливается BGP-соединение с соседом, работает в режиме интеграции в сеть «L3-роутер», то для работы анонсирования требуется каждому списку указать обслуживаемую зону – пару VLAN ID. MITIGATOR будет анонсировать списки BGP-соседу только если внешний и внутренний роутеры данной зоны отвечают на ARP-запросы.

Списки префиксов

Если список префиксов занесен в политику анонса BGP-соседа, этот сосед будет получать актуальные значения префиксов, принадлежащих списку. Список префиксов может быть помечен как сверяемый, в этом случае BGP-соседу будут передаваться не все префиксы списка, а только те из них, что остались после сравнения с проверочным списком.

Списки префиксов могут формироваться вручную или автоматически.

Списки FlowSpec

Если список FlowSpec-правил занесен в политику анонса BGP-соседа, то сосед будет получать актуальные правила для осуществления фильтрации трафика или его перенаправления. Поддерживаются действия над трафиком:

  • redirect – перенаправление;
  • drop – сброс;
  • pass – пропускание;
  • rate-limit – ограничение.

Списки FlowSpec-правил могут формироваться вручную или автоматически.

Списки Community

Списки Community существуют для управления распространением BGP-анонсов. Значения из списка Community могут быть добавлены в политику анонса BGP-соседа для списков префиксов и FlowSpec-правил как дополнительное свойство. Механизм поддерживает Well-known Community: internet, planned-shut, accept-own, route-filter-translated-v4, route-filter-v4, route-filter-translated-v6, route-filter-v6, llgr-stale, no-llgr, blackhole, no-export, no-advertise, no-export-subconfed и no-peer.

Значения Community могут записываться в виде:

  • ключевого слова – названия Well-known Community;
  • 32-битного числа;
  • пары 16 битных чисел в формате ASN:VALUE, где ASN – номер автономной системы, а VALUE – номер Community в данной системе;
  • трех 32 битных чисел в формате ASN:LOCAL_DATA_PART1:LOCAL_DATA_PART2, где ASN – номер автономной системы, а LOCAL_DATA_PART1 и LOCAL_DATA_PART2 – значения, определяемые пользователем.

Формирование списков

Списки префиксов и списки FlowSpec-правил могут быть заданы вручную или формироваться системой автоматически.

В MITIGATOR всегда присутствуют системные списки, имеющие в названии system, они наполняются при определенных условиях, зависящих от типа списка.

Типы списков

Системные списки бывают стандартные и специальные. К специальным относятся .blackhole., .signaling. и .amplification.. Все остальные списки — стандартные.

Наполнение стандартных списков

Для того, чтобы активировать наполнение стандартных списков требуется либо вручную включить переключатель BGP-анонсирования в политике защиты, либо должен сработать любой из порогов автодетектирования, имеющий .Announce. в названии.

Наполнение специальных списков

Для каждого вида специальных списков есть собственные пороги активации наполнения:

  • .blackhole. — наполнение активируется только порогами автодетектирования с .Blackhole. в названии. Списки применяются для анонсирования соседям префиксов, трафик на которые должен быть полностью сброшен.
  • .signaling. — наполнение активируется только порогами автодетектирования с .Signaling. в названии. Списки применяются для анонсирования соседям префиксов, трафик на которые должен быть очищен вышестоящим оператором связи или поставщиком услуги защиты по данным MITIGATOR.
  • .amplification. — наполнение активируется только порогами автодетектирования с .Amplification. в названии. Списки применяются для анонсирования соседям flowspec-правил фильтрации трафика определенного типа, связанного с конкретным видом UDP-амплификации.

Наполнение никаких специальных списков нельзя активировать вручную.

Важно: не следует путать .Announce. и .Amplification. пороги, даже если они ведут подсчет по одной и той же метрике.

Например:

Порог Policy.BGP.Announce.Flow.Arms.InputPps.On = 1 наполнит стандартные списки значениями IP-адресов, на которые по данным Collector поступает трафик, соответствующий типу амплификации, выше порога. Применение стандартного списка, наполненного таким образом, повлияет на весь трафик префиксов, попавших в список.

Порог Policy.BGP.Amplification.Flow.Arms.InputPps.On = 1 наполнит только один из списков flowspec-правил system.policy.flowspec.amplification.arms.prefixes или system.policy.flowspec.amplification.arms.ips, в зависимости от настроек в политике защиты. Применение этих списков означает использование с шаблоном правила drop udp sport 3283 $prefixes, поэтому они повлияют только на трафик с порта 3283.

Источники метрик, которые могут являться триггером для наполнения списков

Списки могут наполняться по метрикам MITIGATOR, или по метрикам Collector. Все пороги автодетектирования, которые содержат в названии .Flow. активируют наполнение списков по метрикам с Collector. Все остальные — по метрикам MITIGATOR.

Отслеживаемые метрики

В MITIGATOR предусмотрено множество разнообразных метрик, по которым могут срабатывать пороги автодетектирования. Среди них:

  • по уровню входящего трафика в политику защиты по метрикам обработчика пакетов или по метрикам с Collector, общему или определенного протокола;
  • по уровню сброса конкретными контрмерами на основе счетчиков обработчика пакетов;
  • по уровню сброса конкретными контрмерами на основе метрик Collector, в случае когда с MITIGATOR на Collector отправляется sFlow по сбросам;
  • по количеству уникальных IP-адресов отправителей по метрикам обработчика пакетов или по метрикам с Collector:
  • по уровню тестового сброса в политике защиты и другие.

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

Данные для наполнения списков

В названии списка также указано, чем конкретно он будет наполнен:

  • .rules — значениями 5-tuple из правил маршрутизации на политику защиты;
  • .prefixes — префиксами получателя из правил маршрутизации на политику защиты;
  • .ips. — IP-адресами получателя, для которых замечено превышение установленных порогов на Collector или в HPD.

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

Списки c .checked в названии сравниваются с проверочным списком.

Списки c .protected в названии применяются для того, чтобы переанонсировать от себя префиксы, полученные от BGP-соседа. Подробнее.

Подробно о каждом списке

Ниже перечислены все системные списки и их описания.

Системные списки префиксов для направления трафика на очистку

  • system.policy.prefixes формируется из префиксов получателя в правилах маршрутизации, ведущих на политику защиты. Список не наполняется, если включено наполнение списка system.policy.ips.

  • system.policy.prefixes.checked равен по содержанию списку system.policy.prefixes, но сравнивается с проверочным списком.

  • system.policy.ips формируется из IP-адресов, полученных от Collector, скорость поступления трафика на которые превышает установленный порог. Должен быть задан флаг «Наполнять листы IP-адресами на основе данных коллектора» на вкладке «Настройка политики» страницы «Политика защиты» и пороги скорости в пакетах и битах.

  • system.policy.ips.checked равен по содержанию списку system.policy.ips, но сравнивается с проверочным списком.

Системные списки префиксов для анонсирования соседям префиксов, трафик на которые должен сбрасываться

  • system.policy.blackhole.prefixes формируется из префиксов получателя в правилах маршрутизации, ведущих на политику защиты.

  • system.policy.blackhole.prefixes.checked равен по содержанию списку system.policy.blackhole.prefixes, но сравнивается с проверочным списком.

  • system.policy.blackhole.ips формируется из IP-адресов, полученных от Collector, скорость поступления трафика на которые превышает установленный порог для направления в blackhole. На вкладке «Настройка политики» страницы «Политика защиты» должны быть заданы пороги скорости в пакетах и битах.

  • system.policy.blackhole.ips.checked равен по содержанию списку system.policy.blackhole.ips, но сравнивается с проверочным списком.

  • system.policy.blackhole.hpd.ips формируется из IP-адресов, скорость поступления трафика на которые превышает порог, заданный в HPD.

  • system.policy.blackhole.hpd.ips.checked равен по содержанию списку system.policy.blackhole.hpd.ips, но сравнивается с проверочным списком.

Системные списки префиксов для сигнализации вышестоящим операторам связи или поставщикам услуг защиты

  • system.policy.signaling.prefixes формируется из префиксов получателя в правилах маршрутизации, ведущих на политику защиты.

  • system.policy.signaling.prefixes.checked равен по содержанию списку system.policy.signaling.prefixes, но сравнивается с проверочным списком.

  • system.policy.signaling.ips формируется из IP-адресов, полученных от Collector, скорость поступления трафика на которые превышает установленный порог для сигнализации. На вкладке «Настройка политики» страницы «Политика защиты» должны быть заданы пороги скорости в пакетах и битах.

  • system.policy.signaling.ips.checked равен по содержанию списку system.policy.signaling.ips, но сравнивается с проверочным списком.

  • system.policy.signaling.hpd.ips формируется из IP-адресов политики защиты, скорость поступления трафика на которые превышает установленный порог для сигнализации, по данным HPD.

  • system.policy.signaling.hpd.ips.checked равен по содержанию списку system.policy.signaling.hpd.ips, но сравнивается с проверочным списком.

Системные списки префиксов для приема префиксов под защиту

  • system.protected.prefixes формируется из префиксов, полученных от BGP-соседа, в настройках которого задан флаг «Принимать префиксы под защиту». Если BGP-сосед ассоциирован с группой, то сообщенные им префиксы будут включены в список только если принадлежат группе.

  • system.protected.prefixes.checked равен по содержанию списку system.protected.prefixes, но сравнивается с проверочным списком.

Системные списки FlowSpec-правил для направления трафика на очистку

Для работы системных списков FlowSpec-правил требуется задать шаблоны правил, в которые будут подставляться префиксы или адреса. Если шаблоны не заданы, правила не формируются. При внесении изменений в шаблоны или в правила маршрутизации FlowSpec-правила обновляются.

  • system.policy.flowspec.prefixes формируется из префиксов получателя в правилах маршрутизации, ведущих на политику защиты. Список не наполняется, если включено наполнение списка system.policy.flowspec.ips на основе данных Collector.

  • system.policy.flowspec.rules формируется из полного набора параметров в правилах маршрутизации, ведущих на политику защиты. Список не наполняется, если включено наполнение списка system.policy.ips.rules на основе данных Collector.

  • system.policy.flowspec.ips формируется из IP-адресов, полученных от Collector, скорость поступления трафика на которые превышает установленный порог. Должен быть задан флаг «Наполнять листы IP-адресами на основе данных коллектора» на вкладке «Настройка политики» страницы «Политика защиты» и пороги скорости в пакетах и битах.

  • system.policy.flowspec.ips.rules формируется из значений четырех параметров в правилах маршрутизации, ведущих на политику защиты: протокол, префикс отправителя, порт отправителя и порт получателя. В качестве префикса получателя используются IP-адреса, полученные от Collector, скорость поступления трафика на которые превышает установленный порог. Должен быть задан флаг «Наполнять листы IP-адресами на основе данных коллектора» на вкладке «Настройка политики» страницы «Политика защиты» и пороги скорости в пакетах и битах.

Системные списки FlowSpec-правил для анонсирования соседям префиксов, трафик которых должен быть полностью сброшен

  • system.policy.flowspec.blackhole.prefixes формируется из префиксов получателя в правилах маршрутизации, ведущих на политику защиты.

  • system.policy.flowspec.blackhole.rules формируется из полного набора параметров в правилах маршрутизации, ведущих на политику защиты.

  • system.policy.flowspec.blackhole.ips формируется из IP-адресов, полученных от Collector, скорость поступления трафика на которые превышает установленный порог для направления в blackhole. На вкладке «Настройка политики» страницы «Политика защиты» должны быть заданы пороги скорости в пакетах и битах.

  • system.policy.flowspec.blackhole.rules.ips формируется из значений четырех параметров в правилах маршрутизации, ведущих на политику защиты: протокол, префикс отправителя, порт отправителя и порт получателя. В качестве префикса получателя используются IP-адреса, полученные от Collector, скорость поступления трафика на которые превышает установленный порог. На вкладке «Настройка политики» страницы «Политика защиты» должны быть заданы пороги скорости в пакетах и битах.

  • system.policy.flowspec.blackhole.hpd.ips формируется из IP-адресов политики защиты, скорость поступления трафика на которые превышает установленный порог для направления в blackhole, по данным HPD.

  • system.policy.flowspec.blackhole.rules.hpd.ips формируется из значений четырех параметров из правил маршрутизации, ведущих на эту политику: протокол, префикс отправителя, порт отправителя и порт получателя. В префикс получателя подставляются IP-адреса, полученные от HPD, скорости поступления трафика на которые превышают установленные пороги для направления в blackhole.

Системные списки FlowSpec-правил для сигнализации вышестоящим операторам связи или поставщикам услуг защиты

  • system.policy.flowspec.signaling.prefixes формируется из префиксов получателя в правилах маршрутизации, ведущих на политику защиты.

  • system.policy.flowspec.signaling.rules формируется из полного набора параметров в правилах маршрутизации, ведущих на политику защиты.

  • system.policy.flowspec.signaling.ips формируется из IP-адресов, полученных от Collector, скорость поступления трафика на которые превышает установленный порог для сигнализации. На вкладке «Настройка политики» страницы «Политика защиты» должны быть заданы пороги скорости в пакетах и битах.

  • system.policy.flowspec.signaling.rules.ips формируется из IP-адресов, полученных от Collector, скорость поступления трафика на которые превышает установленный порог для сигнализации. На вкладке «Настройка политики» страницы «Политика защиты» должны быть заданы пороги скорости в пакетах и битах.

  • system.policy.flowspec.signaling.hpd.ips формируется из IP-адресов политики защиты, скорость поступления трафика на которые превышает установленный порог для сигнализации, по данным HPD.

  • system.policy.flowspec.signaling.rules.hpd.ips формируется из значений четырех параметров из правил маршрутизации, ведущих на эту политику: протокол, префикс отправителя, порт отправителя и порт получателя. В префикс получателя подставляются IP-адреса, полученные от HPD, скорости поступления трафика на которые превышают установленные пороги для сигнализации.

Системные списки FlowSpec-правил для защиты от UDP-амплификаций

Все списки для борьбы с амплификациями работают одинаково, но каждый предназначен для отдельного вида амплификации. * в названии списка и порога автодетектирования, отвечающего за его наполнение указывает на тип амплификации. Они бывают: Udp, Dns, IpFragment, Chargen, Cldap, Spss, Arms, Coap, WS, L2tp, mDns, Memcached, MsSqlRs, NetBios, Ntp, RipV1, RpcBind, Snmp, Ssdp.

  • system.policy.flowspec.amplification.*.prefixes формируется из IP-адресов получателя в правилах маршрутизации на политику защиты, если на Collector зафиксировано превышение порога по трафику, соответствующему типу амплификации.

  • system.policy.flowspec.amplification.*.ips формируется из IP-адресов получателя, для которых на Collector зафиксировано превышение порога по трафику, соответствующему типу амплификации.

Активация BGP-анонсирования

BGP-анонсирование для заворота трафика на фильтрацию может быть активировано вручную или автоматически.

Ручная активация из политики защиты

BGP-анонсирование может быть активировано вручную с помощью переключателя «Отправлять BGP-анонсы» на странице «Политика защиты». Если анонсирование включено, то рядом с переключателем появляется иконка , нажатие на которую покажет список префиксов политики, выбранных для анонса.

Автоматическая активация

Автоматическая активация BGP-анонсирования выполняется по превышению порогов автодетектирования.

  • по данным MITIGATOR;
  • по данным Collector.

Вариативность списков и порогов для активации их наполнения подробно описана выше.

Автоматическое снятие BGP-анонсов

BGP-анонсы могут автоматически сниматься по следующим причинам:

  • по срабатыванию предикатов механизма автодетектирования;
  • из-за остановки обработчика пакетов;
  • из-за остановки gobgp;
  • если анонсируемый префикс исключен из проверочного списка;
  • если IP-адреса внешнего или внутреннего роутеров не отвечают на ARP-запросы.

Отключение механизмом автодетектирования

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

Остановка обработчика пакетов

В случае остановки обработчика пакетов на конкретном экземпляре MITIGATOR, все анонсы BGP-соседям с этого экземпляра автоматически снимаются. BGP-сессия прерывается.

Остановка gobgp

В случае остановки gobgp на конкретном экземпляре MITIGATOR, все анонсы BGP-соседям с этого экземпляра автоматически снимаются. BGP-сессия прерывается.

Анонсируемый префикс исключен из проверочного списка

Если BGP-соседу анонсируется префикс лист с установленным свойством «Сверять», то в случае если источник проверочного списка перестал сообщать префикс, этот префикс автоматически исключается из анонса BGP-соседу. BGP-сессия продолжает работать.

IP-адреса внешнего или внутреннего роутеров не отвечают на ARP-запросы

Если в политике анонса BGP-соседа анонсируемому списку указана зона, и эта зона не разрешается на экземпляре MITIGATOR, то такой список перестает анонсироваться. BGP-сессия продолжает работать. При необходимости данная проверка может быть отключена.

Способы применения

Перенаправление трафика на очистку по BGP-анонсу

Рассмотрим схему сети, в которой несколько экземпляров MITIGATOR работают в режиме «On-demand».

При отсутствии необходимости защиты трафик на защищаемый ресурс может поступать напрямую от R1 к R2, минуя MITIGATOR. В настройках BGP-соседа R1 указан список префиксов system.policy.prefixes. При активации BGP-анонсирования он наполняется значениями dst_prefix из правил маршрутизации, ведущих на данную политику. Этим экземпляры MITIGATOR сообщают, что защищаемый префикс 192.0.2.1/32 доступен через IPm1 и IPm2. Трафик начинает поступать на очистку. После окончания атаки BGP-анонс снимается и трафик идет прежним маршрутом.

Таким образом, применение схемы с перенаправлением трафика на очистку по BGP-анонсу позволяет:

  • повысить отказоустойчивость;
  • горизонтально масштабировать кластер для повышения производительности;
  • защищать ресурсы адресно;
  • по необходимости пускать трафик на MITIGATOR в режиме «On-demand», либо снимать трафик с защиты в режиме «Always-on»;
  • упростить процедуру обслуживания и поиска неисправностей.

Для минимизации времени обновления маршрутов в случае нештатного отключения сервера с MITIGATOR можно использовать протокол BFD.

Проверочные списки

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

Содержимое списков префиксов, для которых задано свойство «Сверять», сверяются с проверочным списком, полученным от BGP-соседа. У системных списков сверяемыми являются те, в названии которых указано .checked, свойство «Сверять» с них не снимается.

Рассмотрим на примере, как изменяется состав анонсируемых префиксов в зависимости от того, что сообщает BGP-сосед R2:

У экземпляров MITIGATOR1 и MITIGATOR2 по два BGP-соседа: Сосед 1 и Сосед 2.
Сосед 1 – BGP-сосед, которому экземпляр MITIGATOR анонсирует сверяемый системный список префиксов system.policy.prefixes.checked. В списке system.policy.prefixes.checked присутствует префикс 192.0.2.0/24, добавленный из правила маршрутизации на политику защиты.
Сосед 2 – BGP-сосед, помеченный как источник проверочного списка.

Пример 1:
Сосед 2 сообщает экземплярам MITIGATOR, что через него доступен префикс 192.0.0.0/16.
В этом случае экземпляры MITIGATOR анонсирует Соседу 1 префикс 192.0.2.0/24, так как проверочный список это разрешает.

Пример 2:
Сосед 2 сообщает экземплярам MITIGATOR, что через него доступен префикс 192.0.2.1/32.
В этом случае экземпляры MITIGATOR не анонсируют Соседу 1 никакие префиксы, так как маска анонсируемого префикса меньше чем у префикса в проверочном списке.

Более специфичные префиксы

В локальных параметрах экземпляра MITIGATOR можно разрешить анонсировать более специфичные префиксы, чем указано в анонсируемом списке.

Пример 3:
В локальных параметрах BGP-соединения экземпляров MITIGATOR1 и MITIGATOR2 установлен флаг «Более специфичные».
Сосед 2 сообщает экземплярам MITIGATOR, что через него доступен префикс 192.0.2.1/32.
В этом случае экземпляры MITIGATOR анонсируют Соседу 1 префикс 192.0.2.1/32, так как разрешено анонсирование более специфичных префиксов, чем указано в списке system.policy.prefixes.checked.

Перенаправление трафика на очистку по FlowSpec

Похожим образом происходит перенаправление трафика анонсированием FlowSpec-правил. Во время работы механизма BGP-анонсирования наполняются системные списки FlowSpec-правил system.policy.flowspec.prefixes и system.policy.flowspec.rules. Эти списки содержат в себе шаблон с действием, RD и переменной. В список system.policy.flowspec.prefixes подставляются значения из dst_prefix, а в список system.policy.flowspec.rules полный набор параметров из правил маршрутизации.

Например, в MITIGATOR задано правило маршрутизации, ведущее на политику Policy1:

Занесем в политику анонса для BGP-соседа R1 системный список system.policy.flowspec.prefixes и зададим для него шаблон:

redirect 123:321 $prefixes

В этом случае BGP-соседу R1 будет отправлен список FlowSpec-правил со значением # Policy1 (ID 4) redirect 123:321 dst 192.0.2.1/32. Здесь Policy1 (ID 4) – название и ID политики защиты.

Аналогичный шаблон для списка system.policy.flowspec.rules

redirect 123:321 $rules

сформирует правило # Policy1 (ID 4) redirect 123:321 protocol 6 dst 192.0.2.1/32 sport 8080 dport 8080 с полным набором параметров из правила маршрутизации.

Получив правила вышестоящий роутер R1 перенаправит трафик, соответствующий данным правилам на очистку.

Blackhole трафика по BGP-анонсу

При превышении порогов трафика в политике защиты или по данным Collector наполняются соответствующие системные списки .blackhole.. Community при анонсировании этих списков указывается в политике анонса BGP-соседу.

Таким образом весь трафик, адресованный IP-адресу 192.0.2.1/32 будет полностью сброшен еще до MITIGATOR. При данном способе будет сбрасываться также и легитимный трафик, что приведет к недоступности защищаемого ресурса, однако, исключит повреждение защищаемой сетевой инфраструктуры на время атаки. После окончания атаки анонс будет снят и трафик снова будет поступать на защищаемый сервер.

О наполнении blackhole-списков префиксами политики сигнализирует индикатор, появляющийся рядом с переключателем «Отправлять BGP-анонсы» на странице «Политика защиты».

Прием префиксов под защиту

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

Например, у оператора связи настроен MITIGATOR. Клиентский MITIGATOR добавлен как BGP-сосед, для которого активирована функция «Принимать префиксы под защиту». MITIGATOR клиента детектирует атаку и передает signaling списки атакуемых префиксов. Подробнее.

На MITIGATOR оператора связи получаемые от BGP-соседа префиксы заносятся в системный список префиксов system.protected.prefixes, после чего этот список анонсируется всем BGP-соседям, для которых список указан в политике анонса. Таким образом происходит направление трафика данных префиксов на очистку на более высоком эшелоне защиты.

Рассылка FlowSpec-правил для фильтрации

Сформировав список FlowSpec-правил с действием DROP и передав его BGP-соседу R1, можно дополнительно осуществлять фильтрацию трафика на вышестоящем маршрутизаторе. Также можно ограничивать поступление трафика, соответствующего правилу, на MITIGATOR действием rate-limit.

Blackhole трафика по FlowSpec

По FlowSpec возможна автоматическая отправка правил для сброса трафика.

При срабатывании условий автодетектирования для blackhole наполняются списки FlowSpec-правил system.policy.flowspec.blackhole.rules, system.policy.flowspec.blackhole.rules.ips и system.policy.flowspec.blackhole.rules.hpd.ips. Эти списки содержат в себе шаблон с действием drop dst $PREFIX или drop $RULES.

Например, в MITIGATOR задано правило маршрутизации, ведущее на политику Policy1:

Занесем в политику анонса для BGP-соседа R1 системный список system.policy.flowspec.blackhole.rules и зададим для него шаблон:

drop $RULES

В этом случае BGP-соседу R1 будет отправлен список FlowSpec-правил со значением # Policy1 (ID 4) drop protocol 6 dst 192.0.2.1/32 sport 8080 dport 8080. Здесь Policy1 (ID 4) – название и ID политики защиты.

Получив правила вышестоящий роутер R1 сбросит трафик, соответствующий данным правилам.

Прием правил фильтрации

MITIGATOR также может принимать FlowSpec-правила от других устройств. Для этого в настройках BGP-соседа нужно разрешить получение FlowSpec.

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

Collector

Активировав наполнение системных списков ips по данным из Collector, можно анонсировать не префиксы, а конкретные IP-адреса. При этом, если на Collector замечено превышение установленного порога трафика, адресованного IP-адресу, только этот адрес будет добавлен в список и передан BGP-соседям. Таким образом можно направлять на очистку только трафик IP-адресов под атакой, в то время как весь остальной трафик защищаемого префикса будет направляться по прямому маршруту от R1 к R2.

Сигнализация

MITIGATOR может использовать взаимодействие по BGP в сценарии сигнализации вышестоящим операторам связи или поставщикам услуг защиты.

Подробнее про сигнализацию на оборудование провайдера.

Подробнее про сигнализацию на MITIGATOR провайдера.

Похожие статьи