令和3年度 春期 情報処理安全確保支援士試験 午後Ⅰ 問2｜名前解決の落とし穴——情報処理安全確保支援士で学ぶDNSセキュリティの実践設計

この記事で扱うセキュリティ事例

• 試験区分: 情報処理安全確保支援士
• 出典: 令和3年度 春期 情報処理安全確保支援士試験 午後Ⅰ 問2
• 主なテーマ: DNSセキュリティ、DNSリフレクション攻撃、DNSキャッシュポイズニング、権威DNSサーバとフルサービスリゾルバの分離、送信元ポートランダム化、DNSSEC、DNS over TLS、ゾーン転送の制御

この記事は「情報処理安全確保支援士 午後問題 全70問」シリーズの1本です。→ 全70問の一覧・テーマ別索引はこちら

導入: なぜこの事例が重要なのか

私たちがWebサイトを開くとき、まず裏側で「ドメイン名（例：www.example.co.jp）をIPアドレスに変換する」処理が走っています。これがDNS（Domain Name System＝ドメイン名とIPアドレスを対応づける、インターネットの電話帳のような仕組み）です。普段は意識すらしないこの仕組みが、攻撃者にとっては格好の標的になります。名前解決を止められればサービスは止まり、名前解決を偽られれば利用者は偽サイトへ誘導される。DNSは、インターネットの「縁の下の力持ち」であると同時に、急所でもあるのです。

情報処理安全確保支援士試験の午後Ⅰで出題されたこの事例は、中規模の小売業を舞台に、一台で何役もこなしていたDNSサーバのリスクを洗い出し、攻撃に強い構成へと作り替えていく物語です。踏み台にされるリスク、キャッシュを汚染されるリスク、通信を盗み見られるリスク——三つの脅威に対し、サーバの役割分担、送信元ポートのランダム化、DNSSEC、DNS over TLSといった対策が、一つずつ積み上げられていきます。

この記事を読むと、なぜDNSサーバを「権威」と「リゾルバ」に分けるべきなのか、リフレクション攻撃やキャッシュポイズニングがどう成立するのか、そしてゾーン転送やファイアウォールのルールをどう設計すれば穴を残さないのかが見えてきます。DNSは地味ですが、ここを理解しているかどうかで、セキュリティ設計の堅牢さは大きく変わります。

インシデントの概要

舞台は、従業員500名の中規模小売業A社です。A社はインターネットを介して消費者向けに商品を宣伝しており、ネットワークは情報システム部（情シ部）のL部長とM主任を含む7名で運用しています。

A社のネットワークには、DMZ（インターネットと社内の間に置く、外部公開用の緩衝地帯）に公開Webサーバ、プロキシサーバ、メールサーバ、そして外部DNSサーバが置かれていました。問題は、この外部DNSサーバが二つの役割を兼ねていたことです。一つは、A社ドメインの権威DNSサーバ——「a-sha.co.jpのことなら私が答えます」と、自社ドメインの情報を外部に提供する役割。もう一つは、フルサービスリゾルバ——社内のプロキシサーバやメールサーバから「このドメインのIPアドレスを教えて」と頼まれ、インターネット上のサーバに問い合わせて答えを返す、再帰的な名前解決の役割です。DNSサーバ用のOSSである「Dソフト」が使われていました。

ある日、Dソフトの脆弱性を悪用したDoS攻撃（大量の通信を送りつけてサービスを停止させる攻撃）で、同業他社が踏み台になったというニュースが流れます。今回の攻撃に使われた脆弱性の修正プログラムは、A社では既に適用済みでした。それでも情シ部は、このニュースを契機に、DNSにおけるリスクと対策の検討を、M主任を中心に行うことにしました。実害が出てから動くのではなく、ニュースを「自社を見直すきっかけ」にする——その姿勢が、この事例の出発点です。

何が起きたのか

M主任はまず、根本的な問いから始めます。「もしA社の外部DNSサーバがサービス停止になったら、何が起きるか」。答えは深刻でした。外部DNSサーバはA社ドメインの権威サーバを兼ねているため、これが止まれば、A社の公開Webサーバの名前解決ができなくなる。つまり、外部の利用者がA社のWebサイトにたどり着けなくなるのです。一台のサーバに役割を集中させていたことが、そのまま単一障害点になっていました。

次にM主任は、外部DNSサーバが攻撃を受けるリスクを調査し、主なものを三つ挙げます。

一つ目のリスクは、踏み台にされることでした。表の構成では、攻撃者は送信元のIPアドレスを偽装した名前解決要求を外部DNSサーバに送ることができます。送信元を攻撃対象のIPアドレスに偽れば、外部DNSサーバはその攻撃対象に向けて、大きな応答を返してしまう。小さな要求に対して大きな応答が返るDNSの性質を悪用し、外部DNSサーバを踏み台にして、第三者のサーバに大量のDNSパケットを送りつけるDoS攻撃——これがDNSリフレクション攻撃（反射・増幅型のDoS攻撃）です。同業他社が踏み台にされたニュースは、まさにこの類型でした。

この対策としてM主任が描いたのは、役割の分離です。問題の根は、フルサービスリゾルバがインターネットの誰からでも使える状態（オープンリゾルバ）になっていたことにありました。そこで、外部DNSサーバを廃止し、権威DNSサーバの機能を担う「DNS-K」と、フルサービスリゾルバの機能を担う「DNS-F」をDMZ上に新設します。これに合わせてファイアウォール（FW）のルールも変更し、インターネットからの名前解決要求は権威サーバであるDNS-Kだけが受け、再帰的名前解決を行うDNS-Fはインターネットから直接アクセスできないようにする。役割を分け、外から触れる範囲を絞ることで、踏み台にされる穴を塞いだのです。

二つ目のリスクは、DNSキャッシュポイズニング攻撃によるリソースレコードの改ざんでした。フルサービスリゾルバは、一度引いた名前解決の結果を一時的に保存（キャッシュ）して再利用します。攻撃者は、このキャッシュに偽の情報を注入しようとします。たとえばメールサーバのAレコード（ドメイン名に対応するIPアドレスを示す記録）が攻撃者のメールサーバのIPアドレスに書き換えられてしまえば、A社が送るはずの電子メールが、まるごと攻撃者のサーバに送られてしまう。盗聴や改ざんの起点になる、恐ろしい攻撃です。

M主任は三つの対策を考えました。一つ目は、一つ目のリスクへの対策（役割分離）を流用すること。二つ目は、送信元ポート番号をランダム化する対策です。キャッシュポイズニングは、攻撃者が正規の応答になりすまして偽の応答を送り込む攻撃ですが、その成功には「問い合わせに使われたポート番号」を当てる必要があります。ポート番号を毎回ランダムに変えれば、攻撃者が当てるべき範囲が一気に広がり、成功確率を大幅に下げられます。三つ目は、DNSSEC（DNS Security Extensions）という技術の利用です。DNSSECは、DNSサーバから受け取るリソースレコードに付与されたディジタル署名を検証することで、送信者の正当性とデータの完全性を確かめます。ただし、鍵の管理という新たな運用負担が伴います。

三つ目のリスクは、中間者攻撃によるDNS通信内容の盗聴・改ざんでした。この対策の一つとして、DNS通信を暗号化するDNS over TLS（DoT）という技術が標準化されています。DoTは、スタブリゾルバ（利用者の端末側で名前解決を依頼する部品）とフルサービスリゾルバの間の通信を暗号化するために開発されたものです。通信路を暗号化すれば、途中で盗み見たり書き換えたりすることが困難になります。

さらにM主任は、外部のホスティングサービス上にDNSサーバを新設する案も検討しました。一つ目の案は、権威DNSサーバを冗長化する構成です。外部DNSサーバを廃止し、DMZ上にDNS-K（プライマリ権威）とDNS-F（フルサービスリゾルバ）を、X社のホスティングサービス上にDNS-S（セカンダリ権威）を新設する。プライマリの権威機能をDNS-Kに、セカンダリの権威機能をDNS-Sに、フルサービスリゾルバ機能をDNS-Fに移す。これにより、片方の権威サーバが止まっても、もう片方が名前解決を続けられるようになります。

権威サーバを複数台にすると、ゾーン情報（自社ドメインの名前解決情報一式）をプライマリからセカンダリへコピーする「ゾーン転送」が必要になります。しかしゾーン転送は、自社の名前解決情報がそっくり流出するリスクも抱えています。そこでM主任は、ゾーン転送要求に対する許可を必要最小限にする設定を行いました。セカンダリのDNS-SがプライマリのDNS-Kにゾーン転送を要求するときだけ許可し、それ以外（DNS-Kからの要求や、第三者からの要求）はすべて拒否する——必要な通信だけを通し、それ以外を遮断する原則を、ここでも貫いたのです。

こうした調査と検討を重ね、A社は最終的に、外部DNSサーバをX社のホスティングサービスに移行することにしました。一台に役割を詰め込んだ危うい構成から、役割を分け、冗長化し、暗号化し、不要な通信を遮断する構成へ——DNSの守りが、着実に作り替えられていきました。