FlowSpec проти RTBH: як LiveShield мінімізує побічні ефекти під час мітигації

RTBH (Remotely Triggered Black Hole) блокує весь трафік, спрямований на певну IP-адресу, зокрема й легітимний. Це принципова відмінність від FlowSpec, який фільтрує лише пакети, що відповідають конкретній сигнатурі атаки. LiveShield мінімізує цей побічний ефект, надаючи пріоритет FlowSpec і запускаючи RTBH лише як аварійний механізм, коли точна фільтрація перестає бути достатньою, а не як першу й єдину реакцію на кожну атаку.

Це розрізнення безпосередньо впливає на якість сервісу під час атаки: неправильно налаштована мітигація може завдати клієнтові більше шкоди, ніж сама атака, відрізавши йому доступ до сервісу, який вона мала захищати.

FlowSpec дозволяє визначити правило фільтрації на основі конкретних характеристик трафіку, як-от адреса призначення, протокол, порт джерела чи призначення, прапорці TCP або розмір пакета, і встановити його безпосередньо в апаратному forwarding path крайового маршрутизатора. Маршрутизатор відкидає лише пакети, що відповідають цій сигнатурі, а весь решта трафіку до цієї адреси проходить без перешкод.

RTBH працює зовсім інакше: він анонсує весь маршрут до IP-адреси (найчастіше /32) як чорну діру, через що маршрутизатор відкидає все, що спрямоване на неї: трафік атаки, а також легітимний трафік, що йде на ту саму адресу. Тут немає селекції на рівні пакета, лише повне відсікання цілі.

Звідси випливає просте правило: там, де можна застосувати FlowSpec, решта трафіку клієнта не страждає. RTBH є остаточним рішенням, яке застосовують тоді, коли FlowSpec перестає бути достатнім, а не типовим першим кроком.

Правила фільтрації (FlowSpec) і правила блекхолінгу (RTBH) перевіряються незалежно одне від одного на основі окремо налаштованих порогів для того самого префікса. Якщо поріг правила фільтрації перевищується першим, система запускає FlowSpec. Одночасно, паралельно, перевіряється поріг блекхолінгу, і доки трафік його не перевищить, RTBH не спрацьовує.

На практиці це означає, що якщо пороги блекхолінгу встановлені вище за пороги фільтрації, що є рекомендованою конфігурацією, то FlowSpec перебирає мітигацію першим, а RTBH вмикається лише тоді, коли попри фільтрацію FlowSpec трафік і далі зростає та наближається до межі, за якої під загрозою насичення каналу. Типовий шаблон конфігурації виглядає так: локальна фільтрація FlowSpec аж до досягнення критичного обсягу трафіку, і лише понад цим рівнем RTBH як захист від насичення стику із зовнішнім світом.

Рекомендована практика при налаштуванні порогу блекхолінгу полягає в тому, щоб залишити в профілі лише контроль на рівні IP-адреси (без розбивки за протоколами) і встановити поріг близько до максимального обсягу трафіку, який цей стик здатен фактично прийняти, а не близько до нуля. Завдяки цьому RTBH справді захищає від насичення портів, а не спрацьовує за кожної невеликої атаки, яку FlowSpec і так би обробив.

Система оцінює правила фільтрації так само, як маршрутизатор оцінює маршрути в маршрутизації: конкретніший префікс має вищий пріоритет за загальний. Завдяки цьому для окремої критичної адреси (наприклад, сервера послуг) у межах ширшої підмережі можна налаштувати окреме правило /32 з іншими порогами, ніж правило, що охоплює всю підмережу, і саме конкретніше правило буде застосоване першим.

Це дає змогу, наприклад, встановити для звичайних клієнтів агресивні, низькі пороги на трафік TCP-SYN, спрямований до них (бо за замовчуванням вони не повинні отримувати багато таких пакетів), а для серверів, які за своєю природою приймають великий трафік SYN від багатьох клієнтів одночасно, залишити вищі пороги чи інший механізм фільтрації, щоб не відрізати їм трафік, який для них є нормальним.

Цей механізм має одне чітке обмеження: він добре працює, коли потрібно виокремити окрему адресу в межах атаки на всю підмережу. Натомість не можна просто виключити конкретну адресу з мітигації, якщо атака охоплює всю підмережу і на рівні всієї підмережі вже діє широке правило FlowSpec чи RTBH. Немає можливості анонсувати ще конкретніший маршрут, який вивів би одну адресу з-під цього правила.

Collateral damage не обмежується самим механізмом RTBH: неправильно підібраний, надто низький поріг фільтрації може відрізати легітимний трафік, хоча система технічно спрацювала відповідно до конфігурації. Типовий приклад із практики: агресивний поріг на фрагментацію IP (IPFRAG), встановлений для захисту від атак із фрагментованими пакетами, може почати відрізати легітимний трафік тунелів IPsec. Протокол ESP за більших пакетів природно фрагментується, тож за низького порогу та правила, що блокує всі фрагменти до певної адреси, увесь VPN-тунель клієнта перестає працювати.

Це показує, чому налаштування порогів є процесом, а не одноразовою дією: конфігурація, яка на папері виглядає безпечною, на практиці може блокувати конкретний легітимний шаблон трафіку, специфічний для певної мережі. Тому LiveShield записує дампи пакетів (packet dump) для спрацьованих правил, що дозволяє постфактум точно перевірити, який трафік було відрізано і чи правило спрацювало відповідно до задуму.

Мінімізація collateral damage у LiveShield ґрунтується на трьох механізмах, що діють разом: пріоритет FlowSpec над RTBH (RTBH як аварійне забезпечення, а не перша лінія оборони), пріоритет конкретніших префіксів над загальними (можливість виокремити інші пороги для критичних адрес у межах ширшої підмережі) та свідоме налаштування порогів фільтрації, щоб самі правила фільтрації не ставали джерелом шкоди. Жоден із цих механізмів не працює повністю автоматично з першого дня: потрібно налаштувати пороги відповідно до конкретної мережі та згодом спостерігати, але саме ця конфігурованість дозволяє звести побічні ефекти мітигації до мінімуму.

Чи працюють RTBH і FlowSpec у LiveShield одночасно, чи одне за одним? Правила фільтрації (FlowSpec) і правила блекхолінгу (RTBH) перевіряються незалежно й паралельно на основі окремих порогів. Якщо поріг блекхолінгу встановлено вище за поріг фільтрації, на практиці першим реагує FlowSpec, а RTBH вмикається лише тоді, коли трафік попри фільтрацію й далі зростає.

Чи можна виключити конкретну IP-адресу з мітигації під час атаки на всю підмережу? Не просто. За звичайних умов для окремої адреси можна налаштувати окреме, конкретніше правило з іншими порогами, але коли атака охоплює всю підмережу й на неї вже діє широке правило FlowSpec чи RTBH, неможливо анонсувати ще конкретніший маршрут, що виключав би з нього одну адресу.

Як встановити поріг блекхолінгу, щоб він не спрацьовував за кожної малої атаки? Рекомендована практика полягає в тому, щоб залишити в профілі блекхолінгу лише контроль на рівні IP-адреси та встановити поріг близько до максимального обсягу трафіку, який стик здатен фактично прийняти.