DNSをスプーフィングするのは簡単ですか？いくつかのシナリオは他のシナリオより安全/危険ですか？
実際には、DNSを偽装するのはどれほど簡単ですか？
他のシナリオよりもリスクが高いシナリオはどれですか？例えば：
ユーザーをハイパーリンクをクリックするように誘導するフィッシングメールまたはTwitterリンク
異なるサブネット上の内部SharePointサイトのリンク
悪意のあるユーザーが同じサブネット上にいる可能性がある場合。
他のシナリオ...（独自のものを追加してください）
被害者がオープンワイヤレスネットワークを使用している場合、DNSのなりすましは簡単です。攻撃者が中間者攻撃を仕掛けるのは簡単です偽造DNS応答を送信します。したがって、オープンワイヤレスネットワークを使用している場合は、DNSをまったく信頼しないでください。DNSを偽造するのは簡単です。
同様に、攻撃者があなたと同じサブネットにいる場合、DNSのなりすましは簡単です。この場合、攻撃者がDNS要求を盗聴し、応答をなりすまし、中間者ゲームをプレイすることは簡単です。
被害者が他のネットワークを使用している場合、DNSのなりすましは容易ではありませんが、可能性があります。被害者が有線ネットワーク経由でネットワークに接続されている場合、ほとんどの場合、攻撃者はネットワーク通信を盗聴するように簡単に調整できません。この場合、簡単な中間者攻撃は適用されなくなり、攻撃者はより多くの努力をしなければなりません。他にもいくつかの可能性のある攻撃がありますが、それらの実装はそれほど簡単ではありません。
Kaminsky攻撃。古いDNSクライアント（送信元ポートのランダム化を使用しないもの）がある場合、なりすましに対する唯一の保護は16ビットのIDフィールドです。 16ビットでは、ランダムな推測を防ぐには不十分であり、Dan Kaminskyは、これらの条件下でDNSを偽装する方法を示しました。したがって、ソースポートのランダム化を使用しない古いDNSクライアントを使用している場合は、DNSのなりすましが容易であると想定する必要があります。
幸い、Kaminskyが攻撃を発見した後、攻撃に対する防御を追加するための協調的な取り組みがあり（たとえば、送信元ポートIDをランダム化することにより）、ほとんどの最近のクライアントは送信元ポートのランダム化を使用しています。したがって、最新のDNSクライアントの場合、Kaminskyの攻撃は原則として依然として可能ですが、大量のトラフィックを必要とするため、そのような攻撃を仕掛けることは可能ですが、簡単ではありません。価値の高いターゲットでない限り、DNSクライアントがソースポートのランダム化を使用している場合は、おそらくかなり安全です。ただし、非常に古いため、または更新されていない組み込みシステムであるか、NATこれは送信元ポートのランダム化を破壊します-そしてそれらのシステムは非常に脆弱なままです。
DNSキャッシュポイズニング。これまで、多くのDNSキャッシュはキャッシュポイズニング攻撃に対して脆弱であり、攻撃者はそれらをだましてDNSクエリへの悪意のある応答を受け入れ、その悪意のあるものをキャッシュできました。応答。次に、そのDNSキャッシュを使用し、その名前を照会する後続のすべてのクライアントは、正しくない悪意のある回答を受け取ります。
最近では、すべての既知のキャッシュポイズニング攻撃を防御するように最新のDNSソフトウェアが更新されているため、今日のキャッシュポイズニング攻撃の実装は困難です。非常に古いソフトウェアを実行しているDNSキャッシュがまだいくつか残っている可能性がありますが、それらはかなりまれであると思います。
クライアント側のマルウェア。一部のクライアント側のマルウェアが行うことの1つは、すべてのDNSクエリが攻撃者のDNSサーバーに送信されるようにシステムの構成を変更することです。したがって、マシンがこのマルウェアに感染している場合、攻撃者はDNSを簡単に偽装することができます。
Drive-by pharming。コンシューマー/ SOHOグレードのケーブルモデム、DSLモデム、パーソナルワイヤレスアクセスポイント、または同様のデバイスを介してインターネットに接続する場合、 drive-by pharming として知られる厄介な攻撃。ドライブバイファーミング攻撃では、攻撃者はルーターを再構成してDNS設定を変更し、すべてのDNSクエリが攻撃者のDNSサーバーに送信されるようにします。攻撃者がこれを実行できる場合、その後、攻撃者がDNSを偽装することが容易になります。
これはどうして起こりますか？ 1つの方法：オープンワイヤレスネットワークを実行している場合、物理的に近くにいる攻撃者がネットワークにホップできる可能性があります。標準アドレス（例： http://192.168.0.1 でルーターに接続します） =）、強力なパスワードを設定していない場合は、パスワードを推測して構成を変更します。少し微妙に、強力なパスワードを選択した場合でも、ログインしている場合、攻撃者は多くのルーターのローカルWeb構成インターフェースがCSRF攻撃を防御しないという事実を利用して、構成を変更できる可能性があります。
さらに悪いことに、これらの攻撃は、世界の反対側にいる攻撃者によってリモートでマウントされる可能性があります。脆弱なルーターを使用していて、現在ブラウザーにログインしている場合、またはルーターに強力なパスワードを設定していない場合、悪意のあるWebサイトにアクセスすると、悪意のあるWebサイトがJavascriptを使用して、 Java（内部インターフェイスから）ルーターに接続するために）パスワードを推測するか、CSRF攻撃を悪用し、そのDNS構成を変更します。
残念ながら、配備されたルーターの多くはこれらの攻撃に対して脆弱であり、セキュリティ更新プログラムを配備するための適切なチャネルがないため、この事実はすぐには変更されないでしょう。私はこの攻撃を中程度の難易度として評価します。この方法で攻撃できる一部のユーザーを見つけることはおそらくそれほど難しくありませんが、標的のユーザーを攻撃することは困難です（物理的に近くにいる場合を除きます）。
サーバー側のハッキング。攻撃者が
example.comを担当するDNSサーバーをハッキングできる場合、攻撃者はクライアントが要求したときに送信される応答を制御できます。example.comのIPアドレス。この攻撃は、ほとんどのサイトでおそらく比較的難しいですが、難易度はターゲットによって異なります。ある調査によると、DNSサーバーの17％に既知の脆弱性があります。この攻撃は、DNSにかなりの推移的な信頼があるため、最初に思われるよりも悪いです。たとえば、ウクライナ政府のWebサイトは、DreamhostのDNSサーバーに間接的に依存しています（
kmu.gov.uaのDNSはadament.netのサーバーによって提供され、adament.netのDNSはdreamhost.comによって提供されます）。ノルウェーとスウェーデンのDNSサーバー（uaのDNS信頼sunet.se、nordu.net、noに依存）、および他のいくつかのDNSサーバー。したがって、これらのDNSサーバーのいずれかをハッキングできれば、ウクライナ政府のWebサイトのDNSを偽装できる可能性があります。そのような信頼の量は、サイトごとに大幅に異なります。ある調査では、この種の脆弱なDNSサーバーへの間接的な依存関係により、DNS名の45％がハッキングの影響を受けやすいことがわかりました。
ボトムライン。全体として、攻撃者が傍受できるオープンネットワークを使用している場合、DNSのなりすましは簡単です-一方、攻撃者が傍受できない他のネットワークを使用している場合、DNSのスプーフィングはかなり困難ですが、不可能ではありません。
したがって、DNSSECやSSL/TLSなどのソリューションを使用するのには十分な理由があると思います。
技術的な意味では、DNSはなりすましが容易です。 （ほとんどの場合）トランスポートプロトコルとしてUDPを使用します。これは、TCPに比べてスプーフィングは簡単です。また、DNS自体はスプーフィングに対する予防策を提供しないため、攻撃者が最初に自分のパケットを返すことができれば、勝ちます。 [〜＃〜] dnssec [〜＃〜] は、この問題と他のいくつかの問題に対処するように設計されていることに注意してください。
DNSスプーフィングの成功は、ネットワークアクセスに依存しています。攻撃者がクライアントの要求を確認できるようにネットワークにアクセスし、応答パケットを偽装すると、意図した以外の場所にクライアントをだますことができます。その事実を考えると、脅威の大きさを判断できます。たとえば、フィッシングメールは通常、ネットワークアクセスを好まないユーザーから送信され、その結果、両者が連携する脅威は低くなります。一方、同じサブネット上の悪意のあるユーザーは、なりすましを実行するために必要なネットワークアクセスのレベルを取得できる可能性があるため、危険性が高まります。
DNSは低レベルのプロトコルであり、一部の高レベルのプロトコルはこの種のなりすましに対する保護を備えています。たとえば、攻撃者はDNSを偽装して https://bigbank.com のユーザーを自分のサイトにリダイレクトする可能性がありますが、警告を回避するには有効なSSL証明書が必要です。ユーザーは実際に攻撃を検出する証明書を確認します。同様に、攻撃者がクライアントのSSH接続をリダイレクトすることを狙ってスプーフィングした場合、攻撃者が何らかの方法で実際のSSHサーバーのホストキーを盗むことができなければ、ホストキーが変更されたというアラートを受け取ります。 Telnetを使用している場合、そのような保護はありません...
私の記憶の及ぶ限り、DNSに関連する公表された侵害の大部分は、ある種のDNSポイズニングによるものであり、一般にスプーフィングによるものではありませんでした。もちろん、ポイズニングは本質的にはるかに一般的であり、なりすましは標的を絞った静かな攻撃に適しているため、スプーフィングが使用されていないことを想定することはできません。ただし、攻撃者がスプーフィングに必要なネットワークアクセスを持っている場合、DNSスプーフィングよりも魅力的な他の攻撃方法がいくつかあると思います。おそらくそれが、まだDNSSECをまだ使用していない理由です。