Снова отсюда: http://vpodans.spaces.live.com/blog/cns!BB1419A2CFC1E008!138.entryЕдинственная вещь, которая отвечает за контроль дублирования адресов в сети - протокол преобразования адресов ARP. В общем смысле картина выглядит так:Узел A при получении нового IP-адреса отправляет специальный броадкаст Gratuitous (добровольный) ARP-запрос. Запрос представляет собой ARP-запрос для собственного IP адреса, в котором поле SPA (Source Protocol Address или IP адрес отправителя) и TPA (Target Protocol Address или IP адрес получателя) содержит собственный адрес. Если ответ на запрос получен, то это означает, что в сети есть дублирующийся адрес. Если ответ не был получен, то, соответственно, можно считать, что данный адрес в сети уникальный. С отстутсвием ответа всё понятно как бы, “нет ножек, нет и мультиков”(c)точка. Гораздо интересней ситуация происходит при получении ответа на такой запрос. Что же происходит в сети в таком случае?Узел, который отправляет в сеть Gratuitous запрос становится т.н. Атакующим узлом (Offening Node), а узел, который ответил на этот запрос становится т.н. Атакуемым узлом (Defending Node). Что происходит на каждом из узлов в процессе обнаружения конфликта:на Атакующем узле. Если адрес настраивается вручную, то при получении ответа на Gratuitous запрос инициализация адреса сбрасывается (т.е. узел не присвоит интерфейсу конфликтующий адрес). Об этом будет записано в системном журнале, ну и на экране появится ошибка. Если же адрес настраивается через DHCP, то клиент проверяет на конфликт адрес, который клиент получил от DHCP-сервера в пакете DHCPOFFER. Если адрес из DHCPOFFER является дублирующим (не уникальным), то клиент получив ответ на Gratuitous запрос отправит DHCP-серверу пакет DHCPDECLINE. Этот адрес в зависимости от реализации DHCP-сервера может помечаться как неисправный и будет удалён из пла свободных адресов. Клиент будет снова пробовать получить IP-адрес от DHCP-сервера отправкой в сеть пакета DHCPDISCOVER.на Атакуемом узле. Атакуемый узел определят конфликт очень просто - если поле SPA (Source Protocol Address или IP адрес отправителя), то узел констатирует конфликт. Этот факт будет так же зарегистрирован в журнале событий и пользователю будет выдана ошибка. При этом, атакуемый узел не сбросит с себя конфликтный IP-адрес (что сделает Атакующий узел).Когда конфликт констатирован, начинает работать механизм разрешения конфликта. Суть проблемы конфликта заключается в следующем:После отправки добровольного запроса по правилу работы ARP-протокола остальные клиенты сегмента обновят свои записи в ARP кэше со схемы: [Конфликтующий адрес:MAC атакуемого узла] (т.к. до этого момента IP-адрес атакуемого узла был уникален) будет заменён на схему: [Конфликтующий IP адрес:MAC атакующего узла]. Если атакуемый узел будет являться шлюзом по умолчанию, то все внешние запросы (которые идут на шлюз) будут перенаправлены с шлюза на атакующий узел (который проводит проверку своего адреса и на самом деле не является шлюзом). В такой ситуации сегмент потеряет связь с внешним миром, т.к. после запроса все машины перепишут новый MAC для шлюза. Однако, ARP ответ атакуемого узла на добровольный запрос не обновляет/исправляет ошибочные записи в ARP кэшах остальных машин в сегменте. Для этого атакуемый узел отправляет в сеть другой широкополосный ARP-запрос, как бы он сам проверял свой адрес на конфликт (атакуемый и атакующий узел меняются ролями). Этим запросом атакуемый узел обратно исправляет записи в кэшах ARP остальных машин в сегменте на правильные значения (ведь, атакующий узел не может использовать конфликтный IP). Но на этот запрос уже атакуемый (до этого он был атакующим) уже никто не ответит, т.к. изначально Атакующий узел к этому времени снимет с себя конфликтный IP-адрес.В итоге мы получаем картину из последовательного обмена тремя кадрами. Для наглядности привожу трассировку с Network Monitor:добровольный запрос атакующего узла: Frame: - Ethernet: Etype = ARP + DestinationAddress: *BROADCAST + SourceAddress: Microsoft Corporation 55578E EthernetType: ARP, 2054(0x806)- Arp: Request, 192.168.1.13 asks for 192.168.1.13 HardwareType: Ethernet ProtocolType: Internet IP (IPv4) HardwareAddressLen: 6 (0x6) ProtocolAddressLen: 4 (0x4) OpCode: Request, 1(0x1) SendersMacAddress: 00-03-FF-55-57-8E SendersIp4Address: 192.168.1.13 TargetMacAddress: 00-00-00-00-00-00 TargetIp4Address: 192.168.1.13ответ атакуемого узла на добровольный запрос: Frame: - Ethernet: Etype = ARP + DestinationAddress: *BROADCAST + SourceAddress: Intel Corporation 54578E EthernetType: ARP, 2054(0x806) UnkownData: Binary Large Object (18 Bytes)- Arp: Response, 192.168.1.13 at 00-18-DE-54-57-8E HardwareType: Ethernet ProtocolType: Internet IP (IPv4) HardwareAddressLen: 6 (0x6) ProtocolAddressLen: 4 (0x4) OpCode: Response, 2(0x2) SendersMacAddress: 00-18-DE-54-57-8E SendersIp4Address: 192.168.1.13 TargetMacAddress: 00-00-00-00-00-00 TargetIp4Address: 0.0.0.0добровольный запрос уже атакуемого узла: Frame: - Ethernet: Etype = ARP + DestinationAddress: *BROADCAST + SourceAddress: Intel Corporation 54578E EthernetType: ARP, 2054(0x806)- Arp: Request, 192.168.1.13 asks for 192.168.1.13 HardwareType: Ethernet ProtocolType: Internet IP (IPv4) HardwareAddressLen: 6 (0x6) ProtocolAddressLen: 4 (0x4) OpCode: Request, 1(0x1) SendersMacAddress: 00-18-DE-54-57-8E SendersIp4Address: 192.168.1.13 TargetMacAddress: 00-00-00-00-00-00 TargetIp4Address: 192.168.1.13Небольшое пояснение к трассировке: MAC=00-03-FF-55-57-8E - это MAC-адрес атакующего узла, который пытается присвоить себе конфликтный адрес (192.168.1.13). MAC=00-18-DE-54-57-8E - это MAC-адрес атакуемого узла, который уже находится в сети и ему присвоен конфликтный адрес (192.168.1.13).Последним кадром заново переписываются таблицы ARP-кэшей остальных узлов в сегменте на правильные значения.Однако, хочу добавить, что обмен Gratuitous-запросами и ответами происходит только при инициализации адреса. Если, например, узел будет сконфигурирован на конфликтный адрес до подключения узла в сеть, то после включения узла с конфликтным адресом обмен такими добровольными запросами-ответами происходить не будет. Поэтому оба узла будут продолжать использовать один конфликтный адрес, но при каждом ARP запросе оба узла будут генерировать ошибки о конфликте адресов.
comments powered by Disqus