Обнаружение другого хоста с тем же MAC-адресом

Ответ 1

Этот вопрос слишком интересный, чтобы подавить! После нескольких ложных запусков я начал думать о существенных компонентах проблемы и запросил советы RFC. Я не нашел окончательного ответа, но здесь мой мыслительный процесс, в надежде, что это поможет:

• В исходном вопросе спрашивается, как обнаружить другое устройство с вашим MAC-адресом. Предполагая, что вы находитесь в сети IP, что необходимо для этого?

• Пассивный метод будет просто прослушивать трафик и искать любые пакеты, которые вы не передавали, но имеете свой MAC-адрес. Это может произойти или не произойти, поэтому, хотя он может сказать вам окончательно, если существует дубликат, он не может сказать вам окончательно, что это не так.

• Любой активный метод требует, чтобы вы передавали пакет, который заставляет самозванец отвечать. Это немедленно устраняет любые методы, которые зависят от дополнительных протоколов.

• Если другое устройство обманывает вас, оно должно (по определению) отвечать на пакеты с вашим MAC-адресом в качестве адресата. В противном случае он отслеживает, но не подделывает.

• Решение должно быть независимым от IP-адреса и включать только MAC-адрес.

• Таким образом, ответ, похоже, должен был передать либо пакет вещания (ethernet), либо пакет с вашим MAC-адресом в качестве адресата, для которого требуется ответ. Обезьяна - это то, что обычно используется IP-адрес, и вы этого не знаете.

Какой протокол подходит для этого описания?

Легкий ответ:

• Если ваша сеть поддерживает BOOTP или DHCP, все готово, потому что это связывает MAC-адрес с IP-адресом. Отправьте запрос BOOTP, получите IP-адрес и попробуйте поговорить с ним. Возможно, вам придется проявить творческий подход, чтобы заставить пакет подключиться к проводнику и не дать ему ответить (я думаю о разумном использовании iptables и NAT).

Непростые ответы:

• Протокол, который не зависит от IP: либо тот, который не использует IP-уровень, либо тот, который разрешает трансляции. Никто не приходит на ум.

• Отправлять любой пакет, который обычно генерирует отклик от вас, не позволять себе отвечать на запросы и искать ответ с другого устройства. Было бы разумно использовать ваш IP-адрес в качестве адресата, но я не уверен в этом. К сожалению, детали (и, следовательно, ответ) остаются в качестве упражнения для OP... но я надеюсь, что обсуждение было полезным.

Я подозреваю, что окончательное решение будет включать в себя сочетание методов, поскольку ни один подход не гарантирует надежного определения.

Некоторая информация доступна на http://en.wikipedia.org/wiki/ARP_spoofing#Defenses

Если все остальное не удается, вы можете наслаждаться этим: http://www.rfc-editor.org/rfc/rfc2321.txt

Пожалуйста, опубликуйте последующее решение с вашим решением, так как я уверен, что он будет полезен другим. Удачи!

Ответ 2

Вы можете отправить запрос ARP для каждого возможного ip в подсети. Конечно, исходный адрес ARP-запроса должен быть ff: ff: ff: ff: ff: ff, иначе вы можете не увидеть ответ.

Я подделал такой пакет с помощью bittwiste и воспроизвел его с помощью PReplay, и все хосты в сети получили ответ. (Я не знаю, являются ли эти кованные ARP-пакеты законными или нет... некоторые ОС могут игнорировать их)

Вот что выглядел поддельный пакет:

Вот как выглядел ответ:

Если вы просматриваете ответы и видите свой MAC-адрес в одном из пакетов (в красном прямоугольнике), то у кого-то есть тот же MAC-адрес, что и вы...

К сожалению, я не мог полностью проверить теорию, потому что ни одна из моих (Windows) машин не заботится обо мне, пытаясь установить MAC-адрес nic...

Ответ 3

Это очень поздно и не ответ, но я хотел следить за тем, что я сделал, если кто-то еще заинтересован.

Я работал с очень странным встроенным оборудованием, которое не имеет MAC-адреса, назначенного при изготовлении. Это означает, что нам нужно было назначить его в программном обеспечении.

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

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

Учитывая низкие шансы на то, что проблема возникла, и, несмотря на превосходные ответы выше, я решил отказаться от обнаружения конфликта и сделать с предупреждением пользователю, чтобы он искал проблемы с конфликтом MAC.

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

Надеюсь, что кто-то поможет где-то где-то - но, вероятно, нет!

Ответ 4

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