Нестандартное использование ARP

Как можно нестандартно использовать ARP протокол? Ответ прост - дело в том что большинство операционных систем ARP-ответ заносит сразу же без проверки (посылала ли система запрос) в ARP таблицу (исключением является Solaris, который игнорирует ARP ответы, если не посылался ARP запрос). Почему в остальных ОС не применен такой же метод, остается загадкой.
Чем грозит такая ситуация? Если интерфейс получит данные о том, что какому-то IP соответствует несуществующий MAC, то IP-датаграммы к данному хосту будут вкладываться в кадр с фальшивым MAC. Это приведет к тому, что ни один сетевой интерфейс в локальной сети не будет воспринимать этот пакет. Таким образом, все данные уйдут в "никуда". Для реализации подобной атаки необходимо периодически (интервал зависит от операционной системы) посылать ложные ARP ответы. В результате атакуемый хост не сможет установить соединение с хостом, IP адрес которого указан в ложном ARP ответе. Данная атака применима, даже если уже установлено соединение между двумя хостами. После посылки даже одного ложного ARP ответа соединение будет разорвано по таймауту. Для того чтобы два хоста не смогли обмениваться пакетами друг с другом, необходимо направить ложные 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
Ответ от 10.0.0.1: число байт=32 время<10мс TTL=128
Ответ от 10.0.0.1: число байт=32 время<10мс TTL=128
Ответ от 10.0.0.1: число байт=32 время<10мс TTL=128
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
Ответ от 10.0.0.1: число байт=32 время<10мс TTL=128
Ответ от 10.0.0.1: число байт=32 время<10мс TTL=128
Ответ от 10.0.0.1: число байт=32 время<10мс TTL=128
Ответ от 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 таблице. Это не совсем удобно (учитывая то, что в локальной сети может быть много хостов), но тогда можно быть уверенным, что данная атака на ваш хост не принесет желаемого результата, для атакующего. Однако определить какой именно хост является атакующим, не представляется возможным.
Есть одна особенность, с которой столкнулся автор статьи в процессе экспериментов со статическими записями в ARP-таблице на Windows NT 4.0 (Service Pack 5). Попробуем добавить статическую запись, а потом попробовать снова послать ложный ARP-ответ.
Добавляем элемент:
arp -s 10.0.0.1 00-95-40-20-40-01

Проверяем список элементов:

arp -a

Интерфейс: 10.0.0.6 on Interface 2
Адрес IP Физический адрес Тип
10.0.0.1 00-95-40-20-40-01 статический

По идее все в порядке - элемент добавлен, и он является статическим. То есть, он не должен изменяться ни при каких обстоятельствах. Проверим это на деле - посылаем ложный 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

Интерфейс: 10.0.0.6 on Interface 2
Адрес IP Физический адрес Тип
10.0.0.1 00-11-22-33-44-55 статический

Что получается? Элемент является статическим, т.е. он не будет удален из ARP-таблицы через некоторое время, а MAC-адрес поменялся, после получения ложного ARP-ответа! Аналогичная особенность присутствует и на Windows 95/9 и даже на Windows 2000 (Professional, Advanced Server). Из этого можно сделать вывод, что защитить себя, прописав статические элементы на данных ОС, к сожалению, нельзя.
Использование персональных файрволов, таких как Tiny Personal FireWall, AtGuard, OutPost - тоже не сможет защитить от данной атаки. В этих брендмауэрах анализируются IP-датаграммы (TCP, UDP, ICMP протоколы). Очень жаль, что нет мониторинга ARP-пакетов. Будем надеяться, что в последующих версиях появятся эти функции.
Еще одной атакой в основу, которой положены слабые места ARP-протокола, является создание "ложного ARP сервера". Представим себе сеть, разделенную на сегменты, которые соединяются сервером, имеющим два интер-фейса. Пакеты из одного сегмента, предназначенные для хостов из другого сег-мента пересылаются через сервер.

Схема 1

Для того чтобы хост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-сервер". Используя данную атаку возможно сниффить траффик между хостами, находящимися в разных сегментах. Это позволяет сниффить траффик даже если сеть разделена на сегменты свитчами и хабами. Итак имеем сеть поделенную на сегменты свитчами или хабами.

Схема 2

При обычных условиях хост3 (атакующий) не может прослушивать траффик между хостами хост1 и хост2. Для создания ложного ARP-сервера сначала необходимо хосту3 послать два ложных ARP-ответа хост1 и хосту2:

Таким образом после получения хостами указанных пакетов, в ARP-таблицах появятся следующие элементы: хост1: IP2:MAC3
хост2: IP1:MAC3

Вследствие этого хост1 все пакеты, предназначенные для хост2 будет направлять по MAC-адресу MAC3, тоже самое будет делать и хост2 с пакетами для хост1.
Теперь хосту3 необходимо "слушать" весь траффик, и следующим образом обрабатывать такие пакеты

• получив MAC-кадр с MAC1->MAC3(IP1->IP2) сменить MAC-кадр на MAC3->MAC2(IP1->IP2) и отправить пакет;
  
• получив MAC-кадр с MAC2->MAC3(IP2->IP1) сменить MAC-кадр на MAC3->MAC1(IP2->IP1) и отправить пакет.

Продолжение следует...