UDP Flood и UDP Fragmentation Flood: признаки и защита

UDP Flood — это атака на доступность сети или сервера, при которой цель получает большое количество UDP-датаграмм. Поток способен заполнить интернет-канал, перегрузить маршрутизатор, межсетевой экран, систему обнаружения атак или сетевой стек операционной системы. Если UDP-пакеты направляются на закрытые порты, сервер также может тратить ресурсы на их проверку и формирование ответов ICMP Destination Unreachable.

UDP Fragmentation Flood — разновидность сетевой атаки, при которой используются фрагментированные IP-пакеты или большое количество отдельных фрагментов. Получателю приходится хранить их, сопоставлять по идентификаторам и пытаться собрать исходные датаграммы. Неполные, повторяющиеся, перекрывающиеся или специально распределённые фрагменты увеличивают нагрузку на механизмы reassembly — обратной сборки IP-пакетов.

Обе атаки могут привести к замедлению сайта, потере пакетов, росту задержек и полной недоступности инфраструктуры. При этом веб-приложение может не получить ни одного подозрительного HTTP-запроса: перегрузка происходит раньше — на сетевом или транспортном уровне.

Что такое UDP

UDP, или User Datagram Protocol, — транспортный протокол, работающий поверх IP. Он описан в RFC 768 и предоставляет приложениям простой механизм отправки датаграмм с минимальным количеством служебных операций. В отличие от TCP, UDP не устанавливает полноценное соединение перед передачей данных и самостоятельно не гарантирует доставку, сохранение порядка или защиту от дублирования.

UDP-заголовок содержит четыре основных поля:

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

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

Эти же свойства упрощают его использование в DDoS-атаках. Отправителю не требуется ждать подтверждения соединения или ответа сервера. Пакеты можно передавать с высокой скоростью, а в некоторых сетях — с подменённым исходным IP-адресом.

Что такое UDP Flood

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

В зависимости от сценария целью становится:

• интернет-канал организации;
• маршрутизатор;
• межсетевой экран;
• балансировщик нагрузки;
• система IDS/IPS;
• NAT-устройство;
• сетевой стек сервера;
• конкретный UDP-сервис;
• DNS-инфраструктура;
• VPN-шлюз;
• игровой или медиасервер.

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

Пример объёмной UDP-атаки

Предположим, канал origin-сервера имеет пропускную способность 1 Гбит/с. Ботнет направляет на него UDP-трафик со скоростью 3 Гбит/с. Даже если сервер и firewall способны обработать пакеты, входящий канал оказывается переполнен. Легитимные TCP- и HTTPS-пакеты начинают теряться ещё до достижения приложения.

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

Пример атаки большим количеством небольших пакетов

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

• прочитать заголовок;
• проверить маршрут;
• применить правила firewall;
• обновить счётчики;
• проверить состояние NAT;
• передать пакет следующему компоненту;
• записать событие в журнал или отправить его в IDS/IPS.

В результате узким местом становится не количество переданных байтов, а производительность обработки пакетов. Поэтому при расследовании UDP Flood необходимо одновременно анализировать BPS и PPS.

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

Упрощённый сценарий выглядит следующим образом:

1. Атакующий определяет IP-адрес цели или диапазон адресов.
2. Ботнет начинает отправлять UDP-пакеты с большого количества устройств.
3. Пакеты направляются на один порт, несколько портов или случайные порты.
4. Канал и сетевое оборудование обрабатывают растущий поток.
5. Легитимные пакеты задерживаются или теряются.
6. Пользователи сталкиваются с ошибками соединения и недоступностью сайта.

Атакующий может менять параметры трафика:

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

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

UDP Flood на открытые и закрытые порты

Атака на открытый порт

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

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

Например, поток может быть направлен на DNS-сервер, VPN-шлюз или игровой сервер. Пакеты не обязательно должны соответствовать протоколу приложения: даже проверка и отбрасывание некорректных данных требует ресурсов.

Атака на закрытый порт

Когда пакет поступает на порт, где нет принимающего приложения, операционная система может проверить состояние порта и сформировать ICMP-сообщение Port Unreachable. При большом потоке такие операции создают дополнительную нагрузку.

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

Атака на случайные порты

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

Характерный признак — резкий рост числа UDP-пакетов при очень широком распределении destination port. Если защищаемая инфраструктура использует только несколько известных UDP-сервисов, обращения к тысячам случайных портов являются сильным индикатором аномалии.

UDP Flood и UDP Amplification — не одно и то же

Эти понятия часто смешивают, но они описывают разные характеристики атаки.

При прямом UDP Flood каждый бот самостоятельно создаёт поток к цели. При amplification-атаке бот отправляет небольшой запрос серверу-отражателю и указывает IP жертвы как адрес отправителя. Сервер отвечает жертве, а при значительном размере ответа возникает усиление.

Например, если запрос размером 80 байт вызывает ответ размером 4 000 байт, условный коэффициент усиления равен 50. Исходящий поток атакующего в 200 Мбит/с способен создать около 10 Гбит/с ответного трафика без учёта накладных расходов и реального поведения сети.

UDP Flood может сочетаться с DNS Amplification или NTP Amplification в рамках одной кампании, но способы обнаружения и фильтрации будут отличаться.

Что такое UDP Fragmentation Flood

Размер IP-пакета ограничивается значением MTU — Maximum Transmission Unit — на сетевом пути. Если датаграмма превышает допустимый размер и фрагментация разрешена, она может быть разделена на несколько IP-фрагментов.

Каждый фрагмент передаётся отдельно. Получатель использует служебные поля IP-заголовка, чтобы определить:

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

При UDP Fragmentation Flood атакующий отправляет большое количество фрагментов, заставляя сетевые компоненты и конечные системы тратить ресурсы на проверку, хранение и reassembly.

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

Как происходит фрагментация UDP-пакета

UDP-датаграмма передаётся внутри IP-пакета. Если пакет больше MTU и должен пройти через участок сети с меньшим допустимым размером, IPv4 допускает разделение на фрагменты при условии, что фрагментация не запрещена флагом DF.

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

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

Упрощённый пример

Предположим, исходная IP-датаграмма после добавления заголовков имеет размер 4 000 байт, а допустимый MTU на пути составляет 1 500 байт. Датаграмма должна быть разделена на несколько частей. Получатель не сможет передать данные UDP-приложению, пока не получит необходимые фрагменты и не соберёт исходный пакет.

Если последний фрагмент не приходит, промежуточные данные некоторое время остаются в очереди reassembly. Один неполный набор создаёт небольшую нагрузку. Тысячи или миллионы одновременно незавершённых наборов способны занять память и процессорное время.

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

Поток корректных фрагментированных датаграмм

Атакующий отправляет большой объём формально корректных фрагментированных пакетов. Система получает все части, собирает датаграммы и передаёт их выше по стеку. Нагрузка создаётся одновременно:

• объёмом трафика;
• количеством фрагментов;
• операциями сопоставления;
• выделением памяти;
• сборкой датаграмм;
• дальнейшей обработкой UDP.

Поток неполных наборов

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

Поток изолированных последующих фрагментов

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

Множество мелких фрагментов

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

Перекрывающиеся фрагменты

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

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

Фрагменты с большим количеством идентификаторов

Атакующий распределяет поток между множеством значений IP Identification, адресов и протокольных комбинаций. Защитному устройству приходится поддерживать большое число независимых контекстов reassembly.

Чем UDP Fragmentation Flood отличается от обычного UDP Flood

UDP Fragmentation Flood может одновременно являться обычной объёмной атакой. Различие заключается в дополнительной нагрузке, возникающей из-за фрагментации.

Почему фрагментация создаёт проблемы

Потеря одного фрагмента разрушает всю датаграмму

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

Требуется временное хранение

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

Не все фрагменты содержат транспортные порты

Обычное правило firewall может опираться на source port и destination port. Но эти поля находятся в UDP-заголовке, который обычно присутствует в начале датаграммы. Последующие IP-фрагменты требуют отдельной логики обработки.

Разные компоненты могут собирать пакет по-разному

Маршрутизатор, firewall, IDS/IPS и конечный сервер способны по-разному относиться к подозрительным или перекрывающимся фрагментам. Несогласованность создаёт риск обхода проверки: защитное устройство реконструирует один вариант пакета, а конечная система — другой.

Высокая скорость повышает риск ошибок

RFC 4963 описывает проблемы IPv4 reassembly на высоких скоростях, связанные в том числе с ограниченным пространством поля Identification и возможностью неправильного сопоставления фрагментов.

Какие компоненты страдают при атаке

Признаки UDP Flood

Для обнаружения недостаточно смотреть только на посещаемость сайта. UDP-трафик может вообще не отражаться в access.log веб-сервера.

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

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

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

• рост softirq и системной загрузки;
• потери пакетов в интерфейсе;
• переполнение UDP receive buffer;
• увеличение ошибок и сбросов;
• рост задержки сетевых операций;
• ухудшение работы TCP и HTTPS;
• замедление DNS, VPN или других UDP-сервисов;
• падение доступности при нормальной загрузке веб-приложения.

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

• сайт периодически перестаёт открываться;
• соединение устанавливается слишком долго;
• возникают ошибки тайм-аута;
• часть пользователей открывает сайт, а часть — нет;
• перестают работать DNS, VPN, игры или голосовые сервисы;
• время ответа резко меняется без обновления приложения.

Признаки UDP Fragmentation Flood

Помимо общего роста UDP-трафика, появляются признаки, связанные непосредственно с IP-фрагментами:

• резкий рост количества fragmented packets;
• аномально высокая доля пакетов с флагом More Fragments;
• большое число ненулевых fragment offset;
• рост reassembly failures;
• увеличение числа reassembly timeouts;
• переполнение очереди фрагментов;
• множество наборов без первого или последнего фрагмента;
• повторяющиеся и перекрывающиеся фрагменты;
• необычно маленький размер фрагментов;
• большое количество разных IP Identification;
• рост потребления памяти сетевым стеком;
• различия между данными firewall и конечного сервера.

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

Метрики необходимо сравнивать с нормальным профилем конкретной инфраструктуры. Для DNS-сервера большой объём UDP является обычным, а для веб-сервера, который обслуживает только HTTP и HTTPS, внезапное появление крупного UDP-потока почти всегда требует расследования.

Как отличить атаку от легитимного UDP-трафика

Некоторые приложения законно создают большой UDP-поток: видеосвязь, игры, VPN, DNS, потоковое аудио и телеметрия. Поэтому блокировка всего UDP способна нарушить работу сервиса.

При анализе учитывают:

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

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

Последствия UDP Flood

• переполнение интернет-канала;
• потеря легитимных пакетов;
• рост сетевой задержки;
• перегрузка маршрутизаторов и firewall;
• нестабильность DNS и VPN;
• недоступность сайта и API;
• разрыв пользовательских сессий;
• перегрузка сетевого стека сервера;
• рост расходов на трафик и облачные ресурсы;
• срабатывание автоматического масштабирования;
• нарушение SLA;
• маскировка параллельных попыток взлома.

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

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

1. Фильтровать ненужные UDP-порты

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

При этом локальное правило firewall защищает серверные ресурсы, но не спасает уже переполненный канал. Для объёмных атак фильтрация должна выполняться до узкого места.

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

Провайдер или Anti-DDoS-сеть может отбрасывать нежелательные пакеты до их поступления в инфраструктуру клиента. Для крупных атак используются распределённые точки присутствия и центры очистки трафика.

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

3. Разделять сервисы

DNS, VPN, игровые сервисы и веб-приложение желательно не размещать за одним узким сетевым каналом без изоляции. Атака на один UDP-сервис не должна автоматически выводить из строя основной сайт.

4. Ограничивать скорость

Rate Limiting может применяться по:

• IP-адресу;
• подсети;
• ASN;
• порту назначения;
• типу пакета;
• размеру;
• общей скорости UDP;
• числу пакетов в секунду.

Ограничение только по одному IP малоэффективно против распределённого ботнета. Необходимы агрегированные лимиты для подсетей, ASN, портов и всей инфраструктуры.

5. Фильтровать подменённые адреса

Сетевые операторы могут применять ingress- и egress-фильтрацию, препятствующую прохождению пакетов с адресами, которые не должны появляться в конкретной сети. Это особенно важно для уменьшения возможности отражённых UDP-атак.

6. Контролировать ICMP-ответы

Скорость генерации ICMP Port Unreachable следует ограничивать. Полное бездумное отключение ICMP тоже может создать проблемы, поскольку он используется для диагностики и работы сетевых механизмов, включая Path MTU Discovery.

7. Настроить мониторинг BPS и PPS

Оповещение только по объёму трафика не обнаружит атаку небольшими пакетами. Нужно контролировать оба показателя, а также распределение по протоколам и портам.

8. Защитить DNS отдельно

Авторитетные DNS-серверы должны иметь собственную устойчивую инфраструктуру, резервирование и защиту от UDP Flood. Недоступность DNS сделает сайт недоступным, даже если его веб-сервер продолжает работать.

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

Ограничивать количество ожидающих сборки наборов

Система не должна бесконечно хранить фрагменты. Необходимы ограничения на:

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

Отбрасывать явно некорректные фрагменты

К подозрительным относятся:

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

Нормализовать трафик до IDS/IPS

Firewall, IDS/IPS и конечная система должны одинаково интерпретировать фрагменты. Нормализация уменьшает риск, что защитное устройство разрешит набор, который сервер соберёт иначе.

Ограничивать фрагменты без начальной части

Большое количество non-initial fragments затрудняет фильтрацию по портам. Для них можно применять отдельные пороги и правила, учитывая легитимный профиль сети.

Избегать ненужной фрагментации в собственных сервисах

RFC 8085 рекомендует UDP-приложениям учитывать ограничения размера сообщений и проблемы IP-фрагментации. UDP не содержит встроенного контроля перегрузки, а потеря одного фрагмента приводит к потере всей датаграммы.

Для собственных приложений полезно:

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

Поможет ли reverse proxy

Обычный HTTP reverse proxy защищает сайт на прикладном уровне: принимает HTTP/HTTPS, анализирует запросы, применяет WAF, Rate Limiting, антибот-фильтрацию и кэширование. Но произвольный UDP Flood направлен не на HTTP и может вообще не проходить через такой прокси.

Возможны три сценария:

1. Атака направлена на IP защитной сети. Нужна способность самой сети поглощать и фильтровать UDP на L3/L4.
2. Атака направлена напрямую на origin. Канал origin может быть перегружен в обход reverse proxy.
3. Атака направлена на отдельный UDP-сервис. Требуется специализированная защита этого сервиса или сетевого протокола.

Поэтому подключение сайта к TrafficVeil помогает скрыть origin IP веб-сервера, отфильтровать HTTP-атаки и не передавать вредоносные веб-запросы на origin. Но защита от прямого объёмного UDP Flood также требует:

• закрытого origin IP;
• правил firewall, разрешающих HTTP-трафик только от прокси;
• upstream-защиты канала;
• защищённой DNS-инфраструктуры;
• отдельной фильтрации действительно используемых UDP-сервисов.

Нельзя обещать полноценную защиту от любого UDP Flood только за счёт WAF: WAF анализирует веб-запросы, а UDP Flood может перегружать инфраструктуру до появления HTTP.

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

1. Подтвердить протокол атаки. Проверить, что рост нагрузки связан именно с UDP.
2. Определить BPS и PPS. Это покажет, перегружен канал или обработка пакетов.
3. Найти порты назначения. Установить, атакуется конкретный сервис или случайный диапазон.
4. Проверить фрагментацию. Оценить долю фрагментов, offsets, тайм-ауты и ошибки сборки.
5. Определить узкое место. Канал, маршрутизатор, firewall, сервер или приложение.
6. Связаться с провайдером. Если канал заполнен, локальная фильтрация не решит проблему.
7. Закрыть ненужные UDP-порты. Лучше сделать это на внешнем периметре.
8. Ввести временные лимиты. Ограничить подозрительные порты, сети и фрагменты.
9. Сохранить сетевые данные. Зафиксировать NetFlow, PCAP, графики и журналы.
10. Проверить параллельные события. Исключить попытку взлома под прикрытием DDoS.

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

• точное время начала и завершения атаки;
• пиковые BPS и PPS;
• протоколы и порты;
• размеры пакетов;
• список основных IP и ASN;
• географическое распределение;
• долю фрагментированных пакетов;
• примеры первых и последующих фрагментов;
• число reassembly failures и timeouts;
• потери на интерфейсах;
• нагрузку маршрутизаторов и firewall;
• принятые меры и время их применения;
• небольшой репрезентативный PCAP без лишних персональных данных.

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

• Блокировка UDP только на сервере. Канал уже занят до применения локального правила.
• Контроль только гигабитов. Небольшие пакеты могут перегрузить оборудование высоким PPS.
• Блокировка одного порта. Атакующий переключается на случайные порты.
• Ограничение только по IP. Ботнет распределяет поток между тысячами адресов.
• Разрешение всех фрагментов. Это создаёт нагрузку и риск обхода фильтрации.
• Полный запрет фрагментов без анализа. Некоторые легитимные сервисы могут перестать работать.
• Отключение всего ICMP. Это нарушает диагностику и может повредить Path MTU Discovery.
• Открытый origin IP. Атакующий обходит reverse proxy.
• Общий канал для всех сервисов. Атака на VPN или DNS выводит из строя сайт.
• Отсутствие базового профиля. Команда не знает, какой UDP-трафик является нормальным.

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

• определены все легитимные UDP-сервисы;
• неиспользуемые UDP-порты закрыты;
• фильтрация выполняется до узкого интернет-канала;
• контролируются BPS и PPS;
• установлены пороги для портов, подсетей и ASN;
• настроено оповещение о резком росте UDP;
• отдельно отслеживаются IP-фрагменты;
• ограничены очереди и время reassembly;
• подозрительные перекрывающиеся фрагменты отбрасываются;
• проверена согласованность firewall, IDS/IPS и сервера;
• DNS имеет отдельную DDoS-защиту и резервирование;
• origin IP веб-сервера не раскрыт;
• origin принимает веб-трафик только от reverse proxy;
• подготовлены контакты провайдера и план реагирования;
• после атаки выполняется проверка на сопутствующий взлом.