Атаки TCP Reflection: враг в отражении

TCP Reflection нередко становится частью многовекторной DDoS-атаки. Угрозы этого типа особенно опасны: они выглядят как легитимный трафик на пакетном уровне и создают высокую нагрузку на инфраструктуру по скорости передачи данных. Какие механизмы используют злоумышленники и как выстроить защиту, разбираем в статье.

Что такое TCP Reflection

TCP Reflection — это класс DDoS-атак, в которых злоумышленник эксплуатирует механику трёхстороннего TCP-рукопожатия, чтобы превратить легитимные серверы в невольных участников атаки. Он не направляет вредоносный трафик напрямую, а заставляет тысячи сторонних узлов — так называемых рефлекторов — генерировать множество TCP-пакетов в адрес жертвы. Создаётся большой объём отражённого трафика.

TCP Reflection происходит на транспортном уровне (L4) сетевой модели OSI и представляет собой подвид DDoS-атак с отражением. Злоумышленники используют этот метод, чтобы генерировать объёмные и протокольные атаки. Под ударом в первую очередь оказывается не пропускная способность канала (Gbps), а производительность обработки пакетов (PPS) и ресурсы TCP-стека.

Подробнее о механизме атаки

TCP Reflection состоит из четырёх основных этапов, разберём каждый отдельно. 

1. Подмена IP-адреса источника (IP Spoofing).

Злоумышленник формирует TCP-сегменты с флагом SYN — стандартные запросы на установку соединения. Однако в поле Source IP он указывает не свой адрес, а адрес узла-жертвы. Корректнее называть такие единицы данных «TCP-сегментами с флагом SYN», поскольку пакет — это сущность сетевого уровня (IP), а не транспортного (TCP). Тем не менее, для простоты мы будем использовать устоявшийся термин «пакет».

Подготовленные таким образом SYN-пакеты рассылаются на множество легитимных серверов с сервисами, которые имеют открытые порты и опубликованы в интернете: веб-серверы, криптографические шлюзы, почтовые серверы и другие узлы, принимающие входящие TCP-подключения. Каждый из этих серверов становится потенциальным рефлектором.

2. Ответ рефлектора.

Сервер-рефлектор воспринимает входящий SYN-пакет как начало легитимного TCP-соединения — на транспортном уровне он ничем не отличается от обычного клиентского запроса. В соответствии со стандартной процедурой трёхстороннего рукопожатия рефлектор формирует ответный пакет SYN+ACK и отправляет его на IP-адрес, указанный в поле Source IP исходного сегмента, — то есть на адрес узла жертвы. 

Она получает SYN+ACK-пакет, который на самом деле не запрашивала. Соединение не завершается, к рефлектору не поступает ожидаемое ACK-подтверждение.

3. Усиление через повторные передачи.

Именно здесь вступает в действие ключевой механизм усиления. Не получив ACK в течение установленного таймаута, рефлектор не отбрасывает незавершённое соединение, а повторно отправляет SYN+ACK в соответствии с параметром tcp_synack_retries. Например, в Linux по умолчанию предусмотрено 5 попыток, а максимально допустимое число — 255. Каждая повторная передача — это дополнительный пакет, направленный на жертву.

Таким образом, один поддельный SYN-пакет может превратиться в 5–6 пакетов SYN+ACK, которые приходят на адрес атакуемого узла с одного рефлектора.  

4. Масштабирование.

Злоумышленники задействуют при атаке тысячи и десятки тысяч рефлекторов и таким образом усиливают эффект. Если 10 000 рефлекторов по 5 раз повторно отправят поддельный SYN-запрос, он превратится в 60 000 пакетов SYN+ACK в адрес атакуемого узла. Это уже мощный поток, способный перегрузить сетевое оборудование или стек TCP/IP на стороне жертвы.

В чём коварство TCP Reflection 

Такие атаки сложнее обнаружить, потому что:

1. Основной вектор воздействия — количество пакетов, передаваемых за секунду (packet rate, pps), а не полоса пропускания (bps). Атака ориентирована на перегрузку плоскости обработки пакетов (control plane / data plane), а не на исчерпание пропускной способности канала. Большинство систем мониторинга и DDoS-детекции опираются на пороговые значения по объёму трафика (битрейт), вследствие чего поток с относительно низкой полосой пропускания, но высоким количеством пакетов может не классифицироваться как аномалия, несмотря на деградацию производительности целевого хоста или сетевого оборудования.
2. Используются легитимные источники — обычные публичные сервисы. Злоумышленники задействуют реальные серверы, корректно отвечающие на подменённые SYN-запросы. В результате целевая система получает поток пакетов с установленным флагом SYN+ACK от валидных IP-адресов обычных публичных сервисов. С точки зрения сетевого трафика такие пакеты неотличимы от легитимных ответов в рамках корректно инициированных TCP-сессий. Это существенно усложняет применение сигнатурной или репутационной фильтрации, в отличие от атак с явно поддельными источниками.  

Единственный способ отличить легитимный запрос SYN+ACK от «отражённого» — сопоставить его с исходящим трафиком. Если защищаемый узел ранее отправлял SYN-запрос к серверу, то SYN+ACK — ответ на него. Если не отправлял — это признак DDoS-атаки. Такой подход требует анализа входящего и исходящего трафика, то есть симметричной схемы фильтрации.

При асимметричной схеме, когда фильтруется только входящий трафик, гораздо сложнее определить, какие SYN+ACK-пакеты являются легитимными ответами, а какие — частью атаки.

Подробнее: Симметричная и асимметричная фильтрация DDoS-атаки: что и когда выбрать?

Виды атак 

Выделяют несколько разновидностей TCP Reflection в зависимости от того, какие узлы выступают рефлекторами и какой механизм протокола эксплуатируется.

TCP SYN-ACK Reflection

Это классический вариант, механика которого описана выше. Злоумышленник рассылает поддельные SYN-сегменты с подменённым IP-адресом источника на большое количество серверов с открытыми TCP-сервисами. Каждый из них отвечает пакетом SYN+ACK и, не получив завершающего ACK, выполняет серию повторных передач.

TCP Middlebox Reflection

Более сложная разновидность атаки, в качестве рефлекторов выступают промежуточные сетевые устройства — так называемые middlebox или middleware. К ним относятся межсетевые экраны, системы глубокого анализа трафика (DPI), устройства для фильтрации контента и другие элементы сетевой инфраструктуры, которые обрабатывают проходящий TCP-трафик, включая HTTP, и могут вмешиваться в соединения.

Такие устройства могут отвечать на определённые TCP-сегменты нестандартным образом — например, генерировать страницы блокировки, HTTP-перенаправления или RST-пакеты. 

Механизм атаки:

1. Злоумышленник отправляет TCP-сегменты, содержащие HTTP-заголовки с запросами к ресурсам, заблокированным на уровне промежуточного устройства. 
2. Оно перехватывает соединение и формирует собственный ответ: HTML-страницу блокировки, JSON-объект с описанием ошибки, набор HTTP-заголовков перенаправления или иной контент. 
3. Весь ответ направляется на IP-адрес жертвы.

Этот вид атаки опасен тем, что объём ответа может в десятки и сотни раз превышать объём исходного запроса. Зафиксированы случаи, когда коэффициент усиления достигал порядка 65×, что сравнимо с показателями атак типа UDP-амплификация.

То есть Middlebox Reflection сочетает в себе оба поражающих фактора: высокую интенсивность пакетов и значительный объём данных. Это делает его одним из наиболее опасных векторов атак.

TCP ACK Reflection

Злоумышленник генерирует массив ACK-сегментов с подменённым IP-адресом источника и направляет их на промежуточные устройства или серверы, обрабатывающие TCP-трафик.

Стек протокола и сетевое оборудование обрабатывают пакеты с флагом ACK как потенциально валидные, пытаясь сопоставить с существующими соединениями. Но когда такие пакеты поступают массово, на поиск и анализ состояний соединений в таблицах тратится много ресурсов. Это может привести к исчерпанию вычислительных мощностей.

Громкие атаки и их «побочный эффект»  

Один из первых всплесков атак TCP Reflection зафиксировали в Скандинавии и Южной Европе в 2019 году. Злоумышленники использовали десятки тысяч открытых серверов в качестве рефлекторов и генерировали мощные потоки пакетов. Сильнее всего пострадали организации в сферах финансов и телекома. 

С 2022 года злоумышленники начали совершать атаки подвида TCP Middlebox Reflection: до этого механизм только теоретически рассматривали исследователи в США. Под ударом оказались организации из банковского сектора, туризма, игровой индустрии, медиа и веб-хостинга. 

Обнаружился и «побочный эффект» TCP Reflection: серверы и устройства, выступающие в роли рефлекторов, испытывали аномальную нагрузку из-за массы незавершённых TCP-соединений. Это приводило к деградации сервисов — они становились медленными или частично недоступными для собственных клиентов. В результате атак страдали интернет- и хостинг-провайдеры, малый бизнес, чью инфраструктуру задействовали хакеры. 

Методы защиты

Легче всего защитить публичный TCP-сервис: если он только принимает входящие TCP-соединения и сам не инициирует исходящие, достаточно заблокировать входящие пакеты SYN+ACK вместе с UDP-трафиком — и проблема решена. Однако если речь идёт о трафике интернет-провайдера, хостинга или любой инфраструктуры, где узлы устанавливают исходящие TCP-соединения, нужен комплексный подход. Методы защиты применяются на нескольких уровнях — инфраструктуры, рефлектора, клиента/сервера и хоста.

1. Профилирование трафика и сегментация ресурсов.

Первый шаг — грамотно разделить ресурсы по IP-адресам и подсетям. Размещение разных типов сервисов отдельно друг от друга позволяет заранее обезопасить инфраструктуру от целых классов угроз за счёт применения индивидуальных политик фильтрации к каждому сегменту.

Например, на IP-адресах, за которыми размещены веб-сайты, можно изначально закрыть все протоколы кроме TCP и запретить входящие пакеты с флагами SYN+ACK, поскольку веб-сервер не инициирует исходящие TCP-подключения к произвольным хостам. Это полностью исключает возможность TCP SYN-ACK Reflection для сегмента. 

На IP-адресах с VDS-серверами или пользователями те же ограничения уже нельзя применить безболезненно: эти узлы устанавливают собственные исходящие TCP-соединения.

В итоге входящие TCP SYN-ACK-пакеты в сегменте, где исходящих соединений быть не должно, будут быстро идентифицированы как атака.

2. Борьба с подменой IP-адресов. 

Поскольку при TCP Reflection подменяется IP-адрес источника, один из наиболее действенных методов противодействия — внедрить рекомендации стандарта BCP38 по борьбе с IP‑спуфингом. Граничные маршрутизаторы операторов связи должны фильтровать исходящие пакеты с IP-адресами источника, не входящими в префиксы, назначенные данной автономной системе. Механизм Unicast Reverse Path Forwarding (uRPF) позволяет автоматизировать такую проверку.

Широкое внедрение BCP38 лишает злоумышленников возможности подменять исходный адрес и, как следствие, направлять рефлекторы на случайные жертвы. К сожалению, на практике этот стандарт реализован далеко не во всех сетях.

3. Настройка TCP‑стека на стороне рефлекторов.

Важно снижать саму возможность усиления атаки на стороне серверов, которые могут быть использованы в качестве рефлекторов. Для этого можно:

• уменьшить количество повторно отправляемых пакетов SYN+ACK при отсутствии ответа;
• включить SYN cookies, чтобы сервер мог обрабатывать входящие SYN-запросы без выделения ресурсов на полуоткрытые соединения;
• ограничить количество новых SYN-запросов в секунду с одного IP-адреса или подсети на уровне TCP-портов.

4. Настройка промежуточных устройств.

Для них рекомендуется минимизировать объём генерируемых ответов. Например, вместо полноценных HTML-страниц блокировки выдавать короткий ответ 301 или 403 без развёрнутого тела. Также необходимо исключить сценарии, при которых устройство отвечает на подозрительные HTTP-запросы длинными цепочками переадресаций. Не стоит забывать и про регулярное обновление программного обеспечения.

5. Подключение специализированных сервисов защиты. 

Современные antiDDoS-решения выявляют TCP Reflection по характерным сигнатурам. Основной индикатор — аномально высокая частота пакетов (PPS) по TCP-портам, где количество SYN-, SYN+ACK- и ACK-пакетов значительно отличается друг от друга или от нормального распределения для этого клиента. При обнаружении таких паттернов трафик перенаправляется в центры очистки: вредоносный блокируется, а легитимный пропускается.

Почему StormWall надёжно защищает от TCP Reflection

При симметричной схеме подключения мы анализируем и входящий, и исходящий трафик и точно определяем, какие входящие SYN+ACK-пакеты соответствуют реальным исходящим соединениям защищаемого ресурса, а какие являются «отражённым» трафиком. Это позволяет отфильтровать атаку на 100%. 

StormWall предлагает собственный механизм фильтрации TCP Reflection. Он обеспечивает защиту от самых мощных атак, используя интеллектуальные фильтры и анализ трафика в реальном времени. В том числе работает при асимметричном подключении, что позволяет при атаке кратно снизить число пакетов, достигающих ресурса под защитой.