別のホストが現在のホストと同じ MAC アドレスを使用しているかどうか (たとえば、別のホストがスプーフィングしているなど) を検出するにはどうすればよいですか?
私は組み込み環境で作業しているため、「このようなツールを使用する」というよりも、プロトコル レベルでの回答を探しています。
編集: RARP はこの問題を解決しません。RARP が何らかの応答を得るためには、RARP をサポートするセグメント上に少なくとも 1 つのホストが必要です。RARP は廃止されたため、最新のオペレーティング システムではサポートされていません。さらに、RARP ができることは、自分の IP アドレスを伝えることだけです。同じ MAC を持つ別のホストがセグメントに存在しても、そのホストが別の IP アドレスを使用していない限り、応答は変わりません。
この質問は面白すぎて書ききれません！何度か間違ったスタートを切った後、私は問題の本質的な構成要素について考え始め、アドバイスを求めて RFC を精査しました。 決定的な答えは見つかりませんでしたが、役立つことを願って、これが私の思考プロセスです。
元の質問では、MAC アドレスで別のデバイスを検出する方法を尋ねています。IP ネットワーク上にいると仮定すると、これを実現するには何が必要ですか?
受動的な方法は、単にトラフィックをリッスンし、送信していないが MAC アドレスを持つパケットを探すことです。これは発生する場合と発生しない場合があるため、重複が存在するかどうかは明確にわかりますが、重複していないことを明確に伝えることはできません。
アクティブな方法では、詐欺師に応答を強制するパケットを送信する必要があります。これにより、オプションのプロトコルに依存するメソッドがすぐに削除されます。
別のデバイスがあなたをスプーフィングしている場合、そのデバイスは(定義により)あなたのMAC アドレスを宛先とするパケットに応答する必要があります。それ以外の場合はスヌーピングですが、スプーフィングではありません。
ソリューションは、IP アドレスに依存せず、MAC アドレスのみを使用する必要があります。
したがって、答えは、ブロードキャスト (イーサネット) パケットまたは MAC アドレスを宛先とするパケットのいずれかを送信することであり、応答が必要です。モンキーレンチは、通常は IP アドレスが関係しているのに、あなたがそれを知らないということです。
この説明に当てはまるプロトコルは何ですか?
簡単な答え:
簡単ではない答え:
IP から独立したプロトコル: IP レイヤーを使用しないプロトコル、またはブロードキャストを許可するプロトコル。どれも思い浮かびません。
通常は応答を生成するパケットを送信し、自分が応答しないようにし、別のデバイスからの応答を探します。自分の IP アドレスを宛先として使用するのは理にかなっているように思えますが、私はそれを確信していません。残念ながら、詳細（したがって答え）はOPの演習として残されています...しかし、議論が役に立ったことを願っています.
信頼できる決定を保証する単一のアプローチはないように思われるため、最終的な解決策には技術の組み合わせが含まれると思います。
一部の情報は、http://en.wikipedia.org/wiki/ARP_spoofing#Defensesで入手できます。
他のすべてが失敗した場合は、これを楽しむことができます: http://www.rfc-editor.org/rfc/rfc2321.txt
他の人に役立つと確信しているので、ソリューションのフォローアップを投稿してください。幸運を！
サブネット内の可能なIPごとにARP要求を送信できます。もちろん、ARP要求の送信元アドレスはff：ff：ff：ff：ff：ffである必要があります。そうでない場合、応答が表示されない可能性があります。
このようなパケットをbittwisteで偽造し、PReplayで再生すると、ネットワーク上のすべてのホストが応答を受け取りました。（これらの偽造されたARPパケットが合法であるかどうかはわかりません...一部のOSはそれらを無視する可能性があります）
偽造されたパッケージは次のようになります。
返信は次のようになりました。
応答を見て、パケットの1つ（赤い長方形）にMACアドレスが表示されている場合、誰かがあなたと同じMACアドレスを持っているよりも...
残念ながら、私の（Windows）マシンのどれも、NICのMACアドレスを設定しようとしていることを気にしていないため、理論を完全にテストできませんでした...
これは非常に遅く、答えはありませんが、他の誰かが興味を持った場合に備えて、私がしたことを正確にフォローアップしたいと思いました。
私は、製造時にMACアドレスが割り当てられていない非常に奇妙な組み込みハードウェアを使用していました。つまり、ソフトウェアで1つ割り当てる必要がありました。
明らかな解決策は、ユーザーにネットワーク上で利用可能であることがわかっているMACアドレスを、できればローカルで管理されている範囲から選択させることです。これが私が行ったことです。ただし、適度に安全なデフォルトを選択し、競合が発生した場合にユーザーに警告することも試みました。
結局、私は、適度なエントロピーを持ついくつかのハードウェア読み取りを行うことによって選択された、ローカルで管理された範囲でランダムっぽいデフォルトを選択することに頼りました。手動で選択される可能性が適度に高いという前提で、範囲の最初と最後を意図的に除外しました。特定のネットワーク上にこれらのデバイスが1つだけ存在する可能性があり、確かに20未満であるため、ある程度予測可能な乱数が原因で発生する可能性があるほど低くはありませんが、競合の可能性は非常に低くなります。
問題が発生する可能性が低く、上記の優れた回答にもかかわらず、競合の検出を省略し、MACの競合の問題に注意するようにユーザーに警告することにしました。
競合検出を実装することにした場合、ネットワークスタック全体を制御しているとすると、おそらく過剰な不明または欠落したパケットを探し、MACアドレスの変更をトリガーするか、それが発生したときにユーザーに警告します。
うまくいけば、それはどこかで他の誰かを助けるでしょう-しかしおそらくそうではありません！
1 つのネットワーク セグメントで同じ MAC アドレスを使用する 2 つのホストは、おそらくスイッチを狂わせ、非常に信頼性の低いネットワーク接続を使用することでおそらくそれを検出できます (スイッチはホストに属するパケットの一部を 2 番目のホストに送信するため、どちらがその方向に最後のパケットを送信したかによって異なります)。