При написанні першої статті мною не мав на меті зробити якесь відкриття, а просто хотілося поділитися практичним досвідом впровадження. На мій погляд, описана конфігурація є більш простий, в порівнянні з відбитої в презентації від вендора із застосуванням Destination Class Usage (DCU). Але саме ця наштовхнуло на думку оцінити можливість застосування DCU і SCU в системах фільтрації трафіку, т. К. Маю гарне уявлення і практичний досвід роботи з DCU, де він застосовувався для зонової тарифікації трафіку VPN-сервісів.
Останнім часом багато пишуть і обговорюють способи захисту від DDoS-атак, намагаються створити і впровадити нові стандарти, томно чекаючи їх перетворення з Draft в повноцінний Internet Standart, а потім ще більше чекаючи вендорськіх імплентацій. Мені здається, що в оперативному плані більш виправданим є застосування існуючих рішень виробників, хоча і розвиток робочих пропозицій теж необхідно.
У будь-операторської мережі з реалізованими сервісами захисту від DDoS, як правило, існує кілька ступенів очищення трафіку, що цілком логічно. Прийняти кілька сотень Gbps або Mpps "брудного" трафіку і очистити його виключно тільки за допомогою TMS (Threat Management System) - невиправдано дорого. Зазвичай, першою ступенів очищення, особливо важливою при атаках з великою volumetric, є Pre-firewall filter, завдання якого зменшити смугу "сміттєвого" трафіку до значення, яке може легко "переварити" операторська мережу і TMS. Існує два основні варіанти реалізації даного фільтру - на прикордонних маршрутизаторах власної мережі і в мережах АПЛІНК. Якщо розглядати варіант з реалізацією всередині власної мережі, то це, звичайно, stateful firewall filters, що працюють на input / output на інтерфейсах, або впроваджений всередині мережі FlowSpec. У мережах АПЛІНК, як правило - FlowSpec, що працює по внутрішньої сигналізації, і по сигналізації, прийнятої з клієнтських мереж. Якщо в першому варіанті існує можливість більш тонкої фільтрації, обмеживши певний destination IP, протокол, порт, прапор, розмір пакета полісером, то в другому варіанті передбачений тільки жорсткий discard, мало чим відрізняється від blackhole, якщо атака має характеристики працюючого сервісу.
SCU і DCU, по мануали Juniper, призначені для 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 представлений на схемі. Конфігурація і її опис дано нижче.
Пропонований спосіб дозволяє істотно обмежити рівень "брудного" трафіку саме з 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-трафіку з обмежуються автономних систем, що істотно не вплине на вже усталені сполуки.