Взаимодействие по 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-правил могут быть заданы вручную или формироваться системой автоматически. В системе всегда присутствуют системные списки, имеющие в названии system, они наполняются автоматически при работе механизма отправки BGP-анонсов. Названия автоматически формируемых списков также отражают, какие данные применяются для их формирования:

  • .rules — значения из правил маршрутизации;
  • .prefixes — dst_prefixes из правил маршрутизации;
  • .ips — dst_IP, для которых замечено превышение установленных порогов;

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

  • .blackhole. — применяются для анонсирования соседям префиксов, трафик на которые должен быть полностью сброшен;
  • .signaling. — применяются для анонсирования соседям префиксов, трафик на которые должен быть очищен вышестоящим оператором связи или поставщиком услуги защиты по данным MITIGATOR;
  • .protected. — применяются для анонсирования соседям префиксов, трафик на которые должен быть направлен на очистку через MITIGATOR оператора связи или поставщика услуги защиты.

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

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

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

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

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

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

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

  • system.policy.blackhole.prefixes формируется из префиксов получателя в правилах маршрутизации, ведущих на политику защиты. Наполнение списка управляется механизмом автодетектирования по срабатыванию порогов Policy.BGP.Blackhole.Input{Bps, Pps}.{On, Off}.

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

  • system.policy.blackhole.ips формируется из IP-адресов, полученных от коллектора, скорость поступления трафика на которые превышает установленный порог для направления в blackhole. Наполнение списка управляется механизмом автодетектирования по срабатыванию порогов Policy.BGP.Flow.Blackhole.Input{Bps, Pps}.{On, Off}. На вкладке «Настройка политики» страницы «Политика защиты» должны быть заданы пороги скорости в пакетах и битах.

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

  • system.policy.blackhole.hpd.ips Формируется из IP-адресов политики защиты, скорость поступления трафика на которые превышает установленный порог для направления в blackhole, по данным HPD. Наполнение списка управляется механизмом автодетектирования по срабатыванию порогов Policy.BGP.HPD.Blackhole.Input{Bps, Pps}.{On, Off}.

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

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

  • system.policy.signaling.prefixes формируется из префиксов получателя в правилах маршрутизации, ведущих на политику защиты. Наполнение списка управляется механизмом автодетектирования по срабатыванию порогов Policy.BGP.Signaling.Input{Bps, Pps}.{On, Off}.

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

  • system.policy.signaling.ips формируется из IP-адресов, полученных от коллектора, скорость поступления трафика на которые превышает установленный порог для направления в blackhole. Наполнение списка управляется механизмом автодетектирования по срабатыванию порогов Policy.BGP.Flow.Signaling.Input{Bps, Pps}.{On, Off}. На вкладке «Настройка политики» страницы «Политика защиты» должны быть заданы пороги скорости в пакетах и битах.

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

  • system.policy.signaling.hpd.ips формируется из IP-адресов политики защиты, скорость поступления трафика на которые превышает установленный порог для сигнализации, по данным HPD. Наполнение списка управляется механизмом автодетектирования по срабатыванию порогов Policy.BGP.HPD.Signaling.Input{Bps, Pps}.{On, Off}.

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

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

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

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

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

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

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

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

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

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

  • system.policy.flowspec.blackhole.prefixes формируется из префиксов получателя в правилах маршрутизации, ведущих на политику защиты. Наполнение списка управляется механизмом автодетектирования по срабатыванию порогов Policy.BGP.Blackhole.Input{Bps, Pps}.{On, Off}.

  • system.policy.flowspec.blackhole.rules формируется из полного набора параметров в правилах маршрутизации, ведущих на политику защиты. Наполнение списка управляется механизмом автодетектирования по срабатыванию порогов Policy.BGP.Blackhole.Input{Bps, Pps}.{On, Off}.

  • system.policy.flowspec.blackhole.ips формируется из IP-адресов, полученных от коллектора, скорость поступления трафика на которые превышает установленный порог для направления в blackhole. Наполнение списка управляется механизмом автодетектирования по срабатыванию порогов Policy.BGP.Flow.Blackhole.Input{Bps, Pps}.{On, Off}. На вкладке «Настройка политики» страницы «Политика защиты» должны быть заданы пороги скорости в пакетах и битах.

  • system.policy.flowspec.blackhole.rules.ips формируется из значений четырех параметров в правилах маршрутизации, ведущих на политику защиты: протокол, префикс отправителя, порт отправителя и порт получателя. В качестве префикса получателя используются IP-адреса, полученные от коллектора, скорость поступления трафика на которые превышает установленный порог. Наполнение списка управляется механизмом автодетектирования по срабатыванию порогов Policy.BGP.Flow.Blackhole.Input{Bps, Pps}.{On, Off}. На вкладке «Настройка политики» страницы «Политика защиты» должны быть заданы пороги скорости в пакетах и битах.

  • system.policy.flowspec.blackhole.hpd.ips формируется из IP-адресов политики защиты, скорость поступления трафика на которые превышает установленный порог для направления в blackhole, по данным HPD. Наполнение списка управляется механизмом автодетектирования по срабатыванию порогов Policy.BGP.HPD.Blackhole.Input{Bps, Pps}.{On, Off}.

  • system.policy.flowspec.blackhole.rules.hpd.ips формируется из значений четырех параметров из правил маршрутизации, ведущих на эту политику: протокол, префикс отправителя, порт отправителя и порт получателя. В префикс получателя подставляются IP-адреса, полученные от HPD, скорости поступления трафика на которые превышают установленные пороги для направления в blackhole. Наполнение списка управляется механизмом автодетектирования по срабатыванию порогов Policy.BGP.HPD.Blackhole.Input{Bps, Pps}.{On, Off}.

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

  • system.policy.flowspec.signaling.prefixes формируется из префиксов получателя в правилах маршрутизации, ведущих на политику защиты. Наполнение списка управляется механизмом автодетектирования по срабатыванию порогов Policy.BGP.Signaling.Input{Bps, Pps}.{On, Off}.

  • system.policy.flowspec.signaling.rules формируется из полного набора параметров в правилах маршрутизации, ведущих на политику защиты. Наполнение списка управляется механизмом автодетектирования по срабатыванию порогов Policy.BGP.Signaling.Input{Bps, Pps}.{On, Off}.

  • system.policy.flowspec.signaling.ips формируется из IP-адресов, полученных от коллектора, скорость поступления трафика на которые превышает установленный порог для сигнализации. Наполнение списка управляется механизмом автодетектирования по срабатыванию порогов Policy.BGP.Flow.Signaling.Input{Bps, Pps}.{On, Off}. На вкладке «Настройка политики» страницы «Политика защиты» должны быть заданы пороги скорости в пакетах и битах.

  • system.policy.flowspec.signaling.rules.ips формируется из IP-адресов, полученных от коллектора, скорость поступления трафика на которые превышает установленный порог для сигнализации. Наполнение списка управляется механизмом автодетектирования по срабатыванию порогов Policy.BGP.Flow.Signaling.Input{Bps, Pps}.{On, Off}. На вкладке «Настройка политики» страницы «Политика защиты» должны быть заданы пороги скорости в пакетах и битах.

  • system.policy.flowspec.signaling.hpd.ips формируется из IP-адресов политики защиты, скорость поступления трафика на которые превышает установленный порог для сигнализации, по данным HPD. Наполнение списка управляется механизмом автодетектирования по срабатыванию порогов Policy.BGP.HPD.Signaling.Input{Bps, Pps}.{On, Off}.

  • system.policy.flowspec.signaling.rules.hpd.ips формируется из значений четырех параметров из правил маршрутизации, ведущих на эту политику: протокол, префикс отправителя, порт отправителя и порт получателя. В префикс получателя подставляются IP-адреса, полученные от HPD, скорости поступления трафика на которые превышают установленные пороги для сигнализации. Наполнение списка управляется механизмом автодетектирования по срабатыванию порогов Policy.BGP.HPD.Signaling.Input{Bps, Pps}.{On, Off}.

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

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

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

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

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

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

Активация механизмом автодетектирования по данным коллектора

В параметрах автодетектирования политики защиты можно задать пороги автоматического включения и выключения BGP-анонсирования в политике защиты с помощью предикатов Policy.BGP.Flow.Input{Bps, Pps}.{On, Off}.

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

Для наполнения списков .blackhole. по данным коллектора применяются предикаты Policy.BGP.Flow.Blackhole.Input{Bps, Pps}.{On, Off}.

Активация механизмом автодетектирования по данным политики защиты

BGP-анонсирование также может управляться предикатами Policy.BGP.Input{Bps, Pps}.{On, Off}, связанными со счетчиками трафика на входе в политику защиты.

Например, перенаправление на MITIGATOR для очистки по данным от коллектора, может привести к падению уровня flow и, как результат, автоматическому снятию анонса. Для того чтобы этого избежать можно использовать предикаты Policy.BGP.Input{Bps, Pps}.{On, Off}, для удержания анонса.

Для наполнения списков .blackhole. по данным счетчиков политики применяются предикаты Policy.BGP.Blackhole.Input{Bps, Pps}.{On, Off}.

Автоматическое снятие 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-анонсу

При превышении порогов трафика в политике защиты или по данным коллектора наполняются соответствующие системные списки .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 по данным из коллектора, можно анонсировать не префиксы, а конкретные IP-адреса. При этом, если на коллекторе замечено превышение установленного порога трафика, адресованного IP-адресу, только этот адрес будет добавлен в список и передан BGP-соседям. Таким образом можно направлять на очистку только трафик IP-адресов под атакой, в то время как весь остальной трафик защищаемого префикса будет направляться по прямому маршруту от R1 к R2.

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

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