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

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

В нормальном TCP-соединении ACK подтверждает полученные данные, а PSH указывает на желание отправителя не задерживать текущую порцию данных ради дополнительного накопления. Комбинация PSH-ACK постоянно встречается в легитимном веб-трафике, API, SSH, базах данных, мессенджерах и других интерактивных протоколах.

Поэтому наличие флагов PSH и ACK само по себе не является признаком атаки. Для обнаружения PSH-ACK Flood необходимо учитывать:

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

PSH-ACK Flood может быть простым потоком пакетов вне состояния или атакой через полноценные TCP-соединения. Во втором случае трафик проходит значительно глубже и способен нагружать reverse proxy, TLS, веб-сервер и приложение.

Что означает флаг PSH

PSH расшифровывается как push. Он связан с push function TCP — механизмом, позволяющим приложению обозначить, что текущую порцию данных желательно передать без неопределённой задержки ради последующей агрегации.

В упрощённом объяснении часто пишут: «PSH заставляет сервер немедленно передать пакет приложению». Это неточно.

RFC 9293 устанавливает несколько важных нюансов:

• отправитель использует PSH в последнем TCP-сегменте, сформированном из передаваемого буфера;
• PSH не является границей сообщения или записи прикладного протокола;
• принимающая TCP-реализация может передать приложению информацию о PSH, но не обязана это делать;
• поведение буферизации зависит от реализации TCP и интерфейса приложения;
• PSH не отменяет проверку состояния, sequence number и целостности TCP.

RFC 9293 прямо указывает, что получатель может передать приложению признак PUSH, но это не является обязательным требованием. Следовательно, утверждение, что любой PSH всегда вызывает немедленный отдельный вызов приложения, неверно.

Что означает флаг ACK

ACK показывает, что поле acknowledgment number имеет значение. Оно сообщает, какой следующий байт ожидает получить отправитель ACK.

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

• подтверждать ранее полученные данные;
• передавать собственную полезную нагрузку;
• обновлять receive window;
• содержать PSH;
• содержать FIN или другие допустимые флаги.

Поэтому PSH-ACK — обычная комбинация внутри установленного соединения.

Как выглядит нормальный PSH-ACK

Предположим, клиент установил HTTPS-соединение и передаёт зашифрованную часть HTTP-запроса. TCP-пакет может иметь:

• флаг ACK для подтверждения ранее полученных данных сервера;
• флаг PSH в последнем сегменте текущего буфера;
• TLS-запись в качестве полезной нагрузки;
• корректный sequence number;
• корректный acknowledgment number;
• размер, соответствующий MSS и условиям сети.

Такой пакет полностью легитимен. Блокировка всех PSH-ACK сделает недоступными многочисленные TCP-приложения.

PSH не является границей прикладного сообщения

TCP передаёт поток байтов, а не отдельные сообщения. Флаг PSH не превращает TCP-сегмент в самостоятельный HTTP-запрос, команду базы данных или сообщение WebSocket.

Один прикладной запрос может:

• помещаться в один TCP-сегмент;
• разделяться между несколькими сегментами;
• объединяться с частью следующего сообщения;
• передаваться с PSH только в последнем сегменте;
• обрабатываться без передачи признака PSH приложению.

RFC 9293 подчёркивает, что PSH не является record marker и не привязан к границам TCP-сегментов.

Почему название PUSH-ACK не совсем точное

В TCP-заголовке флаг называется PSH. Термин PUSH описывает функцию протокола. Поэтому технически точнее использовать название PSH-ACK Flood.

Однако в материалах Anti-DDoS и интерфейсах оборудования встречаются оба варианта:

• PSH Flood;
• PSH-ACK Flood;
• PUSH Flood;
• PUSH-ACK Flood;
• TCP PSH Flood.

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

Как работает PSH-ACK Flood

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

Вариант 1. PSH-ACK вне состояния

Пакеты не относятся к установленным TCP-сессиям. Атакующий может менять:

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

Stateful firewall или TCP-стек не находит соответствующего соединения и должен отбросить пакет. Основная цель — создать высокий PPS и нагрузку на проверку состояния.

Вариант 2. PSH-ACK внутри реальных соединений

Бот завершает TCP-handshake и передаёт данные через действующий сеанс. Пакеты проходят проверку stateful firewall и доходят до reverse proxy или приложения.

Этот сценарий способен нагружать:

• таблицу установленных соединений;
• TLS-обработку;
• буферы чтения;
• event loop;
• воркеры веб-сервера;
• парсер протокола;
• WAF;
• приложение;
• базу данных и внутренние API.

Вариант 3. PSH-ACK с минимальной полезной нагрузкой

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

Такой трафик не обязательно эффективен во всех системах. Современные сетевые стеки применяют offloading, coalescing, буферизацию и пакетную обработку. Реальное влияние зависит от архитектуры.

Вариант 4. PSH-ACK с крупной полезной нагрузкой

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

Вариант 5. Смешанный TCP Flood

PSH-ACK комбинируется с SYN, ACK, RST, FIN и другими пакетами. Это усложняет фильтрацию и создаёт нагрузку на несколько состояний TCP.

Что происходит с PSH-ACK вне соединения

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

Типичная последовательность обработки:

1. Интерфейс принимает пакет.
2. Маршрутизатор или firewall применяет ACL.
3. Stateful-система ищет запись соединения.
4. Пакет классифицируется как не соответствующий состоянию.
5. Он отбрасывается либо вызывает предусмотренную TCP-реакцию.
6. Полезная нагрузка не передаётся веб-приложению.

В таком сценарии флаг PSH не «пробивает» TCP и не заставляет приложение обработать произвольные данные. Атака остаётся преимущественно на L3/L4.

Что происходит внутри установленного соединения

Если handshake выполнен, пакет проходит следующие проверки:

• соответствие адресов и портов;
• текущее состояние соединения;
• sequence number;
• acknowledgment number;
• receive window;
• TCP checksum;
• порядок и возможные дубликаты данных.

После успешной проверки данные помещаются в receive buffer и становятся доступными приложению согласно поведению TCP-стека и модели ввода-вывода.

Только в этом случае PSH-ACK Flood может перейти из пакетной атаки в атаку на приложение.

Правда ли, что PSH заставляет процессор срочно обработать пакет

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

Пакет всё равно проходит обычные этапы:

• обработку сетевой картой;
• очереди приема;
• IP- и TCP-проверки;
• stateful inspection;
• проверку sequence number;
• сборку потока;
• буферизацию;
• планирование приложения.

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

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

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

Крупный поток заполняет внешний канал. Легитимный трафик теряется ещё до защитного сервера.

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

Большое количество маленьких PSH-ACK создаёт высокий PPS. Маршрутизатор или firewall может достичь своего лимита обработки.

Stateful firewall

Для каждого пакета необходимо найти соединение и проверить допустимость ACK, PSH, sequence number и размера данных.

Conntrack

Пакеты вне состояния создают операции поиска, а полноценные соединения занимают записи в таблице.

TCP-стек

Ядро выполняет проверку, сборку потока, обработку дубликатов, управление receive window и передачу данных сокету.

Reverse proxy

Прокси должен читать данные, обрабатывать TLS, собирать HTTP-запросы, применять ограничения и решать, передавать ли запрос origin.

Приложение

Если пакет содержит корректные прикладные данные, нагрузка зависит от операции: простой статический запрос значительно дешевле сложного поиска, генерации отчёта или обращения к базе данных.

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

Критерий	ACK Flood	PSH-ACK Flood
Флаги	ACK	PSH и ACK
Полезная нагрузка	Может отсутствовать	Часто присутствует, но не обязательна
Основная цель вне состояния	Проверка state table	Проверка state table и обработка данных
Влияние внутри соединения	Подтверждение TCP-данных	Передача данных с признаком PUSH
Вероятность достижения приложения	Низкая без данных	Выше при корректной установленной сессии

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

Критерий	PSH-ACK Flood	HTTP Flood
Уровень	TCP, иногда с переходом на приложение	HTTP/HTTPS
Обязательный handshake	Не обязателен для пакетного флуда	Требуется рабочее транспортное соединение
Корректный HTTP	Не обязателен	Обычно присутствует
Основная метрика	PPS, BPS, потоки и соединения	Requests per second и стоимость запроса
Основная защита	L3/L4-фильтрация и state validation	WAF, анализ поведения и rate limiting

Одна атака может сочетать оба механизма. Бот устанавливает TCP-соединение, отправляет PSH-ACK с TLS-данными, а после расшифровки внутри оказывается HTTP Flood.

PSH-ACK Flood и TCP Connection Flood

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

PSH-ACK Flood внутри установленных соединений может быть вторым этапом:

1. бот создаёт TCP-сессию;
2. при HTTPS выполняет TLS-handshake;
3. отправляет данные PSH-ACK-пакетами;
4. повторяет операцию с высокой частотой;
5. удерживает либо закрывает соединение.

В таком сценарии защита по отдельному TCP-флагу малоэффективна. Требуется анализ поведения соединения и прикладного протокола.

PSH-ACK Flood и Small Packet Attack

Если бот передаёт множество минимальных сегментов, атаке могут присвоить дополнительную классификацию small packet flood.

Стоимость возникает из-за того, что одинаковый объём данных разбит на большее количество операций:

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

Однако современные механизмы GRO, LRO и interrupt coalescing могут объединять часть обработки. Поэтому реальное воздействие зависит от оборудования, драйвера, ядра и места захвата трафика.

Может ли PSH-ACK использовать IP spoofing

Да, если пакеты не должны участвовать в полноценном двустороннем обмене. Для потока вне состояния атакующий может подменять source IP при отсутствии egress-фильтрации.

Но для установленного соединения необходимо:

• получить SYN-ACK;
• завершить handshake;
• знать номера последовательности;
• получать подтверждения;
• поддерживать состояние сессии.

Поэтому PSH-ACK Flood на прикладном уровне чаще поступает от ботнета с реальными доступными адресами, прокси или скомпрометированных устройств.

Может ли атака быть отражённой

Классический PSH-ACK Flood является прямой атакой. Произвольный PSH-ACK вне соединения не заставляет сервер отправить крупный ответ.

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

PSH-ACK не относится к классическим высокоэффективным amplification-протоколам.

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

Признаки пакетного PSH-ACK Flood:

• резкий рост PSH-ACK PPS;
• много пакетов без предшествующего handshake;
• высокая доля INVALID;
• случайные sequence и acknowledgment number;
• однотипный размер пакетов;
• большое количество уникальных потоков;
• аномальные source IP или source port;
• рост ответных RST;
• нагрузка firewall при отсутствии роста HTTP-запросов;
• packet drops на интерфейсах.

Признаки атаки внутри соединений:

• рост успешно установленных TCP-сессий;
• высокий connections per second;
• большое число короткоживущих соединений;
• малое количество байтов на соединение;
• частые события чтения;
• рост TLS-handshake;
• увеличение HTTP-запросов;
• однотипное поведение множества клиентов;
• рост нагрузки приложения и upstream;
• ухудшение бизнес-метрик при росте технического трафика.

Как отличить атаку от легитимного PSH-ACK

Признак	Легитимный трафик	PSH-ACK Flood
TCP-состояние	Пакет относится к сессии	Часто состояния нет
Sequence number	Попадает в окно	Может быть случайным
Прикладные данные	Соответствуют протоколу	Отсутствуют, повреждены или однотипны
Частота	Связана с реальной активностью	Резко превышает базовый уровень
Распределение размеров	Разнообразное	Часто преобладает один размер
Поведение клиентов	Различается	Синхронное или шаблонное
Бизнес-результат	Есть просмотры и действия	Нагрузка растёт без полезных действий

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

При легитимном росте обычно одновременно увеличиваются:

• корректные TCP-соединения;
• валидные TLS-сессии;
• HTTP-запросы;
• просмотры страниц;
• переданные байты;
• пользовательские действия;
• разнообразие запрашиваемых ресурсов.

При атаке часто наблюдается дисбаланс: TCP PPS растёт в десятки раз, а валидных HTTP-запросов, сессий и конверсий почти не прибавляется.

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

Как анализировать атаку в PCAP

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

• флаги PSH и ACK;
• наличие SYN, SYN-ACK и завершающего ACK;
• соответствие адресов и портов;
• sequence number;
• acknowledgment number;
• размер TCP-окна;
• длину payload;
• TCP checksum;
• повторные передачи;
• out-of-order и duplicate ACK;
• ответные RST;
• содержимое незашифрованного прикладного протокола;
• структуру TLS-записей при HTTPS без их расшифровки.

Нельзя классифицировать поток только по фильтру PSH-ACK. Нужно определить, принадлежит ли пакет реальной сессии и что происходит до и после него.

Какие метрики нужно контролировать

• общий TCP PPS;
• PSH-ACK PPS;
• BPS PSH-ACK-трафика;
• средний размер пакета;
• connections per second;
• одновременные соединения;
• PSH-ACK без состояния;
• долю INVALID;
• bytes per connection;
• packets per connection;
• connection duration;
• заполнение conntrack;
• CPU firewall и маршрутизатора;
• softirq на сервере;
• packet drops;
• TLS-handshake в секунду;
• HTTP requests per second;
• ошибки reverse proxy;
• нагрузку на приложение и базу данных.

Почему NetFlow недостаточно

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

Но агрегированный поток не всегда позволяет понять:

• в каком порядке были установлены флаги;
• был ли корректный handshake;
• какие пакеты содержали payload;
• соответствовали ли sequence number TCP-окну;
• какой прикладной протокол передавался;
• были ли пакеты повторными.

Для точной диагностики NetFlow следует сочетать с PCAP, conntrack, логами firewall, reverse proxy и приложения.

Почему высокий PSH-ACK может быть нормой

Доля PSH-ACK зависит от:

• операционной системы;
• TCP-реализации;
• модели записи приложения в сокет;
• размера прикладных сообщений;
• Nagle algorithm;
• TCP_CORK и аналогичных механизмов;
• сегментации и offloading;
• места захвата трафика;
• HTTP-версии;
• используемого TLS-стека.

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

Как offloading влияет на анализ

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

• TCP Segmentation Offload;
• Generic Segmentation Offload;
• Generic Receive Offload;
• Large Receive Offload;
• interrupt moderation.

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

При серьёзном расследовании полезно сравнить дампы:

• на внешнем интерфейсе;
• до и после firewall;
• на балансировщике;
• на конечном сервере;
• на SPAN-порту или сетевом TAP.

Защита от PSH-ACK вне состояния

1. Stateful TCP validation

PSH-ACK должен пропускаться только при наличии допустимого установленного соединения. Пакеты вне state table следует отбрасывать.

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

2. Ранняя фильтрация

Очевидно недействительные пакеты желательно удалять до:

• основной state table;
• IDS/IPS с глубокой проверкой;
• NAT;
• балансировщика;
• TLS-терминации;
• конечного сервера.

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

Если серверу нужны только TCP/80 и TCP/443, остальные публичные порты следует закрыть на внешней границе.

4. Фильтрация невозможных комбинаций

Некоторые сочетания флагов не соответствуют нормальному TCP-поведению. Их можно отбрасывать после проверки совместимости с реальным трафиком.

Саму комбинацию PSH-ACK блокировать нельзя — она легитимна.

5. Контроль PPS

Необходимо оценивать производительность маршрутизатора, firewall и балансировщика по минимальным пакетам, а не только по гигабитам.

6. Upstream Anti-DDoS

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

Защита от PSH-ACK внутри соединений

Ограничение новых соединений

Контролируются:

• connections per second на IP;
• одновременные соединения;
• доля соединений без полезных запросов;
• частота повторных подключений;
• распределение по подсетям и ASN.

Ограничение малополезных потоков

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

Настройка тайм-аутов

Следует ограничить:

• время передачи заголовков;
• время передачи тела;
• простой keep-alive;
• время ожидания upstream;
• длительность соединения без прогресса.

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

Минимальная скорость передачи

Некоторые reverse proxy позволяют разрывать соединения, которые слишком долго передают данные без достаточного прогресса. Это помогает против медленных вариантов, но не против высокоскоростного флуда.

Буферизация

Reverse proxy может полностью принять и проверить запрос до передачи origin. Это защищает приложение от медленного или повреждённого потока, но требует памяти на стороне прокси.

Защита приложения

Необходимо:

• ограничивать стоимость операций;
• использовать очереди;
• защищать пулы базы данных;
• применять circuit breaker;
• кэшировать безопасные ответы;
• делать тяжёлые операции асинхронными;
• задавать лимиты на пользователя и токен;
• не доверять одному IP как идентификатору.

Можно ли блокировать PSH

Полная блокировка PSH недопустима для обычного веб-сервиса. Это нарушит легитимные TCP-потоки и может привести к непредсказуемому поведению приложений.

Безопаснее использовать условия:

• PSH-ACK вне установленного состояния;
• недопустимый sequence number;
• пакет на закрытый порт;
• невозможная комбинация флагов;
• аномальный PPS;
• подозрительное поведение полноценного соединения;
• невалидный прикладной протокол.

Помогают ли SYN cookies

SYN cookies защищают очередь полуоткрытых соединений при SYN Flood. Они не фильтруют PSH-ACK внутри установленных сессий.

Если PSH-ACK поступает вне состояния, stateful firewall должен удалить его независимо от SYN cookies.

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

Поможет ли WAF

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

Вариант	Поможет ли WAF
PSH-ACK вне TCP-состояния	Нет, пакет не формирует HTTP-запрос
Повреждённые данные внутри соединения	Частично, если данные доходят до HTTP-парсера
Корректный HTTP Flood	Да, при наличии подходящих правил и анализа поведения
Объёмное насыщение канала	Нет, требуется upstream-фильтрация

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

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

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

Роль TrafficVeil зависит от глубины атаки:

Сценарий	Роль TrafficVeil	Дополнительная защита
PSH-ACK вне состояния	Не относится к HTTP-анализу WAF	L3/L4-фильтрация и защита по PPS
Корректные HTTPS-соединения ботов	ML-анализ, rate limiting и WAF	Поведенческие правила под сайт
Прямая атака на origin	ACL снижает доступность origin для посторонних	Разрешить только адреса TrafficVeil
Насыщение канала origin	Не освобождает канал до дата-центра	Anti-DDoS провайдера или scrubbing

Reverse proxy отделяет клиентские соединения от upstream-соединений с origin. Это полезно: массовое поведение клиентов не должно автоматически создавать такое же количество прямых соединений с приложением.

Но для объёмной атаки на известный IP origin требуется отдельная сетевая Anti-DDoS-защита.

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

Шаг 1. Определить, существует ли TCP-состояние

Разделите поток на пакеты вне состояния и пакеты внутри установленных соединений. Это главный выбор между L3/L4- и L7-реагированием.

Шаг 2. Измерить PPS, BPS и CPS

Не ограничивайтесь трафиком в гигабитах. Проверьте количество пакетов, новых соединений и одновременных сессий.

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

Проверьте:

• внешний канал;
• маршрутизатор;
• firewall;
• conntrack;
• балансировщик;
• TLS-терминатор;
• reverse proxy;
• приложение;
• базу данных.

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

Очевидно недействительные PSH-ACK следует фильтровать как можно ближе к границе сети.

Шаг 5. Ограничить вредоносные соединения

Если боты завершают handshake, применяйте ограничения по поведению, частоте запросов, соединениям, TLS fingerprint, ASN и другим сигналам.

Шаг 6. Защитить origin

Убедитесь, что HTTP/HTTPS доступны только от доверенной прокси-инфраструктуры и реальный IP не раскрывается через DNS, почту, старые записи или поддомены.

Шаг 7. Подключить upstream-защиту

Если канал или граничное оборудование перегружены, передайте провайдеру:

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

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

Сайт начинает медленно отвечать, а CPU граничного firewall достигает критического уровня. При этом количество запросов в журналах веб-сервера почти не меняется.

Анализ показывает:

• резкий рост небольших PSH-ACK-пакетов;
• высокий PPS при умеренном BPS;
• большинство пакетов не соответствует conntrack;
• sequence number имеют случайный характер;
• целевым является TCP/443;
• растёт количество INVALID и ответных RST;
• до reverse proxy доходит лишь небольшая часть потока.

Это пакетный PSH-ACK Flood на L4. Флаг PSH не заставляет веб-приложение обработать данные: атака перегружает stateful firewall раньше уровня HTTP.

После переноса фильтрации пакетов вне состояния на upstream-площадку нагрузка на локальный firewall снижается. Веб-трафик восстанавливается без изменений в WAF, поскольку исходная проблема находилась ниже прикладного уровня.

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

Ошибка 1. Считать любой PSH-ACK атакой

Эта комбинация широко используется в обычных TCP-соединениях.

Ошибка 2. Утверждать, что PSH всегда немедленно вызывает приложение

RFC не требует от всех получателей передавать приложению отдельную PUSH-индикацию.

Ошибка 3. Блокировать весь PSH

Это нарушит нормальный веб-трафик, API, SSH и другие TCP-протоколы.

Ошибка 4. Считать PSH границей сообщения

TCP передаёт поток байтов, а не записи прикладного протокола.

Ошибка 5. Использовать только SYN cookies

Они не фильтруют PSH-ACK внутри установленных соединений.

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

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

Ошибка 7. Считать любой payload прикладной атакой

Данные вне существующего TCP-соединения обычно не передаются приложению.

Ошибка 8. Полагаться только на WAF

WAF не видит пакеты, которые не сформировали корректный HTTP-запрос.

Ошибка 9. Игнорировать offloading

Дамп на сервере может не совпадать с фактической сегментацией пакетов на линии.

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

Злоумышленник сможет обойти reverse proxy и атаковать сервер на L3/L4.

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

• Определён нормальный уровень PSH-ACK PPS.
• Контролируются BPS, PPS и CPS.
• Разделяются пакеты вне состояния и внутри соединений.
• Firewall видит оба направления трафика.
• Пакеты вне state table отбрасываются.
• Проверяются sequence и acknowledgment number.
• Закрыты неиспользуемые TCP-порты.
• Настроена фильтрация невозможных флагов.
• Не блокируется вся комбинация PSH-ACK.
• Контролируется заполнение conntrack.
• Отслеживаются bytes и packets per connection.
• Контролируется длительность соединений.
• Настроены обоснованные тайм-ауты.
• Reverse proxy буферизует и проверяет запросы.
• Применяется rate limiting на прикладном уровне.
• Origin принимает трафик только от reverse proxy.
• Правила охватывают IPv4 и IPv6.
• Есть защита от IP spoofing.
• Провайдер поддерживает L3/L4 Anti-DDoS.
• Подготовлен процесс сбора PCAP и NetFlow.

Заключение

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

При PSH-ACK Flood вне состояния основной целью становятся канал, PPS, firewall, conntrack и сетевой стек. Пакеты не проходят проверку TCP и обычно не достигают веб-приложения.

Если ботнет завершает handshake и передаёт корректные данные, атака способна перейти на прикладной уровень. Тогда к сетевой фильтрации необходимо добавить защиту соединений, TLS, HTTP, reverse proxy, приложения и базы данных.

Эффективная стратегия не блокирует все PSH-ACK, а разделяет трафик по состоянию и поведению. Недействительные пакеты удаляются на L3/L4, а рабочие соединения анализируются с помощью WAF, обнаружения ботов и адаптивного rate limiting.

Скрытие origin за TrafficVeil уменьшает поверхность прямой атаки, однако объёмный поток на известный IP и насыщение канала требуют отдельной upstream Anti-DDoS-защиты.