KNOWLEDGE - COLUMN ナレッジ - コラム

【エバンジェリスト・ボイス】インターネットを支えるインフラのセキュリティ-MozillaとCloudflare

サイバー・セキュリティ・ソリューション(CSS)部
エバンジェリスト フェロー 関原 弘樹     顔写真2_1187x1313

2019年 10 月最後のコラムです。一月前には 30 ℃を超えていた最高気温も 10 度近く下がり、本格的な秋の訪れを感じます。
一方、今月も列島を襲った豪雨の被害に関するニュースに目を向けると、平常時には気にも留めない予防のためのインフラ整備の重要性と人がもつ正常性バイアスの怖さが再認識できました。

さてこの秋、セキュリティに関するニュースの一つに Mozilla Corporation が開発しているウェブブラウザ Firefox が昨年より実験的にサポートしていた DNS over HTTPS DoH/ ドー)を正式にサポートするというものがありました。

今回のコラムではその DoH についてみていきます。

DNS - インターネットでの名前解決
まず、前提条件となるインターネット上の名前解決について簡単におさらいです。

www.idnet.co.jp 」というホストにアクセスしたい場合はまず「 www.idnet.co.jp 」というホスト名をインターネット上の住所である IP アドレスに変換する必要があります。これを名前解決といいます。
名前解決はエンドポイント( PC ・スマホ)上で設定された DNS サーバに対してクエリー(名前解決の問い合わせ)を送信することで行われます。
画像①_530x229
※外部サイト: 出典_総務省 国民のための情報セキュリティサイト  DNS の仕組み

例とし、トラフィックのキャプチャを見てみます。下の画像内の中央左の赤枠部分を確認するとエンドポイント「 10.0.0.11 」が DNS サーバ(に中継する代理サーバです、実際は)「 10.0.0.2 」にクエリーを送信し「 www.idnet.co.jp 」というホスト名を「 52.193.253.207 」というインターネット上でルーティング可能な IP アドレスに解決しています。
また、画像右上の赤枠部分のように 1 データグラムの Standard query に対し 1 データグラムの response というように非常にシンプルに名前解決を実現しています。

画像②_884x502
#Protocolの部分がDNSとなっており使っているポートは53/UDPです。


DNS による名前解決と問題
インターネットを安全に利用するために欠かせない DNS ですが実はセキュリティ的にはかなり脆弱で、例えば DNSの通信中に限っても このような弱点があります。

・インフラとしてコネクションレスで信頼性の無い UDP/IP を使っており、クエリーが本当に意図した DNS サーバに届いているか?また、レスポンスが指定した DNS サーバからのものか?について保障されない。

・レスポンスの内容、例えば「 www.idnet.co.jp 」に対する「 52.193.253.207 」が経路上で改ざんされていないかを検証する手段がない。

名前解決の結果が改ざんされていても現在の Web サイト運営では必須といわれる HTTPs を利用していれば下の画像のような表示ですぐ気づくことができます。

画像③_685x532

意外と重要なサイトでもいまだに HTTPs に対応していないこともあります。

画像④_684x325

HTTPsでサーバの身元を示すデジタル証明書が不正に発行され、悪意のあるものに成りすまされることもあります。
インシデントがあるとブラウザのエラー画面で気づくことができないので、フィッシングの成功率は格段に高まります。

画像⑤_624x730

DoH の登場

そこでそれらの DNS の弱点を克服すべく登場したのが DoH です。

その名の通り、既存の DNS のプロトコルをそのままにその転送インフラだけを UDP/IP から現在 Web サイトのセキュリティ対策として一般的に利用されているプロトコルスタック - TLS (Transport Layer Security※)/TCP/IP に移行しています。
※外部サイト: TLS

IETF のインターネットアーキテクチャ上に図示するとこのようなイメージになります。

画像⑥_862x525

なお、インターネット上で相互接続性を担保するために重要な標準化は RFC TLS を標準化( TLS1.2 RFC5246,TLS1.3 RFC8446 )している IETF が「 DNS Queries over HTTPS RFC8484 」として行っています。

IETF Internet Engineering Task Force  インターネットに関する技術の標準化を推進する団体
RFC Request for Comments  その多くは「コメント求む」という体の実質的な勧告

DoH がゲットした TLS 3 つのセキュリティ機能
DoHではこのようなプロトコルスタックを実現したことにより TLS が持つ 3 つのセキュリティインフラを手に入れました。

DNS 通信中のデータの暗号化
⇒クエリー内容の機密性確保

DNS 通信中の改ざん防止 
 ⇒クエリー結果の完全性確保

DNS サーバの認証
 ⇒①、②の前提となる正しいサーバの認証

個人的に①については DNS の名前解決後、平文で IP アドレスや CN Common Name= 接続先のサーバ名)が含まれた証明書データが流れることから、そこまでの重要性は感じませんが②と③については悪意のある者のフィッシングを回避するために非常に重要ですので方法が DoH かどうかはともかく DNS に対してなんらかの実装は必須であると考えています。

また、通常 HTTPs のためにプロキシサーバでの中継と FW での通過を許可している 443/TCP を利用するため既存のネットワークインフラへの変更がほぼ不要なのは大きな利点といえるかもしれません。

Firefox Cloudflare による DoH の実装
ではここで、 DoH に対応したウェブブラウザ Firefox CDN (コンテンツデリバリーネットワーク)とセキュリティサービスを提供するCloudflareの DNS を使って DoH に関する実装を見てみましょう。

※外部サイト: Cloudflare セキュリティ

執筆時点で最新の Firefox Ver70.0 でオプション⇒ネットワーク設定⇒接続設定を開きます。

画像⑦_807x591

DNS over HTTPS を有効にする」にチェック。すると「プロバイダーを使用」にはデフォルトで Cloudflare が設定されます。(他のサーバの URL も設定可能)

画像⑧_918x572

なお、 Firefox+Cloudflare の組み合わせによる DoH のクエリー先はブラウザの Config URL「https://mozilla.cloudflare-dns.com/dns-query」として与えられています
ということは最初に mozilla.cloudflare-dns.com の名前解決をする必要があり、それは通常の DNS で実行するものと想定されます。

画像⑨_789x340

ちなみに mozilla.cloudflare-dns.com IPv4 アドレスは引いてみると執筆時点では「 104.16.248.249 」と「 104.16.249.249 」です。

画像⑩_519x335

パケットキャプチャで確認すると上記設定後すぐに DoH のクエリー先「 104.16.248.249 」に TLS1.2 でパケットが飛んでいます。 Record Layer Application Data Protocol として「 http-over-tls 」が明記されています。もちろん Application Data は暗号化されており見ることはできません。

画像⑪_855x514

#ここでServerとClientのTLSのHelloがキャプチャされていないことと53/UDPのフィルタに「mozilla.cloudflare-dns.com」の名前解決がキャプチャされていないという疑問が出てきましたが今回は時間の関係で確認はここまでです。

DoH の問題点
DNS通信にセキュリティをもたらすこの DoH ですが、 DNS のクエリーがエンドポイント~ DNS サーバの中間では暗号化されているので DNS クエリをベースとした危険サイトや違法サイトのフィルタリングができないということを問題視する向きもあります。

※外部サイト: インターネットをより安全にする技術「 DoH 」に対して大手 ISP が抱える懸念とは?

これについては だれが責任をとるのか?誰にとってのセキュリティなのか? という問題ですので、技術的なアプローチでの解決は難しそうです。回答はそれぞれのケースによるでしょう。

また、現在 DoH を実装している DNS サーバが Cloudflare Google といった極一部なので DNS トラフィックの独占という面での懸念も上がっているようです。これは今後の広まり方がポイントですね。

ちょっと気になることとして、すべての通信が通常の HTTPs と同様に 443/TCP に見えるのでトラブルシューティングやインシデント時の切り分けにちょっと時間がかかるかもしれません。


■まとめ
今回は DNS の完全性がいかに重要となっているか及びそれに対する一つの解についてご紹介しました。

昨年以来、一部の大手検索サイトが利用者とサービス提供者を結び付ける URL ついて、新たな方向を模索している※というニュースもありました。 Web URL 、そして DNS に関してはこれからの数年間どのような動きがあるか興味が尽きません。

※外部サイト: グーグルは「 URL がない世界」をつくろうとしている


ではまた、次回のエントリーでお会いしましょう。
 
Hiroki Sekihara, CRISC, CISSP, CCSP, CEH, PMP, CCIE #14607 Emeritus,
AWS Certified Solutions Architect – Professional,

 

当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。

エバンジェリストによるコラムやセミナー情報、
IDグループからのお知らせなどをメルマガでお届けしています。

メルマガ登録ボタン

関原 弘樹

株式会社インフォメーション・ディベロプメント フェロー / CISSP

この執筆者の記事一覧

関連するナレッジ・コラム

地味に見えて優秀!マネージドプレフィックスリストでアドレス管理を効率化

DockerでJupyterLabの環境を作ろう

残された攻撃の痕跡を追え! ~Post-Exploitationで起きていること~