Автоматизація реакції на DDoS-атаку: що відбувається після виявлення атаки
DDoS-атаку виявлено. Що робить ваша система в наступні секунди?
Розмови про захист від DDoS зазвичай крутяться навколо одного питання: як швидко система виявить атаку й створить правило фільтрації. Це питання має сенс, але для команди NOC оператора воно рідко вичерпує справу. Згенероване правило FlowSpec чи blackholing зазвичай є початком процедури, а не її кінцем. Хтось має отримати сповіщення, інцидент потрібно залогувати, іноді треба перемкнути клієнта на іншу IP-адресу, іноді запустити скрипт на крайовому пристрої.
У багатьох мережах ці кроки все одно виконує людина. Вона отримує алерт, заходить у панель, перевіряє, що сталося, і лише потім запускає процедуру. За атаки, що триває кільканадцять секунд, ця затримка буває довшою за сумарний час виявлення та фільтрації.
Система вже знає, що відбувається, проблема в тому, що ще ніхто інший не знає
У момент виявлення атаки система захисту від DDoS має повний набір інформації, потрібної для подальших дій: знає IP-адресу жертви, протоколи, масштаб трафіку, точний момент перевищення порогу. Питання в тому, чи ці знання закінчуються на генерації правила фільтрації, чи ними можна одразу запустити щось більше.
У LiveShield для цього слугує event pipeline: набір дій, прив'язаних до конкретних подій у життєвому циклі атаки, наприклад «Blackholing started» чи «Blackholing stopped». До кожної з таких подій можна прив'язати виклик власного скрипта, з атакованою IP-адресою, переданою як параметр, або вебхук на вказану URL-адресу.
Приклад із життя: два пороги, одна автоматична реакція
Типова конфігурація виглядає так:
На префіксі встановлено пороги pps/bps. Після їх перевищення система виявляє атаку з конкретними протоколами й генерує правила FlowSpec. Паралельно перевіряються вищі пороги з профілю blackholing, їх можна встановити сумарно для IP або окремо для окремих протоколів. Якщо ці вищі пороги також перевищено, запускається blackholing.
І тут вступає pipeline. У момент виклику blackholing запускається скрипт, прив'язаний до події «Blackholing started», це може бути, наприклад, зміна IP-адреси клієнта на резервну. Коли атака вщухає і blackholing знімається, подія «Blackholing stopped» викликає зворотну дію, тобто відновлює первинну адресу.
Та сама схема працює за інтеграції зі scrubbing center. Замість фільтрувати трафік локально, pipeline може перенаправити його на зовнішній пункт очищення в момент ескалації атаки, а після її завершення повернутися до стандартної маршрутизації.
Спершу FlowSpec, RTBH лише коли справді потрібно
Розділення порогів виявлення та порогів blackholing має практичний сенс. Нижчий поріг запускає точне правило FlowSpec, що фільтрує трафік за конкретними параметрами: протоколом, портом, прапорцями. Лише після перевищення другого, вищого порогу відбувається blackholing усього префікса. Більшість атак, менших і передбачуваніших, обробляється без втрати легітимного трафіку. RTBH залишається засобом для ситуацій, у яких подальше утримання трафіку до певної адреси починає загрожувати стабільності всієї мережі.
Для адрес з іншим профілем ризику, як-от сервісні сервери, що мають мати вищу доступність, ті самі механізми можна налаштувати окремо. Достатньо додати їх як конкретнішу підмережу з власним набором порогів.
Запустіть систему захисту від DDoS-атак у своїй інфраструктурі. Зв'яжіться з нами: office@liveshield.net
