Научиться настройке MikroTik можно на онлайн курсе по оборудованию этого производителя. Автор курса является сертифицированным тренером MikroTik. Подробней Вы можете прочитать в конце статьи.
Статья отвечает на вопрос насколько опасно блокировать ICMP трафик.
ICMP — яблоко раздора
Многие сетевые администраторы считают, что протокол межсетевых управляющих сообщений (Internet Control Message Protocol (ICMP) представляет собой угрозу безопасности и поэтому должен всегда блокироваться на брандмауэре. Это правда, что протокол имеет некоторые связанные с этим проблемы безопасности, и что часть запросов должна быть заблокирована. Но это не повод блокировать весь ICMP-трафик!
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, чем у отправителя или получателя, и у них не будет средств для обнаружения данной коллизии, то трафик будет незаметно отбрасывается. И вы не будете понимать что происходит с каналом связи; другими словами, «для вас наступят веселые деньки».
Dont Fragment ICMP не пройдет!
Передача IPv4-пакетов с установленным битом Dont Fragment (большинство из них!) или IPv6-пакетов (помним, что в IPv6 нет фрагментации маршрутизаторами), которые слишком велики для передачи через интерфейс, приведёт к тому, что маршрутизатор отбросит пакет и сформирует ответ источнику передачи с следующими ICMP-ошибками: Требуется Фрагментация (Fragmentation Required), либо Пакет Слишком Большой (Packet Too Big). Если ответы с этими ошибками не смогут вернуться к отправителю, то он будет интерпретировать отсутствие подтверждающих ответов о доставке пакетов ACK (Acknowledge) от получателя в качестве перегрузки / потери и источником для повторной передачи пакетов, которые также будут отбрасываться.
Сложно выявить причину подобной проблемы и быстро устранить, процесс обмена 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 — очень полезный инструмент для устранения неполадок в сетевых соединениях между двумя хостами, подробно описывающий каждый шаг пути.
Отправляет пакет с временем жизни пакета данных для протокола 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) содержит много сообщений, которые идентифицируются полем «тип».
| Тип | Наименование | Спецификация |
|---|---|---|
| 0 | Echo Reply | [RFC792] |
| 1 | Unassigned | |
| 2 | Unassigned | |
| 3 | Destination Unreachable | [RFC792] |
| 4 | Source Quench (Deprecated) | [RFC792][RFC6633] |
| 5 | Redirect | [RFC792] |
| 6 | Alternate Host Address (Deprecated) | [RFC6918] |
| 7 | Unassigned | |
| 8 | Echo | [RFC792] |
| 9 | Router Advertisement | [RFC1256] |
| 10 | Router Solicitation | [RFC1256] |
| 11 | Time Exceeded | [RFC792] |
| 12 | Parameter Problem | [RFC792] |
| 13 | Timestamp | [RFC792] |
| 14 | Timestamp Reply | [RFC792] |
| 15 | Information Request (Deprecated) | [RFC792][RFC6918] |
| 16 | Information Reply (Deprecated) | [RFC792][RFC6918] |
| 17 | Address Mask Request (Deprecated) | [RFC950][RFC6918] |
| 18 | Address Mask Reply (Deprecated) | [RFC950][RFC6918] |
| 19 | Reserved (for Security) | Solo |
| 20-29 | Reserved (for Robustness Experiment) | ZSu |
| 30 | Traceroute (Deprecated) | [RFC1393][RFC6918] |
| 31 | Datagram Conversion Error (Deprecated) | [RFC1475][RFC6918] |
| 32 | Mobile Host Redirect (Deprecated) | David_Johnson |
| 33 | IPv6 Where-Are-You (Deprecated) | [RFC6918] |
| 34 | IPv6 I-Am-Here (Deprecated) | [RFC6918] |
| 35 | Mobile Registration Request (Deprecated) | [RFC6918] |
| 36 | Mobile Registration Reply (Deprecated) | [RFC6918] |
| 37 | Domain Name Request (Deprecated) | [RFC1788][RFC6918] |
| 38 | Domain Name Reply (Deprecated) | [RFC1788][RFC6918] |
| 39 | SKIP (Deprecated) | [RFC6918] |
| 40 | Photuris | [RFC2521] |
| 41 | ICMP messages utilized by experimental mobility protocols such as Seamoby | [RFC4065] |
| 42 | Extended Echo Request | [RFC8335] |
| 43 | Extended Echo Reply | [RFC8335] |
| 44-252 | Unassigned | |
| 253 | RFC3692-style Experiment 1 | [RFC4727] |
| 254 | RFC3692-style Experiment 2 | [RFC4727] |
| 255 | Reserved |
Пара слов об ограничении скорости
Хотя ICMP-сообщения, подобные тем, которые описаны в статье, могут быть очень полезными, помните, что генерация всех этих сообщений занимает процессорное время на ваших маршрутизаторах и генерирует трафик. Вы действительно ожидаете, что вы получите 1000 пингов в секунду через ваш брандмауэр в обычной ситуации? Будет ли это считаться нормальным трафиком? Вероятно, нет. Ограничивайте пропускную способность сети для этих типов ICMP трафика, как вы считаете нужным; этот шаг может помочь вам в защите вашей сети.
Читать, исследовать и понимать
Учитывая, что обсуждение темы «блокировать или не блокировать» ICMP-пакетов, всегда приводит к путанице, спорам и разногласиям, предлагаю продолжить изучать эту тему самостоятельно. На этой странице привел много ссылок, считаю для более полного понимания проблематики следует потратить время на их чтение. И сделать осознанный выбор того, что лучше всего подходит для вашей сети.
MikroTik: куда нажать, чтобы заработало? При всех своих достоинствах, есть у продукции компании MikroTik один минус – много разобщенной и далеко не всегда достоверной информации о ее настройке. Рекомендуем проверенный источник на русском языке, где все собрано, логично и структурировано – видеокурс «Настройка оборудования MikroTik». В курс входит 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект. Все материалы остаются у вас бессрочно. Начало курса можно посмотреть бесплатно, оставив заявку на странице курса. Автор курса является сертифицированным тренером MikroTik.
Предыдущая запись mod_rewrite перенаправляем на https сайт Следующая запись Низкая скорость GRE IPSec тоннеля AES CBC