BGP FlowSpec і RTBH у практиці оператора
BGP FlowSpec і RTBH у практиці оператора
Що має підтримувати ваш маршрутизатор і що зовсім не мусить підтримувати аплінк
У розмовах з операторами ISP про захист від DDoS одне запитання повертається частіше за будь-яке інше: «чи мій аплінк мусить підтримувати FlowSpec, щоб це запрацювало?» Відповідь: ні. І це непорозуміння варто прояснити раз і назавжди, бо через нього частина операторів відмовляється навіть розглядати автоматичну мітигацію DDoS, ще до того, як перевірить, що їхньої наявної інфраструктури цілком достатньо.
Два механізми, два різні місця в мережі
BGP FlowSpec і RTBH (Remotely Triggered Blackholing) це два базові механізми мітигації DDoS-атак в операторських мережах. Їх часто кидають в один кошик «BGP для захисту від DDoS», але вони працюють у різних місцях і розв'язують різні проблеми.
FlowSpec це точна фільтрація. Правило FlowSpec описує конкретний трафік (протокол, порт, довжину пакета, фрагментацію) і наказує маршрутизатору, що з ним робити: відкинути, обмежити смугу, перенаправити. Атакована адреса лишається досяжною, вирізається лише трафік, що відповідає шаблону атаки.
RTBH це відсікання. Для атакованої адреси анонсується маршрут зі спеціальною community, а маршрутизатори (власні або аплінка) спрямовують увесь трафік до цієї адреси в null. Ефективно, але грубо: атакована адреса взагалі перестає бути досяжною. RTBH має сенс тоді, коли обсяг атаки загрожує насиченням транзитних каналів і треба рятувати решту мережі.
Ключове: FlowSpec працює локально, на вашому краї
Правила FlowSpec така система, як LiveShield, анонсує сесією BGP на ваші власні крайові маршрутизатори. Саме вони програмують фільтрацію в data plane й вирізають трафік атаки на вході в мережу. Аплінк у цьому не бере участі й не мусить нічого підтримувати чи на щось погоджуватися.
З боку аплінка потрібна лише одна, широко доступна річ: підтримка blackholing через community (RTBH). Це стандарт практично в кожного постачальника транзиту та на точках обміну трафіком. Маршрути blackhole анонсуються звичайною сесією BGP unicast і редистрибутуються вгору з відповідною community, без додаткових технічних домовленостей.
Якщо аплінк додатково приймає правила FlowSpec від клієнтів, чудово: тоді фільтрацію можна перенести ще вище, і атака вирізається, перш ніж торкнеться ваших каналів. На практиці в операторів, чиї аплінки мають FlowSpec, від RTBH можна відмовитися зовсім. Але це опція, а не умова.
Як це виглядає під час реальної атаки: гібридний сценарій
На практиці найефективнішим є поєднання обох механізмів, що діє автоматично залежно від масштабу інциденту:
- Атаку виявлено, і перші правила FlowSpec потрапляють на крайові маршрутизатори впродовж одиниць секунд. Трафік атаки вирізається локально, решта трафіку до атакованої адреси проходить нормально, клієнт не відчуває інциденту.
- Система уточнює фільтрацію на основі аналізу семпльованих пакетів, генеруючи якомога вужчі правила замість блокування всього трафіку певного протоколу.
- Якщо обсяг атаки зростає до рівня, що загрожує насиченням транзитних каналів, запускається RTBH для атакованої адреси: локальної фільтрації вже недостатньо, тож маршрут blackhole редистрибутується до аплінків, і трафік гине поза вашою мережею.
Цей сценарій LiveShield виконує автоматично. Пороги та послідовність реакцій можна налаштовувати для кожного префікса чи групи клієнтів: інші дії для малої атаки, інші для великої, зі сповіщеннями та запуском власних скриптів по дорозі.
BGP FlowSpec у LiveShield
«Чи мій маршрутизатор це потягне?» Практичні апаратні реалії
Це друге за частотою запитання, і тут варто бути чесним: не кожне обладнання, що заявляє підтримку FlowSpec, справді вміє програмувати правила в data plane. Деякі платформи приймають маршрути FlowSpec і вміють їх редистрибутувати, але фільтрації не застосовують.
Кілька практичних порад із впроваджень:
- Перевірені платформи, зокрема, Juniper MX/PTX, Cisco ASR 9000/9900, ASR 1000 та Cisco 8000.
- У серії Cisco NCS 5500 FlowSpec вимагає моделей із зовнішнім eTCAM (позначення -SE), причому не всіх. Правила FlowSpec займають багато місця в TCAM, тож конкретну модель варто перевірити перед купівлею.
- Програмні маршрутизатори (BIRD, CHR і подібні) це окрема історія: BIRD прийме правила FlowSpec, але сам нічого з ними не зробить, окрім передачі далі. Для таких середовищ реальною опцією лишається RTBH або редистрибуція правил до аплінка з підтримкою FlowSpec.
Якщо ви не впевнені щодо своєї моделі, запитайте виробника або напишіть нам. За кількості впроваджень, які ми здійснили, є чималий шанс, що ваше обладнання ми вже знаємо.
Добра практика конфігурації: правила FlowSpec варто застосовувати лише на інтерфейсах аплінка, вимкнувши їх на клієнтських і внутрішніх інтерфейсах. Готові приклади конфігурації для окремих платформ ви знайдете в нашій документації: docs.liveshield.net/bgpconfiguration.html.
Що з цього випливає для оператора
Автоматична мітигація DDoS на основі BGP FlowSpec і RTBH не вимагає ні заміни інфраструктури, ні переговорів із постачальником транзиту. Вона вимагає крайового маршрутизатора з реальною підтримкою FlowSpec, який значна частина операторів уже має, та стандартної підтримки blackholing в аплінка, що сьогодні є нормою.
LiveShield поєднує це в один автоматичний механізм: виявлення для кожної IP і кожної підмережі, правила FlowSpec на вашому краї впродовж секунд від виявлення атаки, RTBH як захист від насичення каналів. Усе on-premise, без перенаправлення трафіку поза вашу мережу й в межах однієї ліцензії.
Сумніваєтеся, чи ваші маршрутизатори впораються з FlowSpec? Напишіть нам: office@liveshield.net. Підкажемо на основі досвіду з конкретними платформами. Роботу системи можна побачити на demo.liveshield.net.
