SYN-ACK Flood и SYN-ACK Reflection DDoS: как работает атака и как защититься

SYN-ACK Flood — разновидность TCP DDoS-атаки, при которой целевая система получает большое количество пакетов с одновременно установленными флагами SYN и ACK.

В нормальном TCP-соединении SYN-ACK является ответом сервера на запрос клиента установить соединение. Если система получает SYN-ACK, которому не предшествовал исходящий SYN, такой пакет не относится к ожидаемому TCP-сеансу.

Существуют два принципиально разных варианта атаки:

• прямой SYN-ACK Flood — злоумышленник или ботнет самостоятельно отправляет SYN-ACK-пакеты в адрес цели;
• SYN-ACK Reflection — атакующий отправляет SYN-запросы сторонним TCP-серверам, но указывает в них поддельный IP-адрес жертвы; серверы отвечают жертве пакетами SYN-ACK.

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

Что означает комбинация SYN-ACK

TCP использует трёхэтапное рукопожатие для установки соединения:

1. клиент отправляет серверу пакет SYN;
2. сервер отвечает SYN-ACK;
3. клиент возвращает ACK.

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

Пакет	Отправитель	Назначение
SYN	Клиент	Запросить новое соединение
SYN-ACK	Сервер	Подтвердить запрос и предложить параметры соединения
ACK	Клиент	Завершить установление соединения

Основная современная спецификация TCP приведена в RFC 9293. Документ описывает TCP как протокол с состоянием, использующий номера последовательности, подтверждения и переходы между состояниями соединения.

Как выглядит легитимный SYN-ACK

У нормального SYN-ACK есть контекст:

• ранее клиент отправил SYN;
• адреса и порты соответствуют исходному запросу;
• ACK number подтверждает клиентский SYN;
• sequence number используется для продолжения handshake;
• пакет приходит в пределах разумного времени после SYN;
• клиент ожидает ответ от конкретного сервера;
• завершающий ACK переводит соединение в установленное состояние.

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

Что такое прямой SYN-ACK Flood

При прямом SYN-ACK Flood пакеты создаются атакующими устройствами и отправляются непосредственно цели. Они могут иметь реальные либо поддельные исходные IP-адреса.

Атакующий меняет:

• исходные IP-адреса;
• исходные и целевые порты;
• sequence number;
• acknowledgment number;
• размер TCP-окна;
• набор TCP-опций;
• размер пакета;
• частоту отправки.

Цель прямого варианта — создать высокий PPS, загрузить процессор сетевого оборудования или заполнить канал.

Что такое SYN-ACK Reflection

SYN-ACK Reflection — отражённая TCP-атака. В ней сторонние серверы становятся невольными источниками трафика.

Последовательность выглядит так:

1. Атакующий выбирает множество публичных TCP-сервисов.
2. На каждый сервер отправляется SYN-запрос.
3. В качестве исходного IP указывается адрес жертвы.
4. Сервер считает, что жертва пытается установить соединение.
5. Сервер отправляет SYN-ACK на IP жертвы.
6. Жертва получает ответы на запросы, которых она не отправляла.
7. Если ACK не приходит, сервер может повторить SYN-ACK.

Источниками входящего трафика выглядят реальные веб-серверы, почтовые серверы, прокси, балансировщики и другие TCP-сервисы. Они не обязательно скомпрометированы: достаточно, чтобы сервис отвечал SYN-ACK на входящий SYN.

Почему отражение возможно

В заголовке IPv4 нет встроенного криптографического подтверждения подлинности source IP. Если сеть атакующего не фильтрует исходящий трафик, устройство может отправить пакет с адресом, который ему не принадлежит.

TCP частично ограничивает возможности злоумышленника: для полноценного соединения необходимо получить SYN-ACK и отправить корректный ACK. Но для отражения одного или нескольких SYN-ACK завершать handshake не требуется.

RFC 7413 отмечает, что SYN-пакеты с поддельными исходными адресами являются причиной уязвимости стандартного TCP к SYN Flood: они могут заполнять очередь слушающего сервера.

В отражённом сценарии жертвой становится не только сервер, получающий поддельные SYN. Ответные SYN-ACK направляются на подставленный адрес другой системы.

Есть ли в SYN-ACK Reflection усиление

SYN-ACK Reflection иногда называют amplification-атакой, однако коэффициент усиления необходимо оценивать аккуратно.

Один обычный SYN и один SYN-ACK часто имеют сопоставимые размеры. Поэтому классическое байтовое усиление одного ответа значительно ниже, чем у DNS, NTP, Memcached или CLDAP Amplification.

Усиление может возникать за счёт:

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

Корректнее говорить, что это прежде всего reflection-атака с возможным повторным усилением, а не протокол с гарантированным высоким amplification factor.

Как повторные SYN-ACK усиливают нагрузку

После получения SYN сервер отправляет SYN-ACK и переходит в состояние SYN-RECEIVED. Если завершающий ACK не приходит, сервер обычно выполняет несколько повторных передач.

Точное количество повторов и интервалы зависят от:

• операционной системы;
• версии ядра;
• настроек TCP;
• сетевого оборудования;
• использования SYN proxy;
• политики балансировщика;
• текущей нагрузки;
• механизма SYN cookies.

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

Две жертвы отражённого сценария

SYN-ACK Reflection создаёт нагрузку на две группы систем.

Основная жертва

Получает отражённые SYN-ACK:

• теряет пропускную способность;
• обрабатывает высокий PPS;
• проверяет пакеты по state table;
• может генерировать RST;
• испытывает потери легитимного трафика.

Сервер-отражатель

Получает поддельные SYN и хранит либо вычисляет состояние:

• отправляет SYN-ACK;
• ожидает ACK;
• повторяет ответ;
• расходует очередь полуоткрытых соединений;
• может сам столкнуться с SYN Flood.

Таким образом, серверы-отражатели одновременно используются для атаки на третью сторону и сами получают вредоносные SYN-запросы.

SYN-ACK Flood и SYN Flood: в чём разница

Критерий	SYN Flood	SYN-ACK Flood
Пакеты у основной цели	SYN	SYN-ACK
Имитация роли	Клиент начинает соединение	Сервер отвечает на соединение
Основное состояние цели	SYN-RECEIVED	Ожидаемое состояние обычно отсутствует
Главная нагрузка	Очередь полуоткрытых соединений	Канал, PPS и проверка состояния
Возможность отражения	Использует жертву как сервер	Сторонние серверы отвечают жертве
SYN cookies	Помогают серверу-цели	Не защищают жертву от входящих SYN-ACK напрямую

RFC 4987 описывает SYN Flood как ситуацию, в которой ложные полуоткрытые соединения исчерпывают ресурсы, необходимые для легитимных клиентов. Документ рассматривает SYN cookies, сокращение тайм-аутов, увеличение очереди и другие меры с их ограничениями.

SYN-ACK Flood и ACK Flood: в чём разница

Критерий	SYN-ACK Flood	ACK Flood
Флаги	SYN и ACK	ACK
Нормальный смысл	Ответ на запрос соединения	Подтверждение в существующем соединении
Отражённый вариант	Распространённый технический сценарий	Обычно прямой поток
Ожидаемое состояние у жертвы	SYN-SENT	Одно из синхронизированных состояний
Возможная реакция жертвы	Отбрасывание или RST	Отбрасывание, проверка окна или другая обработка

Какие TCP-сервисы могут стать отражателями

Практически любой публичный TCP-сервис может ответить SYN-ACK на SYN, если порт открыт и запрос не отфильтрован.

Возможные источники:

• веб-серверы на TCP/80 и TCP/443;
• почтовые серверы;
• SSH-серверы;
• FTP-серверы;
• балансировщики;
• reverse proxy;
• VPN-шлюзы, использующие TCP;
• серверы баз данных с публичными портами;
• панели управления;
• сетевое и промышленное оборудование;
• IoT-устройства с открытыми TCP-сервисами.

Наличие открытого TCP-порта не означает уязвимость в обычном смысле. Ответ SYN-ACK является нормальным поведением TCP. Главная причина отражения — возможность атакующего отправлять SYN с поддельным адресом.

Почему нельзя просто составить список отражателей

Список адресов быстро устаревает:

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

Защита должна учитывать состояние соединения, а не только репутацию исходного адреса.

Как выглядит атака со стороны жертвы

В сетевом трафике видны SYN-ACK от большого количества внешних серверов. При этом защищаемая система не отправляла соответствующие SYN.

Характерные признаки:

• резкий рост SYN-ACK PPS;
• отсутствие соответствующего роста исходящих SYN;
• большое количество разных исходных IP;
• повторные SYN-ACK от одних и тех же серверов;
• ответы с распространённых серверных портов;
• разные целевые эфемерные порты жертвы;
• однотипные интервалы повторной передачи;
• рост исходящих RST со стороны жертвы;
• увеличение INVALID-пакетов на firewall;
• загрузка канала или процессора сетевого оборудования;
• отсутствие сопоставимого роста HTTP-запросов.

Почему целевые порты жертвы могут меняться

В отражённом сценарии атакующий формирует поддельный SYN так, будто он отправлен с IP жертвы и выбранного исходного порта. Ответ сервера идёт на этот порт.

Если злоумышленник меняет поддельный source port, SYN-ACK поступают на множество целевых портов жертвы. Это может:

• увеличивать число уникальных потоков;
• нагружать stateful firewall;
• усложнять фильтрацию по одному порту;
• создавать дополнительную телеметрию и записи;
• маскировать основной профиль атаки.

Почему source port часто выглядит легитимно

Исходным портом отражённого SYN-ACK является открытый порт стороннего сервера. Это может быть TCP/443, TCP/80, TCP/22 или другой реальный сервис.

Поэтому правило «разрешать пакеты с source port 443» не подтверждает их легитимность. Настоящий HTTPS-ответ должен относиться к соединению, которое клиент ранее инициировал.

Какие ресурсы перегружает SYN-ACK Flood

Пропускная способность

Большой распределённый поток способен заполнить внешний канал. В таком случае легитимные пакеты теряются до попадания на сервер.

Пакетная производительность

Небольшие SYN-ACK создают высокий PPS. Маршрутизатор и firewall могут достичь предела обработки раньше, чем канал заполнится по BPS.

Stateful firewall

Устройство проверяет, существует ли исходящий SYN и соответствующее состояние SYN-SENT. Поиск выполняется для каждого пакета.

Conntrack

Неожиданные SYN-ACK обычно не должны создавать полноценное установленное состояние, но всё равно проходят классификацию и поиск в таблице.

TCP-стек

Если пакет доходит до конечной системы, ядро проверяет порты, сокеты, номера последовательности, ACK и текущее состояние.

Исходящий канал

Если жертва отвечает RST на неожиданные SYN-ACK, атака создаёт не только входящий, но и дополнительный исходящий поток.

Как отличить отражённую атаку от прямой

Признак	Прямой SYN-ACK Flood	SYN-ACK Reflection
Источники	Ботнет или поддельные адреса	Реальные TCP-серверы
Исходные порты	Могут быть случайными	Часто соответствуют открытым сервисам
TCP-опции	Могут быть однотипными	Различаются по ОС и сервисам
Повторные передачи	Зависят от генератора	Похожи на реальные retransmission серверов
Распределение во времени	Определяется ботнетом	Может иметь «хвост» из повторов
Репутация адресов	Часто подозрительная	Может быть нормальной

Одного признака недостаточно. Наиболее сильная комбинация для определения reflection — реальные серверные адреса и порты, разнообразные TCP-стеки, отсутствие исходящих SYN и характерные повторные SYN-ACK.

Как отличить атаку от проблемы сети

Неожиданные SYN-ACK могут возникать не только при DDoS.

Возможные технические причины:

• асимметричная маршрутизация;
• firewall не видел исходящий SYN;
• поздний SYN-ACK пришёл после удаления состояния;
• NAT изменил или потерял отображение;
• клиент повторно использовал исходный порт;
• маршрут изменился во время соединения;
• сервер сильно задержал ответ;
• дублирование пакетов в сети;
• ошибка балансировки между stateful-узлами.

При DDoS количество пакетов, источников и потоков резко превышает фоновый уровень, а аномалия одновременно влияет на доступность сервиса.

Какие метрики необходимо собирать

• общий TCP PPS;
• SYN-ACK PPS;
• объём SYN-ACK в битах в секунду;
• отношение исходящих SYN к входящим SYN-ACK;
• число уникальных источников;
• число уникальных потоков;
• распределение исходных портов;
• распределение целевых портов;
• долю SYN-ACK без состояния SYN-SENT;
• количество повторных SYN-ACK;
• количество исходящих RST;
• долю INVALID на firewall;
• заполнение conntrack;
• CPU маршрутизатора и firewall;
• packet drops на всех участках;
• нагрузку softirq на конечном сервере.

Какие данные искать в PCAP

При анализе ограниченного сетевого дампа проверяют:

• одновременно установленные SYN и ACK;
• наличие исходного SYN в обратном направлении;
• source и destination port;
• sequence и acknowledgment number;
• TTL или Hop Limit;
• размер TCP-окна;
• MSS, Window Scale, SACK и Timestamp;
• интервалы между повторами;
• одинаковый sequence number в повторных SYN-ACK;
• ответы RST со стороны жертвы.

Различающиеся значения TTL и TCP-опций могут указывать на множество реальных отражателей с разными операционными системами.

Почему NetFlow полезен, но недостаточен

NetFlow или IPFIX помогает увидеть адреса, порты, объём, число пакетов и TCP-флаги. Этого часто достаточно для первичной классификации.

Но агрегированные данные могут не показать:

• точную последовательность пакетов;
• номера последовательности;
• содержимое TCP-опций;
• интервалы отдельных retransmission;
• наличие соответствующего SYN в пределах другого агрегата.

Для расследования желательно сочетать потоковую телеметрию с коротким PCAP и данными stateful firewall.

Как защитить жертву от SYN-ACK Flood

1. Проверять состояние соединения

Входящий SYN-ACK должен соответствовать ранее отправленному SYN. Пакеты без состояния SYN-SENT следует отбрасывать.

Эта мера требует, чтобы firewall видел оба направления обмена. При асимметричной маршрутизации легитимный SYN может пройти через другой узел.

2. Выполнять раннюю фильтрацию

Неожиданный SYN-ACK желательно удалить до дорогостоящей обработки:

1. в сети Anti-DDoS-провайдера;
2. на аппаратной границе;
3. на граничном маршрутизаторе;
4. до основной таблицы conntrack;
5. до балансировщика и конечного сервера.

3. Закрыть неиспользуемые направления

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

4. Ограничивать только пакеты вне состояния

Rate limit для всех SYN-ACK опасен: легитимные ответы серверов также используют эту комбинацию. Ограничение следует применять к пакетам, не соответствующим исходящим SYN.

5. Контролировать RST

Ответный RST может подтверждать атакующему доступность адреса и создавать дополнительную нагрузку. Поведение конечной системы должно соответствовать стандарту, а фильтрация должна выполняться до генерации ненужных ответов, если это допускает архитектура.

6. Подключить upstream Anti-DDoS

При заполнении канала локальная фильтрация не помогает: вредоносный трафик уже занял линию. Очистка должна происходить в сети оператора или scrubbing-центре.

Как уменьшить участие сервера в отражении

Полностью запретить публичному TCP-сервису отвечать SYN-ACK нельзя: без этого легитимные клиенты не смогут подключиться. Но можно уменьшить побочную нагрузку.

Применять SYN cookies

SYN cookies позволяют не хранить полное состояние полуоткрытого соединения до получения завершающего ACK. Это защищает сервер-отражатель от исчерпания очереди, хотя SYN-ACK всё равно отправляется.

Использовать SYN proxy

Защитное устройство принимает начальное рукопожатие на себя. Это позволяет централизованно применять ограничения и не передавать каждый поддельный SYN конечному серверу.

Ограничивать SYN с одного источника

Метод помогает, если используются реальные адреса. При spoofing источник постоянно меняется, поэтому лимит только по отдельному IP недостаточен.

Настроить глобальный контроль новых соединений

Следует учитывать:

• общий SYN PPS;
• долю незавершённых handshake;
• число SYN_RECV;
• повторные SYN-ACK;
• распределение источников и автономных систем;
• пиковую легитимную нагрузку.

Закрыть ненужные TCP-порты

Каждый лишний публичный сервис увеличивает поверхность атаки. Административные панели, базы данных и SSH лучше ограничить VPN или списком доверенных адресов.

Применять egress-фильтрацию

Операторы и владельцы сетей должны блокировать исходящие пакеты с source IP, не принадлежащим их адресному пространству. Это ключевая системная мера против отражённых атак.

Помогают ли SYN cookies жертве SYN-ACK Flood

Не напрямую. SYN cookies защищают сторону, которая получает SYN и должна ответить SYN-ACK. Основная жертва reflection получает уже готовые SYN-ACK, которым не предшествовали её исходящие SYN.

Поэтому на стороне основной жертвы важны:

• проверка состояния SYN-SENT;
• раннее отбрасывание неожиданных SYN-ACK;
• защита от высокого PPS;
• upstream-фильтрация;
• достаточная пропускная способность.

Поможет ли WAF

WAF анализирует HTTP-запросы после установления TCP-соединения. SYN-ACK Flood не создаёт корректного соединения и не формирует HTTP-запрос.

Следовательно, обычный WAF не является основным средством защиты от такого потока. Нужны L3/L4-механизмы:

• stateful TCP validation;
• фильтрация пакетов вне состояния;
• контроль PPS;
• аппаратные ACL;
• Anti-DDoS провайдера;
• scrubbing.

Как TrafficVeil помогает защищать сайт

TrafficVeil полностью проксирует HTTP- и HTTPS-трафик, предоставляет собственный DNS, автоматический SSL, WAF, ML-детекцию ботов, rate limiting, мониторинг и L7 DDoS-защиту.

При корректной настройке реальный сервер принимает веб-трафик только от доверенных IPv4- и IPv6-адресов TrafficVeil. Это уменьшает поверхность прямой атаки и не позволяет постороннему клиенту обратиться к веб-сервису origin в обход прокси.

Но SYN-ACK Flood относится к сетевому и транспортному уровням. Если поток направлен на раскрытый IP origin и насыщает его канал, обратное проксирование HTTP/HTTPS не заменяет фильтрацию у провайдера.

Сценарий	Роль TrafficVeil	Что требуется дополнительно
SYN-ACK на публичный IP прокси	Инфраструктура прокси принимает веб-трафик вместо origin	L3/L4-защита самой прокси-сети
SYN-ACK на скрытый origin	ACL запрещает посторонний веб-трафик	Фильтрация пакетов и защита канала origin
Атака на раскрытый IP origin	Не может очистить уже заполненный канал до origin	Upstream Anti-DDoS или scrubbing
HTTP Flood после handshake	WAF, ML-анализ и rate limiting	Настройка правил под профиль сайта

Для полноценной защиты необходимо скрыть origin, закрыть прямой доступ к нему и иметь отдельный механизм очистки объёмного L3/L4-трафика.

Что делать во время SYN-ACK Flood

Шаг 1. Подтвердить комбинацию флагов

Проверьте, что основную часть потока составляют пакеты SYN-ACK, а не чистые ACK или RST.

Шаг 2. Сопоставить SYN и SYN-ACK

Определите, существовали ли исходящие SYN. Большое количество ответов без запросов является главным признаком атаки.

Шаг 3. Определить прямой или отражённый вариант

Проанализируйте исходные адреса, порты, TCP-опции и повторные передачи. Реальные серверные порты и характерные retransmission указывают на reflection.

Шаг 4. Найти точку перегрузки

Проверьте:

• внешний канал;
• маршрутизатор;
• firewall;
• conntrack;
• балансировщик;
• сетевой стек сервера.

Шаг 5. Отфильтровать пакеты вне состояния

Разрешайте входящие SYN-ACK только при наличии соответствующего исходящего SYN. Перед включением строгого правила убедитесь в симметричности маршрутизации.

Шаг 6. Подключить провайдера

Если локальная инфраструктура не справляется, передайте оператору:

• атакуемые IP-адреса;
• время начала;
• пиковые BPS и PPS;
• долю SYN-ACK;
• исходные и целевые порты;
• количество уникальных источников;
• NetFlow или IPFIX;
• ограниченный PCAP;
• описание легитимных исходящих TCP-соединений.

Шаг 7. Проверить дополнительные векторы

SYN-ACK Reflection может сопровождаться SYN Flood, ACK Flood, UDP Amplification и HTTP Flood. После подавления одного типа атаки проверьте остальные уровни.

Пример расследования

У сайта увеличилось время ответа, а часть пользователей перестала устанавливать HTTPS-соединения. На веб-сервере CPU оставался умеренным, но граничный firewall начал терять пакеты.

Анализ показал:

• резкий рост TCP PPS;
• преобладание SYN-ACK;
• отсутствие соответствующего количества исходящих SYN;
• тысячи источников с портами 80 и 443;
• разные TCP-опции и значения TTL;
• повторение SYN-ACK через определённые интервалы;
• рост исходящих RST;
• отсутствие роста HTTP-запросов.

Совокупность признаков указывает на SYN-ACK Reflection. Сторонние веб-серверы отвечают на поддельные SYN, в которых source IP заменён адресом жертвы.

Локальная блокировка пакетов вне SYN-SENT снизила нагрузку на сервер, но внешний канал оставался перегруженным. После включения upstream-очистки неожиданные SYN-ACK начали отбрасываться до канала организации.

Типичные ошибки при защите

Ошибка 1. Блокировать все SYN-ACK

Это нарушит установление легитимных исходящих TCP-соединений.

Ошибка 2. Фильтровать только по source port

Отражённые пакеты поступают с настоящих портов 80, 443 и других сервисов. Сам номер порта не доказывает легитимность.

Ошибка 3. Использовать только IP-blacklist

Источниками reflection могут быть легитимные серверы, а их набор быстро меняется.

Ошибка 4. Включать только SYN cookies

Они защищают сервер, получающий SYN, но не жертву, на которую уже направлены SYN-ACK.

Ошибка 5. Игнорировать retransmission

Повторные SYN-ACK создают продолжительный хвост трафика даже после завершения основной волны запросов.

Ошибка 6. Смотреть только на BPS

Небольшие пакеты могут перегрузить firewall высоким PPS при незаполненном канале.

Ошибка 7. Не учитывать асимметричную маршрутизацию

Firewall может не видеть исходящие SYN и ошибочно блокировать легитимные ответы.

Ошибка 8. Пытаться решить насыщение канала локальным firewall

Фильтр работает после прохождения трафика по внешней линии и не освобождает её.

Ошибка 9. Считать WAF защитой от всех DDoS

WAF не анализирует SYN-ACK, поскольку HTTP-сеанс ещё не создан.

Ошибка 10. Оставлять origin публичным

Раскрытый IP позволяет атаковать сервер напрямую в обход reverse proxy.

Чек-лист защиты от SYN-ACK Flood

• Известен нормальный уровень входящих SYN-ACK.
• Контролируются BPS и PPS.
• Измеряется отношение исходящих SYN к входящим SYN-ACK.
• Firewall отслеживает состояние SYN-SENT.
• Пакеты вне состояния отбрасываются.
• Проверена симметричность маршрутизации.
• Контролируются INVALID и packet drops.
• Отслеживается исходящий RST PPS.
• Закрыты неиспользуемые TCP-порты.
• Административные сервисы доступны только через VPN или ACL.
• Настроены эквивалентные правила IPv4 и IPv6.
• Origin скрыт от публичного доступа.
• HTTP/HTTPS на origin разрешены только от reverse proxy.
• Есть мониторинг утечки IP origin.
• Провайдер поддерживает upstream Anti-DDoS.
• Подготовлена процедура включения scrubbing.
• Сохраняются NetFlow или IPFIX.
• Определён безопасный порядок захвата PCAP.
• Сети организации применяют egress-антиспуфинг.
• План реагирования проверяется заранее.

Заключение

SYN-ACK Flood использует нормальный второй этап TCP-handshake для создания нежелательного потока в сторону жертвы. При прямой атаке пакеты формируются ботнетом, а при SYN-ACK Reflection сторонние серверы отвечают на SYN-запросы с поддельным IP.

Отражённый вариант не обеспечивает такого байтового усиления, как DNS или Memcached Amplification. Его сила заключается в распределённости, большом PPS и повторной передаче SYN-ACK при отсутствии завершающего ACK.

Основной признак атаки — большое количество входящих SYN-ACK, которым не соответствуют исходящие SYN. Защита должна проверять состояние SYN-SENT, удалять неожиданные ответы как можно раньше и учитывать производительность оборудования по PPS.

Если поток заполняет внешний канал, фильтрацию необходимо переносить в сеть провайдера или scrubbing-центр. Reverse proxy, WAF и скрытие origin дополняют защиту сайта, но не заменяют L3/L4 Anti-DDoS при объёмной TCP-атаке.