Чи відреагує LiveShield на DDoS-атаку за 1 секунду?

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

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

21 листопада було проведено тест на живій атаці з параметрами 700 kpps / 6,5 Гб/с, що складалася з трьох одночасних векторів: фрагментації IP (IP Fragments), ампліфікації DNS та UDP Flood. Трафік аналізували паралельно LiveShield та інше, широко застосовуване в галузі рішення для захисту від DDoS, на тій самій інфраструктурі й у той самий момент атаки, що дало змогу безпосередньо порівняти час реакції обох систем на ідентичний трафік.

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

LiveShield виявив атаку і розгорнув перше правило фільтрації (на трафік DNS) у ту саму секунду. Порівнюване рішення виявило атаку із запізненням у 4 секунди відносно LiveShield, а його перше правило фільтрації (також на трафік DNS) було розгорнуте із запізненням у 18 секунд відносно моменту, коли LiveShield уже фільтрував цей трафік.

Для другого вектора атаки (фрагментація IP) різниця становила 8 секунд на користь LiveShield. Третій вектор (UDP на конкретний порт призначення) LiveShield обробив окремим наступним правилом. Порівнюване рішення, попри налаштоване правило для цього шаблону трафіку, не розгорнуло його взагалі протягом тесту.

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

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

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

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

У контрольованому тесті на багатовекторній атаці з параметрами 700 kpps / 6,5 Гб/с (IP Fragments, DNS amplification, UDP Flood) LiveShield виявив атаку і розгорнув перше правило фільтрації в ту саму секунду, в яку атака стартувала, випередивши порівнюване ринкове рішення на кілька або кільканадцять секунд на наступних векторах атаки, а одне з правил конкурентна система, попри правильне налаштування, не розгорнула взагалі. Це результат архітектури, що ґрунтується на аналізі трафіку в пам'яті та комунікації між модулями, розробленій під мінімальний час реакції, а не лише заявлена швидкість.

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

Які параметри мала атака, використана в порівняльному тесті? Тест проведено на атаці інтенсивністю 700 kpps і 6,5 Гб/с, що складалася з трьох одночасних векторів: фрагментації IP, ампліфікації DNS та UDP Flood.

Чи всі системи захисту від DDoS реагують за подібний час? Ні. У проведеному тесті порівнюване ринкове рішення виявило ту саму атаку із запізненням у кілька секунд відносно LiveShield, а одне з налаштованих правил фільтрації взагалі не розгорнуло під час атаки.