Есть ли альтернатива BGP Flowspec?


15.01.2018 12:03    Время на чтение: ~6 мин. | слов: ~547

Одним из самых распространенных видов prefirewall фильтров является BGP Flowspec, широко применяемый как в рамках одного домена, так и на междоменном уровне и позволяющий с помощью сигнализации протокола BGP (AFI flow) передавать описанные правила на удаленные узлы в сети, где они выполняются Firewall.

Более подробно это описано в RFC5575, с дополнениями в RFC7674, и сопутствующим количеством документов со статусом Internet-Draft. Невзирая на заголовок статьи, изложенный в ней материал — не попытка преподнести полноценную замену многолетнему стандарту, давно нашедшему реализацию во многих вендорских и операторских решениях. У каждой технологии есть свои особенности, преимущества и недостатки. Речь пойдет о совместном применении всем хорошо известного транзитивного атрибута community протокола BGP, вендорских решениях от Juniper Destination Class Usage и Prefix-Specific Action (у Cisco — microflow policing).Рассмотрим более подробно совместную реализацию данных решений на приведенных схеме, примерах конфигурации, скриншотах тестирования.

Тестовая схема состоит из AS65001, представляющую автономную систему клиента, и анонсирующую защищаемый префикс 192.168.200/24 с community 65000:1111; из AS65000, представляющей IP/MPLS домен ISP; из сегмента Internet с хостом генерирующим тестовый трафик.

Основная конфигурация выполняется на пограничных маршрутизаторах ISP, в который включены аплинки (в нашем примере это PE-маршрутизатор vMX-VCP). Рассмотрим подробнее на примере конфигурации.

1) Опишем community по которому policy будет осуществлять match определенных префиксов:

set policy-options community dst-prefixes members 65000:1111

2) Опишем саму policy, в котором в котором в качестве match указан протокол bgp и ранее описанное community, а в качестве action назначаться destination-class:

set policy-options policy-statement dcu-psa term 1 from protocol bgp
set policy-options policy-statement dcu-psa term 1 from community dst-prefixes
set policy-options policy-statement dcu-psa term 1 then destination-class psa

3) Применим policy к routing-options forwarding-table:

set routing-options forwarding-table export dcu-psa

4) Создадим policer, который будет применяться в prefix-action для ограничения определенного трафика (ограничение в 2 Mbps указано в качестве примера):

set firewall policer lim2m-PSA if-exceeding bandwidth-limit 2m
set firewall policer lim2m-PSA if-exceeding burst-size-limit 15k
set firewall policer lim2m-PSA then discard

5) Создаем firewall prefix-action в котором указываем длину префикса (в нашем случае это /24), его градацию по destination (в примере указано /32), а также policer, ограничивающий определенный трафик на каждый destination (т. е. на каждый IP-адрес):

set firewall family inet prefix-action psa-2m-dest-24-32 policer lim2m-PSA
set firewall family inet prefix-action psa-2m-dest-24-32 count
set firewall family inet prefix-action psa-2m-dest-24-32 filter-specific
set firewall family inet prefix-action psa-2m-dest-24-32 subnet-prefix-length 24
set firewall family inet prefix-action psa-2m-dest-24-32 destination-prefix-length 32

6) В firewall filter PSA ссылаемся на ранее описанный destination-class, описываем критерии по которым необходимо матчить трафик (в примере TCP-пакеты с флагами syn, ack, syn+ack, rst, но в реальности может быть все что угодно, например, тот же UDP) и в качестве action указываем ранее созданный prefix-action:

set firewall filter PSA term psa from destination-class psa
set firewall filter PSA term psa from source-address 0.0.0.0/0
set firewall filter PSA term psa from protocol tcp
set firewall filter PSA term psa from tcp-flags "(((syn & ack) | rst) | syn) | ack"
set firewall filter PSA term psa then next term
set firewall filter PSA term psa then prefix-action psa-2m-dest-24-32
set firewall filter PSA term accept then accept

7) Применяем созданный фильтр к forwarding-options:

set forwarding-options family inet filter output PSA

Полную версию материала читайте здесь. Материал подготовлен сотрудниками DDoS-GUARD.