TCP Flood, ACK Flood, SYN-ACK Flood, RST Flood, FIN Flood и PSH-ACK Flood

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

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

Основная опасность заключается не только в объёме трафика. Поток может быть сравнительно небольшим в гигабитах в секунду, но состоять из миллионов коротких сегментов. Тогда узким местом становится производительность обработки пакетов — packets per second, или pps.

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

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

Обычное TCP-соединение проходит несколько этапов:

1. клиент отправляет SYN;
2. сервер отвечает SYN-ACK;
3. клиент подтверждает соединение пакетом ACK;
4. стороны обмениваются данными;
5. соединение закрывается с использованием FIN и ACK либо аварийно прерывается через RST.

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

Что означают основные TCP-флаги

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

Сам по себе флаг не является вредоносным. Оценивать необходимо сочетание флагов, адресов и портов, текущее состояние соединения, допустимость sequence number, скорость потока и реакцию оборудования.

Что такое TCP Flood

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

В отличие от SYN Flood, который прежде всего создаёт незавершённые соединения в состоянии SYN-RECEIVED, другие варианты TCP Flood часто направлены на обработку пакетов вне состояния либо на уже установленные соединения. SYN Flood целесообразно рассматривать отдельно, поскольку его механизм связан с очередью полуоткрытых соединений. RFC 4987 прямо описывает удержание состояния сервером после получения SYN как основу данного вида отказа в обслуживании.

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

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

Классификация TCP Flood

Атака	Основной флаг	Предполагаемая реакция цели	Типичная точка перегрузки
ACK Flood	ACK	Поиск существующего соединения, проверка состояния	Firewall, балансировщик, сетевой стек
SYN-ACK Flood	SYN + ACK	Проверка соответствия исходящему SYN либо отправка RST	Канал, firewall, сервер, клиентская инфраструктура
RST Flood	RST или RST + ACK	Проверка номера последовательности и возможный сброс соединения	Сетевой стек, активные сессии, stateful-устройства
FIN Flood	FIN или FIN + ACK	Проверка состояния, подтверждение завершения либо отклонение	Firewall, conntrack, сервер
PSH-ACK Flood	PSH + ACK	Обработка как сегмента установленного соединения с данными	Firewall, прокси, сетевой стек, приложение
Смешанный TCP Flag Flood	Разные комбинации	Разные ветви TCP state machine	Несколько компонентов одновременно

Что такое ACK Flood

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

Если сегмент не относится к известному соединению, stateful firewall или сервер всё равно должен выполнить проверку. Как правило, сравниваются:

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

Один такой поиск занимает мало времени. Миллионы пакетов в секунду способны перегрузить таблицу conntrack, CPU firewall, сетевую карту или программный балансировщик.

Stateless и stateful ACK Flood

Stateless ACK Flood состоит из пакетов, не принадлежащих реальным соединениям. Адреса, порты и номера последовательности могут быть случайными. Цель — создать максимальное количество операций проверки состояния.

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

В документах IETF ACK Flood приводится как пример атаки, способной прежде всего истощать ресурсы CPU, тогда как SYN Flood обычно связывается с удержанием состояния и памяти.

На что воздействует ACK Flood

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

ACK Flood и отражённый трафик

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

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

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

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

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

SYN-ACK Flood и SYN Flood — разные атаки

Критерий	SYN Flood	SYN-ACK Flood
Что получает жертва	SYN	SYN + ACK
Роль жертвы	Сервер, который должен принять новое соединение	Сторона, которой приписывают ранее отправленный SYN
Основной эффект	Полуоткрытые соединения и backlog	Поиск отсутствующей сессии, генерация RST, нагрузка на канал и CPU
Типичная защита	SYN cookies, SYN proxy, backlog tuning, rate limiting	Stateful-фильтрация, антиспуфинг, ограничение аномальных SYN-ACK

Как возникает SYN-ACK Flood

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

1. Прямой поток. Ботнет самостоятельно генерирует SYN-ACK и направляет пакеты цели.
2. Ответный поток. Третьим серверам отправляются SYN-пакеты с подменённым адресом жертвы, после чего серверы отвечают SYN-ACK на этот адрес.

Во втором случае наблюдаемые источники могут быть легитимными серверами, которые не участвуют в атаке намеренно. Блокировка каждого такого адреса по отдельности малоэффективна и способна нарушить нормальную работу.

Как SYN-ACK Flood расходует ресурсы

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

Что такое RST Flood

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

RST Flood — массовая отправка сегментов с флагом RST либо комбинацией RST-ACK. У атаки могут быть две принципиально разные цели:

• перегрузить оборудование проверкой большого количества RST-пакетов;
• попытаться сбросить реальные TCP-соединения.

Почему случайный RST не всегда разрывает соединение

Современная TCP-реализация не должна безусловно закрывать сессию после любого пакета с флагом RST. Проверяется соответствие пакета существующему соединению и допустимость sequence number.

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

Следовательно, произвольный RST Flood чаще создаёт нагрузку на обработку, чем массово разрывает реальные соединения. Для успешного воздействия на конкретную сессию атакующему нужны параметры, соответствующие этому соединению, либо возможность наблюдать его трафик.

Какие соединения особенно чувствительны

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

Если RST относится к действительному соединению и проходит проверку, приложение видит внезапный обрыв. Клиент может начать переподключение, создавая дополнительный поток SYN и TLS-handshake. Тогда первоначальная атака вызывает вторичную нагрузку.

Что такое FIN Flood

FIN сообщает, что сторона завершила передачу данных. Нормальное закрытие TCP-сессии требует обмена FIN и ACK, после которого соединение проходит несколько промежуточных состояний, включая FIN-WAIT, CLOSE-WAIT, LAST-ACK и TIME-WAIT.

FIN Flood — поток сегментов с флагом FIN или FIN-ACK, которые могут не соответствовать существующим соединениям либо массово воздействовать на реальные сессии.

Как обрабатывается неожиданный FIN

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

Даже при отбрасывании пакета серверу и промежуточному оборудованию приходится:

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

Может ли FIN Flood заполнить TIME-WAIT

Поток случайных FIN-пакетов сам по себе не означает автоматического появления большого количества записей TIME-WAIT. Такое состояние связано с корректно существовавшими TCP-соединениями и процедурой их закрытия.

Однако если ботнет устанавливает множество реальных соединений и быстро закрывает их, количество состояний TIME-WAIT, FIN-WAIT и CLOSE-WAIT действительно может вырасти. В этом случае речь идёт не просто о stateless FIN Flood, а об атаке с полноценными TCP-сессиями.

Что такое PSH-ACK Flood

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

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

Почему PSH-ACK Flood может быть тяжелее обычного ACK Flood

Пустой ACK преимущественно обрабатывается сетевым стеком и stateful-оборудованием. PSH-ACK с допустимыми данными внутри установленной сессии может пройти дальше:

1. сетевой интерфейс принимает пакет;
2. firewall сопоставляет его с соединением;
3. TCP проверяет номера последовательности;
4. данные помещаются в приёмный буфер;
5. приложение получает уведомление о доступных данных;
6. reverse proxy или сервер анализирует прикладной протокол;
7. могут запускаться TLS-, HTTP- или другие обработчики.

Поэтому stateful PSH-ACK Flood способен переходить от L4-нагрузки к прикладной. Но сам флаг PSH не гарантирует, что пакет будет передан приложению: сначала он должен пройти все проверки TCP-состояния.

Типичные последствия PSH-ACK Flood

• рост системных прерываний и softirq;
• нагрузка на socket buffers;
• частые пробуждения рабочих процессов;
• перегрузка TLS-терминации;
• увеличение числа операций чтения;
• рост очередей reverse proxy;
• исчерпание лимита одновременных соединений;
• увеличение задержки легитимных запросов;
• нагрузка на приложение при валидных TCP-сессиях.

Что такое смешанный TCP Flag Flood

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

Такой подход усложняет фильтрацию:

• одно правило не охватывает весь поток;
• разные сегменты попадают в разные ветви TCP state machine;
• часть пакетов выглядит как ответы, часть — как завершение сессий;
• статические фильтры по одному флагу дают слабый результат;
• в потоке может присутствовать небольшая доля полноценных соединений;
• атака может сочетаться с SYN Flood или HTTP Flood.

Volumetric, protocol и state-exhaustion: три механизма воздействия

Механизм	Что исчерпывается	Основная метрика
Volumetric	Пропускная способность канала	Gbit/s
Packet-rate exhaustion	Производительность обработки пакетов	Packets per second
State exhaustion	Таблицы соединений, NAT, conntrack, память	Количество состояний и скорость их создания
Application exhaustion	Рабочие процессы, TLS, очереди, backend	Соединения, запросы, CPU, latency

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

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

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

Сетевые признаки

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

Системные признаки

• рост CPU в softirq или kernel space;
• переполнение conntrack;
• увеличение packet drops;
• рост ошибок сетевого интерфейса;
• перегрузка firewall или балансировщика;
• увеличение числа прерванных соединений;
• рост TIME-WAIT, FIN-WAIT или CLOSE-WAIT при stateful-атаке;
• задержки обработки даже при умеренной загрузке приложения;
• недоступность нескольких сервисов на одном IP;
• заполнение журналов однотипными событиями.

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

Показатель	Для чего нужен
Входящий и исходящий bps	Определение загрузки канала
Входящий и исходящий pps	Выявление пакетной перегрузки
Распределение TCP-флагов	Определение типа атаки
Количество новых соединений в секунду	Выявление stateful-атаки
Размер conntrack	Контроль исчерпания таблицы состояний
Число пакетов invalid	Оценка потока вне состояния
Количество ответных RST	Выявление SYN-ACK или другого постороннего трафика
Распределение по портам	Поиск конкретной цели либо carpet bombing
CPU firewall и сервера	Определение точки перегрузки
Packet drops по интерфейсам	Выявление потерь до приложения
HTTP-запросы и ответы	Отделение L4 TCP Flood от L7 HTTP Flood

Как отличить TCP Flood от обычного роста трафика

Обычный рост аудитории сопровождается пропорциональным увеличением завершённых TCP-соединений, TLS-сессий, HTTP-запросов, ответов и полезной нагрузки. При stateless TCP Flood количество пакетов увеличивается, но прикладных запросов почти не становится больше.

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

Как защититься от TCP Flood

1. Фильтровать пакеты с учётом состояния

Stateful firewall должен пропускать ACK, FIN, RST и PSH-ACK к защищённому сервису только тогда, когда они соответствуют допустимому соединению. Пакеты со статусом invalid рекомендуется отбрасывать как можно раньше.

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

2. Применять SYN proxy и TCP proxy

Полноценный TCP proxy завершает клиентское соединение на своей стороне и создаёт отдельное соединение с origin-сервером. Пакеты, не соответствующие TCP state machine, не доходят до origin.

SYN proxy прежде всего защищает стадию установки соединения. Он особенно полезен против SYN Flood, но также позволяет отделить неподтверждённые источники от внутренней инфраструктуры.

3. Ограничивать скорость аномальных пакетов

Можно вводить отдельные лимиты для:

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

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

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

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

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

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

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

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

6. Отключить подробное журналирование каждого пакета

При DDoS запись каждого отброшенного сегмента способна перегрузить диск, CPU и систему централизованных логов. Следует использовать агрегацию, sampling и ограничение частоты одинаковых сообщений.

7. Использовать антиспуфинг

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

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

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

• у хостинг-провайдера;
• у интернет-оператора;
• в распределённой anti-DDoS-сети;
• в scrubbing center;
• на внешнем TCP reverse proxy.

9. Защитить origin-сервер

Публичный веб-сервер, работающий через reverse proxy, не должен принимать произвольные соединения из интернета. На origin необходимо разрешить входящий HTTP/HTTPS только от адресов защищённого прокси-контура и от отдельных административных адресов, если они нужны.

Защита от отдельных вариантов

Вариант	Приоритетные меры
ACK Flood	Stateful-фильтрация, early drop invalid, защита conntrack, высокая pps-производительность
SYN-ACK Flood	Фильтрация пакетов без исходящего SYN, rate limit ответных RST, upstream-очистка
RST Flood	Проверка sequence number, современный TCP-стек, защита долгоживущих сессий
FIN Flood	State validation, контроль состояний закрытия, ограничение пакетов вне сессий
PSH-ACK Flood	TCP proxy, проверка состояния, лимиты соединений, L7-анализ после handshake
Смешанный TCP Flood	Поведенческая классификация, нормализация TCP, распределённая очистка

Почему обычный WAF не останавливает stateless TCP Flood

WAF анализирует HTTP- и HTTPS-запросы. Чтобы запрос дошёл до WAF, клиент обычно должен:

1. установить TCP-соединение;
2. при HTTPS пройти TLS-handshake;
3. отправить корректный HTTP-запрос.

При ACK, SYN-ACK, RST или FIN Flood полноценного HTTP-запроса может вообще не существовать. Следовательно, атака должна быть остановлена TCP-прокси, сетевым firewall, пограничным оборудованием или upstream-системой очистки.

Stateful PSH-ACK Flood может пройти дальше, если бот завершает handshake и отправляет прикладные данные. Тогда к L3/L4-защите должны добавляться ограничения соединений, анализ HTTP, детекция автоматизации и поведенческая фильтрация.

Какую роль играет TrafficVeil

TrafficVeil работает как reverse proxy для HTTP- и HTTPS-сайтов. Сервис принимает веб-соединение на защищённом контуре, анализирует запросы и передаёт на origin только разрешённый трафик.

Это создаёт несколько уровней защиты:

• прямые TCP-пакеты к публичному адресу сайта не поступают на origin;
• некорректные соединения отсеиваются до веб-сервера;
• L7 DDoS и HTTP Flood анализируются отдельно от сетевого шума;
• боты оцениваются по поведенческим и техническим признакам;
• WAF фильтрует вредоносные веб-запросы;
• rate limiting ограничивает частоту разрешённых запросов.

Критически важно закрыть настоящий IP origin. Если он остаётся доступен напрямую, атакующий может обойти reverse proxy и направить TCP Flood непосредственно на сервер или его канал.

TrafficVeil не следует представлять как универсальную замену операторской L3/L4-защите. Если объём атаки превышает пропускную способность дата-центра или атакуется внешний адрес origin, фильтрация должна начинаться у оператора либо в специализированном scrubbing center.

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

1. Определить преобладающие флаги. Установить, является ли поток ACK, SYN-ACK, RST, FIN, PSH-ACK или смешанным.
2. Измерить bps и pps. Разделить объёмную и пакетную перегрузку.
3. Проверить состояния. Определить долю пакетов, соответствующих реальным соединениям.
4. Найти узкое место. Проверить канал, маршрутизатор, firewall, conntrack, балансировщик и сервер.
5. Отбросить invalid. Ввести раннюю фильтрацию пакетов вне состояния.
6. Защитить открытые порты. Оставить доступ только к необходимым сервисам.
7. Ограничить аномальный pps. Не затрагивать при этом нормальные ACK и передачу данных.
8. Снизить логирование. Включить агрегацию и rate limit событий.
9. Обратиться к оператору. Передать целевые адреса, порты, флаги, bps, pps и время начала.
10. Переключить трафик на очистку. Если канал или оборудование близки к пределу.
11. Закрыть origin. Разрешить веб-доступ только через TrafficVeil.
12. Контролировать приложение. После сетевой фильтрации убедиться, что атака не перешла в HTTP Flood.

Какие данные сохранить после атаки

• время начала, пика и завершения;
• целевые IP-адреса и порты;
• пиковые bps и pps;
• распределение TCP-флагов;
• соотношение входящего и исходящего трафика;
• количество ответных RST;
• долю invalid-пакетов;
• число записей conntrack по состояниям;
• распределение источников по ASN, странам и подсетям;
• NetFlow, sFlow или IPFIX;
• короткий репрезентативный PCAP;
• загрузку CPU и память устройств;
• счётчики packet drops;
• изменения конфигурации во время инцидента;
• действия оператора и anti-DDoS-провайдера;
• влияние на доступность сайта и другие сервисы.

Распространённые ошибки

Блокировка всех ACK-пакетов

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

Использование только лимита по IP

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

Ориентация только на Gbit/s

Миллионы коротких пакетов могут перегрузить firewall при относительно небольшом объёме данных.

Увеличение conntrack без мониторинга

Большая таблица требует больше памяти и не устраняет причину атаки.

Блокировка всех RST

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

Предположение, что любой FIN создаёт TIME-WAIT

TIME-WAIT появляется в результате обработки существующего соединения, а не от каждого случайного пакета с FIN.

Защита только веб-приложения

При L4 Flood запрос может не дойти до HTTP. Защищать необходимо канал, TCP-прокси и сетевой периметр.

Открытый IP origin-сервера

Если настоящий адрес известен и доступен, reverse proxy можно обойти прямой атакой.

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

• Измеряются входящие и исходящие bps и pps.
• Собирается статистика TCP-флагов.
• Контролируется размер conntrack.
• Настроены алерты на рост invalid-пакетов.
• Закрыты все неиспользуемые порты.
• Пакеты вне состояния отбрасываются как можно раньше.
• Stateful firewall рассчитан на ожидаемый pps.
• Настроена защита control plane.
• Ограничено журналирование повторяющихся событий.
• Есть базовый профиль нормальных ACK, RST, FIN и PSH-ACK.
• Проверена поддержка современных механизмов защиты TCP.
• Подготовлен контакт оператора связи.
• Согласован сценарий перенаправления в scrubbing center.
• Публичный сайт работает через TrafficVeil.
• Origin принимает веб-трафик только от доверенных адресов.
• Проверено, что DNS не раскрывает старый IP origin.
• После L4-фильтрации применяется защита от HTTP Flood.
• Регламент реагирования протестирован заранее.