DNS毒入れとアンプ攻撃を防ぐ必須対策

前回 DNS は世界で一番親切な案内所だって話をしましたよね。いつでも正しいウェブサイトの住所を教えてくれると。 ええ、しましたね。でも、もしですよ、その案内所の人が悪意を持った誰かに騙されて偽の地図を渡してしまったとしたら、あなたならどうしますか？ それが今回私たちが深く掘り下げていくテーマ、DNSキャッシュポイズニングなんです。キャッシュポイズニング。ええ、直訳するとキャッシュへの毒入れですね。 これは本物の案内が届くよりほんのコンマ数秒早く攻撃者が偽の情報を叩き込む、まさに早い者勝ちのサイバー攻撃なんです。早い者勝ちですか。 なるほど、スピード勝負なんですね。そうなんです。案内所、つまりキャッシュサーバーが一番早く届いた情報を、これが正しいんだって信じてメモしちゃう。 ええ。で、そうすると、後からその案内所に来た人たちはもう全員がその毒の入った情報を信じてしまって偽のサイトに誘導されると。 まさにその通りです。今回はこの毒入れ、ポイズニングっていう巧妙な手口の仕組みと、あと、もっと厄介な話として、あなたのサーバーが意図せず攻撃の踏み台、 つまり加害者にならないための対策、この2つの側面から資料をもとに解き明かしていきましょう。了解です。その早い者勝ちというレース、 もう少し詳しく教えていただけますか？普通に考えたら本物の方が早そうですけど。いい質問ですね。攻撃者はキャッシュサーバーが権威 DNS サーバー、 つまり目的地の本当の案内所に、このドメイン名の住所はどこですか？って問い合わせるそのごくわずかな隙をピンポイントで狙うんですよ。 隙、ですか。ええ。サーバー間の通信にはどうしてもほんのわずかな遅延、まあレイテンシーが発生しますからね。ああ、なるほど。 そのコンマ何秒という人間にはもう全然わからないような時間差を突いてくるわけですか。まさに。その間に攻撃者は予測した内容の偽の応答を これが正しい住所ですよって本物の応答が届く前に猛スピードで送り込むんです。うわぁ。キャッシュサーバーは基本的に、あの最初に届いた応答を 正しいものとして受け入れてしまう性質があるので、このレースに攻撃者が勝ってしまうと偽の情報がキャッシュに記録されてしまう。これが毒入れの瞬間です。 怖いですね。つまりユーザーはいつも通り、例えば自分の銀行のサイトの正しい URL を打ち込んでいるだけなのに気づかないうちに見た目がそっくりな 偽のフィッシングサイトに飛ばされちゃう可能性があると。その通りです。そしてそこで ID とかパスワード、クレジットカード情報なんかを入力してしまったら もう全部盗まれてしまう。非常に危険な攻撃です。ではどうすればこの早い者勝ちのレースに負けないようにできるんでしょう。 資料にある最初の対策はランダム化ですね。でも、何かをランダムにするだけでそんな巧妙な攻撃が防げるものなんですか。そこが面白い点なんです。 実は昔の DNS の問い合わせっていうのは、ある意味ですごく素直な仕組みだったんですね。素直な仕組み。ええ。問い合わせに使う合言葉に当たるトランザクション ID とか、 窓口に当たる送信元ポート番号がある程度決まっていたり、連番になっていたりと、すごく予測しやすかったんです。なるほど。 攻撃者からすれば、もう次のレースは第3コースからスタートしますよって毎回アナウンスされているようなものですね。まさに。それなら偽の応答を どこに送りつければいいか狙い撃ちしやすいわけだ。そうなんです。これはインターネットの黎明期に、まあ性善説というか誰も悪いことなんてしないだろうっていう信頼に基づいた 設計思想があったことの名残でもありますね。効率とかシンプルさが優先されていた。ああ、そういう背景があったんですね。 ええ、攻撃者はその古き良き時代の設計の甘さを突いてきたというわけです。だとしたら、対策はすごくシンプルですね。 毎回そのスタートするコースと、レースの参加者番号を完全にバラバラ、つまりランダムにしちゃえばいい。ご明察です。 それがソースポートランダム化、そしてトランザクション ID のランダム化。これが最も基本的で、かつ非常に重要な対策になります。 なるほど。 ID とポート番号の組み合わせを毎回完全に予測できないものにすることで、攻撃者が正しい組み合わせを当てずっぽうで当てる確率を もう天文学的に低くすることができるんです。闇雲に偽の応答を送ってもキャッシュサーバーに、「いや、あなたの ID とポート番号は私が送った問い合わせと違いますよ」って ことごとく弾かれるわけですね。ええ。単純ですけど効果は絶大なんです。そうなんです。ですが、これで完璧かというとそうでもない。 当てにくくするっていう防御なので、確率はゼロではないんです。あ、そっか。そこで、もう一つのより強力な対策が必要になってきます。 それが資料の2つ目に出てくる DNSSEC ですね。これは前回のデジタル署名の応用だとありますが、ランダム化とはどう違うんですか。 ランダム化が攻撃の球を当たりにくくする消極的な防御だとすれば、 DNSSEC は例え球が当たっても、それが偽物だと見破るための積極的な防御策です。 偽物だと見破る。具体的にはどういう仕組みなんですか。 DNS の応答データに、「この情報は間違いなく本物のサーバーから送られたものです」っていう、偽造できない電子的署名、 つまりデジタル署名をつけて送る技術なんです。証明印ですか。はい。キャッシュサーバーは受け取った応答にその証明印があるか、 そしてそれが本物かどうかを、あらかじめ知っている公開鍵を使って検証するんです。ああ、公開鍵暗号の仕組みですね。 つまり案内所であるキャッシュサーバーは、一番早く届いた案内を鵜呑みにするんじゃなくて、まずその案内所にキラリと光る本物の証明印があるかを確認するわけだ。 ええ、ええ。で、署名がなかったり偽物だったりすれば、たとえ一番乗りでもこれは出所不明の怪しい情報だと判断して、すぐに捨てちゃうことができる。 完璧な例えです。そうなると、もはや早い者勝ちのスピード勝負ではなくなるんですよ。ああ、なるほど。 攻撃者がどれだけ早く偽の情報を送りつけても、署名がなければ意味がない。 DNSSEC が正しく導入されていれば、偽の情報がキャッシュに混入する余地は論理的にはなくなるんです。 なるほど。ランダム化で攻撃の的を絞らせないようにして、 DNSSEC で万が一届いても偽物だと見破る。この2段構えで毒入れを防ぐわけですね。 そういうことです。これでキャッシュポイズニングの件はかなりクリアになりました。でも、資料を読み進めるともっと気味の悪い話が出てくるんですよね。 自分のサーバーが被害者になるだけじゃなく、気づかないうちに攻撃の片棒を担がせられる、つまり加害者になってしまうと。ええ、それが DNS アンプ攻撃です。 アンプ攻撃。ここのアンプは音楽で使うアンプと同じで増幅っていう意味です。これはあなたの管理する DNS サーバーが攻撃の踏み台として悪用されてしまう攻撃なんですよ。 ちょっと待ってください。どういう手口でうちのサーバーが踏み台にされるんですか。攻撃者はまず問い合わせパケットの送り主の IP アドレスを、 本当に攻撃したい相手、つまり被害者の IP アドレスに偽装します。送り主を偽装する。そうです。そしてその偽装した情報を使って大量の問い合わせを送りつけるんです。 送り主を偽装して、うちのサーバーに質問を送る。うちのサーバーは親切だから、問い合わせてきた送り主に対して返答を送り返ししますよね。 でも、その送り主のアドレスは偽装されているから、まさか。ええ。全く無関係の被害者の元へ、うちのサーバーから一斉に大量の応答データが送りつけられてしまうってことですか。 まさにその通りです。そして、この攻撃の本当に悪質な点は、その名の通り、増幅。つまりアンプの仕組みにあるんです。増幅。 攻撃者があなたのサーバーに送る質問のデータは意図的に、まあ数10倍とかくらいのすごく小さなものを選びます。 しかし、その小さな質問に対するサーバーからの返答データが、数10倍、数100倍も大きくなるような特殊な問い合わせを悪用するのです。 小さな石を投げたら巨大な岩になって返ってくるイメージですか。その例えは的確ですね。しかも、その岩を投げるための力は、攻撃者にとってはほんのわずかで済む。 これがこの攻撃の非対称性であり恐ろしい点です。ああ、攻撃者はほんの少しの通信量であなたのサーバーを踏み台にして、 その何百倍もの巨大なデータ量を被害者に叩きつけることができる。これが増幅です。被害者は身に覚えのない大量のデータでネットワーク回線を埋め尽くされて、 サーバーはダウンし、サービスが停止してしまう。自分のサーバーが善意で応答した結果、そんな凶悪な DDoS 攻撃の片棒を担わされるなんて、管理者としては悪夢ですね。 どうすればこれを防げるんですか。資料にある通り、最も重要なのは、オープンリゾルバーという設定をやめることです。 オープンリゾルバー、開かれた解決者ですか。なんだか良いものに聞こえますけど。言葉の響きはそうかもしれませんね。 ですが実態は、インターネット上の見ず知らずの誰からの質問にも親切に答えてあげますよ、という、まあ非常におせっかいで性善説に基づいた設定なんです。 ああ、先ほどの昔の DNS の設計思想の話に通じますね。そうなんです。その、「誰にでも答えます」設定になっているから、 IP アドレスを偽装した攻撃者も 自由にうちのサーバーを質問攻めにして、踏み台として悪用できてしまうわけです。なるほど。対策はそのおせっかいをやめること。 つまり自分の管理するネットワークの内部とか、特定の許可された利用者からの問い合わせにだけ応答するように設定を限定することなんですね。その通りです。 外部からの誰だか分からない再帰的な問い合わせは受け付けない、と。自分の会社の社員やサービスを使っているお客様のためだけに案内をして、 通りすがりの見知らぬ人からの、「ちょっとあれ調べてきて」っていうお願いは丁重にお断りするようにするということですね。まさに。 これは管理者として絶対に確認すべき設定項目ですね。ええ、意図せず攻撃の加害者にならないために。これは DNS サーバーを運用する上での必須のセキュリティ対策であり、 社会的責任とも言えます。では、今日の話をまとめましょうか。まず DNS への毒入れ、 DNS キャッシュポイズニングを防ぐには、2つの重要なアプローチがありました。 ええ、1つは攻撃者に的を絞らせないこと。問い合わせの ID とポートを予測不可能にするランダム化。ランダム化。 もう1つは届いた情報が本物か検証すること。 DNSSEC による署名での証明です。この2つが基本となります。 そして、自分のサーバーが増幅器、つまりアンプとして知らないうちに攻撃の踏み台にされないためには、オープンリゾルバーを止めることです。 問い合わせに応答する範囲を信頼できる内部ネットワークに限定することが不可欠です。もしあなたが試験を控えているなら、覚えるべきは驚くほどシンプルです。 ID をランダムに、オープンリゾルバーはやめる。この2つです。そうですね。キャッシュポイズニング対策は ID ランダム化、アンプ攻撃対策はオープンリゾルバーの停止。 まずはこの2つのキーワードを確実に押さえてください。この話は私たちにある重要な問いを投げかけます。 私たちは今日、インターネット上の情報の信頼性をどう担保するかという話を技術的な側面から見てきました。ええ。 これを、ちょっと現実世界に置き換えてみると興味深い問いが浮かび上がってくるんです。あなたは日常生活で無意識のうちにオープンリゾルバーになっていませんか。 日常生活でですか。ええ。出所の不明な情報とか SNS 上の真偽不明の噂話を、その証明、つまり根拠や事実関係を確認しないまま受け入れて、 善意から、あるいは面白半分で誰かに伝えてしまってはいないでしょうか。なるほど。自分が受け取った小さな不確かな情報を、 自分の友人関係とか社会的信用っていうアンプで増幅してしまって、意図せず誰かを傷つけるための踏み台になってしまう可能性があるということですね。 ええ。技術の話が急に自分自身の問題として迫ってきました。技術の世界で学んだ教訓はしばしば私たちの日常にも通じるものがあります。 情報の真偽を見極めようとすること、そして安易に拡散しないこと、それが今日の話から得られるもう一つの重要な学びかもしれませんね。