Система анти-DDoS у мережі оператора - це не один інструмент, а послідовність рівнів захисту: від видимості трафіку у власній мережі, через фільтрацію на крайовому маршрутизаторі, до співпраці з upstream-провайдерами. Ми описуємо ці рівні в тому порядку, в якому їх варто будувати, на прикладі системи LiveShield. Кожен рівень вирішує окрему проблему і вимагає від оператора окремого рішення.
Що таке драбина ескалації в захисті від DDoS?
Драбина ескалації - це порядок реагування на атаку: починаємо з того, що оператор контролює локально, а зовнішні ресурси підключаємо лише на вищих рівнях. Вищі рівні спираються на нижчі, тому будувати їх зверху немає сенсу.
Оператор має локально знати, що б'є по його мережі. Upstream бачить не все, особливо коли мережа має кілька стиків. Зовнішньому scrubbing center також потрібні локальне виявлення, звітність і перенаправлення, щоб він взагалі працював.
Крок 1: Чому система анти-DDoS починається з видимості трафіку?
Без швидкого виявлення атаку не можна ні відфільтрувати, ні задокументувати, тому видимість трафіку - перший і найважливіший рівень. Оператор має бачити, що б'є по його мережі, протягом секунд. Оператори, на яких поширюється польський закон про KSC (Національну систему кібербезпеки), крім того, мусять обробляти інциденти й повідомляти про них. Для цього їх спершу потрібно виявити та задокументувати.
Тому LiveShield не будує виявлення на NetFlow. NetFlow занадто повільний, і не весь трафік потрапляє до аналізу. Система аналізує копію трафіку із дзеркала: з порту SPAN на маршрутизаторі чи комутаторі або з оптичного TAP на лінії. У тесті час реакції системи на атаку становив менше секунди.
Чи потребує аналіз трафіку дорогого обладнання?
Ні. Обробка пакетів на основі DPDK оминає ядро операційної системи, тому один сервер класу Dell R430 з процесором Xeon E5 v4 обробляє 40G трафіку, за ціною близько 2000 PLN. Ще недавно така продуктивність вимагала в рази дорожчого обладнання.
Крок 2: Чи обмежує крайовий маршрутизатор захист від DDoS?
Так. Слабкий крайовий маршрутизатор створює проблеми під час атак, адже саме на нього потрапляють правила фільтрації. Підтримка BGP FlowSpec тут є базовою вимогою, оскільки FlowSpec - основний механізм, яким система передає правила на маршрутизатор.
Апаратний маршрутизатор з ASIC швидко обробляє трафік, має TCAM і великий запас продуктивності. Маршрутизатор на Linux - крайній варіант, і має сенс лише з VPP або DPDK, бо ядро системи занадто повільне для такого трафіку. Такий маршрутизатор здається дешевим, але потребує тривалого налаштування і не дає гарантій продуктивності.
Mikrotik приймає правила FlowSpec, але не застосовує їх, тому з таким пристроєм залишається лише blackholing.
Крок 3: Як фільтрувати атаку, не відрізаючи легітимний трафік?
Ефективна фільтрація поєднує два механізми: prefiltering і advanced filtering. Результатом обох є правила BGP FlowSpec, що надсилаються на маршрутизатор, тому легітимний трафік до атакованої адреси продовжує надходити.
Prefiltering - це наперед визначені правила для найпоширеніших векторів атак, наприклад NTP, DNS чи ICMP. Вони спрацьовують одразу, без очікування навчання трафіку.
Advanced filtering - це динамічне навчання трафіку на основі вмісту пакетів. Він необхідний при атаках із ботнетів і для трафіку на кшталт TCP чи UDP, який не можна просто відрізати.
Селективний blackholing - це останній рівень, а не перший. Він має сенс переважно для окремих адрес. Він не працює проти тривалих атак типу carpet bombing, а не кожен upstream приймає префікси коротші за /32. Ми не відрізаємо трафік локально: трафік з IXP і прямих пірингів залишається.
При атаці, розподіленій по всій підмережі (carpet bombing), важать пороги на підмережу, а не лише на окрему IP-адресу. Без порогів на підмережу таку атаку не буде виявлено.
Крок 4: Що перевірити в upstream-провайдерів до атаки?
Локальної фільтрації недостатньо, якщо атака насичує канал ще до того, як трафік досягне крайового маршрутизатора. Тому вибір upstream-провайдерів - це закупівельне рішення, яке варто закрити до першої великої атаки.
На що звернути увагу:
Пропускна здатність портів. Порти 10G сьогодні часто замалі. Де це можливо, варто перейти на порти з більшою пропускною здатністю та нижчим commitment.
Керування трафіком. З'єднання типу mix ускладнюють керування трафіком, бо незрозуміло, звідки і скільки трафіку приходить.
FlowSpec в upstream. Upstream без FlowSpec - проблема при кожній більшій атаці, особливо типу carpet bombing. Якщо upstream надає FlowSpec або RTBH, правила й префікси можна надсилати безпосередньо на його маршрутизатори. Це потрібно узгоджувати з кожним провайдером окремо.
Необов'язковим доповненням є зовнішній scrubbing center. LiveShield не має власного scrubbing center, але може перенаправити трафік до нього, а поріг перенаправлення можна пов'язати з насиченням каналу. Тоді scrubbing center доповнює локальний захист, а не замінює його.
Крок 5: Що робити з атаками, які виглядають як легітимний трафік?
Такі атаки вимагають аналізу трафіку зі станом, бо окремий пакет не видає, що він є частиною атаки. Типовий приклад - SYN-ACK reflection, а також суміш різних векторів одночасно. Самими порогами на протокол їх неможливо ефективно зупинити без ризику відрізати легітимні з'єднання.
Для таких випадків призначений LiveShield AIF. Він працює inline, між крайовим маршрутизатором і BRAS або концентратором, та двосторонньо відстежує стан TCP-з'єднань. Він ґрунтується на DPDK, тому працює з високою швидкістю.
AIF не замінює пропускну здатність каналів. Атаку, що насичує канал upstream, і надалі потрібно обробляти на вищих рівнях: через FlowSpec або RTBH в upstream-провайдерів.
Крок 6: Як документувати атаки й автоматизувати реагування?
Оператор має в кожну мить бачити, що робить система, і мати змогу використовувати це у власних процесах. LiveShield показує всі правила, активні під час атаки, графіки з розподілом по upstream та генерує звіти, зокрема звіт для KSC. Звіт слугує для підготовки повідомлення, але система не надсилає його автоматично.
Власні event pipeline дозволяють запускати сповіщення електронною поштою, вебхуки та скрипти. Скрипт може також змінювати конфігурацію мережевих пристроїв, наприклад припинити анонсувати префікси вибраним upstream-провайдерам, перемкнути трафік на scrubbing center або залишити лише upstream, який підтримує FlowSpec.
Правила можна також створювати вручну, незалежно від автоматичного виявлення, а конфігурацію змінювати через публічне API.
Крок 7: Як діяти при атаках через IXP?
Атаку через IXP можна стримати, визначивши її джерело, замість того щоб відрізати весь пункт обміну трафіком. Для цього потрібні добрі графіки по upstream і зразки трафіку.
Процедура:
На графіках по upstream видно, що трафік входить через IXP.
Зі зразків трафіку зчитуємо MAC-адресу джерела.
За MAC визначаємо IP-адресу піра та його ASN.
Анонсуємо вибраному ASN community do-not-announce, залежно від правил конкретного IXP.
Трафік цього піра тоді вже не входить у мережу через IXP, а надходить транзитними шляхами.
Що перевірити у власній мережі, поки атаки немає?
Найшвидше почати з питань, які не потребують жодних закупівель:
Чи можна дзеркалити трафік на межі мережі (SPAN або TAP)?
Чи підтримує крайовий маршрутизатор BGP FlowSpec і які моделі маємо в мережі?
Чи кожен upstream надає FlowSpec або RTBH і на яких умовах?
Чи знаємо ми пороги, за яких наші канали стають насиченими?
Хто і як реагує, коли атака б'є по мережі поза робочими годинами?
Відповіді показують, який рівень драбини сьогодні найслабший. Лише тоді варто планувати впровадження системи.
