Содержимое icmp пакетов. Протоколы IP, ARP, RARP

Статья отвечает на вопрос насколько опасно блокировать 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, чем у отправителя или получателя, и у них не будет средств для обнаружения данной коллизии, то трафик будет незаметно отбрасывается. И вы не будете понимать что происходит с каналом связи; другими словами, «для вас наступят веселые деньки».

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

Передача IPv4-пакетов с установленным битом Don’t 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) содержит много сообщений, которые идентифицируются полем «тип».

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

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

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

Как мы не раз отмечали, протокол IP доставляет данные, руководствуясь принципом «по возможности», то есть не предпринимает мер для гарантированной передачи данных адресату. Это свойство «необязательности» протокола IP компенсируется протоколами более высоких уровней стека TCP/IP, например TCP на транспортном уровне и в какой-то степени DNS на прикладном уровне. Они берут на себя обязанности по обеспечению надежности, применяя такие известные приемы, как нумерация сообщений, подтверждение доставки, повторная посылка данных.

Протокол ICMP также служит дополнением, компенсирующим ненадежность протокола IP, но несколько другого рода. Он не предназначен для исправления возникших при передаче пакета проблем: если пакет потерян, ICMP не может послать его заново. Задача ICMP другая - он является средством оповещения отправителя о «несчастных случаях», произошедших с его пакетами. Пусть, например, протокол IP, работающий на каком-либо маршрутизаторе, обнаружил, что пакет для дальнейшей передачи по маршруту необходимо фрагментировать, но в пакете установлен признак DF (не фрагментировать). Протокол IP, обнаруживший, что он не может передать IP-пакет далее по сети, прежде чем отбросить пакет, должен отправить диагностическое ICMP-сообщение конечному узлу-источнику.

Для передачи по сети ICMP-сообщение инкапсулируется в поле данных IP-пакета. IP-адрес узла-источника определяется из заголовка пакета, вызвавшего инцидент.

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

Заметим, что некоторые из пакетов могут исчезнуть в сети, не вызвав при этом никаких оповещений. В частности, протокол ICMP не предусматривает передачу сообщений о проблемах, возникающих при обработке IP-пакетов, несущих ICMP-сообщения об ошибках. Такое решение было принято разработчиками протокола, чтобы не порождать «штормы» в сетях, когда количество сообщений об ошибках лавинообразно возрастает.

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

Рис. 1. Формат ICMP-сообщения

Заголовок ICMP-сообщения состоит из 8 байт:

• тип (1 байт) - числовой идентификатор типа сообщения;
• код (1 байт) - числовой идентификатор, более тонко дифференцирующий тип ошибки;
• контрольная сумма (2 байта) - подсчитывается для всего ICMP-сообщения.

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

На рис. 2 показана таблица основных типов ICMP-сообщений. Эти сообщения можно разделить на две группы (помеченные на рисунке условными символами):

• сообщения об ошибках;
• сообщения запрос-ответ.

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

Рис. 2. Типы и коды ICMP-сообщений

Сообщения, относящиеся к группе сообщений об ошибках, конкретизируются уточняющим кодом. На рисунке показан фрагмент таблицы кодов для сообщения об ошибке недостижимости узла назначения, имеющей тип 3. Из таблицы мы видим, что это сообщение может быть вызвано различными причинами, такими как неверный адрес сети или узла (код О или 1), отсутствием на конечном узле-адресате необходимого протокола прикладного уровня (код 2 - «протокол недостижим») или открытого порта UDP/TCP (код 3 - «порт недостижим»). Узел (или сеть) назначения может быть также недостижим по причине временной неработоспособности аппаратуры или из-за того, что маршрутизатор не имеет данных о пути к сети назначения. Всего таблица содержит 15 кодов. Аналогичные таблицы кодов существуют и для других типов сообщений об ошибках.

Протокол передачи команд и сообщений об ошибках ( ICMP - internet control message protocol, RFC-792, - 1256) выполняет различные и не только диагностические функции. При пересылке пакетов промежуточные узлы не информируются о возникших проблемах, поэтому ошибка в маршрутной таблице может восприниматься как неисправность в узле адресата и достоверно диагностироваться не будет. ICMP-протокол сообщает об ошибках в IP-дейтаграммах, но не дает информации об ошибках в самих ICMP-сообщениях. ICMP использует IP, а IP-протокол должен использовать ICMP. В случае ICMP-фрагментации сообщение об ошибке будет выдано только один раз на дейтаграмму, даже если ошибки были в нескольких фрагментах. Подводя итоги, можно сказать, что ICMP -протокол:

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

ICMP -сообщения об ошибках никогда не выдаются:

• в ответ на ICMP-сообщение об ошибке;
• при мультикастинг-е или широковещательной адресации;
• для фрагмента дейтаграммы (кроме первого);
• для дейтаграмм, чей адрес отправителя является нулевым, широковещательным или мультикастинговым.

Эти правила призваны блокировать потоки дейтаграмм, посылаемые в отклик на мультикастинг- или широковещательные ICMP -сообщения. Особенности протокола ICMPv6 описаны в документе RFC-2463. В IPv6 на протокол ICMP возложены функции управления группами ( IGMP ).

ICMP -сообщения имеют свой формат, а схема их вложения аналогична UDP или TCP и представлена на рис. 3.1 .

Все ICMP пакеты начинаются с 8-битного поля типа ICMP и его кода (15 значений).

Рис. 3.1.

По существу, значения полей типа и кода выполняют почти ту же функцию, что и порт в ТСР и UDP -протоколах.

Код уточняет функцию ICMP -сообщения. Таблица 3.1 этих кодов приведена ниже (символом * помечены сообщения об ошибках, остальные являются запросами).

Процедура "отключение источника" (quench, поле тип ICMP=4 ) позволяет управлять потоками данных в каналах Интернет . Не справляясь с обработкой дейтаграмм, ЭВМадресат (или транзитное сетевое устройство) может послать запрос "отключить источник" отправителю, который может сократить темп посылки пакетов, например, вдвое, или вовсе прервать их посылку. Специальной команды, отменяющей прежние запреты, не существует. Если сообщения об отключении прекращаются, источник может возобновить посылку пакетов или увеличить частоту их отправки. Ниже (на рис. 3.2) представлен формат эхозапроса ( ping ) и отклика для протокола ICMP .

Поля идентификатор (обычно это идентификатор процесса) и номер по порядку (увеличивается на 1 при посылке каждого пакета) служат для того, чтобы отправитель мог связать в пары запросы и отклики.

Поле тип определяет, является ли этот пакет запросом (8) или откликом (0). Поле контрольная сумма представляет собой 16-разрядное дополнение по модулю 1 контрольной суммы всего ICMP -сообщения, начиная с поля тип . Поле данные служит для записи информации, возвращаемой отправителю. При выполнении процедуры ping эхозапрос с временной меткой в поле данные посылается адресату. Если адресат активен, он принимает IP -пакет, меняет адрес отправителя и получателя местами и посылает его обратно. ЭВМ-отправитель, восприняв этот отклик, может сравнить временную метку, записанную им в пакет, с текущим показанием внутренних часов и определить время распространения пакета ( RTT - round trip time ). Размер поля данные не регламентирован и определяется предельным размером IP -пакета.

Так как в пакете ICMP нет поля порт , то при запуске нескольких процессов PING одновременно может возникнуть проблема с тем, какому из процессов следует передать тот или иной отклик. Для преодоления этой неопределенности следует использовать уникальные значения полей идентификатор .

Время распространения ICMP -запроса, вообще говоря, не равно времени распространения отклика (ситуация с очередями, например, в маршрутизаторах может быть разной). Это связано не только с возможными изменениями в канале. В общем случае маршруты их движения могут быть различными. Те же запросы используются при выполнении процедуры Traceroute .

Эта процедура позволяет не только диагностировать, но и оптимизировать маршрут . Например, команда traceroute cernvm.cern.ch , выданная в ЭВМ SUN (ИТЭФ), может отобразить на экране (в скобках указаны IP -адреса узлов и значения времени жизни дейтаграмм, значения RTT приводится в миллисекундах) (таблица 3.1.1.):

Отсюда видно, что наиболее узкими участками маршрута (на момент выполнения процедуры) являются Гамбург-Дюссельдорф-Берн-CERN. Следует иметь в виду, что канал МГУ-Гамбург был спутниковым и 500мс задержки здесь вносит удвоенное время распространения сигнала до спутника и обратно. Участок Гамбург-Дюссельдорф (X.25, квота 256кбит/с) был общим для потока данных из Германии в США. Передача IP поверх X.25 также снижает эффективную широкополосность канала. Остальные связи обладают недостаточной пропускной способностью. Программа ping показывает для данных участков в часы пик высокую долю потерянных пакетов. Таким образом, имея карту связей и используя указанные процедуры, вы можете успешно диагностировать ситуацию в сети. Продвинутые же программисты могут легко написать свои диагностические программы, базирующиеся на ICMP , как для локальной сети, так и для "окрестного" Интернет .

Когда маршрутизатор не может доставить дейтаграмму по месту назначения, он посылает отправителю сообщение "адресат недостижим" ( destination unreachable). Формат такого сообщения показан ниже (на рис. 3.3).

Поле код содержит целое число , проясняющее положение дел. Перечень кодов таких сообщений помещен в таблице 3.1 . Поле MTU на следующем этапе характеризует максимальную длину пакетов на очередном шаге пересылки. Эта информация ( MTU ) позволяет выбрать оптимальный размер пакета .

Так как в сообщении содержится Интернет -заголовок и первые 64-бита дейтаграммы, легко понять, какой адрес оказался недостижим. Этот тип ICMP -сообщения посылается и в случае, когда дейтаграмма имеет флаг DF=1 ("не фрагментировать"), а фрагментация необходима. В поле код в этом случае будет записано число 4.

Если буфер приема сообщения переполнен, ЭВМ посылает сообщение типа 4.

Так как собственные часы различных ЭВМ имеют свое представление о времени, протокол ICMP , среди прочего, служит для синхронизации работы различных узлов, если это требуется (запросы временных меток). Протокол синхронизации NTP ( network time protocol ) описан в RFC-1119.

Когда дейтаграммы поступают слишком часто и принимающая сторона не справляется с этим потоком, отправителю может быть послано сообщение с требованием резко сократить информационный поток (quenchзапрос). Снижение потока должно продолжаться до тех пор, пока не прекратятся quenchзапросы. Такое сообщение имеет формат, показанный на рис. 3.4 .

В Internet таблицы маршрутизации остаются без изменений достаточно долгое время, но иногда они все же меняются. Если маршрутизатор обнаружит, что ЭВМ использует неоптимальный маршрут , он может послать ей ICMP - запрос переадресации. При этом следует учитывать, что этой возможностью может воспользоваться и хакер . Формат такого сообщения отображен на рисунке 3.5 .

Поле Internet-адрес маршрутизатора содержит адрес маршрутизатора, который ЭВМ должна использовать, чтобы посланная дейтаграмма достигла места назначения, указанного в ее заголовке. В поле internet -заголовок кроме самого заголовка лежит 64 первых бита дейтаграммы, вызвавшей это сообщение. Поле код специфицирует то, как нужно интерпретировать адрес места назначения (см. табл. 3.1).

Команды переадресации маршрутизатор посылает только ЭВМ и никогда другим маршрутизаторам. Рассмотрим конкретный пример. Пусть некоторая ЭВМ на основе своей маршрутной таблицы посылает пакет маршрутизатору M1. Он, просмотрев свою маршрутную таблицу, находит, что пакет следует переслать маршрутизатору M2. Причем выясняется, что пакет из M1 в M2 следует послать через тот же интерфейс , через который он попал в M1. Это означает, что M2 доступен и непосредственно для ЭВМ-отправителя. В такой ситуации M1 посылает ICMP - запрос переадресации ЭВМ-отправителю указанного пакета с тем, чтобы она внесла соответствующие коррективы в свою маршрутную таблицу (либо чтобы администратор поменял IPадрес или маску ЭВМ).

Маршрутная таблица может загружаться из файла, формироваться менеджером сети, но может создаваться и в результате запросов и объявлений, посылаемых маршрутизаторами. После загрузки системы маршрутизатор посылает широковещательный запрос . Один или более маршрутизаторов посылают в ответ сообщения об имеющейся маршрутной информации. Кроме того, маршрутизаторы периодически (раз в 450600 сек.) широковещательно объявляют о своих маршрутах, что позволяет другим маршрутизаторам скорректировать свои маршрутные таблицы. В RFC-1256 описаны форматы ICMP -сообщений такого рода (см. рис. 3.6). Из--за своей уязвимости данная технология в последнее время практически не используется.

Поле число адресов характеризует количество адресных записей в сообщении. Поле длина адреса содержит число 32-битных слов, необходимых для описания адреса маршрутизатора. Поле время жизни предназначено для записи продолжительности жизни объявленных маршрутов (адресов) в секундах. По умолчанию время жизни равно 30 мин. Поля уровень приоритета представляют собой меру приоритетности маршрута по отношению к другим маршрутам данной подсети. Чем больше этот код, тем выше приоритет. Маршрут по умолчанию имеет уровень приоритета 0. Формат запроса маршрутной информации (8 октетов,

Хотя IPv4 не является надежным протоколом, на самом деле он предусматривает сообщения, которые будут отправлены в случае определенных ошибок. Эти сообщения отправляются, используя службы Протокола Контрольных Сообщений Интернета (протокол ICMP ). Цель этих сообщений состоит в том, чтобы обеспечить обратную связь о проблемах, связанных с обработкой пакетов IP при определенных условиях, но не для того, чтобы сделать IP надежным. Сообщения ICMP не являются обязательными и часто не разрешены из соображений безопасности.

ICMP является протоколом обмена сообщениями стека TCP/IP . ICMP обеспечивает контрольные сообщения и сообщения об ошибках и используется утилитами ping и traceroute . Хотя ICMP использует базовую поддержку IP, как высокоуровневый протокол, он фактически является отдельным протоколом Уровня 3 из стека TCP/IP.

Типы сообщений ICMP - и причины, почему они отправляются, - обширны. Мы обсудим некоторые из более распространенных сообщений.

Сообщения ICMP, которые могут быть отправлены, включают:

• Подтверждение узла
• Превышение Лимита Времени
• Перенаправление маршрута
• Подавление Источника

Подтверждение узла

Эхо-Сообщение ICMP может использоваться, чтобы определить, является ли узел рабочим. Локальный узел отправляет Эхо-запрос ICMP хосту. Хост, получающий эхо-сообщение, отвечает Эхо-ответом ICMP, как показано на рисунке. Это использование Эхо-сообщений ICMP является основой утилиты ping.

Недостижимое Место назначения или Служба

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

Среди Кодов Недостижимости Места назначения можно назвать:

0 = недостижимая сеть

1 = недостижимый узел

2 = недостижимый протокол

3 = недостижимый порт

Коды недостижимая сеть и недостижимый узел являются ответами от маршрутизатора, когда тот не может передать пакет. Если маршрутизатор получает пакет, для которого у него нет маршрута, он может ответить Недостижимым Местом назначения ICMP с кодом = 0, указывая на недостижимую сеть. Если маршрутизатор получает пакет, для которого он имеет присоединенный маршрут, но неспособен доставить пакет узлу в подключенной сети, маршрутизатор может ответить Недостижимым Местом назначения ICMP с кодом = 1, указывая, что сеть известна, но узел недостижим.

Коды 2 и 3 (недостижимый протокол и недостижимый порт ) используются конечным хостом, чтобы указать, что сегмент TCP или дейтаграмма UDP, содержавшаяся в пакете, не могли быть доставлены службе верхнего уровня.

Когда конечный хост получает пакет PDU Уровня 4, который должен быть доставлен недоступной службе, хост может ответить узлу-отправителю ICMP сообщением Недостижимости Места назначения с кодом = 2 или с кодом = 3, указывая, что служба не доступна. Служба, вероятно, является недоступной, поскольку не запущен соответствующий демон, который предоставляет данную службу, либо потому что безопасность узла не позволяет доступ к службе.

Превышенное время

ICMP Сообщение Превышенного Времени используется маршрутизатором, чтобы указать, что пакет не может быть передан, поскольку TTL пакета истекло. Если маршрутизатор получает пакет и уменьшает поле TTL в пакете до нуля, он отбрасывает пакет. Маршрутизатор может также отправить ICMP Сообщение Превышенного Времени исходному узлу, чтобы сообщить ему причину, по которой пакет был отброшен.

Перенаправление маршрута

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

Подавление Источника

ICMP Сообщение Подавления Источника может использоваться, чтобы сообщить источнику временно прекратить отправлять пакеты. Если у маршрутизатора не будет достаточного количества буферного пространства, чтобы получать входящие пакеты, то маршрутизатор отбросит пакеты. Если маршрутизатору приходится это делать, он может также передать ICMP сообщение Подавления Источника узлам-отправителям для каждого сообщения, которое он отбрасывает.

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

Когда хост получает ICMP сообщение Подавления Источника, он сообщает об этом Транспортному уровню . Далее хост-отправитель может использовать механизмы управления потоком TCP, чтобы скорректировать передачу.

Бедному Диалапщику посвящается!

Хочешь разобраться в работе пресловутого
протокола ICMP, о котором все так много говорят? Да, понимаю,
читать толстенные книги по протоколам, в которых понятны только предлоги, или еще хуже — красными глазами читать RFC, держа перед собой толстенный англо-русский словарь, так как твои познания в английском заканчиваются фразой:
"Who`s on duty today? I am on duty today.» — кому хочется?! Ты прекрасно знаешь, что самый верный путь к знаниям — это практика.
Когда ты видишь как формируются пакеты, как они отправляются, ты сможешь в дальнейшем понять и более сложные вещи! Но у тебя гигантская проблема — Windows 9x!
К сожалению работать с пакетами на низком уровне
winsock (библиотека предоставляющая интерфейс работы с сокетами) в этих версиях
(9х) не позволит! Есть несколько способов решения этой проблемы: ставь другую ось
(или старшие версии Windows 2000, XP…) или ищи NDIS драйвер и учись его использовать
(можешь, конечно, сам его написать, но если ты его написал, то зачем тебе читать все это). Но никто не запрещал тебе работать с протоколами высокого уровня.

Чтобы спуфить пакеты, например ICMP, нужно хотя бы знать как они выглядят и для чего вообще предназначены. Я предлагаю тебе инструмент, с помощью которого ты сможешь анализировать ICMP пакеты — а это достаточно важно!
Что тебе нужно для создания своего собственного анализатора ICMP пакетов:
компилятор какого-либо языка (реализующего
winsock, все функции описанные ниже практически не меняют своего интерфейса),
пальцы чтобы написать код, мозги чтобы все это понять.

Итак, начнем. Я написал все на С++ (Borland C++ v5.01). Сначала действуем по стандартному плану создания сервера: инициализируем структуру sockaddr_in таким образом:

Sockaddr_in *addr;
addr = new sockaddr_in;
addr->sin_family = AF_INET; // Семейство адресов AF_INET или PF_INET — каму как нравится.
addr->sin_port = htons(0); // Номер порта нам неважен, мы работаем на низком уровне,
// где номера портов не имеют значение.
addr->sin_addr.s_addr = htonl(INADDR_ANY); // Выбираем любой интерфейс(обычно он один)

Затем инициализируем структуру protoent, чтобы winsock знал с каким протоколом мы будем работать:

protoent *protocol;
protocol = getprotobyname(«icmp»);

Создаем дескриптор сокета:

int sock;
sock = socket(AF_INET,SOCK_RAW,protocol->p_proto);

Обрати внимание, что мы работаем не с SOCK_DGRAM, и уж тем более не с SOCK_STREAM, а с SOCK_RAW, так называемые «сырые» сокеты. Затем, как обычно, проверяем на ошибки и идем далее
(если INVALID_SOCKET, то обломись дружок). Биндим наш сокет с
адресом, которой мы определили в указателе addr:

int err;
err = bind(sock,(sockaddr *)addr,sizeof(*addr));

int rc;
char buffer;
while(true)
{
rc = recvfrom(sock,buffer,sizeof(buffer),0,(sockaddr *)addr,&len);
}

Проверяем на ошибки, если rc == -1 тогда ошибка, иначе все круто
и идем дальше (все это делается внутри бесконечного цикла).
Когда мы получили пакет из сети, в структуре addr у нас хранится
адрес того хорька, который послал тебе этот ICMP пакет, только не в привычном для нас виде
(«четыре точки»), а в машинном. Надо привести его к читаемому виду.
Легко!

cout<<«received from: «<sin_addr)<

Теперь у нас в руках полученный пакет (в массиве buffer). Что с ним делать? Организуем процедуру для вывода содержимого пакета на экран. Я особо не заморачивался по поводу этой процедуры, так что кому не
нравиться может организовать все самостоятельно. Главное знать, что где находиться!

Теперь о некоторых нюансах. Прежде всего как узнать ось по пингу? Конечно, точно ось не определить, но если тебя пингуют стандартными прогами, входящими в пакет ОС
(ping…) с размером пакета по дефолту, можно точно сказать: если тебе пришло 32 байта,
то знай — это твой товарищ по Виндам, если 56, то это
обладатель UNIX машины!

Если поле тип содержит 0 или 8, то знай — это ping . Если
5 — запрос на переадресацию (советую тщательно изучить именно этот тип ICMP,
так как он бывает очень полезен при проведении некоторых видов атак!).

Если ты все сделаешь, откомпилишь и запустишь, затем
пропингуешь самого себя, ты получишь столько пакетов сколько отправил! Почему, спросишь ты? Дело в том что «сырым» сокетам передаются не все ICMP пакеты, некоторые ядро обрабатывает самостоятельно, это небольшой недостаток нашей с тобой проги.
Зато если вместо IPPROTO_ICMP в сокете написать IPPROTO_RAW, тогда ты получишь доступ и к IGMP пакетам, а также ко всем пакетам в поле протокол которых стоит неизвестное ядру значение, попросту говоря все пакеты, которые ядро не знает как обрабатывать!

С вопросами можете обращаться по адресу , помогу чем смогу!