1. Статьи
Заметки пользователей
08.01.2018 08:50
PDF
11054
2

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

В отличие от предыдущих публикаций статья написана в соавторстве с коллегой. Выражаем искренние признания компании Ростелеком, в который мы получили бесценные знания и опыт, позволившие нам стать настоящими сетевыми инженерами компании, в которой мы работаем в настоящее время, и получили реальную возможность реализовать свой потенциал в одном из самых интересных направлений информационной безопасности - защите от DDoS. Отдельные слова благодарности адресуем порталу NAG.RU, ее главному редактору, любезно предоставившим возможность делиться полученным опытом с коллегами по отрасли.

В одной из предыдущих публикаций описывалась реализация геофильтрации трафика на оборудовании Juniper с использованием технологии Source Class Usage (SCU), как одном из методов применения prefirewall фильтров в сетевых решениях защиты от DDoS. Необходимость применения подобных фильтров, в независимости от схемного решения (централизованная или распределенные схемы фильтрации), обусловлена, прежде всего, большими волюметриками современных атак, отсутствием возможности (целесообразности) транзита всего этого "грязного" трафика в сетях Операторов, дороговизной решений по его очистке в огромных объемах.

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

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

Рассмотрим более подробно совместную реализацию данных решений на приведенных схеме, примерах конфигурации, скриншотах тестирования.

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

Тестовая схема состоит из 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. Создадим 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

4. Создаем 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

4. В 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

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

set forwarding-options family inet filter output PSA

Ниже приведены данные тестирования.

1. Пример ТСР-пакетами с флагом syn. С тестового сервера отправляется syn-flood на адрес 192.168.200.1:

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

Смотрим срабатывание счетчиков и полисера:

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

2. Пример ТСР-пакетами с флагом syn-ack. Флуд на IP 192.168.200.100:

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

Ниже данные счетчиков и полисера:

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

3. Пример ТСР-пакетами с флагом ack. Тестовый трафик отправляется на IP 192.168.200.10:

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

Данные счетчиков и полисера:

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

В заключение, несколько комментариев.

Применение firewall-фильтров на основе классов дает дополнительные возможности реализации механизмов защиты от DDoS-атак (некоторые ISPs предоставляют в виде дополнительного сервиса, такого как bgp extended blackhole community, например). Но все они имеют один существенный недостаток: при таргетированных на сервис атаках, последний однозначно пострадает, т. к., например, при syn-flood фильтром будет дропаться, в том числе, и какая-то доля легитимных пакетов, что приведет к затруднениям в установке новых соединений. Этот недостаток характерен для всех prefirewall-фильтров, умеющих, в лучшем случае, полисить трафик. Идеальным является решение, когда есть возможность не использовать prefirewall, а "прогонять" все объемы трафика через Threat Management System, где его фильтрация осуществляется более интеллектуально. К сожалению, подобные решения не под силу многим ISPs, порой даже крупным.

Также при схемных реализациях (особенно с предоставленной клиентам возможностью управлять специфичными анонсами) с применением prefirewall, необходим постоянный контроль утилизации ресурсов сетевого оборудования, отсутствие которого может привести к плачевным последствиям.

Ниже приведены примеры контроля памяти (Lookup Block ASIC) линейной карты тестового маршрутизатора:

lab@vMX-VCP# run request pfe execute target fpc0 command "show jnh 0 pool usage"
SENT: Ukern command: show jnh 0 pool usage
EDMEM overall usage:
[NH////////|FW////////|CNTR///////////|HASH////|ENCAPS////|--------------------------]
0 4.0 8.0 14.0 17.2 21.3 32.0M
Next Hop
[***************|-----------------|RRRRRRRRRRRRRRRRRRRR] 4.0M (28% | 72%)
Firewall
[|--------------------------------|RRRRRRRRRRRRRRRRRRRR] 4.0M (<1% | >99%)
Counters
[****************************|---------------------------|RRRRRRRRRRRRRRRRRRRRRRRR] 6.0M (35% | 65%)
HASH
[******************************************] 3.2M (100% | 0%)
ENCAPS
[******************************************************] 4.1M (100% | 0%)
Shared Memory - NH/FW/CNTR/HASH/ENCAPS
[--------------------------------------------------------------------------------] 10.7M (0% | 100%)
Free Shared Memory - NH/FW/CNTR/HASH/ENCAPS
[--------------------------------------------------------------------------------] 10.7M (0% | 100%)

Здесь все замечательно, FW использует менее 1% (плюс зарезервированный пул динамически распределяемой памяти, RLDRAM), в реальности же все немного иначе.

Использованные материалы:

 


Надеемся на продолжение публикаций, описывающих методы и способы обеспечения безопасности в Операторских сетях.

 

2 комментариев
Оставлять комментарии могут только авторизованные пользователи
Robot_NagNews
Robot_NagNews
Материал: Данная статья является продолжением серии подборок о способах и методах защиты от DDoS-атак в Операторских сетях. Невзирая на заголовок статьи, изложенный в ней материал - не попытка преподнести полноценную замену многолетнему стандарту, давно нашедшему реализацию во многих решениях. Речь пойдет о совместном применении всем хорошо известного транзитивного атрибута community протокола BGP, вендорских решениях от Juniper Destination Class Usage и Prefix-Specific Action. Полный текст
tec1
tec1
В примере конфигурации упущен один момент. Созданная policy должна быть применена на export к routing-options forwarding-table, например: set routing-options forwarding-table export dcu-psa