RST Flood и TCP Reset Attack: как защитить сайт

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

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

Во время атаки RST может использоваться двумя принципиально разными способами:

• RST Flood — массовый поток пакетов, цель которого состоит в перегрузке канала, firewall, conntrack или TCP-стека;
• TCP Reset Attack — внедрение поддельного RST в конкретное существующее соединение, чтобы принудительно его завершить.

В первом случае основное значение имеют BPS, PPS и стоимость обработки каждого пакета. Во втором — способность атакующего подобрать параметры действующей сессии: адреса, порты и допустимый номер последовательности.

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

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

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

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

Флаг	Назначение	Характер завершения
FIN	Сообщить, что сторона больше не будет передавать данные	Штатное и согласованное закрытие
RST	Немедленно сбросить соединение или отклонить недействительный сегмент	Аварийное завершение

Действующая спецификация TCP содержится в RFC 9293. Она определяет обработку RST в зависимости от состояния соединения, номеров последовательности и полей подтверждения.

Когда RST появляется в легитимном трафике

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

Типичные причины:

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

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

Как работает штатное закрытие через FIN

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

Такой процесс позволяет:

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

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

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

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

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

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

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

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

RST обычно представляет собой небольшой TCP-пакет без значительной полезной нагрузки. Большое количество таких пакетов создаёт высокий показатель packets per second.

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

Нагрузка на stateful firewall

Устройство должно определить:

• существует ли соответствующий поток;
• каково текущее TCP-состояние;
• допустим ли RST в этом состоянии;
• следует ли удалить запись;
• не является ли пакет поддельным или некорректным.

Нагрузка на conntrack

Даже если RST не соответствует известному соединению, система выполняет поиск в таблице состояний и классифицирует пакет. При высоком PPS это расходует процессорное время.

Нарушение действующих соединений

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

Создание дополнительной нагрузки на приложение

После сброса клиенты пытаются подключиться повторно. Возникают новые TCP- и TLS-рукопожатия, авторизация, повторная отправка запросов и восстановление состояния.

Что такое TCP Reset Attack

TCP Reset Attack, или RST injection, — атака на конкретное установленное TCP-соединение. Злоумышленник формирует пакет так, будто его отправила одна из легитимных сторон, и устанавливает флаг RST.

Чтобы сброс был принят, пакет должен достаточно точно соответствовать соединению:

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

Самым сложным параметром обычно является sequence number. Современная реализация не должна принимать произвольный RST только потому, что совпали адреса и порты.

RFC 4953 рассматривает угрозу поддельных RST с подменёнными исходными адресами и отмечает историческую уязвимость TCP-соединений к подобным сбросам.

RST Flood и TCP Reset Attack: в чём разница

Критерий	RST Flood	TCP Reset Attack
Главная цель	Перегрузить инфраструктуру	Разорвать конкретное соединение
Объём	Большое количество пакетов	Иногда достаточно одного принятого RST
Точность параметров	Может быть низкой	Должна быть высокой
Sequence number	Часто случайный	Должен пройти проверку
Основной эффект	Высокий PPS, CPU и packet loss	Немедленное завершение сессии
Типичная защита	Фильтрация и Anti-DDoS	Строгая валидация RST и аутентификация

Как TCP проверяет RST

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

В упрощённом виде проверяются:

• существование соединения;
• состояние LISTEN, SYN-SENT, SYN-RECEIVED или ESTABLISHED;
• sequence number;
• acknowledgment number в некоторых состояниях;
• попадание номера в допустимое receive window;
• точное соответствие следующему ожидаемому номеру.

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

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

Что такое challenge ACK

Challenge ACK — проверочный ACK, который отправляется вместо немедленного сброса соединения, если RST выглядит потенциально относящимся к сеансу, но не соответствует строгому условию.

Механизм работает следующим образом:

1. Узел получает подозрительный RST.
2. RST находится в допустимом диапазоне, но не имеет точного ожидаемого sequence number.
3. Соединение не закрывается немедленно.
4. Узел отправляет challenge ACK.
5. Легитимная сторона может подтвердить реальное состояние соединения.
6. Поддельный или случайный RST не приводит к немедленному разрыву.

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

Blind и on-path RST Attack

Blind RST Attack

Атакующий не видит TCP-трафик между сторонами. Ему приходится угадывать:

• активную комбинацию адресов и портов;
• направление потока;
• текущее TCP-окно;
• подходящий sequence number.

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

On-path RST Attack

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

Против on-path-нарушителя одной проверки sequence number недостаточно: нужные значения ему уже известны. Требуются защита маршрутизации, сегментация, шифрование и аутентификация критичных протоколов.

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

Долгоживущие HTTP-соединения

HTTP keep-alive, HTTP/2 и WebSocket могут передавать много запросов через одно TCP-соединение. Его сброс затрагивает сразу несколько операций.

Загрузка и передача больших файлов

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

Соединения reverse proxy с origin

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

Базы данных

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

BGP-сессии

BGP работает поверх долгоживущих TCP-соединений. Их сброс способен вызвать повторное установление соседства и перерасчёт маршрутов.

RFC 6862 отдельно отмечает, что TLS сам по себе не решает проблему поддельного TCP FIN или RST для маршрутизирующих протоколов, и рекомендует применять надлежащие механизмы аутентификации.

VPN и туннели поверх TCP

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

Удалённое администрирование

Прерывание SSH-сеанса может остановить выполняемую операцию или лишить администратора доступа во время инцидента.

Как RST Flood влияет на HTTPS

RST работает на уровне TCP и не обязан расшифровывать TLS. Если допустимый сброс принят TCP-стеком, зашифрованное HTTPS-соединение завершается до обработки TLS или HTTP.

Последствия:

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

TLS защищает конфиденциальность и целостность передаваемых данных, но не предотвращает обработку TCP RST нижележащим транспортным уровнем.

Можно ли использовать IP spoofing

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

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

IP spoofing усложняет реагирование:

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

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

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

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

Такой вариант не обеспечивает гарантированного высокого коэффициента усиления. Размер запроса и RST часто сопоставим, а реакция зависит от TCP-флагов, состояния порта и реализации.

Корректнее классифицировать его как TCP reflection, а не как мощный amplification-вектор уровня Memcached или DNS.

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

Характерные признаки:

• резкий рост TCP-пакетов с RST или RST-ACK;
• увеличение RST PPS;
• много пакетов, не относящихся к существующим соединениям;
• случайные sequence number;
• множество исходных адресов и портов;
• рост INVALID на stateful firewall;
• высокая нагрузка CPU сетевого оборудования;
• packet drops на интерфейсах;
• обрывы установленных соединений;
• увеличение повторных подключений;
• рост ошибок соединения в приложении;
• ошибки 499, 502, 503 или 504 в зависимости от архитектуры.

Как отличить RST Flood от обычных сбросов

Признак	Обычные RST	RST Flood
Интенсивность	Соответствует числу соединений	Резко превышает фоновый уровень
Состояние	Часто относится к реальным потокам	Большая доля пакетов вне состояния
Sequence number	Соответствует текущему обмену	Часто случайный или повторяющийся
Источники	Известные клиенты и серверы	Множество неожиданных адресов
Распределение портов	Связано с сервисами	Может быть случайным
Влияние	Единичные ошибки	Массовые обрывы или перегрузка

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

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

Перед классификацией необходимо проверить:

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

Как определить отправителя RST

В распределённой инфраструктуре пакет может формировать не только конечный сервер. RST способен отправить:

• клиент;
• origin-сервер;
• reverse proxy;
• L4-балансировщик;
• межсетевой экран;
• IDS или IPS в режиме блокировки;
• NAT-шлюз;
• провайдерское оборудование;
• защитный сервис;
• злоумышленник, подделывающий один из адресов.

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

• TTL или Hop Limit;
• IP ID в IPv4;
• TCP-опции;
• размер окна;
• MAC-адрес на локальном участке;
• время появления пакета в разных точках захвата;
• sequence и acknowledgment number;
• журналы промежуточных устройств.

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

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

• RST packets per second;
• RST bandwidth;
• отношение RST к общему TCP-трафику;
• RST по направлению: входящие и исходящие;
• долю RST внутри известных соединений;
• долю RST с точным sequence number;
• количество challenge ACK;
• INVALID-пакеты на firewall;
• заполнение conntrack;
• число оборванных TCP-соединений;
• скорость повторных подключений;
• ошибки TLS-handshake;
• ошибки reverse proxy;
• потери пакетов;
• CPU маршрутизатора и firewall;
• system CPU и softirq на сервере.

Что искать в PCAP

При расследовании анализируют:

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

Нельзя судить только по наличию RST. Главный вопрос — был ли пакет допустим для конкретного состояния и почему он появился.

Защита от объёмного RST Flood

1. Отбрасывать RST вне известных состояний

Stateful firewall может разрешать RST только для существующих соединений. Пакеты, не соответствующие state table, отбрасываются.

При этом firewall должен видеть оба направления трафика. В асимметричной сети он может ошибочно считать легитимный RST пакетом вне состояния.

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

Если очевидно недействительный RST сначала проходит IDS, NAT, conntrack и балансировщик, каждый уровень расходует ресурсы.

Предпочтительно удалять такой трафик:

1. у Anti-DDoS-провайдера;
2. на аппаратной границе;
3. на маршрутизаторе;
4. до дорогостоящей stateful-обработки;
5. до конечного сервера.

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

При небольших RST-пакетах предел PPS часто достигается раньше предела канала. Производительность оборудования необходимо оценивать не только в гигабитах.

4. Ограничивать аномальные классы трафика

Rate limiting можно применять к RST:

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

Общий жёсткий лимит всех RST способен задержать штатное освобождение ресурсов и ухудшить работу сервиса.

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

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

6. Использовать upstream-фильтрацию

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

Защита от TCP Reset Attack

Строгая проверка RST

Операционная система должна использовать современную обработку RST с точной проверкой sequence number и challenge ACK для подозрительных пакетов.

Обновление ОС и сетевого оборудования

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

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

Аутентификация критичных TCP-сессий

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

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

Защита от on-path-доступа

Следует:

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

Автоматическое восстановление соединений

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

• повторно подключаться с задержкой;
• использовать exponential backoff;
• не создавать reconnect storm;
• безопасно повторять только идемпотентные операции;
• восстанавливать подписки и сессии;
• проверять состояние транзакции перед повтором.

Почему бесконтрольное переподключение опасно

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

• новые SYN и SYN-ACK;
• TLS-handshake;
• аутентификация;
• восстановление WebSocket;
• повторные запросы к API;
• подключения к базам данных;
• пересоздание кэша и сессий.

Даже после прекращения RST Flood инфраструктура может оставаться перегруженной из-за reconnect storm. Клиенты и внутренние сервисы должны использовать случайную задержку и ограничение повторов.

Помогут ли SYN cookies

SYN cookies защищают от исчерпания состояния на этапе SYN. Они не предназначены для проверки RST внутри уже установленного соединения и не останавливают объёмный поток сбросов.

Если атака одновременно содержит SYN Flood и RST Flood, cookies помогут только с SYN-компонентом.

Поможет ли WAF

WAF работает на уровне HTTP после создания TCP-соединения. RST может завершить соединение до формирования полноценного HTTP-запроса.

Поэтому WAF не является основным средством защиты от RST Flood. Необходимы:

• проверка TCP-состояния;
• валидация sequence number;
• фильтрация по PPS;
• аппаратные ACL;
• защита conntrack;
• upstream Anti-DDoS.

WAF полезен против сопутствующей атаки, если после TCP-соединения боты начинают отправлять вредоносные HTTP-запросы.

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

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

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

Это снижает риск прямого TCP Reset Attack на соединения пользователей с origin, поскольку пользователи подключаются к прокси, а не непосредственно к серверу.

Однако RST Flood относится преимущественно к транспортному уровню. Если злоумышленник знает IP origin и направляет на него объёмный поток, TrafficVeil не может освободить уже насыщенный канал дата-центра. Нужна upstream-фильтрация.

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

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

Шаг 1. Подтвердить рост RST

Определите долю RST и RST-ACK, PPS, BPS, целевые порты и количество источников.

Шаг 2. Определить характер атаки

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

Шаг 3. Найти отправителя

Сравните сетевые дампы до и после firewall, reverse proxy и балансировщика. Определите, где впервые появляется RST.

Шаг 4. Проверить инфраструктуру

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

Шаг 5. Отфильтровать пакеты вне состояния

Разрешайте RST только для известных соединений и проверяйте корректность sequence number. Перед строгой фильтрацией проверьте симметричность маршрутов.

Шаг 6. Включить upstream-защиту

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

Шаг 7. Ограничить reconnect storm

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

Шаг 8. Сохранить доказательства

Сохраните:

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

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

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

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

• резкий рост RST и RST-ACK;
• большинство пакетов не относилось к существующим соединениям;
• sequence number выглядели случайными;
• firewall тратил значительные ресурсы на state lookup;
• небольшая часть RST попадала в диапазоны активных соединений;
• после обрывов клиенты одновременно переподключались;
• нагрузку дополнительно усиливали TLS-handshake.

Инцидент сочетал объёмный RST Flood и попытки сбросить реальные соединения. Ранняя фильтрация пакетов вне состояния снизила PPS на сервере, а upstream Anti-DDoS убрал основную часть потока до локального firewall.

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

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

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

Ошибка 2. Считать любой рост RST атакой

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

Ошибка 3. Проверять только IP-адрес

Для определения допустимости RST нужно учитывать порты, состояние и sequence number.

Ошибка 4. Использовать только blacklist

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

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

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

Ошибка 6. Игнорировать challenge ACK

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

Ошибка 7. Считать TLS полной защитой

TLS защищает прикладные данные, но TCP-стек обрабатывает RST на нижележащем уровне.

Ошибка 8. Не учитывать переподключения

Reconnect storm может продолжать перегружать систему после уменьшения входящего RST-потока.

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

Локальная фильтрация не освобождает внешний канал и не защищает слабое граничное оборудование.

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

Раскрытый IP позволяет направить RST Flood непосредственно на сервер в обход reverse proxy.

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

• Определён нормальный уровень RST PPS.
• Раздельно контролируются входящие и исходящие RST.
• Отслеживаются RST и RST-ACK.
• Firewall проверяет состояние соединения.
• Используется строгая валидация sequence number.
• Поддерживается challenge ACK.
• Обновлены ОС и сетевое оборудование.
• Проверена симметричность маршрутов.
• Закрыты ненужные TCP-порты.
• Пакеты вне состояния отбрасываются как можно раньше.
• Настроен мониторинг conntrack.
• Контролируются PPS, BPS и CPU firewall.
• Критичные TCP-сессии используют аутентификацию.
• Включён антиспуфинг.
• Origin скрыт за reverse proxy.
• Прямой веб-доступ к origin запрещён.
• Правила действуют для IPv4 и IPv6.
• Приложения используют контролируемое переподключение.
• Провайдер предоставляет upstream Anti-DDoS.
• Подготовлен план сбора PCAP и NetFlow.

Заключение

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

При RST Flood большинство случайных пакетов может не разорвать реальные соединения, но каждый из них требует обработки. Высокий PPS перегружает маршрутизаторы, firewall, conntrack и сетевой стек.

TCP Reset Attack представляет другую угрозу: правильно сформированный RST способен немедленно завершить HTTPS, WebSocket, соединение с базой данных, управляющий сеанс или маршрутизирующее соседство.

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

Reverse proxy и скрытие origin уменьшают поверхность прямой атаки на сайт, но при объёмном RST Flood на сетевом уровне необходима отдельная L3/L4 Anti-DDoS-защита у провайдера или в scrubbing-центре.