
ICMP Flood — это атака на доступность сети, сервера или сетевого оборудования с помощью большого количества ICMP-сообщений. Поток способен заполнить интернет-канал, повысить нагрузку на маршрутизаторы и межсетевые экраны, занять ресурсы сетевого стека и вызвать потерю легитимных пакетов.
Ping Flood — наиболее известная разновидность ICMP Flood. При такой атаке цель получает большое количество ICMP Echo Request — тех же запросов, которые использует обычная команда ping. Получатель проверяет каждый пакет и при стандартном поведении формирует Echo Reply. При достаточной интенсивности атакующий создаёт двойную нагрузку: входящий поток запросов и исходящий поток ответов.
ICMP Flood не обязательно содержит вредоносный код и не пытается войти в административную панель. Его задача — нарушить доступность. Сайт может не получить ни одного подозрительного HTTP-запроса, но перестать открываться из-за переполненного канала или перегруженного сетевого оборудования.
Что такое ICMP
ICMP расшифровывается как Internet Control Message Protocol. Он используется устройствами для передачи служебной информации о состоянии сети, доступности узлов и ошибках доставки IP-пакетов.
ICMP не является заменой TCP или UDP и обычно не используется для передачи прикладных данных сайта. Он дополняет IP и помогает сетевым узлам сообщать о проблемах.
К распространённым ICMP-сообщениям относятся:
- Echo Request;
- Echo Reply;
- Destination Unreachable;
- Time Exceeded;
- Redirect;
- Parameter Problem.
Согласно RFC 792, Echo Request имеет тип 8, а Echo Reply — тип 0. Для формирования ответа источник и получатель меняются местами, пересчитывается контрольная сумма, а данные исходного Echo Request возвращаются отправителю.
ICMP необходим для нормальной эксплуатации сети. Он применяется при диагностике, обнаружении недоступных узлов, определении проблем маршрутизации и передаче информации о необходимости изменить размер пакета.
Поэтому стратегия «полностью заблокировать весь ICMP» не всегда является безопасной. Она может скрыть диагностику, нарушить Path MTU Discovery и затруднить определение сетевых неисправностей.
Как работает обычный ping
Утилита ping проверяет доступность узла и приблизительное время прохождения пакета до цели и обратно.
Упрощённый процесс выглядит так:
- клиент отправляет ICMP Echo Request;
- пакет проходит через сеть к целевому узлу;
- получатель обрабатывает запрос;
- получатель создаёт Echo Reply;
- ответ возвращается клиенту;
- клиент вычисляет задержку и фиксирует наличие или потерю ответа.
RFC 1122 предусматривает реализацию функции ICMP Echo на интернет-хостах: узел принимает Echo Request и отправляет соответствующий Echo Reply.
В обычной ситуации отправляется несколько запросов с небольшим интервалом. Такой трафик практически не влияет на производительность. Во время Ping Flood частота запросов увеличивается в тысячи или миллионы раз, а источниками могут выступать тысячи устройств.
Что такое ICMP Flood
ICMP Flood — более широкое понятие, чем Ping Flood. Оно охватывает массовую отправку различных ICMP-сообщений, направленную на истощение ресурсов цели или промежуточной инфраструктуры.
Атакующий может использовать:
- Echo Request;
- Echo Reply;
- Destination Unreachable;
- Time Exceeded;
- пакеты нестандартного размера;
- фрагментированные ICMP-пакеты;
- случайное сочетание типов и кодов;
- ICMPv6-сообщения;
- подменённые исходные IP-адреса.
Конкретный эффект зависит от типа пакетов, объёма потока и того, как маршрутизаторы, firewall и операционная система обрабатывают полученные сообщения.
Подключите домен и посмотрите живую ленту: кто пришёл, с какой сети, что запрашивал и по какому правилу был пропущен или заблокирован.
Что такое Ping Flood
Ping Flood — массовая отправка ICMP Echo Request. Каждый корректный запрос может вызвать Echo Reply, поэтому цель расходует ресурсы на приём, проверку и формирование ответного пакета.
Главные параметры Ping Flood:
- количество пакетов в секунду;
- объём трафика в битах в секунду;
- размер Echo Request;
- количество источников;
- наличие подменённых адресов;
- соотношение входящего и исходящего потока;
- распределение атаки по IP-адресам цели.
Небольшой сервер может столкнуться с отказом при сравнительно умеренном потоке, если его канал, виртуальная сеть или firewall имеют низкие лимиты. Для крупной инфраструктуры потребуется существенно больший объём или сочетание Ping Flood с другими векторами.
Чем ICMP Flood отличается от Ping Flood
| Параметр | ICMP Flood | Ping Flood |
|---|---|---|
| Определение | Общее семейство атак через ICMP | Разновидность ICMP Flood через Echo Request |
| Типы сообщений | Различные типы и коды ICMP | Преимущественно Echo Request, тип 8 |
| Ожидаемая реакция | Зависит от типа сообщения | Формирование Echo Reply |
| Основная цель | Канал, сетевой стек или оборудование | Канал и обработка Echo-запросов |
| Простота обнаружения | Зависит от структуры трафика | Обычно заметен по росту Echo Request |
Таким образом, любой Ping Flood относится к ICMP Flood, но не любой ICMP Flood является Ping Flood.
Как проходит ICMP Flood
Типичный сценарий состоит из нескольких этапов:
- Атакующий определяет IP-адрес сервера, маршрутизатора или другого узла.
- Ботнет начинает отправлять ICMP-пакеты.
- Поток проходит через канал и сетевое оборудование.
- Firewall проверяет пакеты и применяет правила.
- Операционная система обрабатывает разрешённые сообщения.
- Для Echo Request могут формироваться Echo Reply.
- При превышении возможностей инфраструктуры растут задержки и потери.
- Обычные пользователи теряют доступ к сайту и другим сервисам.
Атака может быть направлена не только на конечный сервер. Целью способны стать:
- маршрутизатор;
- межсетевой экран;
- VPN-шлюз;
- балансировщик;
- интернет-канал;
- виртуальный сетевой интерфейс;
- диапазон публичных IP-адресов;
- система обнаружения вторжений.
Почему ICMP Flood способен вывести сайт из строя
Веб-сайт обычно работает через HTTP или HTTPS поверх TCP. Но это не означает, что ICMP не может повлиять на его доступность.
HTTPS и ICMP используют общие компоненты:
- входящий интернет-канал;
- маршрутизаторы;
- сетевые интерфейсы;
- firewall;
- операционную систему;
- часть процессорных и сетевых ресурсов.
Если ICMP-поток заполняет канал, TCP-пакеты начинают теряться. Браузер повторно передаёт данные, увеличивает задержку и в итоге показывает ошибку соединения. В access.log веб-сервера при этом может не быть заметного роста, поскольку HTTPS-запросы до приложения не доходят.
Пример перегрузки канала
Сервер подключён через канал 1 Гбит/с. Обычная нагрузка составляет 150 Мбит/с. Во время атаки поступает 1,5 Гбит/с ICMP-трафика.
Суммарный входящий поток превышает доступную пропускную способность:
150 Мбит/с + 1 500 Мбит/с = 1 650 Мбит/с.
Даже если firewall отбрасывает ICMP, он делает это после прохождения внешнего канала. Канал уже переполнен, поэтому легитимный HTTPS-трафик теряется вместе с вредоносным.
Пример перегрузки количеством пакетов
Канал может оставаться формально свободным, но оборудование не справляется с количеством пакетов. Маршрутизатор способен передавать большие пакеты на полной скорости, но достигает предела PPS при потоке небольших сообщений.
Например, два потока имеют одинаковую скорость 500 Мбит/с:
- первый состоит из крупных пакетов;
- второй — из очень маленьких ICMP-пакетов.
Во втором случае устройство выполняет намного больше операций в секунду. Поэтому анализ только мегабитов или гигабит не показывает полную картину.
Основные разновидности ICMP Flood
ICMP Echo Request Flood
Классический Ping Flood. Цель получает большое количество Echo Request и при стандартной настройке отвечает Echo Reply.
ICMP Echo Reply Flood
На цель направляется поток Echo Reply, хотя она не отправляла соответствующие запросы. Такие пакеты могут быть сразу отброшены, но канал и сетевые устройства всё равно тратят ресурсы на их передачу и проверку.
ICMP Destination Unreachable Flood
Атакующий отправляет большое количество сообщений Destination Unreachable. Они могут создавать нагрузку на сетевой стек и влиять на обработку существующих соединений, если система неправильно доверяет содержимому ICMP-сообщений.
Современные реализации должны проверять контекст и не завершать соединения исключительно на основании неподтверждённого или несоответствующего сообщения.
ICMP Time Exceeded Flood
Сообщение Time Exceeded обычно возникает при достижении нулевого TTL или истечении времени сборки фрагментов. Оно применяется, в частности, при работе traceroute. Массовый поток таких сообщений может перегружать обработку и системы мониторинга.
ICMP Fragmentation Flood
ICMP-пакеты могут передаваться в составе фрагментированных IP-датаграмм. Большое количество фрагментов создаёт дополнительную нагрузку на механизм reassembly, firewall и IDS/IPS.
ICMP Flood с подменой IP
При отсутствии фильтрации исходных адресов атакующий может формировать пакеты с подменённым source IP. Это затрудняет определение реального источника и позволяет менять адрес без использования большого числа настоящих устройств.
Распределённый ICMP Flood
Пакеты отправляются множеством устройств ботнета. Каждый адрес может создавать умеренный поток, но суммарная нагрузка становится критической.
Например, 100 000 устройств отправляют по 20 пакетов в секунду. На один IP приходится небольшая активность, однако общая скорость достигает двух миллионов пакетов в секунду.
Что такое ICMPv6 Flood
Для IPv6 используется ICMPv6, определённый RFC 4443. Это не просто диагностическое дополнение: ICMPv6 участвует в критически важных процессах IPv6, включая Neighbor Discovery и Path MTU Discovery.
К ICMPv6-атакам относятся:
- Echo Request Flood;
- Echo Reply Flood;
- Neighbor Solicitation Flood;
- Neighbor Advertisement Flood;
- Router Solicitation Flood;
- Router Advertisement Abuse;
- Packet Too Big Flood;
- Destination Unreachable Flood.
Полная блокировка ICMPv6 особенно опасна: она способна нарушить базовую работу IPv6. Защита должна учитывать типы сообщений, направление, частоту и допустимые источники.
Подробные атаки на Neighbor Discovery лучше рассматривать в отдельной статье про IPv6 Flood, а в материале про ICMP Flood достаточно обозначить их как связанную группу.
ICMP Flood, Smurf Attack и Ping Flood
Smurf Attack использует ICMP Echo Request, но отличается от прямого Ping Flood механизмом отражения.
| Параметр | Прямой Ping Flood | Smurf Attack |
|---|---|---|
| Куда отправляется запрос | Непосредственно жертве | На broadcast-адрес промежуточной сети |
| Исходный IP | Настоящий или подменённый | Подменяется на IP жертвы |
| Кто отправляет ответы | Сама жертва | Множество устройств промежуточной сети |
| Усиление | Обычно отсутствует | Возникает за счёт множества ответов |
| Характер трафика у жертвы | Преимущественно Echo Request | Большое количество Echo Reply |
В Smurf Attack атакующий отправляет Echo Request на широковещательный адрес и указывает IP жертвы как источник. Если устройства в сети отвечают на такой broadcast-запрос, их Echo Reply направляются жертве.
Прямой Ping Flood не требует broadcast-сети и может выполняться обычным ботнетом. Smurf Attack заслуживает отдельной статьи вместе с близкой по механике Fraggle Attack.
ICMP Flood и Ping of Death — разные атаки
Ping Flood и Ping of Death часто ошибочно считают одним и тем же.
| Параметр | Ping Flood | Ping of Death |
|---|---|---|
| Основной принцип | Большое количество пакетов | Некорректный или чрезмерно большой пакет |
| Основная цель | Исчерпание ресурсов | Ошибка обработки и сбой системы |
| Нужен большой поток | Обычно да | Исторически мог быть не нужен |
| Актуальность | Сохраняется | Классическая техника затрагивает старые уязвимые реализации |
Ping Flood перегружает инфраструктуру количеством запросов. Ping of Death исторически использовал проблемы обработки нестандартных или превышающих допустимый размер IP-пакетов после сборки фрагментов.
В современной энциклопедии эти темы следует связывать внутренними ссылками, но не объединять под одним названием.
ICMP Flood и ICMP Amplification
При прямом ICMP Flood пакеты передаются цели непосредственно. При отражённой атаке используются сторонние устройства, которые отправляют ответы на подменённый адрес жертвы.
Сам обычный Echo Reply чаще всего имеет примерно тот же объём данных, что и Echo Request, поэтому классический ping не создаёт значительного коэффициента усиления по размеру одного ответа. Усиление в Smurf Attack возникает за счёт количества устройств, отвечающих на один broadcast-запрос.
Это отличается от DNS Amplification, где один UDP-сервер способен вернуть ответ, многократно превышающий размер исходного запроса.
Как ботнет выполняет Ping Flood
Ботнет состоит из заражённых или иным образом контролируемых устройств. Это могут быть:
- домашние компьютеры;
- маршрутизаторы;
- IP-камеры;
- видеорегистраторы;
- серверы;
- виртуальные машины;
- IoT-устройства.
После получения команды каждый узел начинает отправлять ICMP-пакеты цели. Распределённость даёт атакующему несколько преимуществ:
- суммируется пропускная способность множества сетей;
- простая блокировка одного IP не помогает;
- адреса могут принадлежать реальным домашним пользователям;
- трафик приходит из разных стран и ASN;
- порог на один источник может не превышаться;
- состав ботнета меняется во время атаки.
На какие ресурсы воздействует атака
| Ресурс | Воздействие ICMP Flood |
|---|---|
| Интернет-канал | Заполнение входящим или исходящим потоком |
| Маршрутизатор | Высокий PPS и рост очередей |
| Firewall | Проверка каждого пакета и применение правил |
| IDS/IPS | Анализ, корреляция и создание событий |
| Операционная система | Обработка ICMP и формирование ответов |
| Сетевой интерфейс | Потери и переполнение очередей |
| Система мониторинга | Большое количество событий и ложная недоступность |
| Облачная инфраструктура | Рост трафика и потенциальных расходов |
Признаки ICMP Flood
ICMP Flood необходимо искать на сетевом уровне. Access.log Nginx или Apache может не содержать прямых следов атаки.
Основные сетевые признаки
- резкий рост ICMP-трафика;
- большое количество Echo Request;
- аномальный поток Echo Reply без исходящих запросов;
- высокое значение packets per second;
- рост входящей и исходящей пропускной способности;
- большое число источников;
- постоянная частота пакетов;
- одинаковый размер запросов;
- необычные типы и коды ICMP;
- рост фрагментированных ICMP-пакетов;
- запросы к диапазону IP-адресов вместо одного узла;
- резкое изменение географии источников.
Признаки на оборудовании
- рост загрузки маршрутизатора;
- увеличение CPU firewall;
- потери на интерфейсах;
- переполнение входящих и исходящих очередей;
- рост количества отброшенных пакетов;
- задержка применения правил;
- сбои мониторинга;
- нестабильная доступность сразу нескольких сервисов.
Признаки на сервере
- рост системной, а не прикладной нагрузки;
- увеличение softirq;
- высокая активность сетевого стека;
- рост ICMP Echo Replies;
- потери входящих пакетов;
- увеличение задержки TCP;
- тайм-ауты при нормальной нагрузке приложения;
- отсутствие соответствующего роста в HTTP-логах.
Признаки для пользователя
- сайт открывается через раз;
- страницы загружаются дольше обычного;
- возникают ошибки соединения;
- не работают сразу сайт, VPN и почта;
- проблема проявляется у пользователей из разных регионов;
- доступность периодически восстанавливается между волнами.
Какие метрики нужно контролировать
| Метрика | Зачем она нужна |
|---|---|
| ICMP bits per second | Показывает объём трафика |
| ICMP packets per second | Показывает нагрузку на обработку пакетов |
| Echo Requests per second | Выявляет Ping Flood |
| Echo Replies per second | Показывает ответную нагрузку или отражённый поток |
| Соотношение Request/Reply | Помогает определить направление и характер атаки |
| ICMP type и code | Разделяет Echo, Unreachable, Time Exceeded и другие сообщения |
| Размер пакета | Выявляет аномальные и однотипные сообщения |
| Уникальные IP | Определяет распределённость |
| ASN и тип сети | Показывает концентрацию по провайдерам и дата-центрам |
| Interface drops | Фиксирует реальные потери |
| Latency и packet loss | Показывает влияние на легитимных пользователей |
Сам по себе рост количества уникальных IP не доказывает ботнет. При крупном сбое мониторинга множество легитимных систем тоже может одновременно проверять доступность узла. Поэтому необходим анализ частоты, структуры пакетов, истории адресов и текущего контекста.
Как отличить атаку от обычной диагностики
ICMP используется системами мониторинга, администраторами и сетевыми устройствами. Небольшой постоянный поток Echo Request может быть нормальным.
| Признак | Обычная диагностика | ICMP Flood |
|---|---|---|
| Частота | Несколько пакетов через заданный интервал | Массовый непрерывный или волновой поток |
| Источники | Известные системы мониторинга | Множество неизвестных адресов |
| Размеры | Предсказуемые и умеренные | Однотипные, случайные или аномальные |
| Время | Соответствует настройкам проверки | Не связано с эксплуатационным графиком |
| Влияние | Практически отсутствует | Задержки, потери и недоступность |
| ASN и география | Ожидаемые сети | Необычное распределение |
Для корректного обнаружения полезно заранее сформировать allowlist адресов корпоративного мониторинга. Тогда их запросы не будут смешиваться с неизвестным внешним трафиком.
Как отличить ICMP Flood от проблем с сетью
Потери пакетов и высокая задержка не всегда означают атаку. Аналогичные симптомы вызывают:
- неисправность сетевого оборудования;
- перегрузка канала легитимным трафиком;
- ошибка маршрутизации;
- неудачное обновление firewall;
- проблема у оператора связи;
- неправильный QoS;
- повреждённый интерфейс;
- петля в сети;
- ошибка облачной инфраструктуры.
На атаку указывает одновременное появление большого ICMP-потока, аномальных источников и ухудшения доступности. Если ICMP не вырос, следует искать другую причину.
Последствия ICMP Flood
- недоступность сайта;
- рост задержки;
- потеря TCP- и UDP-пакетов;
- снижение скорости API;
- разрыв VPN-соединений;
- нестабильная работа DNS;
- перегрузка firewall;
- сбой мониторинга;
- рост расходов на трафик;
- ложные уведомления о недоступности;
- нарушение SLA;
- потеря заказов и обращений;
- маскировка параллельного взлома.
ICMP Flood может использоваться как отвлекающий манёвр. Пока специалисты восстанавливают доступность, злоумышленник пытается войти в административную панель, использовать украденный пароль, загрузить файл или провести другую атаку.
Как защититься от ICMP Flood
1. Не блокировать ICMP без разбора
ICMP выполняет важные сетевые функции. Вместо полного запрета лучше определить:
- какие типы сообщений необходимы;
- кто может их отправлять;
- какая частота является нормальной;
- какие сообщения должны ограничиваться;
- где применять фильтрацию.
Например, публичный сервер может принимать ограниченное количество Echo Request, сохраняя необходимые сообщения Destination Unreachable и Fragmentation Needed.
2. Настроить Rate Limiting
Ограничивать можно:
- общий ICMP PPS;
- Echo Request на один IP;
- поток от одной подсети;
- поток от одного ASN;
- конкретные типы и коды;
- ответы Echo Reply;
- аномальные размеры пакетов.
Лимит только на один source IP недостаточен против ботнета. Нужны общие и агрегированные пороги.
3. Разрешить критически важные ICMP-сообщения
При фильтрации следует учитывать сообщения, необходимые для нормальной работы сети. В IPv4 к ним может относиться Destination Unreachable с информацией о необходимости фрагментации, а в IPv6 — Packet Too Big и сообщения Neighbor Discovery.
Конкретная политика зависит от архитектуры, поэтому нельзя без проверки копировать универсальное правило «deny all ICMP».
4. Применять фильтрацию у провайдера
Если поток превышает пропускную способность подключения, firewall на сервере не поможет. Вредоносные пакеты должны быть отброшены до входа в узкий канал.
Для этого применяются:
- защита оператора связи;
- центры очистки трафика;
- распределённые Anti-DDoS-сети;
- маршрутизация через защищённый периметр;
- временная фильтрация или перенаправление трафика.
5. Проверять подменённые адреса
Ingress- и egress-фильтрация у сетевых операторов уменьшает возможность отправки пакетов с подменёнными адресами. Внутри собственной сети также следует запрещать исходящий трафик с адресами, не принадлежащими соответствующему сегменту.
6. Настроить приоритеты трафика
QoS и control-plane policing помогают не допустить, чтобы большой поток диагностических сообщений полностью вытеснил критически важный трафик или перегрузил управляющую плоскость маршрутизатора.
Настройки должны учитывать производительность конкретного оборудования. Слишком высокий лимит не остановит атаку, а слишком низкий нарушит диагностику.
7. Защитить control plane
Пакеты, которые обрабатываются непосредственно процессором маршрутизатора, опаснее обычного транзитного трафика. Для управляющей плоскости применяются отдельные политики:
- ограничение частоты;
- классификация ICMP;
- приоритет критических сообщений;
- отбрасывание аномальных типов;
- мониторинг загрузки control plane.
8. Контролировать одновременно BPS и PPS
Атака крупными пакетами чаще проявляется в объёме трафика. Атака мелкими пакетами — в количестве операций. Оповещения необходимо настроить по обоим показателям.
9. Использовать базовый профиль
Полезно заранее определить:
- обычное количество Echo Request;
- адреса мониторинга;
- средний размер пакета;
- обычное соотношение Request и Reply;
- нормальную географию;
- типичные значения PPS;
- обычную долю ICMP в трафике.
Без такого профиля трудно отличить атаку от штатной диагностики или кратковременной сетевой ошибки.
Почему локальный firewall может не помочь
Представим, что сервер подключён каналом 1 Гбит/с, а ICMP Flood достигает 4 Гбит/с. Firewall сервера отбрасывает каждый пакет, но только после его прохождения по внешнему каналу.
Результат:
- канал остаётся переполненным;
- HTTPS-пакеты не достигают сервера;
- сайт остаётся недоступным;
- локальная загрузка может выглядеть нормальной;
- правило firewall создаёт ложное ощущение защиты.
Локальная фильтрация полезна против умеренных потоков и для защиты ресурсов операционной системы. Против объёмной атаки требуется фильтрация выше по маршруту.
Поможет ли reverse proxy и WAF
Обычный reverse proxy для сайта принимает HTTP и HTTPS. ICMP не является веб-запросом и не проходит через правила WAF, предназначенные для анализа URL, заголовков, cookies и тела HTTP-запроса.
Возможны два основных сценария.
Атака направлена на защищённый адрес reverse proxy
Отражение атаки зависит от сетевой инфраструктуры поставщика: пропускной способности, распределения трафика и фильтрации на L3/L4.
Атака направлена на настоящий IP origin-сервера
Трафик обходит reverse proxy и поступает напрямую в сеть хостинга. Если origin IP раскрыт, WAF и HTTP-фильтрация не участвуют в защите.
TrafficVeil помогает скрыть origin веб-сайта и не передавать вредоносные HTTP-запросы на сервер. Но защита от прямого объёмного ICMP Flood дополнительно требует:
- закрытия прямого доступа к origin;
- разрешения веб-трафика только от доверенных адресов прокси;
- защиты канала хостинга;
- upstream-фильтрации;
- корректной настройки ICMP на firewall;
- отдельной защиты DNS и других публичных сервисов.
Нельзя считать обычный WAF полноценной защитой от ICMP Flood: атака происходит до уровня HTTP.
Что делать во время ICMP Flood
- Проверить протокол. Убедиться, что нагрузку создаёт именно ICMP.
- Определить типы и коды. Отделить Echo Request от Reply, Unreachable и Time Exceeded.
- Измерить BPS и PPS. Понять, переполнен канал или оборудование не справляется с количеством пакетов.
- Найти узкое место. Канал, маршрутизатор, firewall, интерфейс или операционная система.
- Проверить источники. Проанализировать IP, подсети, ASN, страны и типы сетей.
- Связаться с провайдером. Это необходимо, если атака превышает пропускную способность подключения.
- Ввести временные ограничения. Уменьшить допустимую частоту Echo Request и подозрительных типов.
- Сохранить данные. Зафиксировать NetFlow, PCAP, графики и системные журналы.
- Проверить origin. Исключить прямую атаку в обход reverse proxy.
- Проверить другие события. Найти возможные попытки взлома на фоне DDoS.
Какие данные сохранить после атаки
- время начала и окончания;
- пиковый объём трафика;
- пиковое количество пакетов;
- ICMP type и code;
- размеры пакетов;
- соотношение Echo Request и Echo Reply;
- основные source IP;
- подсети и ASN;
- географию источников;
- нагрузку маршрутизатора и firewall;
- interface drops;
- данные о задержках и потерях;
- применённые правила;
- время, когда каждое правило начало действовать;
- небольшой репрезентативный PCAP.
Типичные ошибки при защите
- Полностью отключать ICMP. Это может нарушить важные сетевые функции.
- Блокировать только Echo Request на сервере. Переполненный внешний канал останется недоступным.
- Следить только за мегабитами. Высокий PPS способен перегрузить оборудование при умеренном объёме.
- Ограничивать только один IP. Распределённая атака обходит такой лимит.
- Считать любой ping атакой. Мониторинг и диагностика создают легитимный ICMP.
- Не разделять типы ICMP. Echo Request и Packet Too Big имеют разное назначение.
- Оставлять origin открытым. Атакующий направит ICMP напрямую на сервер.
- Не защищать IPv6. Фильтрация IPv4 не распространяется автоматически на ICMPv6.
- Игнорировать control plane. Маршрутизатор может потерять управление раньше заполнения канала.
- Не сохранять сетевые данные. После завершения потока будет сложно определить источник и механизм атаки.
Чек-лист защиты от ICMP Flood
- определены необходимые типы ICMP и ICMPv6;
- известны адреса систем мониторинга;
- настроены лимиты Echo Request;
- контролируется общий ICMP PPS;
- контролируется объём ICMP в битах в секунду;
- отдельно анализируются type и code;
- настроены пороги для IP, подсетей и ASN;
- защищена управляющая плоскость маршрутизаторов;
- отслеживаются interface drops;
- настроено оповещение о росте ICMP;
- проверена политика для IPv6;
- origin IP сайта скрыт;
- прямой доступ к origin ограничен;
- провайдер предоставляет upstream-фильтрацию;
- подготовлен план действий при переполнении канала;
- после атаки проверяется сопутствующая активность.
Частые вопросы
Что такое ICMP Flood простыми словами?
Что такое Ping Flood?
Чем ICMP Flood отличается от Ping Flood?
Ping Flood и Ping of Death — одна атака?
Чем Ping Flood отличается от Smurf Attack?
Можно ли полностью отключить ICMP?
Поможет ли блокировка ping на сервере?
Защищает ли WAF от Ping Flood?
Может ли ICMP Flood вывести из строя HTTPS-сайт?
Почему важно учитывать packets per second?
Как определить распределённую ICMP-атаку?
Что необходимо сделать после завершения атаки?
Команда TrafficVeil разрабатывает инструменты защиты сайтов от ботов, DDoS и веб-атак. Разборы ботов пишем по логам подключённых доменов и открытым данным операторов.


