2 одинаковых IP в одной сети. Опции

[Просмотр профиля]

1) Кто нибудь может сказать, что происходит, если в сети 2 одинаковых ИП?
2) Как вычислить 2 одинаковых адреса в сети, если 1 из них твой? (2 чужих одинаковых IP)?

[Просмотр профиля]

1) Кто нибудь может сказать, что происходит, если в сети 2 одинаковых ИП?

если в одном домене широковещания, то один или оба узла перестанут функционировать (вывалятся в APIPA).

2) Как вычислить 2 одинаковых адреса в сети, если 1 из них твой? (2 чужих одинаковых IP)?

ping или arp.

[Просмотр профиля]

если в одном домене широковещания, то один или оба узла перестанут функционировать (вывалятся в APIPA).

Ээээ, недумаю что именно так. Например я наблюдал такую картину:
У меня был ИП 192,168,1,5, но помощник случайно умудрился этот же ип себе сделать. Результат - у меня сеть работает, но не все адреса доступны, и что то странно как то себя всё вело, но всё же РАБОТАЛО... Сразу и не раскусил.... я сначала думал что что то либо с драйвером либо с сетевухой, пока случайно не обнаружил что у него такой же ип.

ping или arp.

А что покажет ПИНГ? Всё пингуется, как будто ничего и не произошло.
Arp правда не пробовал.




А тут на днях я что то похожее у себя заметил в сети локалки провайдера дома. Вот сижу и думаю, что за нафик, и как это обнаружить, и вылечить... Ну найти конечно дубликат вообще непонимаю как.


Может кто натыкался на такие грабли?

[Просмотр профиля]

some

Для отслеживания таких ситуаций попробуй использовать

Layer-2 Network Guard



Если штатные средства в домене - то искать проще всего, если имеется активное сетевое оборудорвание (к примеру Cisco). При совпадении адресов в жкрнале пишется MAC системы у которой такой же адрес. А потом найти - вопрос техники.

[Просмотр профиля]

some

Для отслеживания таких ситуаций попробуй использовать

Layer-2 Network Guard



Если штатные средства в домене - то искать проще всего, если имеется активное сетевое оборудование (к примеру Cisco). При совпадении адресов в журнале пишется MAC системы у которой такой же адрес. А потом найти - вопрос техники.

Спасибо. Дельный совет.
Конечно вариант с доменом не подходит, ибо нет там такого. насчет кисок -хз, что там у провайдера стоит, я то там всего лишь юзер((
Просто подозреваю, что кто то мой ИП стырить пытается, или захватить трафик. Поставил OutpostFirewall, вроде он такие вещи должен разрулить...

[Просмотр профиля]

При совпадении адресов в жкрнале пишется MAC системы у которой такой же адрес.

если не ошибаюсь, то виндовый журнал тоже пишет предупреждение в журнал дефолтно. Выявление клона не зависит от реализации ОС. Это заложено на уровне работы ARP.

[Просмотр профиля]

Нашёл кое чего по теме
http://otvety.google.ru/otvety/thread?tid=...%26tab%3Dwtmtod
http://www.securitylab.ru/forum/forum20/topic1619/messages/

[Просмотр профиля]

как только машина обнаруживает одинаковые ip Она доолжна сообщить о дубликате. Так должно быть правильно, если не сообщает это уже не хорошо,Ю да и в логах все можно посмотреть.

[Просмотр профиля]

Выявление клона не зависит от реализации ОС. Это заложено на уровне работы ARP.

Возможно. Но тема "Windowsдля новичков" - из этого и исходим.

Поставил OutpostFirewall, вроде он такие вещи должен разрулить...

каким образом?

[Просмотр профиля]

Ну чтож, попробую внести ясность в этот вопрос (если получится). Итак:
Единственная вещь, которая отвечает за дублирование адресов в сети - протокол преобразования адресов ARP. В общем смысле картина выглядит так:
Узел A получил новый адрес и он отправляет специальный броадкаст ARP запрос Gratuitous (добровольный). Запрос представляет собой ARP запрос для собственного IP адреса, в котором поле SPA (Source Protocol Address или IP адрес отправителя) и TPA (Target Protocol Address или IP адрес получателя) содержит собственный адрес. Если ответ на запрос получен, то это означает, что в сети есть дублирующийся адрес. Если ответ не был получен, то, соответственно, можно считать, что данный адрес в сети уникальный. С отстутсвием ответа всё понятно как бы, "нет ножек, нет и мультиков". Гораздо интересней ситуация происходит при получении ответа на такой запрос. Что же происходит в сети в таком случае:

Узел, который отправляет в сеть Gratuitous запрос становится т.н. Атакующим узлом (Offening Node), а узел, который ответил на этот запрос становится т.н. Атакуемым узлом (Defending Node). Что происходит на каждом из узлов в процессе обнаружения конфликта:

1)на Атакующем узле. Если адрес настраивается вручную, то при получении ответа на Gratuitous запрос инициализация адреса сбрасывается (т.е. узел не присвоит интерфейсу конфликтующий адрес). Об этом будет записано в системном журнале, ну и на экране появится ошибка. Если же адрес настраивается через DHCP, то клиент проверяет на конфликт адрес, который клиент получил от DHCP сервера в пакете DHCPOFFER. Если адрес из DHCPOFFER является дублирующим (не уникальным), то клиент получив ответ на Gratuitous запрос отправит DHCP серверу пакет DHCPDECLINE. Этот адрес в зависимости от реализации DHCP сервера может помечаться как неисправный и будет удалён из пла свободных адресов. Клиент будет снова пробовать получить IP адрес от DHCP сервера отправкой в сеть пакета DHCPDISCOVER.

2)на Атакуемом узле. Атакуемый узел определят конфликт очень просто - если поле SPA (Source Protocol Address или IP адрес отправителя), то узел констатирует конфликт. Этот факт будет так же зарегистрирован в журнале событий и пользователю будет выдана ошибка. При этом, атакуемый узел не сбросит с себя конфликтный IP адрес (что сделает Атакующий узел).

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

В итоге мы получаем картину из последовательного обмена тремя кадрами:
1)добровольный запрос атакующего узла:
SPA=конфликтный адрес
SHA=MAC атакующего узла
TPA=конфликтный адрес
THA=все нули
Где SPA - Source Protocol Address, SHA - Source Hardware Address, TPA и THA - то же самое, но только не Source, а Target (получатель).

2)ответ атакуемого узла на добровольный запрос:
SPA=конфликтный адрес
SHA=MAC атакуемого узла
TPA=все нули
THA=все нули.

3)добровольный запрос уже атакуемого узла:
SPA=конфликтный адрес
SHA=MAC атакуемого узла
TPA=конфликтный адрес
THA=все нули.
этим кадром заново переписываются таблицы ARP кэшей остальных узлов в сегменте на правильные значения.

Однако, хочу добавить, что обмен Gratuitous запросами и ответами происходит только при инициализации адреса. Если, например, узел будет сконфигурирован на конфликтный адрес до подключения узла в сеть, то после включения узла с конфликтным адресом обмен такими добровольными запросами-ответами не будет. Поэтому оба узла будут продолжать использовать один конфликтный адрес, но при каждом ARP запросе оба узла будут генерировать ошибки о конфликте адресов.

з.ы. если плохо написал - не пинайте, пишу как умею (IMG:style_emoticons/default/smile.gif)

Причина редактирования: поправил ошибки

[Просмотр профиля]

Camelot
Очень доступно и понятно. Спасибо (IMG:style_emoticons/default/28.gif)
Теоретический вопрос такой: есть ли отличия от этой схемы при намеренном arp спуфинге?

[Просмотр профиля]

JaM
нету. ARP протокол слишком простой и узкоспециализированный и различных возможностей у него мало. Зато в обычном режиме крайне стабильный. Только хочу добавить один момент:

ARP запрос Gratuitous (добровольный).

я подчеркнул последнее слово. Видите ли, протокол ARP не обязывает клиентов обмениваться вот такими пакетами при инициализации адреса. Это всё сугубо добровольно. По умолчанию в ОС Windows этот механизм включен, но ничто не мешает его отключить и тогда разрешения конфликта не будет и при определённых обстоятельствах сетка просто ложится намертво.

з.ы. немного отредактировал пост и опубликовал пока у себя (если будет нужно, закину это всё в wiki).
http://vpodans.spaces.live.com/blog/cns...8!138.entry