「インターネットで使われているプロトコルの認証機能って，何もしないゆるゆる状態か，電子証明書を使ってガッチリ固めるかの二者択一な気がするんです。後者はすごく実装が面倒くさい。もっと実装しやすい“ほどよい”対策があるといいんですが」。あるネットワーク関連機器ベンダーの方に取材している時に聞いた一言です。

　たしかに，特に拡張機能などを実装しない“素”の状態では「私が今，通信している相手は正しい」と厳密に確認できる仕組みを持たないプロトコルはけっこうあります。DNS（domain name system）やBGP（boarder gateway protocol），SMTP（simple mail transfer protocol）などがこの範疇に入りそうです。

　これらの仕様がゆるい理由は，「プロトコルが広く普及し，成功するためには何と言っても“実装しやすさ”，“運用しやすさ”が重視される。セキュリティは重要だが，仕様の策定や実装は後回しになるケースが多い」（DNSサーバー・ベンダーの米ノミナム ゴパラ・ツムルリ副社長）からでしょう。ここではDNSを例に見ていくことにします。

クラッカの攻撃はより巧妙に

　DNSの基になった最初の仕様（RFC882）が公開されたのは1983年。その後，1997年に電子証明書を使った認証用の拡張プロトコルDNSSECが仕様化されました。ところが前述の通り，DNSSECは「すごく実装が面倒」なため，まだ広く普及するには至っていません。

　こうしたプロトコルの仕様そのものが抱える認証の弱さは当然，クラッカに狙われます。この種の攻撃は今に始まったことではなく，古くから存在しています。

　例えば2008年7月に話題になった「DNSキャッシュ・ポイズニング」の危険性が最初に認識されたのは，1989年ころだそうです。DNSキャッシュ・ポイズニングはDNSサーバーのキャッシュに偽の情報を埋め込む攻撃です。攻撃が成功すると，エンドユーザーのパソコンが不正なWebサイトに誘導されるといった被害が起こります。

　ただ，これまでは電子証明書を使ってセキュリティを固めなくても，「少しずつ実装を強化することで攻撃の多くは防ぐことができた。DNSキャッシュ・ポイズニングの脆弱性が及ぼす影響も限定的と考えられていた」（ツムルリ氏）といいます。

　昔はネットワークやコンピュータのリソースがリッチではなかったため，攻撃の成功率がそんなに高くなかったということもあるでしょう。しかし，今では状況が変わり，かなり効率的に攻撃を仕掛けられるようになっています。2008年7月に話題になったDNSキャッシュ・ポイズニングの新手法は，まさにその一例です（関連記事1，関連記事2）。

　一般にDNSでは（電子証明書は使わないものの）やり取りの正当性を確認するため，問い合わせ時に利用した(1)送信元IPアドレスおよび(2)UDPのポート番号あての通信であることを確認します。さらに，問い合わせごとに異なる(3)16ビットの識別子（トランザクションID）もチェックします。専門家によると，このうち(1)と(2)は比較的容易に特定・推定できるそうです。

　残る(3)は16ビット，つまり6万5536通りのIDを総当たりで試せば，いずれ正解にたどり着きます。DNSプロトコルができたころには6万5536通りで十分だったのかもしれません。現在ではコンピュータの処理性能が向上したため，以前は非現実的だった攻撃でも力わざで実行できるようになってきた感があります。攻撃者は自らターゲットのDNSサーバーに多数の問い合わせをかけ，それに対してランダムなトランザクションIDを付けた偽の応答パケットを大量に送り返し続ければいいわけです。

　さらに従来の攻撃頻度はDNSサーバーのキャッシュ生存時間に依存していたのですが，2008年7月の手口では最初の問い合わせに実在しないドメインを使うことで，キャッシュ生存時間の長さによらず，連続して攻撃を仕掛けられるようになってしまいました。

「ゆるさ」は「メリット」の裏返し

　ここ数年言われ尽くしていることですが，クラッカは愉快犯でなく，金儲けのために真剣に攻撃を仕掛けてきます。「DNSプロトコルのアーキテクチャ自体が古びたとは思わない。ただ，セキュリティをもっと真剣に考えなければならないフェーズに来たということだろう」（ツムルリ氏）。こうした傾向は，認証機能がゆるいDNS以外のプロトコルにも当てはまるでしょう。

　ただし，「セキュリティを強化する」と言うのは簡単ですが，実行するのは難しそうです。極論すれば，「最初からセキュリティに配慮して設計された、インターネットとは別の次世代ネットワークを使う」という手がありそうです。しかし，移行コストや手間を考えると現実的ではありません。

　同じ理由で，拡張プロトコルの多くもすぐには実装するのが難しそうです。そもそもインターネットのプロトコルは最初の仕様で“実装しやすさ”と“運用しやすさ”を重視したからこそ普及し，手頃な価格で多数のサービスが作られてきました。「ゆるさ」は「メリット」の裏返しという一面があります。そこを無視して実装しにくいセキュリティ対策を進めてもなかなか受け入れられないでしょう。

　今後しばらくは実装の強化でしのぎ，少しずつ拡張プロトコルの実装を進めていくのが現実解と言えそうです。この場合，事前対策は難しく，現れた脅威に対して対処療法的に対策を打っていくことになります。

　つまり，事後の対応をいかに早くするかが課題です。今後はCSIRTなどセキュリティ対策に当たるチームの編成や，メンテナンスしやすいシステム作り，異常値を検出するログ監視などがますます重要になるでしょう。