あらゆる情報を、うのみにするな？！：Security&Trust ウォッチ（8）

　セキュリティ対策の基本を挙げよ、といわれたら、何が思い浮かぶだろうか？ 私は3つの事柄を挙げたい。

　まずは、常にセキュリティへの気配りを忘れないようにすることだ。具体的な対策というよりも、心構えの部類に入るのだろうが、こうした意識なしには何も始まらない。日ごろから、最悪のケースも含めてさまざまなケースを想定し、事後の対策手順をシミュレーションするよう心掛ける。頭の中で考えるだけではなく、簡単な項目だけでもドキュメントとしてまとめておけば、いざというときでも慌てることなく対応できるだろう。

　2つ目は、システムは何にせよ、デフォルトのまま利用しないことだ。最も分かりやすい例が、OSやアプリケーションだろう。これらを素直にインストールしていくと、ユーザーにとっては不必要な、そして攻撃者にとっては絶好のターゲットとなるサービスまでもが稼働することがある。しかもこの場合、ユーザーが自ら選んでインストールするわけではないため、そのようなサービスが稼働していること自体、気付かないケースもある。これは非常に大きなリスクだ。

　従って、何かシステムをインストールしたならば、不要なサービスは停止するよう設定を変更する。おそらく利用しないであろうサンプルプログラムやモジュールは、削除してしまう方がいい。

　ただし最近では、ユーザー、ベンダともにデフォルト設定の危険性を認識するようになった。このため、ソフトウェアの設定が初めから「安全」な方に設定されている場合も増えてきたようだ。以前は、便利だからと、使いもしないサービスまで自動的にインストールし、潜在的なセキュリティホールを作り出していたが、その代わりに、必要最低限のサービスだけを導入しておき、必要に応じてモジュールを追加していくというアプローチが多く見られる。この点をさんざん指摘されてきたマイクロソフトもアプローチを変えた。現在開発が進むIIS（Internet Information Service）の次期バージョンは、その好例といえるだろう。

　デフォルト設定の危険性は、OSなどのソフトウェアに限った話ではない。例えばルータやスイッチ、無線LANのアクセスポイントなどのネットワークデバイスには、出荷時にデフォルトのパスワードが設定されている。これを変更せずそのまま利用し続けることの危険性は、あえて説明するまでもないだろう。

　セキュリティ対策の基本としての最後の項目は、常に新しい情報に注意を払い、システムに適切なメンテナンスを施し続けていくことだ。新手の攻撃手法が登場したならば、それをブロックするようフィルタリングやファイアウォールの設定を変更すること。古いセキュリティホールが修正された最新のOSやアプリケーションを利用すること。そして利用しているシステムに何らかのセキュリティホールが発見されたならば、速やかにパッチを適用することだ（ただしシステム安定稼働の観点からは、同一構成のテストマシンを用意しておき、パッチ適用によって問題が生じることがないかチェックしておくことが望ましい）。

　残念ながら、KlezやBugbearといった、Internet Explorerで1年以上前に発見されたセキュリティホールを悪用するウイルスが、いまだに跳梁跋扈（ちょうりょうばっこ）しているのが現実である。最新バージョンの採用とパッチ適用の重要さは、いくら強調しても強調しすぎることはないはずだ。

最新バージョンがかえって害を招く？

　中には、「“パッチは速やかに適用すべし”なんてことは、もう耳にタコができるくらい聞いているし、実践している」という人もいるかもしれない。ちょっと昔ならば、これで十分、セキュリティ対策は及第点といえた。

　だがいま、パッチの適用という作業そのものが、セキュリティホールを作り出してしまう可能性が浮上している。

　今年7月、オープンソースの暗号通信ソフトウェア「OpenSSH」にトロイの木馬が仕掛けられるという事件があった。10月にはメールサーバの「sendmail」に、さらに11月に入ると「tcpdump」と「libpcap」にトロイの木馬が仕込まれ、警告が発せられている。セキュリティの観点から望ましいとされる最新バージョンのソースコードが、かえって害をなしかねないわけだ。

　この種の事件は今後も起こる可能性がある。それも、もっと悪い形で起きないとも限らない。DNSやSSLの脆弱性を悪用して、にせのサイトにユーザーを誘導し、トロイの木馬入りプログラムを入手させるよう仕向ける可能性だってある。既知のセキュリティホールをうまく組み合わせ、悪用すれば、不可能ではないはずだ。

　無論、これを避ける手はずはある。実践的な手法としては、ファイルをダウンロードする前にその正当性をチェックすることが挙げられる。方法は簡単だ。日付やファイルサイズに加え、MD5チェックサムを取って比較するだけでも、正当なバージョンかそうでないかを判断することができる。

　ただ、ここにも安心できない要素が潜んでいる。仮に、ソフトウェア提供元のWebサイトに「これが正しいMD5チェックサムです」と書かれていたとしよう（PGPキーでも同じことだ）。では、そのWebページが改ざんされていないと、だれが保証できるだろうか？ 比較の基となるデータの正当性は、いったいどうやって検証すればいいのだろう？

　残念ながら私は、この問題に対する明快な解答を持ち合わせていない。本当に正しいデータがほしいのであれば、オフラインで直接会うなどして受け渡すしかないだろう。

　反対の視点からいっても、問題は深刻だ。つまり、自分が何らかのソフトウェアやモジュールを提供している場合はどうすればいいのだろう？ どうやったら安全に、最新のものを配布するこができるだろうか？

　1つ期待できるとすれば、ユーザー同士、管理者同士の横のコミュニケーションである。日ごろから複数の情報ソースを持ち、情報交換を行っておけば、いざというときには多くの情報を照らし合わせることができ、より妥当な判断に近づけるのではないだろうか。それだけでは心もとないというのであれば、有料のセキュリティ情報サービスという手もある。

　私は冒頭で、最悪のケースも含めてさまざまな想定を行うべきだと書いたが、突き詰めて考えればこういう結論に至る。もはやどんな情報も、どんな警告も、うのみにして信用することはできない。チェックサムのような技術的な側面と、複数の情報ソースという人的な側面の両方から、あらゆる情報を検証する必要があるのかもしれない。いささか窮屈といえば窮屈なのだが……。