Захист від DDoS у мережі оператора: як працює система захисту від DDoS на практиці

DDoS-атака в мережі оператора рідко виглядає так, як її подають маркетингові матеріали хмарних постачальників. Це не поодинокий інцидент на одному сервері, а проблема на рівні каналу, крайового маршрутизатора та всього адресного пулу клієнтів. Для ISP, дата-центру чи телекомунікаційного оператора питання не в тому, «чи це нас торкнеться», а в тому, «що станеться, коли 20 Гбіт/с сміттєвого трафіку вдарить по нашому аплінку посеред ночі». Ця стаття є практичним поглядом на захист від DDoS з перспективи операторської мережі: які бувають типи атак, як реально виглядає anti-DDoS на рівні інфраструктури і чому система захисту від DDoS, що працює on-premise, на власному обладнанні, має для оператора інше обґрунтування, ніж для окремої компанії з одним вебсайтом.

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

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

Волюметричні атаки найпростіші для розуміння і досі найпоширеніші. Їхня мета це насичення смуги: UDP flood, ампліфікація DNS, NTP чи інші техніки reflection/amplification, де зловмисник надсилає невеликий запит із підробленою адресою джерела жертви, а відповідь повертається у багато разів більшою. Захист від цього типу атак має працювати на стику з аплінком, ще до того, як трафік взагалі потрапить у мережу оператора, звідси значення механізмів на кшталт BGP FlowSpec і blackholing.

Протокольні атаки цілять у стан з'єднання, а не в саму смугу. Класичний SYN flood може покласти маршрутизатор чи сервер при відносно невеликому обсязі трафіку, бо вичерпує таблицю з'єднань, а не канал. Саме цей тип атаки буває найпідступнішим: тривога за обсягом може не спрацювати, а сервіс уже не відповідає.

Дедалі частіше з'являється також варіант, що поєднує stateful-протокольну атаку зі спробою обійти класичний волюметричний захист: хвиля SYN-ACK, ACK чи RST без відповідного вихідного SYN, спрямована безпосередньо на стик BRAS/концентратора. Обсяг буває надто низьким, щоб викликати реакцію системи, яка ґрунтується виключно на порогах трафіку, і все ж може забити стан з'єднань на абонентських пристроях.

Ефективний захист від DDoS для оператора ґрунтується на кількох взаємодоповнювальних механізмах, а не на одному універсальному рішенні.

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

Мітигація через BGP FlowSpec. Коли система виявляє атаку, вона генерує правила FlowSpec і передає їх на крайовий маршрутизатор оператора через сесію BGP. Маршрутизатор програмує правила в апаратному забезпеченні й фільтрує трафік на ранньому етапі, до того як він навантажить решту інфраструктури. Це рішення працює локально, між системою захисту від DDoS і власними маршрутизаторами оператора. Воно не потребує підтримки FlowSpec від постачальника аплінка, достатньо, щоб аплінк виконував стандартні blackholing community. Умовою є обладнання з підтримкою FlowSpec в апаратному забезпеченні; перевірений список охоплює, зокрема, Juniper MX/PTX та Cisco ASR1k/9k/NCS5500 SE/8000. За іншого обладнання, наприклад Huawei, стандартний RTBH має спрацювати, але підтримку FlowSpec потрібно перевіряти для кожної моделі.

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

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

Stateful-фільтрація inline. Для протокольних атак типу SYN-ACK/ACK/RST без відповідного вихідного з'єднання захисту від DDoS на рівні FlowSpec чи RTBH недостатньо: це атака на стан з'єднання, а не на обсяг. Тут потрібен рушій, що відстежує двонапрямлено стан з'єднань TCP, розміщений inline між крайовим маршрутизатором і BRAS чи концентратором, який відкидає пакети, що не відповідають жодній відомій сесії. Це рішення має сенс як додатковий шар, а не заміна волюметричного захисту: якщо атака насичує сам канал аплінка, жоден stateful-фільтр цього не виправить, доки RTBH не розвантажить канал.

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

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

Захист від DDoS сьогодні це не лише питання доступності сервісу, а й регуляторний обов'язок. Оператори ключових і важливих послуг, на яких поширюється директива NIS2 та національний закон про національну систему кібербезпеки, мусять впроваджувати відповідні технічні та організаційні заходи з управління ризиками, а DDoS-інциденти відповідного масштабу підлягають обов'язку повідомлення до CSIRT. Система захисту від DDoS, що генерує готові звіти у вимаганому обсязі даних, скорочує час, потрібний для виконання цього обов'язку, хоча саме подання повідомлення в системі CSIRT і далі залишається за оператором.

Захист від DDoS для оператора це не один продукт, а набір взаємодоповнювальних механізмів, підібраних під шар атаки: FlowSpec і селективний RTBH на рівні мережі для волюметричних атак, агрегація для кожного префікса для carpet bombing, stateful-фільтрація inline для протокольних атак, що обходять класичні пороги обсягу. Система захисту від DDoS, що працює on-premise, на власному обладнанні й у власній мережі, дає операторові те, чого не може дати хмарний сервіс: повний контроль над тим, як і коли фільтрується трафік, без посередника в найкритичніший момент.

Якщо ви замислюєтеся, як виглядає впровадження системи захисту від DDoS LiveShield у вашій мережі, яке обладнання знадобиться за вашого обсягу трафіку і які крайові маршрутизатори підтримують FlowSpec, найпростішою відправною точкою є розмова про вашу конкретну топологію мережі.