Для чего используется сообщение redirect протокола icmp
Обновлено: 30.06.2024
Как это часто бывает, различия неотличимы. Я рассматриваю 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.
Описание реализации атаки
Давайте представим гипотетическую сеть.
Все машины соединены простейшим способом (коаксиал, нет коммутаторов и интеллектуальных концентраторов). Вы находитесь на машине CAT рутом. Ваша задача - стать для остальных клиентов сети машиной DOG. Вы знаете, что DOG доверяет хосту RAT, так что Ваша задача - подставить в сетевом протоколе свою машину вместо RAT.
Программа 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 минут.
Что ещё может быть сделано
Особый интерес представляет так называемый "даровой (gratuitous) ARP". Подобная ситуация возникает, если IP-адреса источника и цели в ARP-запросе равны. Это обычно происходит в случае широковещательного Ethernet-запроса. Некоторые реализации TCP/IP-cтека определяют подобную ситуацию, как специальный случай, и система посылает запросы об обновлении информации ко всем сетевым клиентам, обновляя собственный кэш ARP-ответами. В этом случае один пакет может привести к компроментации всей сети. Хотелось бы отметить, что "даровой (gratuitous) ARP" не определён, как часть стандрата ARP, поэтому большинство производителей ОС не применяют его, что придаёт ему меньшую популярность.
ARP - достаточно серьёзный инструмент для всякого рода сетевых атак. Давайте представим, что кто-то установил ретранслятор (релэй), или тоннель на своей машине и убедил две соседние машины посылать пакеты друг другу через Ethernet-карту ретранслятора. Если этот ретранслятор просто пересылает пакеты к их настоящему месту назначения, никто ничего не заметит. Однако, в данной ситуации машина-ретранслятор способна модифицировать передаваемые данные, что представляет собой довольно большую угрозу конфиденциальности (безопасности) передаваемых данных. Простой программный фильтр может подставлять 2 случайных байта в произвольные моменты времени. Контрольная сумма большинства пакетов при этом не будет изменяться, но суммарный приходящий пакет будет искажён.
ICMP redirects
При определении маршрута модель сетевого протокола (IP) сначала просматривает элементы таблицы для хостов, а затем для сетей. Если оба поиска не дают результата, используется маршрут по умолчанию (обзначенный в таблице в поле Destination как 0.0.0.0). Обычно используется первый найденный маршрут. Таким образом, порядок поиска обеспечивает приоритетность маршрутов к хостам по отношению к маршрутам к сетям, что естественно, поскольку первые представлены более конкретными адресами. Также маршруты подразделяются на прямые (direct) и косвенные (indirect). Маршрут в сеть, непосредственно подключенную к сетевому интерфейсу, является прямым. Маршрут по умолчанию - косвенный, так как адресует получателя, расположенного вне вне непосредственно доступных сетевых сегментов. Время жизни маршрута зависит от протокола верхнего уровня. Например модуль TCP хранит маршрут на протяжении жизни виртуального канала (образуемого при установлении TCP-сеанса).
Поля имеют значения: Type-5 (ICMP-тип-Redirect), Сode -
Добавление, включённое переводчиком.
Согласно книге "TCP/IP Illusrated" хост с реализацией сокетов 4.4 BSD, который принял ICMP-redirect применяет некоторые правила до модификации таблицы маршрутизации. Это предотвращает неправильное (и неправомерное) изменение таблиц маршрутизации. Такие правила включают следующие условия:
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-кэш можно командой 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 пакетов включением в какой-нибудь из стартовых скриптов следующей последовательности:
Что касается операционной системы FreeBSD, то реагирование данной ОС на пакеты ICMP redirect перекрывается следующим образом:
В состав операционной системы 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 за издание книги "Атака на Интернет", выдержки из которой использовались в качестве многих дополнений.
Содержание
Запрос и ответ эхо-повтора ICMP
Примечание В большинстве операционных систем команды эхо-тестирования имеют синтаксис PING .
Например, обычно автор, чтобы обратиться на Web-узел Microsoft, отправляет со своего домашнего компьютера пакеты, которые вначале поступают на узел в г. Роли (Raleigh), шт. Северная Каролина, затем в Вашингтон, округ Колумбия, и наконец, поступают в Сиэтл, шт. Вашингтон. А когда автор заметил, что в определенные дни Web-узел Microsoft отвечает на запросы с особенно значительным замедлением, он решил выяснить, находится ли причина такого замедления в его локальной сети, в сети провайдера Internet или просто связана с нарушением работы опорной сети. А поскольку после выполнения трассировки маршрута с помощью программы traceroute было обнаружено, что путь в Сиэтл в период значительного замедления проходит через Флориду, ответ стал очевидным. По всей вероятности, опорная сеть, которая обычно используется, была перегружена или остановлена, поэтому пакеты были направлены по альтернативному маршруту, который оказался намного длиннее.
Дополнительная информация о протоколе ICMP приведена в документе RFC 792 (стандарт 5).
Этот документ был переведен Cisco с помощью машинного перевода, при ограниченном участии переводчика, чтобы сделать материалы и ресурсы поддержки доступными пользователям на их родном языке. Обратите внимание: даже лучший машинный перевод не может быть настолько точным и правильным, как перевод, выполненный профессиональным переводчиком. Компания Cisco Systems, Inc. не несет ответственности за точность этих переводов и рекомендует обращаться к английской версии документа (ссылка предоставлена) для уточнения.
Содержание
Введение
Протокол ICMP используется для связи с исходным источником, устранения ошибок, возникших при маршрутизации пакетов, и контроля трафика. В этом документе рассмотрены механизм перенаправлений ICMP и условия возникновения перенаправлений в сети.
Предварительные условия
Требования
Необходимо знание набора протоколов IP.
Используемые компоненты
Это поддерживается во всей серии версий программного обеспечения Cisco IOS и маршрутизаторов Cisco.
Условные обозначения
Пакет поступает на маршрутизатор через тот же интерфейс, через который выполняется маршрутизация исходящих пакетов.
Подсеть или сеть исходного IP-адреса находятся в той же подсети или сети IP-адреса следующего перехода, что и маршрутизируемый пакет.
Дейтаграмма не маршрутизируется от источника.
Например, если маршрутизатор имеет два IP-адреса в одном из интерфейсов:
Первоначальный пакет, для которого маршрутизатор отсылает команду переадресации, все равно маршрутизируется в нужном направлении.
Протокол IP имеет ясную и элегантную структуру. В нормальных ситуациях IP очень эффективно использует для пересылки память и ресурсы. Однако что произойдет в нестандартной ситуации? Что может прервать бесцельное блуждание датаграммы до завершения ее времени жизни после краха маршрутизатора и неисправности в сети? Кто предупредит приложение о прекращении отправки датаграмм в недостижимую точку назначения?
Бывают ситуации, приводящие к отбрасыванию (удалению из сети) датаграммы IP. Например, точка назначения может стать недоступной из-за обрыва связи. Или может завершиться время жизни датаграммы. Маршрутизатор не сможет переслать длинную датаграмму при запрещении фрагментации.
ICMP быстро сообщит системе о выявленной проблеме. Это очень надежный протокол, поскольку указание на ошибки не зависит от наличия сетевого центра управления.
Реально ICMP не имеет средств предоставить отчет об ошибках выделенному операционному центру. Для этого служит протокол SNMP (см. главу 20).
■ Трижды отправляется датаграмма.
■ Процесс повторяется с увеличением Time-to-Live на каждом шаге.
Если можно достичь точки назначения, то в итоге можно получить полный путь до него.
■ Широковещательных и многоадресных датаграммах
■ Фрагментах датаграмм, кроме первых
Существует много причин прекращения доставки датаграммы. Разорванная связь физически не позволит маршрутизатору достичь подсети назначения или выполнить пересылку в точку следующего попадания. Хост назначения может стать недоступным при отключении его для проведения профилактики.
Как уже отмечалось в главе 6, современные маршрутизаторы имеют хорошие средства обеспечения безопасности. Они могут быть сконфигурированы для просмотра входящего в сеть трафика. При запрещении сетевым администратором доступа к точке назначения датаграмма также не может быть доставлена.
| Код | Смысл |
|---|---|
| 0 | Сеть недостижима. |
| 1 | Хост недостижим. |
| 2 | Запрашиваемый протокол не поддерживается в точке назначения. |
| 3 | Порт недостижим (недоступно удалённое приложение). |
| 4 | Необходима фрагментация, но установлен флаг "Не фрагментировать". |
| 5 | Неверен маршрут от источника. |
| 6 | Неизвестна сеть назначения. |
| 7 | Неизвестен хост назначения. |
| 8 | Хост источника изолирован. |
| 9 | Административно запрещены коммуникации с сетью назначения. |
| 10 | Административно запрещены коммуникации с хостом назначения. |
| 11 | Сеть недостижима для заданного типа обслуживания. |
| 12 | Хост недостижим для заданного типа обслуживания. |
Значения кодов (см. таблицу 7.3) отражают причину тайм-аута.
| Код | Смысл |
|---|---|
| 0 | Завершилось время жизни датаграммы. |
| 1 | Завершилось время на сборку фрагментов датаграммы. |
| Код | Смысл |
|---|---|
| 0 | Значение в поле указателя специфицирует ошибочный октет. |
| 1 | Отсутствует требуемый вариант (используется военными для указания на отсутствие параметров безопасности) |
| 2 | Неверная длина |
Протокол IP очень прост: хост или маршрутизатор обрабатывают датаграмму и посылают ее как можно быстрее. Однако доставка не всегда проходит гладко. Могут возникнуть различные проблемы.
Когда один или несколько хостов отправляют трафик UDP на медленный сервер, то на последнем может возникнуть перегрузка, что приведет к отбрасыванию сервером некоторой части этого трафика.
Маршрутизатор может переполнить свои буферы и далее будет вынужден отбрасывать некоторые поступающие датаграммы. Медленное соединение через региональную сеть (например, на скорости 56 Кбит/с) между двумя скоростными локальными сетями (например, в 10 Мбит/с) может создать затор на пути следования датаграмм. Из-за этого в сети возникнут перегрузки, которые также приведут к отбрасыванию датаграммы и, следовательно, к созданию еще большего трафика.
Таблица 7.5 Коды перенаправления
| Код | Смысл |
|---|---|
| 0 | Перенаправление датаграммы в сеть |
| 1 | Перенаправление датаграммы в хост |
| 2 | Перенаправление датаграммы в сеть на основе значения из поля типа обслуживания |
| 3 | Перенаправление датаграммы в хост на основе значения из поля типа обслуживания |
Иногда ошибки должны обрабатываться совместно операционной системой, коммуникационным программным обеспечением и сетевым приложением.
При пересылке большого объема данных (например, при копировании файлов по сети) с одного хоста на другой размер датаграмм существенно влияет на производительность. Заголовки IP и TCP требуют не менее 40 дополнительных байт.
■ Если данные пересылаются в 80-байтовых датаграммах, дополнительная нагрузка составит 50%.
■ Если данные пересылаются в 400-байтовых датаграммах, дополнительная нагрузка составит 10%.
■ Если данные пересылаются в 4000-байтовых датаграммах, дополнительная нагрузка составит 1%.
Для минимизации дополнительной нагрузки лучше отсылать датаграммы наибольшего размера. Однако этот размер ограничивается значением максимального элемента пересылки (Maximum Transmission Unit — MTU) для каждого из носителей. Если датаграмма будет слишком большой, то она будет фрагментирована, а этот процесс снижает производительность. (С точки зрения пользователя, качество сети определяется двумя параметрами: интервалом пересылки (от начала пересылки до ее завершения) и временем ожидания (задержкой доступа к сети, занятой другими пользователями). Увеличение размера датаграммы приводит к снижению интервала пересылки, но увеличению ожидания для других пользователей. Грубо говоря, нагрузка на сеть будет выглядеть как пиковые импульсы с очень небольшой нагрузкой между ними, что считается самым неудачным вариантом загрузки сети. Гораздо лучше, когда сеть нагружается равномерно. — Прим. пер.)
Многие годы хосты избегали фрагментации, устанавливая эффективное значение MTU для пересылки в 576 октетов для всех нелокальных хостов. Это часто приводило к ненужному снижению производительности.
Гораздо полезнее заранее знать наибольший допустимый размер датаграммы, которую можно переслать по заданному пути. Существует очень простой механизм исследования MTU по пути (Path MTU discovery), позволяющий узнать это значение. Для такого исследования:
■ Флаг "Не фрагментировать" заголовка IP устанавливают в 1.
■ Размер MTU по пути первоначально устанавливают в значение MTU для локального интерфейса.
■ Хост источника уменьшит размер датаграммы и повторит попытку.
Поскольку пути пересылки могут меняться динамически, флажок "Не фрагментировать" нужно устанавливать во всех коммуникационных датаграммах. При необходимости маршрутизатор будут посылать сведения об обновлениях.
Если маршрутизатор использует устаревшее программное обеспечение, он не сможет предоставить значение MTU для следующего попадания. В этом случае значение для следующей попытки будет выбираться из списка стандартных размеров MTU (см. главу 4) с постепенным уменьшением для каждой новой попытки до достижения значения, нужного для коммуникации с удаленным хостом.
Разумеется, изменение пути следования может создать предпосылки для использования большего размера MTU. В этом случае система, согласовавшая небольшой размер MTU, будет пытаться его увеличить, если такое улучшение будет возможно.
■ Эхо-запросы и эхо-ответы обеспечивают обмен информацией между хостами и маршрутизаторами.
■ Запросы и ответы о маске адреса позволяют системе исследовать присвоенную интерфейсу маску адреса.
■ Запросы и ответы временной метки служат для извлечения сведений об установке времени на целевой системе. Ответы на такие запросы дают информацию, необходимую для оценки времени обработки датаграмм на хосте.
Эхо-запросы (Echo Request) и эхо-ответы (Echo Reply) применяются для проверки активности системы. Код типа 8 применяется в запросах, а код 0 — в ответах. Количество октетов в поле данных переменно и может выбираться отправителем.
Читайте также: