|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Нестандартное использование ARPВ данной статье описывается для чего нужен и как можно использовать ARP протокол. Автор не несет никакой ответственности за ущерб, который может быть нанесен после прочтения данной статьи. Материал предоставляется ИСКЛЮЧИТЕЛЬНО в учебных целях. Прежде всего, мне хотелось бы немного рассказать о том, как в локальной сети пакеты передаются от одного интерфейса к другому. В соответствии с семи-уровневой моделью OSI уровень связи данных (Data link layer) организует данные в кадры (frame). Иногда ее называют канальным уровнем. Каждый кадр имеет заголовок (header), содержащий адрес и управляющую информацию, а завершающая секция кадра (trailer) используется для исправления ошибок (иногда ее называют хвостом кадра). Кадр доставляется на сетевой адаптер, физический адрес которого совпадает с физическим адресом назначения из заголовка кадра. Заголовок кадра содержит физический адрес интерфейса назначения, часто называемый MAC-адресом (от Media Access Control - управление доступом к носителю). Система с указанным адресом принимает посланное сообщение и обрабатывает его.
Обозначения: Таким образом, для доставки
датаграммы в локальной сети нужно
определить физический адрес узла
назначения. Именно для этого существует
процедура автоматического определения
физических адресов. Протокол разрешения
адресов (Address Resolution Protocol - ARP)
обеспечивает метод динамической
трансляции между IP-адресом и
соответствующим физическим адресом на
основе широковещательных рассылок.
Данный ARP-запрос был "пойман"
после того как была запущена программа ping
10.0.0.1. В ARP-таблице не было данного IP-адреса
- поэтому был послан запрос. Отметим что
поле Destination Hardware Address неизвестно -
поэтому заполнено нулями (00:00:00:00:00:00). > ARP -a выводит список всех
закешированных элементов Как можно нестандартно
использовать ARP протокол? Ответ прост -
дело в том что большинство операционных
систем ARP-ответ заносит сразу же без
проверки (посылала ли система запрос) в
ARP таблицу (исключением является Solaris,
который игнорирует ARP ответы, если не
посылался ARP запрос). Почему в остальных
ОС не применен такой же метод, остается
загадкой. Демонстрация атаки: на хосте, который атакуем запускается ping с ключом -t (до прерывания пользователем). Через некоторое время посылается ложный ARP-ответ, а затем ARP ответ с правильным MAC-адресом. Посылать ARP-ответ можно или с помощью сниффера NetXRay, либо специально написанными для этого программами. Вот что будет результатом: >ping -t 10.0.0.1 Обмен пакетами с 10.0.0.1 по 32 байт: Ответ от 10.0.0.1: число байт=32
время<10мс TTL=128 Как видим, возникает тайм-аут
посланных пакетов. А какая будет
ситуация если послать только один ARP-ответ
с несуществующим MAC в данном случае? В
этом случае хост не сможет установить
соединение с хостом с IP-адресом 10.0.0.1 до
тех пор пока не будет прервано
выполнение команды ping. Дело в том,
что при попытке послать данные другим
приложением по этому же IP-адресу, в кеше
ARP-таблицы будет найдено соответствие MAC
и IP (повторяющаяся команда ping не дает
этим данным "устареть"). Если же мы
прекратим пинговать хост, то через
некоторое время (для многих систем 35-40
секунд) элемент ARP-таблицы будет удален
из нее, и при последующих попытках
какого-нибудь приложения установить
соединение или послать датаграмму к
хосту, будет послан ARP-ответ и в таблицу
соответствия MAC и IP адреса занесутся
верные данные. Проверяем список элементов: arp -a По идее все в порядке - элемент добавлен, и он является статическим. То есть, он не должен изменяться ни при каких обстоятельствах. Проверим это на деле - посылаем ложный ARP-ответ (Src IP: 10.0.0.1, Src MAC: 00-11-22-33-44-55, Dst IP: 10.0.0.6, Dst MAC: 00-40-95-01-59-01). Затем проверяем таблицу записей: arp -a Что получается? Элемент
является статическим, т.е. он не будет
удален из ARP-таблицы через некоторое
время, а MAC-адрес поменялся, после
получения ложного ARP-ответа! Аналогичная
особенность присутствует и на Windows 95/9 и
даже на Windows 2000 (Professional, Advanced Server). Из
этого можно сделать вывод, что защитить
себя, прописав статические элементы на
данных ОС, к сожалению, нельзя. Для того чтобы хост1 отправил датаграмму IP хосту2, необходимо переслать сначала ее на интерфейс1 сервера, а затем датаграмма будет отправлена с интерфейса2 хосту2. Как это происходит: IP-датаграмма укладывается в MAC-кадр, в котором Src MAC=MAC1, Dst MAC=MACs1. При получении интерфейсом1 на сервере, определяется что датаграмма предназначена для хоста2. IP-датаграмма укладывается в MAC-кадр, в котором Src MAC=MACs2, Dst MAC=MAC2 и отправляется. Данный кадр, отправленный с интерфейса2 сервера будет получен хостом2. Этот пример приведен для того чтобы яснее представить атаку "ложный ARP-сервер". Используя данную атаку возможно сниффить трафик между хостами, находящимися в разных сегментах. Это позволяет сниффить траффик даже если сеть разделена на сегменты свитчами и хабами. Итак имеем сеть поделенную на сегменты свитчами или хабами. При обычных условиях хост3 (атакующий) не может прослушивать траффик между хостами хост1 и хост2. Для создания ложного ARP-сервера сначала необходимо хосту3 послать два ложных ARP-ответа хост1 и хосту2:
Таким образом после получения
хостами указанных пакетов, в ARP-таблицах
появятся следующие элементы: хост1:
IP2:MAC3 Вследствие этого хост1 все
пакеты, предназначенные для хост2
будет направлять по MAC-адресу MAC3,
тоже самое будет делать и хост2 с
пакетами для хост1.
Продолжение следует...
Домашняя страница автора: http://www.uinc.ru/. Источник - SoftТерра, http://www.softerra.ru
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Copyright © "Internet Zone", http://www.izcity.com/, info@izcity.com |