ユニキャストARP要求：有害と見なされますか？
Snortのダウンロード可能なルールを試してみたところ、簡単にアクティブ化できるルールが見つかりました。ユニキャストARPリクエストを送信することです。では、ARPリクエストの挿入を開始し、宛先がブロードキャストに設定されていないことを確認します。そして確かに、Snortはそれを拾います。それでは、次に進んで、より複雑なことをしましょう。
しかし、なぜこのルールが存在するのか理解できません。私が読んだほとんどのARPスプーフィング/キャッシュポイズニング攻撃は、ARP応答を利用しています。リクエストは誰にも問題を引き起こさないようです（ ここ （「何ができるか」、パラグラフ5）。たとえば、ユニキャストの「キープアライブ」リクエストは、攻撃を実装するときに問題であるとさえ言われています） 。
まだこのルールが存在し、正当化を見つけることができません。 ARP要求がユニキャストであることが疑わしいのはなぜですか？多くの実装で明らかにこれは機能と見なされていますか？ Snortに焦点を当てた侵入検知に関する book があり、「ユニキャストアドレスに送信されるARP要求は、多くの場合、ARPキャッシュを変更するように設計された攻撃の兆候である」と述べています。わからない…
繰り返しになりますが、私はネットワークセキュリティの経験があまりないので、創造的に考えているのではないでしょうか。
Snortメーリングリストでのやり取り の後（そしてこのルールについて作者に連絡することに失敗した）、私は
これは定義された動作ではなく、一部の特定のシステムではARPポーリングが問題になる可能性がありますが、いくつかの理由で正当化されるかどうかアプリオリがわからないため、ルールはまだ存在する必要がありますコンテキスト固有のメカニズム。そして、私たちが彼らが危険であるかもしれない方法を見ていない場合でも、正当な理由のために理由はありませんユニキャストリクエストを送信するホスト。したがって、通常とは異なる動作のようにアラートをトリガーする必要があります。
答えのために。皆さんは興味深い点を挙げていますが、それらは教育を受けた推測のようであり、ジェフネイサンだけが提供できると私が求めた「決定的な」回答のようではありません。
しかし、あなたの答えをありがとう、私はそれらから学んだ。
NB：編集前に、この回答は危険である可能性があります。これは、受信ARPかどうかに関係なく、ホストがMAC <-> IPペアリングをテーブルに追加したためであると考えられますパケットは要求または応答です（したがって、要求を送信してホストのテーブルをあふれさせる可能性があります）が、RFC 826の受信アルゴリズムにより、プロトコル宛先フィールドがIPに対応している限り、ホストがテーブルを更新することがわかりました。したがって、この攻撃が機能するために要求をユニキャストにする必要はありません。
NB2：私は、この問題についてはるかに経験豊富な同僚と楽しい話をしました。私はルールについて彼に尋ねました、そして彼にARPポーリングについて話したとき、彼の最初の反応は完全に反転して彼のマシンに走って、この種のリクエストを送信していないことを確認することでした。 heが:)を意味しない場合に、彼のコンピュータがネットワークと通信する必要がある理由はありません（また、彼は頻繁に連絡しないホストについて、ポーリング機能の結果、トラフィックが無駄になります）。
おそらくMACフラッディング攻撃-一種のユニキャストフラッド攻撃攻撃者はスイッチのMAC割り当てテーブルのスペースを使い果たすため、アドレスキャッシュで正しいアドレスを見つけることができず（すべて攻撃者から提供されたもの）、パケットがすべてのポートにフラッディングされます（スイッチが受信した場合）宛先アドレスが不明なユニキャストパケット。パケットはブロードキャストパケットのように扱われ、ネットワーク上のすべてのホストに送信されます）。ほとんど/すべて/ターゲットの正当なMACがテーブルから強制的に除外された後、スイッチによって生成された以前は利用できなかったパケットがキャプチャに利用できるとされているため、パケットスニファを開始するのに最適なタイミングです。パケットキャプチャが意図されていなくても、これはすでに一種のDoS攻撃です。大規模なネットワークでは（スイッチと通信するクライアントの数が原因）、ネットワークパフォーマンスが確実に低下します。
ところで、ユニキャストARP要求は、23ページに記載されている RFC1122 に従って正当です。
（2）ユニキャストポーリング-ポイントツーポイントARP要求を定期的に送信してリモートホストをアクティブにポーリングし、N回の連続したポーリングからARP応答を受信しない場合はエントリを削除します。この場合も、タイムアウトは1分程度であり、通常はNは2です。
normal[〜＃〜] arp [〜＃〜] の使用方法はブロードキャストフレームによるものです。これは、ARPがマシンに他のホストのMACアドレスを検出できるようにするためのものです。これは、MACアドレスが実際に事前に知られていない場合にのみ意味があります。通常、マシンはそれ自体に関する要求に応答する責任があります。誰かが現在IPアドレス10.0.17.42を所有しているマシンのMACアドレスを要求した場合、そのマシンは応答するはずです。さらに重要なことに、ネットワーク上の他のホストは10.0.17.42アドレスの現在の所有者のMACアドレスを知っていても、refrainは応答しません。
アドレスの所有者だけが実際に応答することで、ネットワークの溺死を回避できます。あるマシンが検出したすべての要求に応答していた場合、ビジーなネットワークでのブロードキャストARP要求が何百もの応答をトリガーする可能性があります。
ユニキャストARP要求が意味を持つためには、IPアドレスの所有者自体ではなく、MACアドレスがわかっているホストに送信する必要があります（それ以外の場合、要求のポイントは何ですか？）。しかし、そのホストはデフォルトでは応答しません。したがって、正当なユニキャストARP要求は、他のマシンに割り当てられたIPアドレスのARP要求に応答するように構成された既知のARPレスポンダが存在する状況でのみ発生します。これはかなり珍しい設定です。
Linuxシステムは、他のマシンのアドレスに対するARP要求に応答するように構成できます。これは Proxy ARP と呼ばれます。ただし、主な使用例は、透過的なファイアウォールの使用です。LANは複数の個別のLANに分割され、ローカルマシンはその分割を認識しません。サブLANを接続するマシンはプロキシARPを実行して、通信をフィルタリングしながら、単一のLANのような錯覚を維持します。しかし、その場合、マシンはnawareセットアップです。ユニキャストARP要求は、LAN分割が行われたことをどういうわけか知っているマシンの1つからのみ発生します。
したがって、実際には、ユニキャストARP要求は通常は不正行為の兆候です。通常のマシンはそれをしません。
ユニキャストARPリクエストの正当な使用法を知りません。これは一部の実装の機能であると述べました。その詳細はありますか？
ユニキャストARPリクエストの悪用は、なりすまし防止機能を回避することだと思います。たとえば、Linuxカーネルは一方的なARP応答をリッスンしませんが、スプーフィングされたARP要求を使用して、要求がだまされて応答が要求されていると見なすことができます。また、ユニキャスト要求は、ブロードキャスト要求よりも他のデバイスに影響を与えたり、気づかれたりする可能性が低くなります。
Snortには非常に多くのルールがあるため、この1つの問題に詳しく焦点を当てるのではなく、さまざまな問題について経験を積むことに焦点を当てることをお勧めします。