Статья отвечает на вопрос насколько опасно блокировать ICMP трафик.

ICMP — яблоко раздора

Многие сетевые администраторы считают, что протокол межсетевых управляющих сообщений (Internet Control Message Protocol (ICMP) представляет собой угрозу безопасности и поэтому должен всегда блокироваться на брандмауэре. Это правда, что протокол имеет некоторые связанные с этим проблемы безопасности, и что часть запросов должна быть заблокирована. Но это не повод блокировать весь ICMP-трафик!

icmp error

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

Echo запрос и and Echo ответ

IPv4 – Echo запрос (Type8, Code0) и Echo ответ (Type0, Code0)
IPv6 – Echo запрос (Type128, Code0) and Echo ответ (Type129, Code0)

Мы все хорошо знаем, что ping, — один из первых инструментов для поиска и устранения неполадок. Да, если вы включите на своем оборудование обработку ICMP-пакетов, то это значит, что ваш хост теперь доступен для обнаружения, но разве ваш веб-сервер уже не слушает порт 80, и не отправляет ответы на клиентские запросы? Конечно, заблокируйте ещё и эти запросы, если вы действительно хотите, чтобы на границе сети была ваша DMZ. Но блокируя ICMP трафик внутри вашей сети, не усилите защиту, напротив получите систему с излишне сложным процессом поиска и устранения неполадок («Проверьте пожалуйста отзывается ли шлюз на сетевые запросы?», «Нет, но это меня ничуть не расстраивает, потому что мне это ничего не скажет! »).

Помните, также можете разрешить прохождение запросов в определенном направлении; например, настроить оборудование так, чтобы Echo запросы из вашей сети проходили в сеть Интернет и Echo ответы из Интернета в вашу сеть, но не наоборот.

Необходима фрагментация пакета (IPv4) / Пакет слишком большой (IPv6)

IPv4 – (Type3, Code4)
IPv6 – (Type2, Code0)

Данные компоненты протокола ICMP очень важны, так как являются важным компонентом в Path MTU Discovery (PMTUD), который является неотъемлемой частью протокола TCP. Позволяет двум хостам корректировать значение максимального размера сегмента TCP (MSS) до значения, которое будет соответствовать наименьшему MTU по пути связей между двумя адресатами. Если на пути следования пакетов будет узел с меньшим Maximum Transmission Unit, чем у отправителя или получателя, и у них не будет средств для обнаружения данной коллизии, то трафик будет незаметно отбрасывается. И вы не будете понимать что происходит с каналом связи; другими словами, «для вас наступят веселые деньки».

Don’t Fragment – ICMP не пройдет!

Передача IPv4-пакетов с установленным битом Don’t Fragment (большинство из них!) или IPv6-пакетов (помним, что в IPv6 нет фрагментации маршрутизаторами), которые слишком велики для передачи через интерфейс, приведёт к тому, что маршрутизатор отбросит пакет и сформирует ответ источнику передачи с следующими ICMP-ошибками: Требуется Фрагментация (Fragmentation Required), либо Пакет Слишком Большой (Packet Too Big). Если ответы с этими ошибками не смогут вернуться к отправителю, то он будет интерпретировать отсутствие подтверждающих ответов о доставке пакетов ACK (Acknowledge) от получателя в качестве перегрузки / потери и источником для повторной передачи пакетов, которые также будут отбрасываться.

TCP-handshake

Сложно выявить причину подобной проблемы и быстро устранить, процесс обмена TCP-рукопожатиями (TCP-handshake) работает нормально, поскольку в нем задействованы небольшие пакеты, но как только происходит массовая передача данных сеанс передачи зависает, так как источник передачи не получает сообщения об ошибках.

Исследование пути доставки пакетов

RFC 4821 был разработан для того, чтобы помочь участникам передачи трафика в сети обойти эту проблему, используя исследование пути распространения пакетов (Path MTU Discovery (PLPMTUD). Стандарт позволяет обнаружить максимальный объём данных (Maximum Transmission Unit (MTU), который может быть передан протоколом за одну итерацию,  путем постепенного увеличения максимального размера полезного блока данных (Maximum Segment Size (MSS), для того чтобы найти максимально возможную величину пакета без его фрагментации на пути следования от передатчика к приемнику. Данный функционал уменьшает зависимость от своевременного получения ответов с ошибками по протоколу межсетевых управляющих сообщений (Internet Control Message Protocol (ICMP) и доступен в большинстве сетевых стеков устройств и клиентских операционных систем. К сожалению, он не так эффективен, как непосредственное получение данных о максимальном возможном размере передаваемых пакетов. Пожалуйста, позвольте этим сообщениям протокола ICMP возвращаться к источнику передачи, хорошо?

Превышение времени передачи пакетов

IPv4 – (Type11, Code0)
IPv6 – (Type3, Code0)

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

Time to live

Отправляет пакет с временем жизни пакета данных для протокола IP (Time to live (TTL) равным 1, чтобы первый маршрутизатор отправил сообщение с ошибкой (включая собственный IP-адрес) о превышении времени жизни пакета. Затем отправляет пакет с TTL 2 и так далее. Данная процедура необходима для того, чтобы обнаружить каждый узел на пути следования пакетов.

NDP and SLAAC (IPv6)

Router Solicitation (RS) (Type133, Code0)
Router Advertisement (RA) (Type134, Code0)
Neighbour Solicitation (NS) (Type135, Code0)
Neighbour Advertisement (NA) (Type136, Code0)
Redirect (Type137, Code0)

В то время как IPv4 использовал протокол разрешения адресов (ARP) для сопоставления 2 и 3 уровней сетевой модели OSI, IPv6 использует другой подход в виде протокола обнаружения соседей (NDP). NDP предоставляет множество функций, включая обнаружение маршрутизатора, обнаружение префикса, разрешение адреса и многое другое. В дополнение к NDP, Автоконфигурация (StateLess Address AutoConfiguration (SLAAC) позволяет динамически настраивать хост в сети, аналогично концепции протокола динамической настройки узла (Dynamic Host Configuration Protocol (DHCP) (хотя DHCPv6 предназначается для более тонкого управления).

Эти пять типов ICMP сообщений не должны блокироваться внутри вашей сети (не учитываем внешний периметр), чтобы протокол передачи данных IP функционировал правильно.

Нумерация типов ICMP

Протокол межсетевых управляющих сообщений (ICMP) содержит много сообщений, которые идентифицируются полем «тип».

ТипНаименованиеСпецификация
Echo Reply[RFC792]
1Unassigned
2Unassigned
3Destination Unreachable[RFC792]
4Source Quench (Deprecated)[RFC792][RFC6633]
5Redirect[RFC792]
6Alternate Host Address (Deprecated)[RFC6918]
7Unassigned
8Echo[RFC792]
9Router Advertisement[RFC1256]
10Router Solicitation[RFC1256]
11Time Exceeded[RFC792]
12Parameter Problem[RFC792]
13Timestamp[RFC792]
14Timestamp Reply[RFC792]
15Information Request (Deprecated)[RFC792][RFC6918]
16Information Reply (Deprecated)[RFC792][RFC6918]
17Address Mask Request (Deprecated)[RFC950][RFC6918]
18Address Mask Reply (Deprecated)[RFC950][RFC6918]
19Reserved (for Security)Solo
20-29Reserved (for Robustness Experiment)ZSu
30Traceroute (Deprecated)[RFC1393][RFC6918]
31Datagram Conversion Error (Deprecated)[RFC1475][RFC6918]
32Mobile Host Redirect (Deprecated)David_Johnson
33IPv6 Where-Are-You (Deprecated)[RFC6918]
34IPv6 I-Am-Here (Deprecated)[RFC6918]
35Mobile Registration Request (Deprecated)[RFC6918]
36Mobile Registration Reply (Deprecated)[RFC6918]
37Domain Name Request (Deprecated)[RFC1788][RFC6918]
38Domain Name Reply (Deprecated)[RFC1788][RFC6918]
39SKIP (Deprecated)[RFC6918]
40Photuris[RFC2521]
41ICMP messages utilized by experimental mobility protocols such as Seamoby[RFC4065]
42Extended Echo Request[RFC8335]
43Extended Echo Reply[RFC8335]
44-252Unassigned
253RFC3692-style Experiment 1[RFC4727]
254RFC3692-style Experiment 2[RFC4727]
255Reserved

Пара слов об ограничении скорости

Хотя ICMP-сообщения, подобные тем, которые описаны в статье, могут быть очень полезными, помните, что генерация всех этих сообщений занимает процессорное время на ваших маршрутизаторах и генерирует трафик. Вы действительно ожидаете, что вы получите 1000 пингов в секунду через ваш брандмауэр в обычной ситуации? Будет ли это считаться нормальным трафиком? Вероятно, нет. Ограничивайте пропускную способность сети для этих типов ICMP трафика, как вы считаете нужным; этот шаг может помочь вам в защите вашей сети.

Читать, исследовать и понимать

Учитывая, что обсуждение темы «блокировать или не блокировать» ICMP-пакетов, всегда приводит к путанице, спорам и разногласиям, предлагаю продолжить изучать эту тему самостоятельно. На этой странице привел много ссылок, считаю для более полного понимания проблематики следует потратить время на их чтение. И сделать осознанный выбор того, что лучше всего подходит для вашей сети.

Читать далее

Блокировать ли ICMP трафик? Вопрос безопасности
Метки:
Adblock detector