web-dev-qa-db-ja.com

DNSSEC-MITM攻撃からどのように保護しますか？

私は数時間DNSSECについて読んでいますが、それがMITM攻撃からどのように保護されるかを理解できていません。また、DNSSECに関連するserverfaultに関するすべての質問を読みました。

このDNSSECパケットキャプチャをご覧ください： https://www.cloudshark.org/captures/79e23786259b

MITMがすべてのクエリをインターセプトし、DNSKEYS、RRSIGおよびDSレコードごとに独自のキーペアで返信するのを止めるのは何ですか。

たとえば、MITMはwww.ietf.orgに対してRRSIGを生成し、次にietf.orgに対してDNSKEYSを生成し、次にietf.orgに対してDSレコードを生成します。そして、 "org"のDNSKEYSおよびDSレコードの別のセット、次に<Root>のレコード。

TLSでは、すべてのシステムにルートCAが事前にインストールされているため、CAとの信頼の連鎖を信頼でき、それに対する応答をチェックできます。 DNSSECでは、ルートDNSKEYがルートCAのようなシステムにインストールされているとは思いません。では、受け取ったルートキーを信頼できるのはなぜでしょうか。

dnssec
4
pHeoz

この問題は信頼の連鎖によって解決されます。この連鎖のすべてのリンクは、前のゾーンでDSレコードに署名しています。 。これは、ルートネームサーバーでのアンカーの重要性を強調します。これが偽装された場合、信頼のチェーン全体が侵害されました。したがって、リゾルバは、トラストアンカーで事前構成する必要があります。 RFC 6781 説明：

4.2.3。リゾルバーに固定されたキーの侵害

キーは、リゾルバーでトラストアンカーとして事前に構成することもできます。トラストアンカーキーが侵害された場合、これらのキーを使用するリゾルバーの管理者にこの事実を通知する必要があります。ゾーン管理者は、SEPキーがロールオーバーされようとしているという事実を伝えるためにメーリングリストを設定することを検討するかもしれません。このコミュニケーションは、例えば、デジタル署名。

アンカーキーを更新するタスクに直面しているエンドユーザーは、常に新しいキーを確認する必要があります。新しいキーは、たとえば、トランスポート層セキュリティ（TLS） [RFC5246] を使用して保護されたアナウンスWebサイトを使用して、帯域外で認証される必要があります。

Current Root Trust Anchors（bind.keys） Internet Systems Consortiumから直接。サイトはTLSを使用して保護されており、ファイルも署名鍵で署名されています。

何もない場合named.confありませんbind.keysファイルは、名前付きでコンパイルされたキーを使用します。

注：これらはマネージドキーであるため、namedを初めて実行するときにのみ適用されます。キーの有効期限がまだ切れていない場合（namedはキーの有効期限が切れていることをログに記録し、検証が機能しない）、namedはRFC 5011を使用して新しいキーを検出し、キーを自動的にロールして維持します。名前を付けてキーを管理すると、現在のキーはmanaged-keys.bindまたは*.mkeys、ビューを使用する場合。

もう1つの問題は、リゾルバーとの通信である「ラストマイル」です。リゾルバーが署名を検証し、DNSで応答している可能性がありますAuthenticated Data（AD）ビットですが、DNSはプレーンテキストで機能するため、中間者（MITM）の攻撃者によって結果が変更される可能性があります。これには複数の解決策があります：

  • アンカーキーファイルを備えた独自のローカルリゾルバを作成することもできますが、これは大容量の実用的な解決策ではありません。また、フォワーダーが構成されていない場合、ルートネームサーバーへのトラフィックが増加します。これは、自分で署名を検証する、信頼の置けるソリューションです。

  • DNS-over-TLS ＆ DNS-over-HTTPS 。例えば。 Cloudflare with 1.1.1.1両方をサポート ：

    必要なのは、新しい最新のプロトコルへの移行です。いくつかの異なるアプローチがあります。 1つはDNS-over-TLSです。これは、既存のDNSプロトコルを使用して、トランスポート層の暗号化を追加します。もう1つはDNS-over-HTTPSです。これには、セキュリティだけでなく、他のトランスポート層（QUICなど）のサポートやサーバーHTTP/2サーバープッシュなどの新しいテクノロジーのサポートなど、すべての最新の拡張機能が含まれています。 DNS-over-TLSとDNS-over-HTTPSはどちらもオープンスタンダードです。

    DNS-over-HTTPSは特に有望で、高速で、解析が簡単で、暗号化されています。 – –独立したDNS-over-HTTPSサービスが利用可能になり、ブラウザ、オペレーティングシステム、ルーター、アプリからのプロトコルをサポートする実験がさらに増えることを期待しています。

  • DNSCrypt 暗号署名を使用して、DNSクライアントとDNSリゾルバー間の通信を認証します。これはIETFに提案されたことはありません（RFCはありません）。

4
Esa Jokinen

Esa Jokinenの広範な返信に加えて、次の話に戻りましょう。

ルートDNSKEYがルートCAのようなシステムにインストールされているとは思いません。これは、あなたが持っているすべての結果を作成するという誤った仮定です説明する権利。

ただし、ルートDNSKEYは実際にはリゾルバーに付属しています。これにより、特にこのキーの計画的な変更の結果として、他の問題が発生します（最後の10月に計画されたが延期されました）。

あなたは確かにDNSSECブートストラップを持っています。ソフトウェアには帯域外のキーが必要ですが、更新する必要がある場合もあります。今日、現在のキーが付属している製品を購入し、それを2年間そのままにしてから電源をオンにすると、現在のDNSKEYルートキーが別のルートキーに置き換えられるとどうなりますか？

多くのことを想像できます...もちろん、HTTPSを介してIANA Webサイトからキーを取得しましょう！それを行うには、IANA Webサイト名を解決する必要があることを除いて、DNSと、構成しようとしている関連DNSSECに依存します。もちろん、IANA WebサイトのIPアドレスもハーコード化しません。または、TLSハンドシェイク中に信頼のDNS/DNSSECチェーンを交換することもできるので、TLSだけに依存することを想像できます...ただし、CA証明書を同梱する必要があることを意味します。そのCA証明書はDNSSECルートキーよりも長く持続します（ただし、Let's Encryptを使用すると、より短いCAの将来も想像できます...）。

鶏と卵の問題。

この問題とその解決策の詳細については、このドキュメントの例をご覧ください。 https://datatracker.ietf.org/doc/draft-jabley-dnsop-bootstrap-validator/このドキュメントでは、DNSSECバリデーターにおけるトラストアンカーの自動構成のアプローチについて説明します。

有効な（現在の）DNSSECルートキーが既にある場合、発生したときに新しいキーに安全に自動的に切り替えるための特定の手順があります。 DNSセキュリティの自動更新（DNSSEC）トラストアンカー

0
Patrick Mevzek