私はこれについて多くの記事を読みましたが、以下の場合にキャッシュ ポイズニングがどのように発生するのか理解できません。
- 応答のトランザクション ID が一致しない場合、クエリはキャンセルされ、失敗としてマークされます (つまり、最初の応答のみが受け入れられるため、攻撃者はトランザクション ID をブルート フォースで調べることはできません)。
- 再帰リゾルバは、一度に同じドメイン/タイプ/クラスに対して1つのリクエストのみを送信します。つまり、攻撃者は同じドメインに対して多数のリクエストをトリガーしてトランザクションIDをブルートフォース攻撃することはできません。
基本的な構成のように見えますが、攻撃者がトランザクション ID を推測する必要がある場合、キャッシュ ポイズニングはどのように可能になるのでしょうか。攻撃者は、再帰リゾルバに同じドメインを何度も解決させて、試行回数を増やすのでしょうか。その場合、数時間かかる可能性があります...
答え1
不正確なのは主に最初の箇条書きです。
- 応答のトランザクション ID が一致しない場合、クエリはキャンセルされ、失敗としてマークされます (つまり、最初の応答のみが受け入れられるため、攻撃者はトランザクション ID をブルート フォースで調べることはできません)。
不明なトランザクション ID が受信されると、その応答は破棄されます。ただし、未処理のクエリが何らかの理由で失敗したとみなされるという仮定は正しくありません。
事実上、この攻撃シナリオは、実際のネームサーバーからの応答が到着する前に、攻撃者が有効な応答を取得するための競争になります。
あなたの仮定の問題は、トランザクション ID (+ UDP 送信元ポート) の全体的なポイントは、応答を未処理のクエリと一致させることですが、これらの値が間違っている (どのクエリとも一致しない) 応答がある場合、どのクエリを失敗したと見なすべきかをどのように判断できるでしょうか。
また、何らかの形の部分一致を許可する場合、攻撃者にとって多少面倒な競合を、簡単に悪用できる DoS 攻撃に置き換えない方法でそれを実装するにはどうすればよいでしょうか。
「本当の」保護のためのオプション:
- DNSSEC を使用すると、クエリの発信者が応答内のレコードの信頼性を検証できるため、署名されたゾーン内の名前に対して攻撃者が生成した応答が受け入れられないことが保証されます。
- 何らかのクライアント/フォワーダーからリゾルバサーバーへのクエリについては、DoTとDoHはキャッシュポイズニングの問題も回避します。この特定の「ホップ」(DoT/DoH は 2 つのホスト間の通信チャネルのみを保護し、DNS 解決では複数の「ホップ」が発生する傾向があります)。
(TCP 経由でクエリを実行するだけでも、質問の特定のシナリオは改善されますが、暗号化ベースのソリューションは、対処する攻撃の点で明らかにはるかに広範囲です。)