🔰ハッカーは「インターネットの住所録」を書き換える🔯ミカと教授のサイバーセキュリテイ🖥️第16回
【DNSキャッシュポイズニング――「インターネットの住所録を書き換えられたら？」】
ミカ「教授、今日はDNSですね」
教授「そうだ」
ミカ「DNSは、Webサイトの名前をIPアドレスへ変換する仕組みでしたね」
教授「例えば人間は『example.jp』という名前を覚える。しかしコンピューター同士の通信ではIPアドレスが必要になる」
ミカ「そこでDNSが住所を教える」
教授「そのとおり」
ミカ「ではDNSキャッシュポイズニングとは？」
教授「DNSサーバーが覚えている住所情報へ、偽物の住所を混ぜる攻撃だ」
ミカ「正しいサイト名を入力しても？」
教授「偽物の住所を教えられれば、別のサーバーへ行ってしまう」
ミカ「私は何も間違えていないのに」
教授「そこが怖いところだ」
【まずDNSの正常な流れを理解しよう】
ミカ「DNSは毎回、世界中へ住所を聞きに行くのですか」
教授「それでは遅すぎる。そこでDNSサーバーは、一度調べた結果を一定時間覚えておく」
ミカ「それがキャッシュ？」
教授「そうだ」
ミカ「例えば私は shop.example.jp を開く」
教授「パソコンがDNSへ『この名前の住所は？』と問い合わせる」
ミカ「DNSが調べて『192.0.2.10です』と答える」
教授「さらに、その答えをしばらく覚えておく」
ミカ「次の人にはすぐ答えられる」
教授「高速になるわけだ」
ミカ「便利ですね」
教授「その言葉を第16回まで無警戒に使うとは」
ミカ「嫌な予感がしてきました」
【キャッシュへ偽物を入れられたらどうなるのか】
教授「正常な住所がこうだったとしよう」
bank.example.jp → 正規サーバー
教授「ところがDNSキャッシュへ偽物の情報が入り込む」
bank.example.jp → 攻撃者側の偽サーバー
ミカ「利用者は bank.example.jp と正しく入力しています」
教授「そうだ」
ミカ「でもDNSが偽サーバーの住所を返す」
教授「利用者はその住所へ接続する」
ミカ「これがDNSキャッシュポイズニング」
教授「名前を偽造するのではなく、名前から住所を調べる結果を汚染するわけだ」
【身近な例――電話帳を書き換えられたら】
ミカ「もっと簡単な例をお願いします」
教授「会社の内線電話帳を考えよう」
ミカ「社長室は内線100ですね」
教授「攻撃者が電話帳をこっそり書き換える」
ミカ「社長室100を、攻撃者の電話200へ」
教授「社員は？」
ミカ「電話帳を信じて100ではなく、表示された200へかけてしまう」
教授「本人は『社長へ電話している』つもりだ」
ミカ「でも相手は攻撃者」
教授「DNSキャッシュポイズニングも同じだ」
ミカ「利用者の操作は正しいのに、案内役が間違っている」
教授「今日の核心だ」
【なぜキャッシュを狙うのか】
ミカ「利用者一人を騙すよりDNSを狙う意味は？」
教授「一つのDNSサーバーを多数の利用者が使っている場合、そのキャッシュへ誤った情報が入れば？」
ミカ「そのDNSを使う全員へ同じ偽住所を返す可能性がある」
教授「そうだ」
ミカ「一人ずつフィッシングメールを送らなくてもよい」
教授「だから影響範囲が大きくなる可能性がある」
ミカ「住所録一冊を書き換えるだけで、会社全員を迷子にできる」
教授「良い例えだ」
【攻撃はどう成立するのか――安全な範囲で理解する】
ミカ「具体的にはどうやって偽物のDNS情報を入れるのですか」
教授「攻撃手順そのものではなく、仕組みだけ理解しよう」
ミカ「はい」
教授「DNSサーバーが外部へ『このドメインの住所を教えてください』と問い合わせる」
ミカ「正常なDNSサーバーから回答が返る」
教授「その前後で、攻撃者が本物に見える偽のDNS応答を送り込める状況があるとする」
ミカ「DNSサーバーが偽物を本物だと思ったら？」
教授「その情報をキャッシュしてしまう可能性がある」
ミカ「その後の利用者にも偽住所を返す」
教授「そうだ」
ミカ「つまり攻撃者は利用者を一人ずつ騙すのではなく、案内所そのものを騙す」
教授「その理解でよい」
【DNSハイジャックとは違うのか】
ミカ「DNSハイジャックと同じですか」
教授「似ているが、同じとは限らない」
ミカ「違いは？」
教授「DNSハイジャックは、DNS設定そのものやドメイン管理、ルーター設定などを不正に変更し、問い合わせ先や回答を攻撃者側へ誘導するような広い概念として使われる」
ミカ「DNSキャッシュポイズニングは？」
教授「DNSキャッシュへ誤った名前解決情報を覚え込ませることに焦点がある」
ミカ「住所録そのものを盗むのがハイジャック」
教授「例えとしてはそう考えてよい」
ミカ「住所録の一ページへ偽住所を書き込むのがキャッシュポイズニング」
教授「かなり分かりやすい」
【成立すると何が起こるのか】
ミカ「偽サイトへ連れて行かれたら何が起きますか」
教授「攻撃者が用意したサイト次第だ」
ミカ「ログイン画面をそっくり作る」
教授「利用者がIDとパスワードを入力する」
ミカ「フィッシングにつながる」
教授「マルウェアを配布するサイトへ誘導することも考えられる」
ミカ「通信内容を盗む？」
教授「中間者攻撃と組み合わされる場合も考えられる」
ミカ「第12回まで戻ってきました」
教授「実際の攻撃は、教科書の見出しどおり一種類ずつ来てくれるわけではない」
【HTTPSがあれば助かるのか】
ミカ「でも正しいURLを入れて偽IPへ行っても、HTTPSがありますよね」
教授「非常に重要だ」
ミカ「偽サーバーは本物の会社の証明書を持っていない」
教授「通常はそこでブラウザが証明書の問題を検知する可能性がある」
ミカ「『この接続ではプライバシーが保護されません』」
教授「そうした警告を無視してはいけない」
ミカ「DNSを騙されてもTLSが次の壁になる」
教授「多層防御だ」
ミカ「また出演しましたね」
教授「多層防御君は長期レギュラーだ」
【異常をどう発見するのか① 突然違うサイトが表示される】
ミカ「では本題です。利用者はどうやって異常を発見しますか」
教授「一番分かりやすいのは表示内容の変化だ」
ミカ「いつものサイトと違う？」
教授「デザインが突然変わった、ログインをもう一度求められた、日本語がおかしい、普段とは違う情報を要求される」
ミカ「でも偽サイトが完璧なら？」
教授「見た目だけでは判断できない」
ミカ「そこで証明書警告を見る」
教授「そうだ。正しいURLなのに証明書警告が出たら、DNSや通信経路も含めて異常を疑う材料になる」
【異常をどう発見するのか② 複数のDNSで結果を比較する】
ミカ「管理者なら、もっと具体的に確認できますか」
教授「できる。例えば同じドメインを、社内DNSと別の信頼できるDNSで問い合わせて比較する」
ミカ「結果のIPアドレスを見る？」
教授「そうだ」
ミカ「社内DNSだけ全く違うIPを返していたら？」
教授「調査する価値がある」
ミカ「Windowsなら nslookup も使えますね」
教授「そうだ。PowerShellなら Resolve-DnsName も使える」
ミカ「例えば？」
Resolve-DnsName example.jp教授「これで通常利用しているDNSの結果を確認できる」
ミカ「別のDNSサーバーを指定して比較することもできる」
教授「そうだ。ただし、CDNなどでは接続場所によって異なる正規IPが返る場合もある」
ミカ「IPが違う＝攻撃とは断定できない」
教授「非常に重要だ。比較結果は異常を見つける手掛かりであって、単独で攻撃を証明するものではない」
【異常をどう発見するのか③ 権威DNSと比較する】
ミカ「より確実に調べるなら？」
教授「そのドメインを管理する権威DNSの情報と比較する方法がある」
ミカ「社内DNSではAという住所」
教授「権威DNSではBという住所」
ミカ「一致しない」
教授「CDNや構成変更など正当な理由がないか確認する」
ミカ「それでも説明できなければ？」
教授「DNSキャッシュやDNSサーバーの状態を調査する」
ミカ「つまり、案内所の答えを、本籍地の住所録と照合する」
教授「そんな感じだ」
【異常をどう発見するのか④ TTLを見る】
ミカ「DNSにはTTLというものがありますね」
教授「Time To Live。キャッシュしてよい時間だ」
ミカ「例えば3600秒なら一時間？」
教授「そうだ」
ミカ「TTLも調査材料になりますか」
教授「なる。普段と大きく違うTTLや、不自然に長いキャッシュ期間などが見つかれば確認材料になる」
ミカ「ただしTTLが違うだけで攻撃とは限らない」
教授「そのとおり。DNS設定変更でも変わる」
ミカ「セキュリティは『怪しい＝犯人』ではない」
教授「証拠を重ねて判断する」
【異常をどう発見するのか⑤ DNSログを監視する】
ミカ「会社ならDNSサーバーのログも見ますか」
教授「重要だ」
ミカ「何を見る？」
教授「普段とは違う名前解決結果、異常な問い合わせ量、未知のDNSサーバーへの問い合わせ、設定変更などだ」
ミカ「DNSサーバーそのものの管理者ログも？」
教授「もちろんだ」
ミカ「いつ誰が設定を変更したか」
教授「そこまで記録できれば調査しやすい」
ミカ「ログを取るだけでは？」
教授「第15回で言っただろう」
ミカ「誰も見ないログは高価な日記帳」
教授「覚えていたか」
【異常をどう発見するのか⑥ 社内の複数端末で確認する】
ミカ「私のPCだけ変なサイトへ行く場合は？」
教授「ローカルPCのDNSキャッシュやhostsファイル、ルーター設定など別の原因も考えられる」
ミカ「会社全員なら？」
教授「共通して使っているDNSやネットワーク機器を疑う材料になる」
ミカ「一人か全員かで調査場所が変わる」
教授「非常に大切だ」
ミカ「問題の範囲を切り分ける」
教授「セキュリティだけでなく障害対応の基本だ」
【発見したら最初に何をするのか】
ミカ「DNSキャッシュがおかしいと疑ったら？」
教授「まず影響範囲を確認する」
ミカ「一台だけか、部署全体か、会社全体か」
教授「次に正しいDNS情報を確認する」
ミカ「そのあと？」
教授「管理しているDNSサーバーのキャッシュを調査し、必要なら不正または古いキャッシュを削除・更新する」
ミカ「Windows PCにもDNSキャッシュがありますよね」
教授「ある。端末側の問題ならキャッシュをクリアして再取得する方法もある」
ミカ「ただキャッシュを消して終わりではない？」
教授「そこが重要だ。なぜ偽情報が入ったのか原因を調べなければ再発する」
ミカ「玄関の泥を拭いても、屋根の穴を直さなければまた濡れる」
教授「今日は比喩が絶好調だな」
【防止策① DNSサーバーを最新状態に保つ】
ミカ「防御の第一歩は？」
教授「DNSサーバーやネットワーク機器を最新状態に保つ」
ミカ「脆弱性修正ですね」
教授「そうだ。古いDNSソフトウェアやルーターを放置しない」
ミカ「ファームウェアも？」
教授「当然だ」
ミカ「DNSというインフラは一度設定したら10年間触らない、ではだめ」
教授「むしろ重要な基盤ほど継続管理が必要だ」
【防止策② DNSSECを利用する】
ミカ「もっとDNSらしい防御策は？」
教授「DNSSECがある」
ミカ「DNS Security Extensions？」
教授「そうだ。DNSの応答へ電子署名を付け、受け取ったDNS情報が正当なものか検証できるようにする仕組みだ」
ミカ「住所録に電子印鑑を付ける？」
教授「良いイメージだ」
ミカ「攻撃者が偽住所を書いても？」
教授「正しい署名を作れなければ検証で問題を検知できる」
ミカ「DNSキャッシュポイズニング対策として重要ですね」
教授「そうだ。ただしドメイン側、DNS事業者側などを含め適切に構成されている必要がある」
【DNSSECとHTTPSは役割が違う】
ミカ「DNSSECがあればHTTPSはいらない？」
教授「いらなくならない」
ミカ「なぜ？」
教授「DNSSECはDNS情報の真正性を守る」
ミカ「住所録を守る」
教授「HTTPS/TLSはWebサーバーとの通信を暗号化し、接続先確認にも使う」
ミカ「会話を守る」
教授「そうだ」
ミカ「DNSSEC＋HTTPS」
教授「別々の層を守る」
ミカ「多層防御君がまた出ました」
教授「今日は出演時間が長いな」
【防止策③ 社内で利用するDNSを管理する】
ミカ「社員が好きなDNSを使ってもよいですか」
教授「企業ではDNS利用方針を決めるほうが管理しやすい」
ミカ「会社指定のDNSを使う」
教授「そうすればログ監視やフィルタリング、異常検知もしやすい」
ミカ「端末が勝手に正体不明のDNSへ問い合わせるのは？」
教授「必要に応じてネットワーク側で制御する」
ミカ「DNSにもシャドーITみたいな問題がある」
教授「名前解決の経路を把握できないと、異常時の調査も難しくなる」
【防止策④ ルーターのDNS設定を守る】
ミカ「会社のDNSサーバーを使っていない小さな事務所なら？」
教授「ルーターのDNS設定も非常に重要だ」
ミカ「ルーターの管理画面を乗っ取られてDNSを書き換えられたら？」
教授「利用者を偽DNSへ誘導される可能性がある」
ミカ「対策は？」
教授「初期管理パスワードを変更する。管理画面をインターネットへ不要に公開しない。ファームウェアを更新する。管理アクセスを制限する」
ミカ「家庭用ルーターでも同じですね」
教授「そうだ」
【防止策⑤ 再帰DNSを誰にでも使わせない】
ミカ「DNSサーバーを立てる場合の注意は？」
教授「外部から誰でも自由に再帰問い合わせできるオープンリゾルバーにしないことが重要だ」
ミカ「社内用DNSなら社内だけから利用可能にする」
教授「そうだ。アクセス制御を行う」
ミカ「なぜ？」
教授「不正利用や別のDNS攻撃へ悪用されるリスクを減らせる」
ミカ「DNSサーバーも最小権限」
教授「サービスにも最小権限の考え方は使える」
【防止策⑥ 証明書警告を無視しない】
ミカ「利用者側では結局これですね」
教授「そうだ。DNSが何らかの理由で偽のサーバーへ案内しても、HTTPSの証明書検証が次の防御になる」
ミカ「そこで警告が出たら止まる」
教授「重要サイトで証明書警告が突然出たら、先へ進まず管理者へ連絡する」
ミカ「『昨日まで開けたから大丈夫』は？」
教授「昨日安全だったことは、今日の証明書を保証しない」
【防止策⑦ 重要サイトではURLも確認する】
ミカ「DNSキャッシュポイズニングではURLは正しいのでは？」
教授「そういうケースもある。ただし実際の攻撃ではフィッシングなど別の手法も組み合わされる」
ミカ「だからURL確認は無駄ではない」
教授「そうだ。ただし今日の攻撃が教えるのは、URLだけ確認して終わってはいけないということでもある」
ミカ「正しいURL＋HTTPS＋証明書」
教授「複数の要素を見る」
【DNSキャッシュポイズニングを疑うチェックポイント】
ミカ「実務で使えるようにまとめましょう」
教授「では七つだ」
正しいURLなのに突然違うサイトが表示されないか
証明書警告が突然出ていないか
社内DNSと別の信頼できるDNSで結果が大きく異ならないか
権威DNSの情報と矛盾していないか
DNSレコードやTTLに不自然な変化がないか
DNSサーバーやルーターの設定変更履歴に異常がないか
一台だけの問題か、組織全体の問題かを切り分けたか
ミカ「これなら障害対応でも使えそうですね」
教授「DNS障害と攻撃は症状が似ることもあるから、冷静に切り分けることが大切だ」
【経営者が確認すべきこと】
ミカ「経営者には何を聞けばよいですか」
教授「『うちのDNSは誰が管理していますか』」
ミカ「いきなり答えられない会社もありそうです」
教授「次に『ルーターやDNSサービスは更新されていますか』」
ミカ「はい」
教授「『DNS設定を誰が変更できますか』」
ミカ「権限管理」
教授「『変更履歴は残っていますか』」
ミカ「ログ」
教授「『DNS異常が起きたら誰に連絡しますか』」
ミカ「インシデント対応」
教授「DNSは目立たないが、止まったり書き換えられたりすると会社全体へ影響する」
ミカ「住所録係だから地味ですが、休むと全員迷子になる」
教授「DNS担当者が聞いたら喜ぶか微妙な褒め方だな」
【利用者が覚えるのは三つでよい】
ミカ「一般利用者には少し難しいですね」
教授「三つだけ覚えればよい」
ミカ「何ですか」
教授「正しいURLでも油断しない」
ミカ「一つ」
教授「突然の証明書警告を無視しない」
ミカ「二つ」
教授「普段と違うログイン画面や動作なら入力を止める」
ミカ「三つ」
教授「そして会社なら管理者へ報告する」
ミカ「自分でDNSサーバーを修理しなくてよい」
教授「むしろ勝手に設定を変えないでほしい」
【DNSキャッシュポイズニングの本当の怖さ】
ミカ「今日の攻撃は利用者が気を付けても完全には防げませんね」
教授「そこが特徴だ」
ミカ「フィッシングならリンクを押さない」
教授「パスワード攻撃ならMFAを使う」
ミカ「でもDNSが偽住所を返したら、正しく操作していても誘導される可能性がある」
教授「だからインターネットでは、名前解決、通信暗号化、証明書確認など複数の仕組みで相互に守っている」
ミカ「一つの仕組みを絶対に信用しない」
教授「良いまとめだ」
【ミカと教授の一言で締める】
ミカ「教授、DNSキャッシュポイズニングを一言で説明してください」
教授「DNSサーバーが覚えている名前とIPアドレスの対応へ偽情報を混ぜ、利用者を本来とは違う場所へ案内する攻撃だ」
ミカ「何を狙う？」
教授「インターネットの住所録だ」
ミカ「発見するには？」
教授「複数のDNS結果、権威DNS、証明書、ログ、端末の範囲を比較する」
ミカ「防御は？」
教授「DNSSEC、DNSサーバーの更新、DNS設定の保護、HTTPS、証明書検証などを重ねる」
ミカ「教授の住所をDNSへ登録しておきます」
教授「何のためだ」
ミカ「レポート提出先として」
教授「キャッシュごと削除しておきなさい」
【次回予告】
【第17回 ARPスプーフィング――「社内LANで、なぜ他人の通信が自分のPCを通るのか」】
ミカ「次回はDNSよりさらに社内ネットワークへ近づくのですね」
教授「そうだ」
ミカ「ARPとは？」
教授「同じネットワークの中で、IPアドレスと機器のMACアドレスを対応付ける仕組みだ」
ミカ「それも住所録？」
教授「今度は町内会の住所録に近い」
ミカ「また書き換えられるのですか」
教授「攻撃者が『そのIPアドレスなら私です』と偽ったらどうなるか」
ミカ「通信が攻撃者のPCへ？」
教授「第17回では、社内LANの中で通信の行き先を偽るARPスプーフィングを具体的に見ていこう」
