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

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

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

Главная опасность ACK Flood заключается не в самом флаге ACK, а в стоимости проверки огромного количества пакетов. Атака может:

• перегрузить процессор firewall или маршрутизатора;
• создать высокий показатель packets per second;
• заполнить канал связи;
• перегрузить таблицу отслеживания соединений;
• увеличить нагрузку на TCP-стек операционной системы;
• вызвать потери пакетов в очередях сетевых интерфейсов;
• нарушить работу легитимных HTTP- и HTTPS-соединений;
• замаскировать другие векторы многовекторной DDoS-атаки.

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

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

ACK расшифровывается как acknowledgment — подтверждение. Установленный флаг показывает, что поле acknowledgment number TCP-заголовка имеет значение и должно учитываться принимающей стороной.

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

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

Простой пример легитимного ACK

Клиент получил от сервера определённый диапазон байтов. В следующем TCP-пакете клиент указывает номер следующего ожидаемого байта и устанавливает флаг ACK. Сервер понимает, какие данные успешно доставлены и какие данные можно удалить из очереди повторной передачи.

ACK участвует в следующих процессах:

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

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

Где ACK появляется в TCP-соединении

Установка соединения

1. Клиент отправляет SYN.
2. Сервер возвращает SYN-ACK.
3. Клиент отправляет ACK.

Третий пакет завершает handshake и переводит соединение в установленное состояние.

Передача данных

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

Завершение соединения

ACK используется для подтверждения FIN и других этапов штатного закрытия соединения. Следовательно, наличие ACK допустимо во множестве TCP-состояний.

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

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

Возможны два основных сценария.

ACK-пакеты вне существующего соединения

Пакет содержит ACK, но соответствующего соединения нет. Stateful firewall ищет запись по комбинации параметров потока:

• исходный IP-адрес;
• целевой IP-адрес;
• исходный порт;
• целевой порт;
• транспортный протокол;
• текущее состояние TCP.

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

ACK-пакеты, имитирующие существующие потоки

Атакующий может менять адреса, порты, номера последовательности, acknowledgment number, размер окна и дополнительные признаки. Цель состоит в увеличении стоимости проверки или попытке сделать поток похожим на легитимные соединения.

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

Почему ACK Flood создаёт нагрузку

Поиск состояния

Stateful-устройство не должно принимать решение только по установленному флагу ACK. Оно проверяет, существует ли соответствующее соединение и допустим ли пакет в текущем состоянии.

При миллионах пакетов в секунду даже быстрый поиск по таблице требует существенных ресурсов процессора и памяти.

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

Для существующего соединения необходимо определить, попадает ли sequence number в допустимое окно и согласуется ли acknowledgment number с переданными данными.

Обработка пакетными фильтрами

Пакет может последовательно проходить:

• аппаратные ACL;
• антиспуфинг;
• conntrack;
• правила межсетевого экрана;
• IDS или IPS;
• NAT;
• балансировщик;
• сетевой стек сервера.

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

Высокий PPS

ACK-пакет без полезной нагрузки имеет небольшой размер. При одинаковом объёме канала маленькие пакеты создают большее количество пакетов в секунду, чем крупные.

Например, один и тот же поток в гигабитах может по-разному влиять на оборудование:

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

RFC 8782 прямо приводит ACK Flood как пример атаки, направленной на исчерпание процессорных ресурсов. В документе также отмечено, что DDoS может перегружать канал и stateful firewall.

Какие системы становятся целью ACK Flood

Stateful firewall

Одна из основных целей. Firewall должен определить, относится ли ACK к разрешённому соединению. При высокой интенсивности растёт CPU, увеличиваются задержки и начинаются packet drops.

Система conntrack

В Linux и сетевых устройствах conntrack хранит состояние потоков. Вредоносные пакеты могут создавать высокую нагрузку на поиск записей и обработку состояния.

В зависимости от правил и реализации некоторые потоки могут приводить к созданию новых записей, другие — маркироваться INVALID без сохранения полноценного состояния. Поэтому реальное влияние необходимо проверять на конкретной системе.

Маршрутизатор

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

Балансировщик нагрузки

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

IDS и IPS

Система обнаружения вторжений анализирует заголовки и состояние протокола. Глубокая проверка огромного количества пакетов способна стать узким местом.

Конечный сервер

Если пакет проходит периметр, его обрабатывает сетевой стек операционной системы. Сервер проверяет сокеты, состояние соединения и номера последовательности, а затем решает, игнорировать пакет или сформировать ответ.

ACK Flood без установления соединений

Для простого ACK Flood злоумышленнику не обязательно выполнять TCP handshake. Он может отправлять пакеты, которые выглядят как часть ранее установленного соединения.

Это отличает ACK Flood от TCP Connection Flood:

Характеристика	ACK Flood вне состояния	Connection Flood
Handshake	Не выполняется	Полностью выполняется
Реальный обратный адрес	Не всегда необходим	Обычно необходим
Состояние на сервере	Может отсутствовать	Создаётся
Основная цель	Пакетная обработка и проверка состояния	Сокеты, соединения и приложение
Достижение L7	Обычно нет	Возможно

Может ли ACK Flood использовать подмену IP-адреса

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

IP spoofing затрудняет защиту:

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

Однако не каждая ACK Flood-атака использует spoofing. Реальный ботнет также способен создавать поток ACK-пакетов с настоящих адресов заражённых устройств.

ACK Flood и ACK Reflection

ACK Flood не обязательно является отражённой атакой. В большинстве случаев пакеты направляются непосредственно на цель.

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

Обычный ACK-пакет не заставляет произвольный сервер гарантированно вернуть крупный ответ. Реакция зависит от порта, TCP-состояния и реализации. Поэтому термины ACK Flood и SYN-ACK Reflection нельзя считать взаимозаменяемыми.

ACK Flood с фиксированным портом

Атакующий может направить все пакеты на конкретный сервис, например TCP/443. В таком случае нагрузка сосредоточена на одном VIP, балансировщике или правиле firewall.

Признаки:

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

ACK Flood по диапазону портов

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

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

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

ACK Flood с полезной нагрузкой

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

Наличие payload необходимо учитывать при классификации:

Тип	Основная нагрузка
Маленькие ACK без данных	Высокий PPS и проверки состояния
ACK с крупной нагрузкой	Канал, IDS/IPS и сетевой стек
ACK внутри реального соединения	Сокеты, приложение и upstream

ACK Flood и TCP Challenge ACK

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

RFC 5961 описывает challenge ACK, в частности для защиты от слепых атак с поддельными RST или SYN в синхронизированном состоянии. Если подозрительный сегмент не подтверждает владение параметрами соединения, он отбрасывается.

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

Защитнику необходимо контролировать:

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

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

Критерий	ACK Flood	SYN Flood
Основной флаг	ACK	SYN
Имитация этапа	Установленное соединение	Начало соединения
Главная цель	CPU, PPS и stateful inspection	Очередь полуоткрытых соединений
Создание SYN_RECV	Обычно нет	Да
Эффект SYN cookies	Практически не решают проблему	Могут значительно помочь
Типичная реакция firewall	Поиск существующего состояния	Создание или проверка нового состояния

Чем ACK Flood отличается от PSH-ACK Flood

При обычном ACK Flood установлен флаг ACK, а полезной нагрузки может не быть. В PSH-ACK Flood одновременно установлены PSH и ACK.

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

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

Чем ACK Flood отличается от легитимного ACK-трафика

Признак	Легитимный трафик	ACK Flood
Предшествующий handshake	Присутствует	Часто отсутствует
Запись в state table	Существует	Часто отсутствует
Sequence number	Соответствует окну	Случайный или некорректный
Acknowledgment number	Подтверждает отправленные данные	Не соответствует реальному обмену
Направление	Согласуется с двусторонним потоком	Может быть односторонним
Скорость	Связана с передаваемыми данными	Резко превышает нормальный профиль
Размер пакетов	Различается	Часто преобладают однотипные размеры

Как обнаружить ACK Flood

1. Рост ACK packets per second

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

2. ACK без предшествующего SYN

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

3. Высокая доля INVALID

Stateful firewall может помечать такие пакеты как INVALID. Резкий рост этого состояния указывает на ошибку маршрутизации, асимметричный трафик, проблему conntrack или атаку.

4. Рост CPU сетевого оборудования

ACK Flood часто проявляется повышенной нагрузкой на firewall или маршрутизатор при сравнительно умеренной загрузке приложения.

5. Packet drops

Потери могут появляться:

• на физическом интерфейсе;
• в очередях драйвера;
• в softnet backlog;
• на firewall;
• в policer;
• на балансировщике;
• в сети провайдера.

6. Отсутствие роста HTTP-запросов

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

7. Аномальное количество уникальных потоков

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

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

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

Почему NetFlow недостаточно для полного анализа

NetFlow или IPFIX хорошо показывают объём, направления, адреса и порты. Однако агрегированные потоки могут не сохранять полную последовательность TCP-флагов и номеров.

Для точной диагностики полезно совместить:

• NetFlow или IPFIX;
• счётчики интерфейсов;
• телеметрию firewall;
• метрики conntrack;
• ограниченный PCAP;
• журналы reverse proxy;
• системные метрики сервера.

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

Почему асимметричная маршрутизация похожа на ACK Flood

Stateful firewall должен видеть оба направления соединения. Если SYN проходит через одно устройство, а последующие ACK возвращаются через другое, второе устройство не обнаруживает состояние и считает пакеты неожиданными.

Перед объявлением инцидента необходимо проверить:

• изменения маршрутов;
• ECMP;
• policy-based routing;
• переключение резервного канала;
• неравномерную балансировку;
• изменения BGP-анонсов;
• маршруты между дата-центрами;
• расположение NAT и stateful firewall.

Главное отличие атаки — сочетание высокой интенсивности, аномального профиля источников и отсутствия соответствующей легитимной активности.

Защита от ACK Flood

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

Stateful firewall должен разрешать ACK только тогда, когда пакет соответствует допустимому соединению. Неожиданные ACK можно помечать INVALID и отбрасывать.

Но такое правило требует корректной симметрии маршрутов. Иначе легитимные пакеты будут ошибочно заблокированы.

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

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

1. аппаратная фильтрация на границе;
2. фильтрация у провайдера;
3. scrubbing-центр;
4. граничный маршрутизатор;
5. firewall;
6. балансировщик;
7. конечный сервер.

3. Использовать stateless ACL для очевидного мусора

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

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

4. Ограничить скорость аномального ACK-трафика

Rate limiting может применяться к пакетам, которые:

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

Лимит для всех ACK без разделения состояния опасен: он может нарушить нормальную передачу данных.

5. Защитить таблицу conntrack

Необходимо:

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

6. Применять антиспуфинг

Сети должны блокировать исходящие пакеты с адресами, которые не принадлежат их клиентам. Это не позволяет использовать сеть как источник ACK Flood с поддельными IP.

На стороне жертвы также следует отбрасывать пакеты с явно недопустимыми адресами: приватными, зарезервированными, multicast или невозможными для данного интерфейса.

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

Если ACK Flood заполняет канал или превышает PPS граничного устройства, локальный firewall уже не сможет решить проблему. Очистка должна происходить в сети провайдера или scrubbing-центре.

8. Использовать Anycast и распределённую инфраструктуру

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

Защита Linux-сервера

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

Необходимо контролировать:

• состояние conntrack;
• softirq и system CPU;
• очереди сетевого интерфейса;
• packet drops;
• скорость генерации RST;
• challenge ACK;
• ошибки сокетов;
• TCP retransmissions;
• память сетевого стека;
• распределение обработки по ядрам CPU.

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

Помогают ли SYN cookies против ACK Flood

Практически нет. SYN cookies предназначены для снижения потребления состояния при обработке начальных SYN-запросов.

ACK Flood отправляет ACK-пакеты, которые часто не связаны с SYN-запросами и полуоткрытыми соединениями. Серверу или firewall всё равно необходимо проверить их состояние.

SYN cookies полезны, если злоумышленник одновременно использует SYN Flood. При чистом ACK Flood нужны другие меры:

• stateful validation;
• ранняя фильтрация;
• аппаратные ACL;
• rate limiting аномальных пакетов;
• upstream-очистка;
• контроль производительности по PPS.

Поможет ли WAF против ACK Flood

Обычный WAF анализирует HTTP-запросы. ACK Flood может не формировать ни одного полноценного HTTP-запроса, поэтому поток не доходит до уровня, на котором работает WAF.

Для защиты необходимы L3/L4-механизмы:

• фильтрация TCP-состояния;
• проверка флагов;
• контроль PPS;
• защита firewall и conntrack;
• очистка трафика до входного канала.

Если атакующие завершают handshake и отправляют HTTP-запросы, атака переходит на уровень L7. Тогда WAF, обнаружение ботов и rate limiting становятся необходимой второй линией защиты.

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

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

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

Однако ACK Flood относится преимущественно к L3/L4. Если большой поток ACK направлен на раскрытый IP origin и заполняет канал до сервера, reverse proxy и WAF не могут освободить этот участок сети.

Уровень атаки	Роль TrafficVeil	Дополнительная защита
HTTP Flood	WAF, ML-детекция, rate limiting	Настройка правил под приложение
Прямые подключения к origin	Снижает риск, если origin закрыт ACL	Разрешить только адреса TrafficVeil
ACK Flood на IP origin	Не заменяет сетевую очистку канала	Anti-DDoS провайдера или scrubbing
ACK Flood на другой TCP-сервис	Не проксирует произвольные TCP-протоколы	ACL, VPN и L3/L4-защита

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

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

Шаг 1. Подтвердить тип атаки

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

Шаг 2. Определить точку перегрузки

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

Шаг 3. Исключить проблему маршрутизации

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

Шаг 4. Отбросить очевидно недопустимый трафик

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

Шаг 5. Ограничить аномальный поток

Rate limiting следует применять к вредоносному классу трафика, а не ко всем ACK без разбора.

Шаг 6. Обратиться к провайдеру

Если растут BPS или PPS на внешнем канале, передайте оператору:

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

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

Одновременно могут идти SYN Flood, SYN-ACK Flood, UDP Flood и HTTP Flood. Фильтрация ACK не должна закрывать наблюдение за остальными направлениями.

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

Зафиксируйте графики, состояния firewall, счётчики интерфейсов, изменения маршрутов, правила фильтрации и время действий провайдера.

Пример разбора ACK Flood

Сайт периодически перестаёт отвечать, хотя веб-сервер обрабатывает сравнительно мало HTTP-запросов. Мониторинг показывает высокий CPU на граничном firewall и packet drops на внешнем интерфейсе.

Анализ выявляет:

• резкий рост TCP PPS;
• более 90% входящих пакетов содержат ACK;
• подавляющее большинство не соответствует conntrack;
• исходные адреса и порты постоянно меняются;
• целевым является TCP/443;
• HTTP-журналы не показывают аналогичного роста запросов;
• канал заполнен лишь частично, но firewall достиг предела по PPS.

Это указывает на пакетную ACK Flood-атаку, целью которой является не веб-приложение, а stateful firewall.

Перенос фильтрации на upstream-площадку позволяет удалить пакеты вне состояния до локального firewall. После этого CPU и packet drops возвращаются к нормальным значениям, хотя исходный атакующий поток продолжает поступать в сеть Anti-DDoS-провайдера.

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

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

Практически весь установленный TCP-трафик использует ACK. Такое правило сделает сайт недоступным.

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

SYN cookies не устраняют нагрузку от ACK-пакетов вне состояния.

Ошибка 3. Оценивать только заполнение канала

ACK Flood может вывести firewall из строя высоким PPS при незаполненном канале.

Ошибка 4. Фильтровать после conntrack

Если цель атаки — stateful-проверка, вредоносный пакет желательно удалить до дорогостоящего поиска состояния.

Ошибка 5. Игнорировать асимметричную маршрутизацию

Легитимные ACK могут выглядеть как пакеты вне состояния, если firewall не видел начало соединения.

Ошибка 6. Блокировать источники вручную

Адреса могут быть поддельными или принадлежать большому распределённому ботнету.

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

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

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

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

Ошибка 9. Не защищать IPv6

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

Ошибка 10. Собирать неограниченный PCAP

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

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

• Известны нормальные значения TCP и ACK PPS.
• Контролируются BPS, PPS и количество потоков.
• Настроен мониторинг CPU граничного оборудования.
• Отслеживается заполнение conntrack.
• Настроены алерты по INVALID-пакетам.
• Firewall видит оба направления TCP-соединений.
• Проверены ECMP и асимметричные маршруты.
• Неиспользуемые TCP-порты закрыты на границе.
• Применяется антиспуфинг.
• Пакеты вне состояния отбрасываются.
• Очевидный мусор фильтруется до conntrack.
• Лимиты не блокируют легитимный ACK-трафик.
• Origin скрыт за reverse proxy.
• Прямой доступ к origin запрещён.
• Правила действуют для IPv4 и IPv6.
• Провайдер поддерживает L3/L4 Anti-DDoS.
• Подготовлена процедура включения scrubbing.
• Определён безопасный порядок сбора PCAP.
• Хранятся NetFlow или IPFIX.
• План реагирования регулярно проверяется.

Заключение

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

Главными признаками атаки являются резкий рост ACK PPS, большое количество пакетов без соответствующего handshake, увеличение INVALID-состояний, высокая нагрузка на сетевое оборудование и отсутствие сопоставимого роста HTTP-запросов.

Защита должна быть многоуровневой: закрытие ненужных портов, проверка TCP-состояния, ранняя stateless-фильтрация, защита conntrack, антиспуфинг и upstream-очистка при превышении возможностей локальной инфраструктуры.

WAF и reverse proxy дополняют эту схему, но не заменяют сетевую Anti-DDoS-защиту. Чтобы ACK Flood не достигал origin напрямую, реальный адрес сервера необходимо скрыть, а входящий веб-трафик разрешить только от доверенной прокси-инфраструктуры.