Атаки SYN-ACK reflection: коли трафік виглядає легітимним, але є атакою

Останніми місяцями дедалі більше польських операторів ISP стикаються з однією й тією самою ситуацією: дзвінок або e-mail із погрозою DDoS-атаки, якщо компанія не заплатить викуп. Що відрізняє цю хвилю від класичного шантажу, то це тип атаки, якою погрожують і яка справді настає, коли оператор не піддається тиску. Йдеться про SYN-ACK reflection, атаку, яку важко зупинити стандартними методами фільтрації.

Механізм ґрунтується на використанні інфраструктури, яка не перевіряє адреси джерела вихідного трафіку (відсутність упровадженого BCP38 на боці зловмисника або оператора, в якого зловмисник має сервер).

Зловмисник масово надсилає пакети SYN до легітимних публічних серверів, як-от популярні портали, хмарні сервіси, будь-які хости, що відповідають на з'єднання TCP, підміняючи адресу джерела на IP-адресу жертви. Сервери, які отримали ці пакети, відповідають згідно зі специфікацією TCP пакетом SYN-ACK. Оскільки адресу джерела підроблено, відповіді потрапляють не до зловмисника, а безпосередньо до жертви.

Наслідок: жертву заливають тисячі пакетів SYN-ACK за секунду, що надходять з IP-адрес, які самі по собі цілком легітимні та впізнавані. Жодна база репутації IP не позначить їх як загрозу.

Стандартний підхід до мітигації волюметричних атак ґрунтується на двох механізмах: FlowSpec, тобто точних правилах фільтрації, що генеруються на основі характеристик трафіку (порт, протокол, довжина пакета), та RTBH (Remotely Triggered Black Hole), тобто блокуванні всього трафіку до атакованої IP-адреси.

Обидва механізми дуже добре працюють за типових атак: UDP flood, ампліфікації, фрагментації IP. Проблема виникає, коли трафік атаки структурно не відрізняється від легітимного. Системи без стану (stateless), зокрема рішення, що ґрунтуються виключно на семплюванні NetFlow/sFlow, аналізують пакет у відриві від контексту з'єднання. Окремий пакет SYN-ACK з адреси відомого публічного сервера не виглядає підозріло, доки не перевірити, чи йому справді передував запит SYN, надісланий раніше з мережі оператора.

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

Атаки SYN-ACK reflection не є новиною з теоретичного погляду: їх уже багато років описують як один із варіантів reflection/amplification. Новим є масштаб і систематичність, з якими їх використовують проти польських телекомунікаційних операторів у спробах вимагання викупу. Це зміщує тягар відповідальності на постачальників систем захисту: класична пара FlowSpec плюс RTBH перестає бути достатньою як повна відповідь на реальні загрози, з якими сьогодні стикається польський ринок ISP.

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

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

Якщо ваша компанія зіткнулася зі спробою шантажу на основі погрози DDoS-атаки або вже протидіє такій атаці, запрошуємо зв'язатися з нами. Охоче обговоримо доступні методи підтримки: office@liveshield.net