9.5

DDoS-Guard.net

Обычно, 1-й ступенью очистки является pre-firewall filter, задача которого - уменьшить полосу паразитного трафика до объема, который сможет легко принять операторская сеть и TMS. Эта ступень очистки особенно важна при сильных волюметрических атаках. Существует 2 способа реализации данного фильтра: 1) на пограничных маршрутизаторах собственной сети, 2) в сетях вышестоящих операторов.

Если рассматривать вариант с реализацией внутри собственной сети, то это, как правило, stateless firewall filters, работающие на input/output на интерфейсах, или интегрированный внутрь сети FlowSpec. В сетях аплинков, как правило, используется FlowSpec, работающий по внутренней сигнализации, либо по сигнализации, принимаемой с сетей клиента. При использовании stateless firewall filters есть возможность настройки более точной фильтрации: можно полисером ограничить тот или иной destination IP, порт, протокол, флаг, размер пакета. При использовании FlowSpec предусмотрен только жесткий discard, который мало чем отличается от блэкхолла, если атака имеет параметры работающего сервиса.

Согласно руководству от Juniper, SCU и DCU предназначены для accounting-трафика по сопоставлению с определенным policy с match по определенным параметрам. Это означает, что можно считать трафик по описанным в специфичный класс конкретным префиксам, BGP-community, target-community, etc. Firewall filter позволяет делать match по source-class и destination-class. Данные опции позволяют создать firewall filter с возможностью тонкой фильтрации по source AS, или, если выражаться простым языком, осуществлять геофильтрацию трафика с помощью Pre-firewall filter.

Представим такую фильтрацию на примере TCP Syn-flood схематично:\

Данные о flow "чистого" и "грязного" трафика с помощью протокола IPFIX (в данной статье его работа рассматриваться не будет) снимаются с line cards маршрутизатора с определенной дискретностью (sampling) и передаются на Flow Collector, где обрабатываются и отображаются в системе мониторинга Flow Monitor. Это один из способов реализации мониторинга входящего flow, в разных операторских сетях он реализован по разному. Одним из важных параметров, отображаемый в IPFIX является SrcAS. Кто сталкивался с огромными по объему атаками в сотни Gbps и наблюдал за автономными системами происхождения "грязного" трафика, обратил внимание, что при определенных видах атак распределение источников того же флуда далеко неоднородно. Т.е. существует какое-то число топовых ASN с превалирующим значением. Подобная картина отчетливо прослеживалась во время прошлогодних DDoS-атак с применением знаменитого ботнета Mirai.

Предлагаемый способ позволяет существенно ограничить уровень "грязного" трафика именно с ASNs, входящих в ТОР.

Давайте поэтапно рассмотрим функцинал на примере конфигурационного файла.

1. Создаем policy scu_ddos в котором делаем матч по протоколу bgp и по as-path source-as. Перечисленным атрибутам присваиваем source-class ddos.

set policy-options policy-statement scu_ddos term 1 from protocol bgp
set policy-options policy-statement scu_ddos term 1 from as-path source-as
set policy-options policy-statement scu_ddos term 1 then source-class ddos

2. В as-path source-as в виде регулярного выражения добавляем origin-as для топовых ASNs.

set policy-options as-path source-as ".* 65000|65002"

В нашем примере на рисунке они обозначены красным цветом, и с них, в приведенном примере, поступает 80Gbps TCP syn-flood.

3. Применяем созданный policy на экспорт к forwarding-table. Если на экспорт уже есть примененные policy, то scu_ddos желательно поставить первым, используя команду insert в соответствующем конфигурационном блоке.

set routing-options forwarding-table export scu_ddos

4. Создаем policer lim100m.

set firewall policer lim100m filter-specific
set firewall policer lim100m shared-bandwidth-policer
set firewall policer lim100m if-exceeding bandwidth-limit 100m
set firewall policer lim100m if-exceeding burst-size-limit 1m
set firewall policer lim100m then discard

5. Создаем firewall filter scu_ddos_limit, в котором осуществляем match по source-class ddos, ограничиваемому протоколу и флагу, считаем и ограничиваем полисером в 100 Mbps весь трафик соответствующий данным критериям.

set firewall filter scu_ddos_limit term1 from source-class ddos
set firewall filter scu_ddos_limit term1 from protocol tcp
set firewall filter scu_ddos_limit term1 from tcp-flags syn
set firewall filter scu_ddos_limit term1 then policer lim100m
set firewall filter scu_ddos_limit term1 then count scu_ddos_count
set firewall filter scu_ddos_limit term2 then accept
 

6. На интерфейсах включения аплинков включаем accounting и применяем на input созданный фильтр scu_ddos_limit.

set interfaces ae1 unit 0 family inet accounting source-class-usage input
set interfaces ae1 unit 0 family inet filter input scu_ddos_limit

7. Проверяем срабатывание счетчиков и полисера на интерфейсе.

run show firewall filter scu_ddos_limit-ae1.0-i | match "lim100m-ae1.0-i|scu_ddos_count-ae1.0-i"
scu_ddos_count-ae1.0-i 90763066484 1745338287
lim100m-ae1.0-i 343023655 9801281

Таким образом, мы можем нивелировать значительную часть syn-флуда (в примере на рисунке из суммарной полосы в 100 Gbps до 20 Gbps), тем самым предотвратить перегрузку собственных сетевых ресурсов и устройств очистки трафика.

При правильно подобранном значении полисера дропы пакетов проявляются только во время атаки. Необходимо понимать, что в момент атак полисером также будет дропаться и часть легитимного TCP syn-трафика с ограничиваемых автономных систем, что существенно не повлияет на уже установившиеся соединения.