Icmp redirect что это

Пытаюсь реализовать ICMP-redirect атаку в лабораторных условиях.
Допустим три хоста
А 192.168.1.3 /255.255.255.0 на нем же 192.168.2.1/255.255.255.0
В 192.168.1.2
С 192.168.1.1

Так вот нужно сформировать пакет ICMP-redirect-host (ну или net), чтобы изменить таблицу маршрутизации на хосте 192.168.1.1., чтобы В мог перехватывать пакеты идущие с С на А (ясно потом нужно будет еще настроить перенаправление, но это уж другая тема)

Делаю это с хоста B при помощи Hping’a

Осноная проблема в том как присобачить к сообщению «Заголовок IP и 64 бита исходной дейтаграммы». Решил так: создал дейтагармму (echo request) от 192.168.1.1 к 192.168.2.1, перехватил wireshark’ом и схранил как бинарник data ее заголовок ip.
Теперь нужно это добро отослать вместе с моим ICMP-redirectом

пытаюсь сначала так:

hping3 192.168.1.1 —icmp —icmptype 5 —icmpcode 1 —icmp-gw 192.168.1.2 —spoof 192.168.1.3 -d 28 -E /root/Desktop/data

пакет redirect формируется нормально, адрес спуфится, но в данных(т.е.в «исходной дейтаграмме») бред:
заголовок ip левый, точнее от 1.2.3.4 к 5.6.7.8.
Hping наотрез отказывается воспринимать мой бинарник как нужно. Пытался тектсовым файлом — не работает.
Бьюсь уж довольно долго ничего в голову не идет.

Подскажите, что исправить, или может есть другие пути?

ЗЫ Утилита ICMP-redirect с дистрибутива back|track не работает.
ЗЗЫ Думаю проблема в том что, не проставлена опция —end, но на любые попытки ее проставить hping ругается. Как ее вообще юзать то, эту опцию.

Сообщений: 895 Баллов: 909 Регистрация: 25.08.2006
Это нравится: 0Да / 0Нет
12.07.2008 23:59:57

Попробуйте проще, я юзал Rehost Attacker (на Windows c GUI) для проведения такой атаки, она есть здесь http://www.securitylab.ru/software/233715.php . Из альтернатив ещё выделю Nemesis Packet Generator (GUI: Jnemesis), он есть не только под Linux, и sing ( http://sourceforge.net/projects/sing ).

В вашем случае, команда для ICMP-редиректа будет такая:

nemesis icmp -S 192.168.1.1 -D 192.168.1.3 -G 192.168.1.2 -qR

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

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

23.3.6 Сообщение Redirect

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

Ha рис. 23.5 показан предложенный формат для сообщения Redirect в ICMPv6. Целевой адрес — это адрес IP следующего попадания, который должен использоваться при пересылке пакета. Адрес назначения — это выбранная точка назначения. Поле выбора содержит адрес уровня связи данных целевой системы и может также включать сведения для перенаправления датаграммы.

Рис. 23.5. Формат сообщения Redirect

Icmp redirect что это

Как уже подчеркивалось в п. 3.2.3.1, маршрутизация в сети Internet играет важнейшую роль для обеспечения нормального функционирования сети. Маршрутизация в Internet осуществляется на сетевом уровне (IP-уровень). Для ее обеспечения в памяти сетевой ОС каждого хоста существуют таблицы маршрутизации, содержащие данные о возможных маршрутах. Каждый сегмент сети подключен к глобальной сети Internet как минимум через один маршрутизатор, а, следовательно, все хосты в этом сегменте и маршрутизатор должны физически располагаться в одном сегменте. Поэтому все сообщения, адресованные в другие сегменты сети, направляются на маршрутизатор, который, в свою очередь, перенаправляет их далее по указанному в пакете IP-адресу, выбирая при этом оптимальный маршрут. Напомним, что в сети Internet для выбора оптимального маршрута используются специальные протоколы маршрутизации: RIP, OSPF и т. д.

Рассмотрим, что представляет из себя таблица маршрутизации хоста. В каждой строке этой таблицы содержится описание соответствующего маршрута. Это описание включает: IP-адрес конечной точки маршрута (Destination), IP-адрес соответствующего маршрутизатора (Gateway), а также ряд других параметров, характеризующих этот маршрут. Обычно в системе существует так называемый маршрут по умолчанию (поле Destination содержит значение 0.0.0.0, то есть default, а поле Gateway — IP-адрес маршрутизатора). Этот маршрут означает, что все пакеты, адресуемые на IP-адрес вне пределов данной подсети, будут направляться по указанному default-маршруту, то есть на маршрутизатор (это реализуется установкой в поле адреса назначения в Ethernet-пакете аппаратного адреса маршрутизатора).

Как говорилось ранее, в сети Internet существует управляющий протокол ICMP, одной из функций которого является удаленное управление маршрутизацией на хостах внутри сегмента сети. Удаленное управление маршрутизацией необходимо для предотвращения возможной передачи сообщений по неоптимальному маршруту. В сети Internet удаленное управление маршрутизацией реализовано в виде передачи с маршрутизатора на хост управляющего ICMP-сообщения: Redirect Message. Исследование протокола ICMP показало, что сообщение Redirect бывает двух типов. Первый тип сообщения носит название Redirect Net и уведомляет хост о необходимости смены адреса маршрутизатора, то есть default-маршрута. Второй тип — Redirect Host — информирует хост о необходимости создания нового маршрута к указанной в сообщении системе и внесения ее в таблицу маршрутизации. Для этого в сообщении указывается IP-адрес хоста, для которого необходима смена маршрута (адрес будет занесен в поле Destination), и новый IP-адрес маршрутизатора, на который необходимо направлять пакеты, адресованные данному хосту (этот адрес заносится в поле Gateway). Необходимо обратить внимание на важное ограничение, накладываемое на IP-адрес нового маршрутизатора: он должен быть в пределах адресов данной подсети!

Анализ исходных текстов ОС Linux 1.2.8 показал, что ICMP-сообщение Redirect Net игнорируется данной ОС (это представляется логичным, так как динамическая смена маршрутизатора в процессе работы системы вряд ли необходима. Видимо, можно сделать вывод, что это сообщение игнорируют и другие сетевые ОС). Что касается управляющего сообщения ICMP Redirect Host, то единственным идентифицирующим его параметром является IP-адрес отправителя, который должен совпадать с IP-адресом маршрутизатора, так как это сообщение может передаваться только маршрутизатором. Особенность протокола ICMP состоит в том, что он не предусматривает никакой дополнительной аутентификации источников сообщений. Таким образом, ICMP-сообщения передаются на хост маршрутизатором однонаправлено, без создания виртуального соединения. Следовательно, ничто не мешает атакующему послать ложное ICMP-сообщение о смене маршрута от имени маршрутизатора.

Приведенные выше факты позволяют осуществить типовую удаленную атаку «Внедрение в распределенную ВС ложного объекта путем навязывания ложного маршрута» , рассмотренную в п. 3.2.3.1.

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

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

Рис. 4.7. Внутрисегментное навязывание хосту ложного маршрута при использовании протокола ICMP.

Рис. 4.7.1. Фаза передачи ложного ICMP Redirect сообщения от имени маршрутизатора.

передача на атакуемый хост ложного ICMP Redirect Host сообщения;
отправление ARP-ответа в случае, если пришел ARP-запpос от атакуемого хоста;
перенаправление пакетов от атакуемого хоста на настоящий маршрутизатор;
перенаправление пакетов от маршрутизатора на атакуемый хост;
при приеме пакета возможно воздействие на информацию по схеме «Ложный объект РВС»(п. 3.2.3.3).

В случае осуществления второго варианта удаленной атаки атакующий находится в другом сегменте относительно цели атаки. Тогда, в случае передачи на атакуемый хост ложного ICMP Redirect сообщения, сам атакующий уже не сможет получить контроль над трафиком, так как адрес нового маршрутизатора должен находиться в пределах подсети атакуемого хоста (см. описанную выше в этом пункте реакцию сетевой ОС на ICMP Redirect сообщение), поэтому использование данного варианта этой удаленной атаки не позволит атакующему получить доступ к передаваемой по каналу связи информации. Однако, в этом случае атака достигает другой цели: нарушается работоспособность хоста. Атакующий с любого хоста в Internet может послать подобное сообщение на атакуемый хост и в случае, если сетевая ОС на данном хосте не проигнорирует данное сообщение, то связь между данным хостом и указанным в ложном ICMP-сообщении сервером будет нарушена. Это произойдет из-за того, что все пакеты, направляемые хостом на этот сервер, будут отправлены на IP-адрес несуществующего маршрутизатора. Схема этой атаки приведена на рис. 4.8.

Рис. 4.8. Межсегментное навязывание хосту ложного маршрута при использовании протокола ICMP, приводящее к отказу в обслуживании.

Рис. 4.8.1. Передача атакующим на хост 1 ложного ICMP Redirect сообщения от имени маршрутизатора 1.

Рис. 4.8.2. Дезинформация хоста 1. Его таблица маршрутизации содержит информацию о ложном маршруте к хосту top.secret.com

Эксперимент показал, что оба варианта рассмотренной удаленной атаки удается осуществить (как межсегментно, так и внутрисегментно) на ОС Linux 1.2.8, ОС Windows ’95 и ОС Windows NT 4.0. Остальные сетевые ОС, исследованные нами (Linux 2.0.0 и защищенный по классу B1 UNIX), игнорировали данное ICMP Redirect сообщение (что, не правда ли, кажется вполне логичным с точки зрения обеспечения безопасности!).

Исследование возможностей перенаправления пакетов в протоколах ARP and ICMP

Как это часто бывает, различия неотличимы. Я рассматриваю 2 официальных протокола модели TCP/IP-ARP и ICMP, которые будучи внимательно рассмотрены, могут использоваться для достижения определённых целей.

На данный момент (1997 г. — прим. переводчика) большее распространение получили пассивные типы атак (сетевой сниффинг) для получения root-доступа в локальной сети, активные атаки приобрели меньшее распространены. Однако, разновидности активных атак в LAN могуть представлять большую опасность для системных администраторов. Технические аспекты атаки могут быть не вполне очевидны, поэтому давайте остановимся на них.

Варианты атаки, рассматриваемые в данном документе, включают спуффинг (spoofing-подмена одного из участников сетевого соединения, прим. переводчика) и DoS (Denial Of Service — отказ в обслуживании). IP-blind spoofing (я бы перевёл как слепая подмена IP-адреса) — наиболее общий и очень мощный способ атаки, требующий больших усилий и являющийся достаточно сложным в части реализации. В отличие от него ARP-спуффинг достаточно прост.

Поскольку ARP-spoofing возможен только в локальной сети, он является очень серьёзным способом для расширения границ сетевой атаки в случае получения доступа к одной из машин сети.

Основы протокола ARP

Автор пишет, что он мог бы углубиться в описание протокола ARP, но вместо этого рекомендует книгу W.Richard Stevens «TCP/IP Illustrated». (Прим. переводчика — ZDNC довольно подробно описал нюансы этого протокола в своей статье). Протокол описан в RFC826.

Описание реализации атаки

Давайте представим гипотетическую сеть.

IP 10.0.0.1 10.0.0.2 10.0.0.3 10.0.04 hostname CAT RAT DOG BAT hwaddr AA:AA BB:BB CC:CC DD:DD (для упрощения)

Все машины соединены простейшим способом (коаксиал, нет коммутаторов и интеллектуальных концентраторов). Вы находитесь на машине CAT рутом. Ваша задача — стать для остальных клиентов сети машиной DOG. Вы знаете, что DOG доверяет хосту RAT, так что Ваша задача — подставить в сетевом протоколе свою машину вместо RAT.

Первая мысль, которая приходит в голову — «почему я не могу установить IP-адрес другой машины и…» Но это не будет работать, по крайней мере это не будет работать надёжно. Если Вы скажете Ethernet-драйверу на CAT, что его IP-адрес 10.0.0.2, он станет отвечать ARP-ответами на этот IP. Но таким же образом будет себя вести и RAT. В данной ситуации не выиграет никто (в том числе и Вы). Подобная ситуация случается иногда в локальной сети при неправильной сетевой конфигурации машины (если ей назначается работающий IP-адрес). Многие сетевые программы (в том числе анализаторы сетевого траффика) моментально обнаруживают подобные вещи. Кроме того на консоли сетевого администратора может появиться сообщение, что такой-то MAC использует такой-то IP. То есть Вы не достигли того, чего хотели.

Программа send_arp.c (прилагаемая к данному тексту) может быть использована для решения поставленной задачи. Как видно из её названия, она посылает ARP-пакет (ARP-ответ, если быть точным: как следует из определения протокола, ответ будет принят успешно даже если его никто не запрашивал) в сеть, и Вы можете делать с данным пакетом всё, что Вы хотите. Посылая пакет при помощи данной программы, необходимо указать IP-адрес источника посылки и цели атаки и их hw-адреса (MAC).

Прежде всего необходимо «заглушить» свой Ethernet-драйвер. Это можно сделать при помощи команды ifconfig -arp. Разумеется, драйвер всё равно нуждается в ARP-информации (обмен пакетами ведётся на канальном уровне OSI-модели посредством включения в заголовки пакетов MAC-адресов), но этого можно достичь, указав ядру ARP-информацию вручную при помощи команды arp (8). Критическая часть нашего замысла — убедить соседей (по сети) в достоверности передаваемой информации. В случае, описанном здесь, Вы хотите, чтобы DOG верил, что МАС-адрес RAT на самом деле равен МАС-адресу САТ (АА:АА). Поэтому вы посылаете ARP-ответ с источником IP-адреса 10.0.0.2, hw-адресом источника АА:АА, IP-адресом цели 10.0.0.3 и hw-адресом СС:СС. Сейчас DOG знает, что RAT-это АА:АА. ARP-кэш, конечно, необходимо периодически обновлять (поскольку в противном случае ARP-запросы начнёт посылать сама машина, что не входит в наши планы). Периодичность часто зависит от конкретной ОС, но как выяснилось, посылки пакета один раз в 40 сек в большинстве случаев бывает достаточно. Вы можете посылать пакет и чаще — это не повредит.

Сложность здесь связана с особенностью механизма ARP-кэширования. Некоторые ОС (например, LINUX) будут пытаться обновить кэш-таблицу, посылая unicast (однонаправленные) пакеты к кэшируемым адресам. Так как такой запрос, направленный к ИСТИННОМУ RAT может помешать нам в наших планах, его необходимо предупредить. Этого можно достичь, зафлудив систему, которая могла послать ARP-запрос, ложными ARP-ответами таким образом, что она никогда не пошлёт ARP-запрос. Предупреждение, как всегда, является лучшим лекарством. В то время, как настоящий пакет от DOG к RAT должен быть послан, посылается ложный пакет с ARP-ответом от САТ. Как говорилось выше, периодичности в 40 сек. бывает достаточно.

Итак, процедура довольно простая. «Поднимаем» (bring up) алиас-интерфейс, т.е. eth0:1 (или используем текущий, не имеет значения) с IP-адресом RAT и включённым ARP-поскольку необходимо заполнить кэш-таблицу сначала, а это невозможно с выключенным ARP. Устанавливаем маршрут для DOG через правильный интерфейс. Устанавливаем в кэш-таблице запись для DOG и затем отключаем ARP. Теперь у нас всё установлено.

После этого запускаем прилагаемую программу send_arp для DOG и для RAT и теперь DOG уверен, что на самом деле Вы RAT. В дальнейшем не забываем периодически посылать ARP-пакеты для DOG и RAT.

Описанная атака работает, конечно, только в локальной сети (вернее, граница атаки зависит от дальности прохождения ARP-пакетов, которые почти никогда не маршрутизируются). Но интересное применение возможно, если в приведённом выше примере заменить DOG hw-адрес на hw-адрес маршрутизатора. Если это сработает (я не уверен, что это всегда будет работать, ARP-реализация на маршрутизаторах может быть достаточно глупой), Вы можете легко подменить любую машину в локальной сети для всего остального мира (Интернета, имеется в виду — прим. переводчика). Таким образом целевая машина мрожет быть где угодно, но машина, которую Вы хотите подментить должна быть в одном с Вами сегменте сети.

Исследования различных сетевых ОС (источник — книга «Атака на Интернет») выявили, что в ОС Linux при адресации к хосту, находящемуся в одной подсети с данным хостом, ARP-запрос передаётся, если в ARP-таблице отсутствует соответствующая запись о Ethernet-адресе, и при последующих обращениях к данному хосту ARP-запрос не посылается. В SunOS при каждом новом обращении к хосту (в том случае, если в течение некоторого времени обращения не было) происходит передача ARP-запроса и, следовательно, ARP-таблица динамически обновляется. ОС Windows 95 ведёт себя почти как Linux, за исключением того, что периодически (каждую минуту) посылает ARP-запрос о MAC-адресе маршрутизатора; в результате в течение нескольких минут вся LAN с Win95 без труда берётся под контроль ложным ARP-сервером. ОС WinNT 4.0 также использует динамически изменяемую ARP-таблицу, и ARP-запросы о MAC-адресах маршрутизатора передаются каждые 5 минут.

Что ещё может быть сделано

Кроме спуффинга, есть ещё большой диапазон действий, которые могут быть совершены при помощи манипуляций с ARP-протоколом. DoS (Denial Of Service — отказ в обслуживании — прим. переводчика) — наиболее очевидное применение. Наводняя жертву неправильными hw-адресами, можно сделать её полностью «немой». Возможно даже полностью предотвратить связь этой машины с любой (или определённой) машиной сети (и размер ARP-кэша обычно достаточен для заполнения ARP-информацией всех машин LAN ). Также очевидной целью атаки могут быть маршрутизаторы. Удар по ARP-кэшу в этом случае также должен быть двухсторонним: обе системы — жертва и машина, с которой Вы хотите отключить связь данной машины, должны быть зафлужены ложными пакетами. В простейшем случае в пакете должен быть установлен несуществующий адрес. Но это не очень эффективно, поскольку машина быстро поймёт, что она говорит с несуществующей машиной и пошлёт обратный ARP-запрос. Конечно, послав со своей стороны следующий ARP-ответ, вы опять «обнулите» результат, но необходимо это делать достаточно часто. Более эффективный путь — наводнить жертву пакетами с hw-адресами машины, которая «жива» и работает в сети. Опять же, это зависит от определённой ситуации, но очень часто случается, что жертва посылает обратно пакеты различных типов, которые достигают неверного места назначения — тогда система, принимающая пакеты, будет генерировать ICMP-пакеты типа 3 «ICMP Xxxx Unreachable» для машины-жертвы, таким образом эмулируя соединения несколько неправильным способом. Подобного рода псевдосоединения могут легко отсрочить время истечения ARP-кэша. В Linux, например, псевдосоединения увеличивают время истечения срока кэша (то есть время, когда будет послан пакет на обновление кэш-таблицы) с обычных 1 мин. до 10 мин. На это время большинство (или все) TCP-соединения оказываются заблокированными (screw up).

Особый интерес представляет так называемый «даровой (gratuitous) ARP». Подобная ситуация возникает, если IP-адреса источника и цели в ARP-запросе равны. Это обычно происходит в случае широковещательного Ethernet-запроса. Некоторые реализации TCP/IP-cтека определяют подобную ситуацию, как специальный случай, и система посылает запросы об обновлении информации ко всем сетевым клиентам, обновляя собственный кэш ARP-ответами. В этом случае один пакет может привести к компроментации всей сети. Хотелось бы отметить, что «даровой (gratuitous) ARP» не определён, как часть стандрата ARP, поэтому большинство производителей ОС не применяют его, что придаёт ему меньшую популярность.

ARP — достаточно серьёзный инструмент для всякого рода сетевых атак. Давайте представим, что кто-то установил ретранслятор (релэй), или тоннель на своей машине и убедил две соседние машины посылать пакеты друг другу через Ethernet-карту ретранслятора. Если этот ретранслятор просто пересылает пакеты к их настоящему месту назначения, никто ничего не заметит. Однако, в данной ситуации машина-ретранслятор способна модифицировать передаваемые данные, что представляет собой довольно большую угрозу конфиденциальности (безопасности) передаваемых данных. Простой программный фильтр может подставлять 2 случайных байта в произвольные моменты времени. Контрольная сумма большинства пакетов при этом не будет изменяться, но суммарный приходящий пакет будет искажён.

ICMP redirects

Эффект, подобный описанному выше при работе с протоколом ARP, может быть также достигнут другим путём, используя законную особенность протокола ICMP, а именно возможность посылки сообщения, требующего перенаправления пакетов при маршрутизации. Протокол ICMP (Internet Control Message Protocol — RFC792) предназначен для управления процессом передачи IP-пакетов и формирования сообщений при возникновении ошибок при передаче отправителю датаграммы. Одной из функций этого протокола является управление таблицами маршрутизации на хостах внутри сегмента сети. Сетевая подсистема предназначена для работы в коммуникационной среде, представляющей собой набор сегментов, связанных между собой. связь между отдельными сегментами достигается путём подключения их к хостам, имеющим несколько различных сетевых интерфейсов. Такие хосты (называемые маршрутизаторами) при необходимости выполняют передачу данных от одного сегмента к другому (forwarding). Для сетей пакетной коммутации выполнение этой задачи непосредственно связано с выбором маршрута прохождения пакетов данных (routing). Для этого система хранит таблицы маршрутизации, используемые протоколами сетевого уровня для выбора требуемого интерфейса для передачи пакета адресату. Информация о маршрутах хранится в виде 2-х таблиц, одна из которых предназначена для маршрутов к хостам, а вторая — для маршрутов к сетям. Посмотреть таблицы маршрутизации можно при помощи команд route (route -n) и netstat -rn.

При определении маршрута модель сетевого протокола (IP) сначала просматривает элементы таблицы для хостов, а затем для сетей. Если оба поиска не дают результата, используется маршрут по умолчанию (обзначенный в таблице в поле Destination как 0.0.0.0). Обычно используется первый найденный маршрут. Таким образом, порядок поиска обеспечивает приоритетность маршрутов к хостам по отношению к маршрутам к сетям, что естественно, поскольку первые представлены более конкретными адресами. Также маршруты подразделяются на прямые (direct) и косвенные (indirect). Маршрут в сеть, непосредственно подключенную к сетевому интерфейсу, является прямым. Маршрут по умолчанию — косвенный, так как адресует получателя, расположенного вне вне непосредственно доступных сетевых сегментов. Время жизни маршрута зависит от протокола верхнего уровня. Например модуль TCP хранит маршрут на протяжении жизни виртуального канала (образуемого при установлении TCP-сеанса).

Перенаправление (изменение маршрута) осуществляется функцией rtredirect(), вызываемой модулем протокола в ответ на получение от соседних шлюзов управляющих сообщений о перенаправлении маршрута. Динамическое управление маршрутизацией изначально задумывалось для предотврещения возможной передачи сообщений по неоптимальному маршруту, а также для повышения отказоустойчивости Сети в целом. Предполагалось, что сетевой сегмент может быть подключён не через один (как обычно), а через несколько маршрутизаторов. В этом случае адресоваться во внешнюю сеть можно через любой из ближайших узлов. При изменении оптимального маршрута или отказе одного из маршрутизаторов необходимо изменение таблицы маршрутизации в памяти операционной системы. Такое динамическое изменение возложено на протокол ICMP. Протокол в этом случае посылает сообщение ICMP Redirect Message следующего формата:

------------------------------------------- | 8bit Type | 8bit Code | 16bit Checksum | ------------------------------------------- | 32 bit Gateway IP | ------------------------------------------- | Internet Header + 64 bits of Datagram | -------------------------------------------

Поля имеют значения: Type-5 (ICMP-тип-Redirect), Сode —

0=Redirect datagrams for the Network\\ 1=Redirect datagrams for the Host\\ 2=Redirect datagrams for the Type of Service and Network\\ 3=Redirect datagrams for Type of Service and Host.

Cообщения с кодами 0 и 2 не используются современными ОС. Сообщение с кодом 1 информирует хост о том, что следует создать новый маршрут к отмеченному в сообщении объекту и внести его в таблицу маршрутизации, указывая IP-адрес хоста, для которого нужна смена маршрута (адрес будет занесён в поле Destination в пристыкованном IP-заголовке), и новый IP маршрутизатора, куда необходимо направлять пакеты для данного хоста (этот адрес заносится в поле Gateway). Что касается поля Type of Service (TOS) в заголовке IP-пакета, оно, по замыслу разработчиков должно было определять приоритет при маршрутизации. На это поле отводится 8 бит. Различные биты представлют собой значимость, задержку, скорость передачи, надёжность. TOS определяет обработку датаграммы при передаче через различные сети от источника к получателю. В большинстве случаев может оказаться невозможным удовлетворить сразу нескольким требованиям при обработке, предусмотренным полем TOS.

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

Добавление, включённое переводчиком.

Согласно книге «TCP/IP Illusrated» хост с реализацией сокетов 4.4 BSD, который принял ICMP-redirect применяет некоторые правила до модификации таблицы маршрутизации. Это предотвращает неправильное (и неправомерное) изменение таблиц маршрутизации. Такие правила включают следующие условия:

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

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

Безопасность ICMP как протокола в данной ситуации равна нулю. Подменить IP-адрес в пакете на IP-адрес маршрутизатора достаточно просто и прилагаемая программа icmp_redir.c делает это. RFC , в которм предъявляются требования к хостам, определяет, что система ДОЛЖНА следовать указаниям ICMP redirect, если пакет исходит от роутера. Многие системы именно так и поступают (за исключением непатченного (vanilla) Linux 2.0.30, где этого не произошло и тестовых 2.0.29 и 2.0.31pre9 Алана Кокса).

ICMP redirect представляет большую потенциальную возможность для DoS. В отличии от ARP-кэша, маршруты хоста не требуют обновления со временем. И конечно, в данном случае не требуется доступа к локальной сети, атака может быть запущена с любого места. Таким образом, если машина-жертва принимает ICMP redirects (и пакеты могут действительно достичь её), то система может прекратить поддерживать связь с любым определённым адресом в сети (не со всеми, но с теми, которые расположены в других физических сетях с жертвой). ДНС-сервера в данном случае могут быть потенциальными жертвами.

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

Первая проблема — внутренний IP роутера — решается простым перебором, так как узнать его из внешней сети не представляется возможным (traceroute дает только IP роутера во внешней сети). Так как большинство хостов в сети находится в подсетях класса С, то для осуществления этой атаки достаточно будет послать 254 пакета (O-й и 255-й адрес отпадают по вполне понятным причинам) ICMP Redirect с различными IP отправителя.

Вторая проблема — выбор имени (или IP) сервера, к которому будет изменена маршрутизация. Тут можно просто посылать пакеты с IP известных и часто используемых серверов Internet (поисковые сервера, серверы известных фирм, IRC -сервера и т.д.)

Эксперимент, проведённый авторами книги «Атака на Интернет» показал, что реализовать вариант удалённой атаки типа ICMP Redirect удалось осуществить как межсегментно, так и внутрисегментно на ОС Linux 1.2.8, ОС Win95 и ОС WinNT 4.0. Остальные сетевые ОС (испытывались Linux версии выше 2.0.0 и CX/ LAN /SX, защищённая по классу B1 UNIX), проигнорировали ICMP Redirect.

Добавление, включённое переводчиком.

Здесь хотелось бы добавить, что сам Алан Кокс в дискуссии на сервере BUGTRAQ по данной статье указывает, что Юрий неправ. ICMP redirect маршруты для хостов всё-таки не постоянно держатся в таблице маршрутизации, а убираются через некоторе время.

Однако если находиться на коммутируемой сети (switched в оригинале) с большой сетевой маской (например сети класса B), можно использовать переназначение ICMP против многих хостов для добавления больше 65000 маршрутов в их таблицы.

Таким образом *nix-машины просто израсходуют всё доступоное RAM. Многие «десктоповые» ОС используют линейный алгоритм для поиска маршрутов.

Как защититься

ARP, как протокол низкого уровня обычно скрыт от большинства людей (работа протокола — прим. переводчика). LAN -администраторы, конечно, представляют себе механизм работы протокола, но обычно уделяют ему мало внимания. Вы всегда можете исследовать содержимое ARP-таблицы используя команду arp(8) в случае возникновения каких-нибудь сетевых проблемм, но это не самое очевидное, что обычно приходит в голову. Даже M$-системы имеют arp-команду и необходимо помнить, что изучение содержимого ARP-таблицы может помочь в некоторых ситуациях. Однако, если Вы цель атаки, источник которой из другой подсети, проникший через подмену ARP маршрутизатора, Вам это ни о чём не скажет. Просто, таблица маршрутизации хоста может быть исследована на предмет опознавания входов, сгенерированных ICMP (в большинстве версий route(1)они маркируются флагом D в поле флагов).

Напомним, что просмотреть ARP-кэш можно командой arp -a (или -an, чтобы предотвратить обращение к ДНС-серверу).

Приведённая выше схема ARP-атаки работает в сетях 10Base2 (коаксиал). Однако, если машины соединены более «продвинутым» способом, используя некоторые «разумные» концентраторы или коммутаторы, атака может быть обнаружена и даже невозможна (то же самое касается и пассивных атак).

Почему я не остановился более подробно на ICMP-атаках? Дело в том, что многие сети имеют очень простую структуру и поэтому нет необходимости для добавления чего-нибудь в таблицы маршрутизации. Во-вторых, во многих сетях обычно устанавливают статические таблицы маршрутизации вручную, поэтому зачем доверять подобное измененение ICMP? И окончательно, ввиду опасности вышеописанной атаки, я даже запретил подобную ситуацию в моей ОС, даже ценой несоблюдения RFC1122. Но это может быть довольно непросто. На Linux или любой другой ОС с открытыми кодами, это может быть сделано на уровне «хака» ядра. На IRIX 6.2 и возможно других версий это достигается выставкой icmp_dropdirects=1 при использовании systune. Также можно достичь хорошего эффекта запретив прохождение пакетов типа ICMP redirect через маршрутизаторы (файрволлы). Как это сделать для Linux описывается во многих примерах настройки пакета ipchains (ipfw, iptables), также настройке фильтрации ICMP-пакетов уделено много места в книге «Брандмауэры в Linux». В качестве примера хотелось бы сказать что в Linux можно вообще очень просто запретить приём ICMP Redirect пакетов включением в какой-нибудь из стартовых скриптов следующей последовательности:

for f in /proc/sys/net/ipv4/conf/*/accept_redirects; do echo 0 > &f done;

Что касается операционной системы FreeBSD, то реагирование данной ОС на пакеты ICMP redirect перекрывается следующим образом:

/etc/rc.conf icmp_drop_redirect="YES"

В ARP мы сталкиваемся с ситуацией динамического разрешения IP-адресов без применения централизованного сервера. В протоколе DNS , например, при преобразовании hostname-адресов в IP-адреса сначала проверяется файл /etc/hosts и в случае отсутствия там IP-адреса посылается запрос на ДНС-сервер (хотя порядок опредения можно и изменить). Я не вижу причины, почему бы также не поступить в случае с ARP. Ethernet-адреса не изменяются очень часто. Кроме того отказ от динамического обновления ARP-таблицы значительно снизит нагрузку сети. Ethernet-карта может быть запущена без включения ARP-режима, а необходимые записи в ARP-таблицу могут быть включены вручную. Кроме того, это уменьшит количество пакетов, передаваемых по сети. Существует также способ брать MAC-адреса из файла /etc/ethers. Еще существет способ статически прописывать ARP-записи в ARP-кэш при помощи опций -f -s команды ARP. Можно, для счастливых пользователей ОС Linux привести пример скрипта на Perl, который статически прописывает ARP-таблицу из предварительно составленного файла. Данный скрипт должен запускаться ПОСЛЕ «поднятия» сетевых интерфейсов.

#!/usr/bin/perl # by John Goerzen #Program: forcehwaddr #Program to run ARP to force certain tables. #Specify filename to read from on command line, or read from stdin. foreach(<>) < # For each input line. chomp; # Strip if CR/LF if(/^#/) < next; ># If it's a comment, skip it. if(((($host, $hw)=/\s*(.+?)\s+(\S+)\s*/)==2)&& !(/^#/)) < # The text between the slashes parses the input line as follows: # Ignore leading whitespace. (\s*) # Then, start matching and put it into $host($host,(.+?)) # Skip over the whitespace after that (\s+) # Start matching. Continue matching until end of line or optional # trailing whitespace. # Then, the if checks to see that both a # host and a hardware address were matched. # (2 matches). If not, we skip the # line (assuming it is blank or invalid or something). # a poung sign; if so, ignore it (as a comment). # Otherwise, run the appropriate command: printf("Setting IP %-15s to hardware address %s\n",$host,$hw); system "/usr/sbin/arp -s $host $hw\n"; >>

В состав операционной системы LINUX входит утилита arpwatch, при помощи которой ARP-кэш держит таблицу соответствия MAC и IP-адресов.

Из мануала:
Arpwatch keeps track for ethernet/ip address pairings. It syslogs activity and reports certain changes via email. Arpwatch uses pcap(3) to listen for arp packets on a local ethernet interface.

Также, для UNIX есть утилита ARP Wrap, которая предотвращает атаки типа АРП-спуффинга до выполнения программ (telnet, SSH).

Из оригинального описания:
Arpwrap is a tool which attempts to detect ARP spoofing attacks before executing a unix command (such as SSH or Telnet).

Приложение

Исходные тексты программ

Полная версия этой статьи в PDF формате: arp_icmp.pdf

Господам Медведовскому И.Д., Семьянову П.В., Леонову Д.Г. ака dl за издание книги «Атака на Интернет», выдержки из которой использовались в качестве многих дополнений.

А.Робачевскому за прекрасную книгу «Операционная система UNIX»
XR за просмотр первоначального варианта статьи и выдачу пожеланий.
KMINT21 за дополнение по защите FreeBSD.
Статья Ю.Волобуева: http://www.securityfocus.com/data/library/arp_fun.txt
Медведовский И.Д., Семьянов П.В., Леонов Д.Г. — «Атака на Интернет»,
изд. второе, изд. ДМК, 1999 г.
Робачевский А. — «Операционная система UNIX», изд BHV, 1997 г.
Роберт Л. Зиглер — «Брандмауэры в Linux», 2000 г.

Сайт rtfm.wiki использует cookies и трекинг посещений. Продолжая использовать этот сайт, вы соглашаетесь с сохранением файлов cookie на вашем компьютере. Если вы не согласны покиньте сайт или включите Adblock �� ОК Что такое cookies? ��

Icmp redirect что это

Icmp redirect что это

23.3.6 Сообщение Redirect

Читайте также

7.4.1 Сообщение Destination Unreachable

7.4.2 Сообщение Time Exceeded

7.4.3 Сообщение Parameter Problem

7.4.5 Сообщение Source Quench

7.4.6 Сообщения Redirect

20.9.7 Сообщение get-bulk версии 2

20.9.9 Сообщение inform версии 2

Ответ на сообщение

6.5.9. Действие REDIRECT

Сообщение при загрузке

1.3.3.1. Сообщение WM_NCHCHITTEST

Сообщение об ошибках gbak

8.1. Сообщение WM_COPYDATA

Как сообщение подписывается.

Как послать зашифрованное сообщение.

Сообщение от друга

Icmp redirect что это

Исследование возможностей перенаправления пакетов в протоколах ARP and ICMP

Основы протокола ARP

Описание реализации атаки

Что ещё может быть сделано

ICMP redirects

Как защититься

Приложение

Добавить комментарий Отменить ответ