Периодически на форумах поднимаются вопросы о работе сетей, которые содержат одинаковые IP адреса в одном физическом сегменте. Почитав некоторые форумы, пришёл к выводу, что не все ясно представляют себе весь этот процесс и за факты начинают выдавать какие-то выдумки или догадки, которые не очень близки от истины. Вот и недавно, на одном замечательном ресурсе системных администраторов был поднят вопрос об этом. И я решил как-то прояснить этот вопрос. Формат форумов предполагает обмен цепочками вопрос-ответ  небольших объёмов. Поэтому попробую более развёрнуто обсудить вопрос здесь, в блоге.

Единственная вещь, которая отвечает за контроль дублирования адресов в сети - протокол преобразования адресов 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:

1. добровольный запрос атакующего узла:
     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
2. ответ атакуемого узла на добровольный запрос:
     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
3. добровольный запрос уже атакуемого узла:
     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 запросе оба узла будут генерировать ошибки о конфликте адресов.

• право удаления файла появляется не от разрешений самого файла, а родительской папки.

Дело в том, что при удалении файла NTFS не берёт в расчёт разрешения самого файла, а смотрит право родительской папки для этого файла. А если посмотреть свойства родительской папки, то там будет отмечено разрешение Delete subfolders and files. При этом не важно, наследует ли файл разрешения от родителькой папки, или нет. Именно право Delete subfolders and files перекрывает право самого файла (Read) и позволяет удалить этот файл.

Решение проблемы:

Очень многие спотыкаются на эти грабли, поэтому для эффективного, а главное, гарантированного назначения прав пользователю следует руководствоваться следующими правилами:

• не задавать права на ресурсы на уровне файлов, а только на уровне папок;
• не давать пользователям права Full Control на папку, а только Modify;
• Создавать иерархию разрешений в виде ёлочки. Т.е. увеличивая права пользователя на ресурс спускаясь по дереву. Иными словами "наименьшие права на корень ресурса и расширять права уже на дочерние ресурсы.

Во втором пункте отмечено Modify. Почему Modify, если это по сути равно Full Control? Дело в том, что право Modify не содержит права Delete subfolders and files, а значит, что при правах чтения на файл пользователь уже не сможет его удалить.

Проблема:

Схожий случай. Имеется папка Folder1, на которую пользователи JohnSmith и MikeJohnson имеют право Full Control. В этой папке JohnSmith создал свой файл. Файл может наследовать права, а может и не наследовать права от родительской папки (вобщем, без разницы). Но по некоторым причинам администратору потребовалось временно запретить доступ к файлу для пользователя MikeJohnson. Но при этом оставить права Full Control для остальных ресурсов в папке Folder1. Что самое вероятное сделает администратор? Как показывает практика, то администратор выставит на файле Deny Full Control для пользователя MikeJohnson. При этом будет запрещён доступ к файлу у MikeJohnson и задача по сути решена. Но опираясь на предыдущий пример при наличии прав Full Control пользователь сможет его удалить, хотя из-за запрета Deny просмотреть содержимое файла не сможет (а перехватить владение ему не даст политика). А если просмотреть Effective Permissions для пользователя MikeJohnson, то увидим, что прав он никаких не имеет на файл. Но, пользуясь правом Delete subfolders and files, которое перекроет явный запрет от родительской папки удаление возможно. И тут даже не спасает _явный_ запрет любого доступа к файлу.

Решение:

решение данной ситуации (точнее её избежание) будет основываться на следующих правилах: