TCP Flood DDoS: как работает атака и как защитить сайт

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

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

Поэтому фразы «сайт атаковали TCP-флудом» недостаточно для выбора защиты. Необходимо определить:

• какие TCP-флаги преобладают;
• завершается ли трёхэтапное рукопожатие;
• подменяются ли исходные IP-адреса;
• создаётся ли состояние на firewall и сервере;
• передаются ли данные после установки соединения;
• что именно перегружается: канал, маршрутизатор, firewall, ядро ОС, reverse proxy или приложение.

Универсального фильтра для всех TCP Flood не существует. Защита должна соответствовать конкретному механизму атаки.

Что такое протокол TCP

TCP, или Transmission Control Protocol, — транспортный протокол, обеспечивающий надёжную и упорядоченную передачу данных между двумя узлами. TCP используется в работе HTTP/1.1, HTTP/2, HTTPS поверх TCP, SSH, SMTP, IMAP, баз данных и множества других сетевых сервисов.

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

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

Как устанавливается TCP-соединение

Стандартное соединение создаётся через трёхэтапное рукопожатие — TCP three-way handshake:

1. SYN. Клиент отправляет серверу запрос на установление соединения.
2. SYN-ACK. Сервер подтверждает запрос и сообщает собственные параметры соединения.
3. ACK. Клиент подтверждает ответ сервера, после чего соединение считается установленным.

Для легитимного клиента это короткий подготовительный этап. Для атакующего — возможность заставить сервер или промежуточное оборудование обрабатывать огромное число пакетов, создавать состояния и расходовать вычислительные ресурсы.

Этап	Направление	Основные флаги	Состояние сервера
1	Клиент → сервер	SYN	Получает запрос на соединение
2	Сервер → клиент	SYN, ACK	Ожидает завершающее подтверждение
3	Клиент → сервер	ACK	Переводит соединение в ESTABLISHED

Трёхэтапная схема SYN → SYN-ACK → ACK также используется в методиках тестирования сетевых устройств как базовый способ установки TCP-соединения.

Основные TCP-флаги

Флаг	Назначение	Как может использоваться при атаке
SYN	Начало соединения и синхронизация номеров последовательности	Создание множества полуоткрытых соединений
ACK	Подтверждение полученных данных	Перегрузка фильтрации, firewall и сетевого стека
RST	Немедленный сброс соединения	Поток фиктивных сбросов или попытки нарушить существующие сеансы
FIN	Штатное завершение передачи	Создание большого количества пакетов завершения
PSH	Указание быстрее передать данные приложению	Дополнительная нагрузка на обработку данных
URG	Обозначение срочных данных	Используется в аномальных комбинациях и для проверки реализации стека

Флаг сам по себе не делает пакет вредоносным. ACK, FIN и RST постоянно встречаются в обычном TCP-трафике. Атака определяется объёмом, частотой, контекстом, корректностью состояния и поведением источников.

Как работает TCP Flood

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

В зависимости от варианта атака может расходовать:

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

RFC 8782 приводит SYN Flood как пример атаки, направленной на исчерпание памяти, а ACK Flood — как пример нагрузки на процессор. Этот же документ отмечает, что атаки могут перегружать канал и таблицы состояний firewall.

Основные цели TCP Flood

1. Заполнение канала

При достаточно большом объёме трафик заполняет входящую полосу. Легитимные TCP-пакеты теряются или задерживаются ещё до того, как попадут на сервер.

2. Перегрузка по PPS

Небольшие пакеты могут не создавать рекордный трафик в битах в секунду, но формировать огромный показатель packets per second. Каждый пакет необходимо принять, разобрать, проверить и сопоставить с состоянием.

3. Исчерпание таблицы состояний

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

4. Перегрузка TCP-стека

Операционная система должна обрабатывать номера последовательности, окна, подтверждения, таймеры, повторные передачи и переходы между состояниями. Массовый поток аномальных пакетов увеличивает нагрузку на ядро.

5. Исчерпание ресурсов приложения

Если ботнет завершает handshake, соединение выглядит более легитимным. После его установки бот может медленно передавать данные, многократно создавать и закрывать сеансы либо отправлять запросы приложению.

Виды TCP Flood

SYN Flood

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

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

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

ACK Flood

При ACK Flood на цель поступает большое количество пакетов с установленным флагом ACK. Они могут не относиться к существующим TCP-соединениям.

Firewall и сетевой стек должны проверить каждый пакет: найти состояние, оценить номера последовательности и решить, пропустить, отклонить или ответить. При высокой скорости это создаёт значительную нагрузку на процессор и таблицу соединений.

SYN-ACK Flood

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

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

RST Flood

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

Современные реализации TCP должны строго проверять номера последовательности. RFC 5961 усиливает защиту от слепых атак с поддельными RST и SYN-пакетами.

FIN Flood

FIN означает нормальное завершение передачи данных одной из сторон. Массовые FIN-пакеты, не соответствующие состоянию соединений, создают нагрузку на проверку таблиц и TCP state machine.

PSH-ACK Flood

Комбинация PSH и ACK обычно встречается при передаче данных в установленном соединении. Во время атаки такие пакеты могут отправляться массово, в том числе вне корректного состояния.

Если фильтрация недостаточно строгая, трафик проходит глубже по сетевому стеку или до приложения, увеличивая стоимость обработки одного пакета.

TCP Connection Flood

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

Целью становятся:

• лимит одновременных соединений;
• файловые дескрипторы;
• воркеры веб-сервера;
• память балансировщика;
• соединения с upstream-серверами;
• TLS-рукопожатия;
• пулы базы данных.

TCP Reconnect Flood

Клиенты быстро устанавливают и закрывают соединения. Даже если количество одновременных подключений невелико, сервер постоянно выполняет дорогостоящие операции создания и удаления состояний.

При HTTPS дополнительно расходуются ресурсы на TLS, если соединения не переиспользуются.

TCP Data Flood

После корректного handshake бот передаёт большие объёмы данных либо часто обращается к ресурсоёмким операциям. На этом этапе граница между L4 TCP Flood и L7-атакой становится менее очевидной.

Mixed TCP Flood

В смешанной атаке одновременно используются SYN, ACK, RST, FIN, PSH-ACK и полноценные соединения. Это затрудняет создание простого правила и повышает риск блокировки легитимных пользователей.

Чем TCP Flood отличается от SYN Flood

Критерий	TCP Flood	SYN Flood
Значение термина	Общая категория TCP-атак	Конкретная атака SYN-пакетами
Флаги	Любые комбинации	Преимущественно SYN
Handshake	Может завершаться или не завершаться	Обычно не завершается
Главная цель	Канал, PPS, состояния, CPU или приложение	Очередь полуоткрытых соединений и TCP-стек
SYN cookies	Помогают только против части сценариев	Одна из основных мер защиты

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

Чем TCP Flood отличается от UDP Flood

Характеристика	TCP Flood	UDP Flood
Установление соединения	Предусмотрено TCP	Отсутствует
Состояние на сервере	Часто создаётся	Не требуется протоколом
Подмена адреса	Применима преимущественно к отдельным пакетным сценариям	Проще используется для отражения
Полноценный обмен	Требует получения ответов и корректных номеров	Может выполняться без ответа
Основная нагрузка	Состояния, CPU, соединения, канал	Канал, PPS и обработка дейтаграмм

Можно ли подменить IP-адрес при TCP Flood

Да, но эффективность зависит от сценария.

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

Поэтому TCP Connection Flood обычно создаётся ботнетом с реальными доступными IP-адресами. А SYN Flood может использовать как реальные, так и поддельные адреса.

Почему маленькие TCP-пакеты могут быть опаснее крупных

При DDoS важно измерять не только гигабиты в секунду. Большое количество минимальных пакетов создаёт высокий PPS.

Для каждого пакета оборудование выполняет ряд операций:

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

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

Какие компоненты инфраструктуры могут отказать первыми

Компонент	Признак перегрузки	Возможная причина
Канал провайдера	Потери до периметра организации	Слишком высокий BPS
Маршрутизатор	Рост CPU и packet drops	Высокий PPS
Stateful firewall	Заполнение conntrack или session table	Много новых потоков
Балансировщик	Ошибки соединения и рост очередей	Высокий CPS или concurrent connections
Операционная система	Переполнение backlog, рост softirq	SYN Flood или высокий PPS
Веб-сервер	Заканчиваются воркеры и дескрипторы	Connection Flood
Приложение	Увеличивается время ответа	Установленные соединения передают запросы
База данных	Исчерпан пул подключений	L7-нагрузка после установки TCP

Как определить TCP Flood

Для обнаружения необходимо сопоставлять сетевые и серверные показатели. Один график входящего трафика не показывает точный механизм атаки.

Основные сетевые признаки

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

Признаки на сервере

• рост состояний SYN_RECV;
• рост ESTABLISHED без соответствующей прикладной активности;
• увеличение TIME_WAIT;
• переполнение listen backlog;
• исчерпание файловых дескрипторов;
• рост softirq и system CPU;
• packet drops на интерфейсе;
• ошибки conntrack;
• рост retransmissions;
• увеличение времени установки соединения;
• ошибки 502, 503 и 504 на reverse proxy;
• при этом прикладные журналы могут содержать сравнительно мало HTTP-запросов.

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

Метрика	Что показывает
Bits per second	Степень загрузки канала
Packets per second	Нагрузку на обработку пакетов
Connections per second	Интенсивность создания соединений
Concurrent connections	Общее количество одновременных сеансов
SYN/SYN-ACK/ACK ratio	Насколько корректно завершается handshake
SYN_RECV	Число полуоткрытых соединений
RST rate	Количество сбросов соединений
FIN rate	Интенсивность завершения сеансов
Connection duration	Выявляет слишком короткие или зависшие соединения
Bytes per connection	Помогает найти соединения без полезной нагрузки
Firewall table usage	Риск исчерпания таблицы состояний
Retransmissions	Потери, перегрузку и нарушение нормального обмена

Как отличить TCP Flood от обычного роста посещаемости

Признак	Обычный рост трафика	TCP Flood
Handshake	Большинство соединений успешно устанавливается	Может массово не завершаться
HTTP-запросы	Растут вместе с TCP-соединениями	Могут почти не расти
Полезные данные	Передаются страницы, API и файлы	Много соединений без полезной нагрузки
Поведение	Соответствует пользовательским сценариям	Однотипное и высокочастотное
TCP-флаги	Сбалансированная последовательность	Преобладает один флаг или аномальная комбинация
Продолжительность	Соответствует работе сайта	Много сверхкоротких или зависших соединений
Конверсия	Растут просмотры и действия пользователей	Бизнес-показатели не растут

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

Защита от TCP Flood на сетевом уровне

1. Фильтрация вне инфраструктуры

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

Фильтрация рядом с сервером не освобождает уже заполненный внешний канал.

2. Stateless ACL

Простые ACL могут отбрасывать явно нежелательные пакеты с меньшей стоимостью, чем stateful firewall. Однако слишком общие правила способны нарушить легитимные соединения.

3. Stateful inspection

Firewall проверяет, соответствует ли пакет существующему соединению и допустимому переходу TCP state machine. Это помогает против неожиданных ACK, SYN-ACK, RST и FIN.

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

4. SYN proxy

SYN proxy завершает начальный handshake с клиентом до передачи соединения защищаемому серверу. Источник должен доказать, что способен получить ответ на указанный IP-адрес.

Это снижает нагрузку от поддельных SYN, но защитное устройство само должно выдерживать высокий PPS и количество новых соединений.

5. SYN cookies

При использовании SYN cookies сервер не сохраняет полное состояние после первого SYN. Необходимая информация кодируется в начальном номере последовательности SYN-ACK и восстанавливается после получения корректного ACK.

Это уменьшает риск заполнения очереди полуоткрытых соединений, но не устраняет нагрузку на канал и обработку пакетов. Также SYN cookies не являются универсальной защитой от остальных вариантов TCP Flood.

6. Rate limiting

Можно ограничивать:

• SYN в секунду;
• новые соединения с одного адреса;
• одновременные соединения на источник;
• RST и FIN в секунду;
• соединения на конкретный порт;
• скорость создания потоков из одной подсети или ASN.

Статический лимит не должен быть ниже легитимных пиков. Для NAT-сетей множество пользователей могут иметь один публичный IP-адрес.

7. Фильтрация пакетов с некорректными флагами

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

Защита сервера и операционной системы

Настройка очередей соединений

Размеры listen backlog и SYN backlog должны соответствовать профилю нагрузки. Увеличение очереди даёт запас, но само по себе не останавливает атаку: при достаточном потоке заполнится и большая очередь.

Сокращение тайм-аутов

Неактивные и полуоткрытые состояния не должны храниться дольше необходимого. Чрезмерно агрессивное сокращение тайм-аутов может разрывать соединения мобильных пользователей и клиентов с высокой задержкой.

Контроль conntrack

Если используется stateful-фильтрация, необходимо отслеживать:

• текущий размер таблицы;
• максимальный лимит;
• скорость создания и удаления записей;
• число ошибок вставки;
• распределение записей по состояниям;
• потребление памяти.

Лимиты файловых дескрипторов

Полноценные соединения используют сокеты и файловые дескрипторы. Лимиты должны быть согласованы между операционной системой, reverse proxy, веб-сервером и менеджером процессов.

Переиспользование соединений

Keep-alive уменьшает количество повторных TCP- и TLS-рукопожатий для легитимных клиентов. Но чрезмерно длительный keep-alive позволяет большому числу неактивных клиентов удерживать ресурсы. Требуется баланс.

Защита reverse proxy и веб-сервера

• ограничивать число соединений с одного адреса;
• задавать тайм-аут чтения заголовков и тела запроса;
• ограничивать время простоя keep-alive;
• задавать максимальный размер заголовков и тела;
• разделять лимиты для статических файлов и динамических обработчиков;
• не передавать каждое входящее соединение непосредственно приложению;
• использовать очереди и circuit breaker для upstream;
• контролировать пулы соединений с базой данных;
• кэшировать безопасные ответы;
• отключать неиспользуемые внешние TCP-сервисы.

Почему блокировка отдельных IP-адресов часто не помогает

Современный DDoS может поступать от десятков тысяч заражённых устройств. Ручное добавление IP-адресов в blacklist не успевает за изменением источников.

Кроме того:

• часть адресов может принадлежать реальным домашним пользователям;
• один адрес за NAT может представлять много клиентов;
• ботнет может менять адреса и автономные системы;
• при подмене source IP блокируются случайные непричастные адреса;
• большой blacklist сам увеличивает стоимость фильтрации.

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

Что делать во время TCP Flood

Шаг 1. Определить масштаб

Зафиксируйте BPS, PPS, CPS, число одновременных соединений и заполнение таблиц состояний. Сравните значения с нормальным профилем.

Шаг 2. Определить преобладающие флаги

Разделите трафик на SYN, SYN-ACK, ACK, RST, FIN и PSH-ACK. Проверьте, корректна ли последовательность handshake.

Шаг 3. Найти точку отказа

Определите, перегружены ли канал, маршрутизатор, firewall, ядро ОС, reverse proxy или приложение. От этого зависит место фильтрации.

Шаг 4. Применить точечные меры

• при SYN Flood активировать SYN cookies или SYN proxy;
• для пакетов вне состояния усилить stateful-проверку;
• ограничить явно аномальную скорость новых соединений;
• сократить завышенные тайм-ауты;
• отключить неиспользуемые порты;
• защитить upstream и базу данных от каскадной перегрузки.

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

Если канал близок к насыщению, локальные меры уже недостаточны. Провайдеру следует передать атакуемый адрес, время начала, BPS, PPS, флаги, порты, NetFlow и образец PCAP.

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

После фильтрации грубого TCP-потока убедитесь, что ботнет не продолжает атаку через полноценные HTTPS-соединения и HTTP-запросы.

Шаг 7. Сохранить материалы инцидента

Сохраните сетевые дампы, Flow-данные, системные метрики, журналы firewall, временную шкалу изменений и действия провайдера.

Как TrafficVeil помогает при TCP Flood

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

Если origin-сервер принимает веб-соединения только от доверенных IPv4- и IPv6-адресов TrafficVeil, атакующему сложнее направить TCP-соединения непосредственно на веб-сервер. Публичные DNS-записи при этом не должны раскрывать IP origin.

Но защита зависит от уровня атаки:

Сценарий	Роль TrafficVeil	Что требуется дополнительно
HTTP Flood через полноценные соединения	WAF, ML-анализ, rate limiting, L7-фильтрация	Корректные правила и профиль трафика
Прямой TCP Flood на скрытый origin	Снижает доступность origin для посторонних адресов	Firewall с разрешением только адресов TrafficVeil
Атака на раскрытый IP origin	Не может освободить насыщенный канал до origin	Upstream Anti-DDoS или scrubbing
TCP Flood на незащищённый SSH, почту или БД	Не проксирует произвольные TCP-сервисы	VPN, ACL и сетевая Anti-DDoS-защита

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

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

Ошибка 1. Считать любой TCP Flood SYN Flood

При ACK Flood, RST Flood или потоке установленных соединений SYN cookies не решат основную проблему.

Ошибка 2. Смотреть только на гигабиты

Устройство может отказать из-за PPS или CPS, даже если канал не заполнен.

Ошибка 3. Разрешать TCP-пакеты только по флагу ACK

Наличие ACK не доказывает существование соединения. Необходима проверка состояния.

Ошибка 4. Увеличивать лимиты без мониторинга

Увеличенная таблица conntrack или backlog потребляет дополнительную память и лишь отодвигает момент исчерпания.

Ошибка 5. Блокировать крупные подсети

Это может остановить атаку ценой недоступности сайта для реальных пользователей.

Ошибка 6. Фильтровать только на сервере

Если внешний канал заполнен, серверные правила не восстановят связь.

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

Атакующий может обойти reverse proxy и направить TCP Flood непосредственно на сервер.

Ошибка 8. Не учитывать IPv6

Закрытый по IPv4 origin может оставаться доступным по IPv6.

Ошибка 9. Не различать TCP и L7-нагрузку

Если соединения успешно устанавливаются и передают HTTP-запросы, одной сетевой фильтрации недостаточно.

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

• Определены публично необходимые TCP-порты.
• Остальные сервисы закрыты ACL или доступны через VPN.
• Origin не раскрывается в DNS и служебных записях.
• Веб-доступ к origin разрешён только от reverse proxy.
• Правила настроены одинаково для IPv4 и IPv6.
• Контролируются BPS, PPS, CPS и concurrent connections.
• Отслеживается заполнение conntrack и firewall session table.
• Настроены алерты по SYN_RECV и backlog.
• Проверена работа SYN cookies или SYN proxy.
• Установлены обоснованные тайм-ауты.
• Ограничено количество соединений с одного источника.
• Учтены пользователи за NAT и мобильные сети.
• Reverse proxy защищает приложение от избытка соединений.
• Есть лимиты на upstream и базу данных.
• Провайдер предоставляет L3/L4 Anti-DDoS или scrubbing.
• Известна процедура экстренной активации защиты.
• Регулярно сохраняются NetFlow или IPFIX.
• Подготовлен безопасный процесс захвата PCAP.
• Проводится разбор каждого инцидента.

Заключение

TCP Flood — широкая категория атак, использующих особенности TCP и необходимость обработки состояния соединений. Атака может состоять из SYN, ACK, RST, FIN, PSH-ACK, полноценных соединений или комбинации нескольких вариантов.

Ключевая задача при реагировании — определить не только протокол, но и механизм перегрузки. Нужно понимать, заполнен ли канал, исчерпана ли таблица состояний, переполнен ли SYN backlog или нагрузка уже дошла до приложения.

Эффективная защита строится на нескольких уровнях: фильтрация у провайдера, производительное граничное оборудование, stateful-проверка, SYN proxy или SYN cookies, безопасные лимиты, защита reverse proxy и изоляция origin-сервера.

Если атака переходит на уровень полноценных HTTPS-соединений и запросов, сетевые средства необходимо дополнять WAF, анализом поведения, обнаружением ботов и адаптивным rate limiting.