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

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

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

Во время FIN Flood значительная часть пакетов не относится к реальным TCP-сессиям. Тем не менее сетевое оборудование и операционная система должны:

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

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

Что означает TCP-флаг FIN

FIN означает finish — завершение передачи. Сторона, отправившая FIN, сообщает, что больше не будет передавать новые данные в данном направлении.

TCP является полнодуплексным протоколом. Два направления соединения закрываются независимо. Поэтому получение FIN не всегда означает, что обе стороны немедленно прекращают обмен.

После получения FIN другая сторона может:

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

Актуальная спецификация TCP приведена в RFC 9293. Она описывает обработку FIN и переходы между состояниями FIN-WAIT, CLOSE-WAIT, CLOSING, LAST-ACK и TIME-WAIT.

Как штатно закрывается TCP-соединение

Типичная последовательность закрытия состоит из четырёх этапов:

1. Сторона A отправляет FIN.
2. Сторона B подтверждает его пакетом ACK.
3. Когда сторона B заканчивает передачу, она отправляет свой FIN.
4. Сторона A подтверждает его ACK.

Этап	Пакет	Что происходит
1	FIN или FIN-ACK	Первая сторона прекращает передачу данных
2	ACK	Вторая сторона подтверждает FIN
3	FIN или FIN-ACK	Вторая сторона закрывает своё направление
4	ACK	Закрытие подтверждается

На практике ACK первого FIN и встречный FIN могут быть объединены в один пакет FIN-ACK. Поэтому закрытие иногда выглядит как последовательность из трёх пакетов.

Какие состояния связаны с закрытием TCP

FIN-WAIT-1

Система отправила FIN и ожидает его подтверждения либо встречного FIN. Соединение ещё сохраняет состояние и таймеры.

FIN-WAIT-2

Отправленный FIN подтверждён, но встречная сторона пока не прислала свой FIN. Локальная сторона больше не отправляет данные, однако продолжает принимать их.

CLOSE-WAIT

Система получила FIN и подтвердила его, но локальное приложение ещё не закрыло свою сторону соединения. Большое количество длительных CLOSE-WAIT часто указывает на проблему приложения, а не на сетевую атаку.

CLOSING

Обе стороны почти одновременно отправили FIN и ожидают подтверждений.

LAST-ACK

Система получила FIN, затем отправила собственный FIN и ждёт последнего ACK.

TIME-WAIT

Сторона, завершившая закрытие, временно сохраняет информацию о соединении. Это защищает новые соединения от старых задержавшихся пакетов и позволяет повторно подтвердить FIN, если последний ACK потерялся.

RFC 1337 рассматривает риски преждевременного уничтожения состояния TIME-WAIT — так называемые TIME-WAIT Assassination Hazards.

FIN и RST: в чём разница

Критерий	FIN	RST
Назначение	Штатно завершить передачу	Немедленно сбросить соединение
Подтверждение	Требуется ACK	Обычно не используется согласованное закрытие
Оставшиеся данные	Могут передаваться в обратном направлении	Соединение прекращается
Состояния закрытия	FIN-WAIT, CLOSE-WAIT, LAST-ACK, TIME-WAIT	Переход к аварийному завершению
Требования к атаке	Нужен корректный sequence number для реальной сессии	Также требуется пройти проверку RST

FIN не является «мягким RST». Он обозначает завершение только одного направления передачи и занимает место в пространстве TCP sequence number.

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

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

• случайные исходные IP-адреса;
• подменённые адреса реальных клиентов;
• случайные исходные и целевые порты;
• один конкретный порт, например TCP/443;
• случайные sequence number;
• одинаковые повторяющиеся значения;
• сочетания FIN-ACK;
• аномальные комбинации FIN-SYN или FIN-RST;
• маленькие пакеты с высоким PPS.

Большинство случайных FIN не сможет закрыть реальные соединения, поскольку не совпадут адреса, порты и номера последовательности. Но каждый пакет всё равно проходит несколько этапов проверки.

Основные варианты FIN Flood

FIN Flood вне состояния

FIN направляется на систему, где соответствующего соединения нет. Stateful firewall ищет запись, не находит её и классифицирует пакет как INVALID либо отбрасывает по политике.

Основная нагрузка создаётся на:

• пакетную обработку;
• поиск в таблице состояний;
• ACL и firewall;
• IDS/IPS;
• сетевой стек.

FIN-ACK Flood

Одновременно установлены FIN и ACK. Такая комбинация нормальна при закрытии реального соединения, поэтому фильтрация только по набору флагов недостаточна.

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

FIN Flood на открытый порт

Пакеты направляются на работающий сервис — например, TCP/80 или TCP/443. Целью может быть firewall, балансировщик или сервер, обслуживающий большое количество одновременных соединений.

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

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

FIN injection в существующие соединения

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

• адреса обеих сторон;
• исходный и целевой порт;
• актуальный sequence number;
• размер receive window;
• направление соединения.

Успешный FIN не обязательно мгновенно уничтожит соединение, как RST. Но он может заставить получателя считать, что удалённая сторона завершила передачу, и перевести сеанс в CLOSE-WAIT или другую стадию закрытия.

Может ли случайный FIN закрыть соединение

Обычно нет. Для обработки FIN внутри существующей сессии пакет должен пройти проверку sequence number.

Если FIN находится вне ожидаемого TCP-окна, корректная реализация не должна принимать его как завершение потока.

Для blind-атаки злоумышленнику приходится угадывать допустимые значения. Вероятность зависит от:

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

RFC 4272 при анализе угроз для BGP отмечает, что для поддельного FIN требуется правильный sequence number; механизмы аутентификации TCP могут противодействовать таким атакам на маршрутизирующие сессии.

Blind и on-path FIN Attack

Blind FIN injection

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

On-path FIN injection

Атакующий способен наблюдать проходящие пакеты. Он видит адреса, порты и актуальные sequence number, поэтому может сформировать убедительный FIN.

В этом случае обычная проверка номера не помогает: атакующий знает допустимое значение. Нужны:

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

Какие ресурсы перегружает FIN Flood

Внешний канал

При достаточном объёме поток заполняет пропускную способность. Легитимные пакеты теряются до попадания на сервер.

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

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

Stateful firewall

Для FIN требуется найти соединение и проверить допустимость изменения состояния. Firewall может достичь предела по CPU или числу операций в секунду.

Conntrack

Система выполняет поиск состояния и классифицирует пакеты. Если правила или реализация создают дополнительные записи для неожиданных потоков, растёт потребление памяти.

Балансировщик

L4- и L7-балансировщики отслеживают клиентские и upstream-соединения. Массовые FIN увеличивают количество проверок, закрытий и удаления состояний.

TCP-стек конечного сервера

Ядро проверяет сокеты, номера последовательности, состояния и необходимость отправки ответа.

Приложение

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

Может ли FIN Flood создать много CLOSE-WAIT

Только если FIN принимаются как относящиеся к реальным установленным соединениям. Случайный FIN вне состояния не должен переводить систему в CLOSE-WAIT.

CLOSE-WAIT означает:

1. удалённая сторона отправила допустимый FIN;
2. локальный TCP-стек подтвердил его;
3. локальное приложение ещё не закрыло сокет.

Если CLOSE-WAIT постоянно растёт без явной атаки, наиболее вероятна ошибка приложения: оно не освобождает соединения после получения EOF.

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

Может ли FIN Flood создать много TIME-WAIT

TIME-WAIT обычно возникает на стороне, которая активно завершает закрытие соединения и отправляет последний ACK. Один случайный FIN вне состояния не обязан создавать TIME-WAIT.

Большое количество TIME-WAIT чаще связано с:

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

Поэтому утверждение «любой FIN Flood заполняет TIME-WAIT» технически неверно. Необходимо анализировать полный жизненный цикл соединений.

Почему TIME-WAIT нельзя бездумно отключать

TIME-WAIT защищает TCP от старых дубликатов, относящихся к предыдущему соединению с той же комбинацией адресов и портов.

Слишком агрессивное удаление состояния может:

• позволить старым сегментам попасть в новое соединение;
• создать неправильную обработку повторных FIN;
• нарушить надёжность TCP;
• вызвать трудно диагностируемые ошибки;
• ухудшить безопасность при повторном использовании портов.

RFC 6191 описывает ограниченный механизм более безопасной обработки новых SYN для соединений в TIME-WAIT при использовании TCP timestamps. Это не является рекомендацией просто удалить или резко сократить все TIME-WAIT.

Чем FIN Flood отличается от RST Flood

Критерий	FIN Flood	RST Flood
Нормальное назначение	Штатно завершить передачу	Аварийно сбросить соединение
Результат принятия	Начинается согласованное закрытие	Соединение немедленно завершается
Подтверждение	Получатель отправляет ACK	Обычно не требуется обычная процедура закрытия
Основные состояния	FIN-WAIT, CLOSE-WAIT, LAST-ACK, TIME-WAIT	Аварийный переход к CLOSED
Воздействие на приложение	Может вызвать EOF и завершение одной стороны потока	Обычно вызывает ошибку соединения

Чем FIN Flood отличается от FIN Scan

FIN Scan — метод сетевого сканирования. Небольшое количество FIN отправляется на разные порты, чтобы по реакции системы определить их состояние.

FIN Flood — атака на доступность, использующая большой объём пакетов или высокую частоту.

Критерий	FIN Scan	FIN Flood
Цель	Разведка портов	Перегрузка или нарушение соединений
Интенсивность	Низкая или умеренная	Высокая
Распределение	Много портов одного или нескольких узлов	Один или множество портов с высоким PPS
Основная метрика	Количество проверенных портов	PPS, BPS и нагрузка инфраструктуры

Может ли FIN Flood использовать IP spoofing

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

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

Подмена адресов:

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

Является ли FIN Flood отражённой атакой

Обычно FIN Flood является прямой атакой. Произвольный FIN не заставляет сервер отправить крупный ответ.

Некоторые TCP-стеки могут ответить RST или ACK в зависимости от состояния порта и параметров пакета. Если source IP подменён, этот ответ уйдёт на указанный адрес.

Однако размеры запроса и ответа обычно сопоставимы. Поэтому FIN не относится к классическим протоколам с высоким коэффициентом усиления.

Как выглядит FIN Flood в сетевом трафике

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

• резкий рост пакетов с FIN или FIN-ACK;
• высокий FIN PPS;
• много FIN без установленного соединения;
• случайные sequence number;
• аномальные комбинации TCP-флагов;
• множество исходных адресов и портов;
• рост состояния INVALID;
• увеличение ответных ACK или RST;
• рост CPU firewall;
• packet drops на интерфейсах;
• массовые переходы соединений в состояния закрытия;
• обрывы HTTP, WebSocket и upstream-соединений.

Как отличить FIN Flood от легитимного закрытия

Признак	Легитимный FIN	FIN Flood
Существующее соединение	Присутствует	Часто отсутствует
Sequence number	Соответствует TCP-потоку	Часто случайный
Предшествующая передача данных	Обычно есть	Часто отсутствует
Частота	Связана с числом соединений	Резко превышает нормальный уровень
Распределение источников	Соответствует клиентам	Аномальное или случайное
Дальнейший обмен	ACK и встречный FIN	Неполная или бессмысленная последовательность

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

Большое количество FIN и состояний закрытия может появиться из-за внутренней проблемы.

Необходимо проверить:

• не уменьшился ли keep-alive timeout;
• не отключено ли переиспользование соединений;
• не перезапускается ли сервер;
• не закрывает ли балансировщик соединения слишком рано;
• не истекают ли upstream-тайм-ауты;
• не завершает ли приложение сокеты после каждого запроса;
• не выросло ли число реальных пользователей;
• не появилась ли ошибка обработки EOF;
• не остаются ли сокеты в CLOSE-WAIT;
• не происходит ли health-check storm.

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

• FIN packets per second;
• FIN-ACK packets per second;
• долю FIN в общем TCP-трафике;
• FIN без существующего состояния;
• количество INVALID-пакетов;
• число соединений FIN-WAIT-1;
• число соединений FIN-WAIT-2;
• число соединений CLOSE-WAIT;
• число соединений CLOSING;
• число соединений LAST-ACK;
• число соединений TIME-WAIT;
• скорость закрытия соединений;
• скорость новых подключений после закрытия;
• CPU firewall и маршрутизатора;
• packet drops;
• заполнение conntrack;
• ошибки приложений и reverse proxy.

Что искать в PCAP

Для расследования проверяют:

• наличие FIN и сочетания FIN-ACK;
• предшествующий TCP handshake;
• наличие двусторонней передачи данных;
• sequence number;
• acknowledgment number;
• попадание FIN в receive window;
• ответный ACK;
• встречный FIN;
• повторную передачу FIN;
• RST после неожиданного FIN;
• TTL или Hop Limit;
• одинаковые шаблоны пакетов от разных источников.

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

Защита от FIN Flood

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

FIN должен приниматься только в допустимом контексте существующего соединения. Пакеты вне state table необходимо отбрасывать.

Stateful firewall должен видеть оба направления потока. При асимметричной маршрутизации он может не увидеть handshake и ошибочно блокировать легитимные FIN.

2. Проверять sequence number

Совпадения адресов и портов недостаточно. FIN должен попадать в допустимое окно и соответствовать текущему состоянию потока.

3. Отбрасывать невозможные комбинации флагов

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

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

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

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

• основной таблицы conntrack;
• IDS/IPS с глубокой проверкой;
• балансировщика;
• reverse proxy;
• конечного сервера.

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

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

6. Использовать rate limiting избирательно

Ограничивать можно FIN:

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

Нельзя бездумно ограничивать все FIN: это задержит освобождение сокетов и увеличит время хранения состояний.

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

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

8. Использовать upstream Anti-DDoS

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

Безопасная настройка состояний закрытия

FIN-WAIT-2

Слишком длительное хранение FIN-WAIT-2 расходует ресурсы, если удалённая сторона никогда не отправляет свой FIN. Тайм-аут должен быть разумным, но не настолько коротким, чтобы нарушать легитимные соединения.

CLOSE-WAIT

Это состояние в основном контролирует приложение. Сетевые параметры не исправят утечку сокетов, если приложение не вызывает закрытие после получения FIN.

TIME-WAIT

Сокращать или переиспользовать TIME-WAIT следует только с пониманием рисков. Безопасность и корректность важнее косметического уменьшения числа записей.

LAST-ACK

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

Почему увеличение лимитов не является полной защитой

Увеличение таблиц и тайм-аутов может дать дополнительный запас, но создаёт новые риски:

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

Настройку лимитов необходимо сочетать с ранней фильтрацией и мониторингом.

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

SYN cookies применяются при установлении соединения и защищают от SYN Flood. FIN появляется на этапе закрытия либо имитирует этот этап.

Поэтому SYN cookies не являются прямой защитой от FIN Flood. Они полезны только в том случае, если атака одновременно содержит большое количество SYN.

Поможет ли WAF

WAF анализирует HTTP-запросы после успешного TCP-handshake. FIN вне состояния не формирует HTTP-запрос и обрабатывается раньше.

Основными средствами защиты являются:

• stateful TCP validation;
• проверка sequence number;
• фильтрация аномальных флагов;
• контроль PPS;
• защита conntrack;
• upstream-очистка.

WAF полезен против сопутствующего HTTP Flood, когда боты устанавливают соединения и атакуют приложение.

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

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

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

Это уменьшает поверхность прямой FIN-атаки на пользовательские соединения с origin: TCP-сессии посетителей завершаются на прокси-инфраструктуре, а к origin идут отдельные защищённые upstream-соединения.

Однако FIN Flood относится к L3/L4. Если поток направлен на известный IP origin и перегружает канал до дата-центра, одного reverse proxy недостаточно.

Сценарий	Роль TrafficVeil	Дополнительная защита
FIN Flood на публичный веб-домен	Веб-соединения завершаются на прокси	L3/L4-защита прокси-инфраструктуры
Прямой FIN Flood на origin	ACL блокирует посторонние подключения	Защита канала и upstream Anti-DDoS
Поддельный FIN между прокси и origin	Изолированный список источников упрощает контроль	Строгая stateful-фильтрация и мониторинг
HTTP Flood внутри соединений	WAF, ML-анализ и rate limiting	Правила под профиль приложения

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

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

Определите долю FIN и FIN-ACK, целевые порты, размеры пакетов, PPS и BPS.

Шаг 2. Проверить состояние

Выясните, сколько FIN относится к реальным соединениям, а сколько классифицируется как INVALID.

Шаг 3. Найти перегруженный компонент

Проверьте канал, маршрутизатор, firewall, conntrack, балансировщик, reverse proxy и конечный сервер.

Шаг 4. Исключить внутреннюю проблему

Убедитесь, что рост FIN не вызван перезапуском сервиса, изменением keep-alive или агрессивными тайм-аутами.

Шаг 5. Включить точечную фильтрацию

Отбрасывайте FIN вне состояния, пакеты на закрытые порты и заведомо невозможные комбинации флагов.

Шаг 6. Защитить таблицу состояний

Контролируйте заполнение conntrack и распределение соединений по стадиям закрытия. Не меняйте тайм-ауты без оценки побочных эффектов.

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

Если поток превышает возможности локального периметра, передайте оператору:

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

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

FIN Flood может быть частью смешанной атаки вместе с SYN, ACK, RST, PSH-ACK, UDP Flood и HTTP Flood.

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

Веб-сайт начал периодически терять соединения. На сервере вырос system CPU, а firewall сообщил об увеличении INVALID-трафика.

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

• многократный рост FIN PPS;
• большинство пакетов не относилось к существующим соединениям;
• использовались случайные исходные адреса и порты;
• часть пакетов имела FIN-ACK;
• HTTP-журналы не показывали роста запросов;
• число CLOSE-WAIT почти не изменилось;
• CPU firewall достиг предела раньше заполнения канала.

Это указывает на пакетный FIN Flood, направленный на stateful-проверку, а не на успешное завершение реальных соединений.

После раннего отбрасывания FIN вне состояния нагрузка на сервер уменьшилась. Основной поток был перенесён на upstream Anti-DDoS-фильтрацию, что разгрузило локальный firewall.

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

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

Соединения не смогут штатно закрываться и будут дольше занимать ресурсы.

Ошибка 2. Считать FIN-ACK заведомо вредоносным

FIN-ACK является нормальной комбинацией при завершении TCP-сеанса.

Ошибка 3. Считать любой CLOSE-WAIT атакой

Длительный CLOSE-WAIT чаще указывает на то, что приложение не закрывает сокеты.

Ошибка 4. Считать любой TIME-WAIT результатом FIN Flood

TIME-WAIT обычно растёт из-за большого числа корректно закрытых соединений.

Ошибка 5. Безопасно считать любой FIN вне состояния

При асимметричной маршрутизации firewall может не видеть начало легитимного соединения.

Ошибка 6. Оценивать только BPS

Маленькие FIN-пакеты часто атакуют производительность по PPS.

Ошибка 7. Резко уменьшать все тайм-ауты

Это может нарушить медленные и нестабильные легитимные соединения.

Ошибка 8. Удалять TIME-WAIT без понимания риска

Старые сегменты могут попасть в новое соединение с той же комбинацией адресов и портов.

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

FIN обрабатывается на TCP-уровне до формирования HTTP-запроса.

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

Злоумышленник сможет направить L3/L4-трафик непосредственно на сервер.

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

• Определён нормальный уровень FIN PPS.
• Раздельно контролируются FIN и FIN-ACK.
• Firewall проверяет состояние соединений.
• FIN вне состояния отбрасываются.
• Проверяются sequence и acknowledgment number.
• Проверена симметричность маршрутов.
• Закрыты неиспользуемые TCP-порты.
• Настроена фильтрация невозможных комбинаций флагов.
• Контролируются BPS и PPS.
• Отслеживается заполнение conntrack.
• Есть метрики FIN-WAIT-1 и FIN-WAIT-2.
• Есть метрики CLOSE-WAIT и LAST-ACK.
• Есть метрики TIME-WAIT.
• Проверена корректность закрытия сокетов приложением.
• Тайм-ауты изменяются только после тестирования.
• Используется антиспуфинг.
• Origin скрыт за reverse proxy.
• Прямой веб-доступ к origin закрыт.
• Правила охватывают IPv4 и IPv6.
• Подготовлена upstream Anti-DDoS-фильтрация.

Заключение

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

Большинство случайных FIN не сможет закрыть реальные сессии, но каждый пакет требует обработки. Высокий PPS способен перегрузить маршрутизатор, firewall, conntrack и TCP-стек даже при незаполненном канале.

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

Эффективная защита включает проверку TCP-состояния, валидацию sequence number, раннюю фильтрацию пакетов вне состояния, мониторинг стадий закрытия, антиспуфинг и upstream Anti-DDoS.

Reverse proxy и скрытие origin уменьшают поверхность прямой атаки на сайт, но не заменяют сетевую защиту, если объёмный FIN Flood направлен непосредственно на IP-адрес сервера или канал дата-центра.