3月3日に公開されたsendmailのセキュリティ・ホールを例に出すまでもなく,OSやアプリケーション・ソフトのセキュリティ・ホールは後を絶たない。システム管理者の負担は増大する一方である。そこで記事の前半では,その負担を軽減できる方法をいくつか取り上げ,そのメリットとデメリットを考えてみたい。後半では,管理者に求められる備えについてまとめた。このコラムで既に取り上げているものばかりではあるが,改めて確認してほしい。併せて,sendmailのセキュリティ・ホールについても簡単に紹介する。

“枯れた”OS/アプリケーションを使用する

 管理者にとっては,頻繁にセキュリティ・ホールが現れることが問題なのである。現れるたびにパッチの適用や設定変更などに追われることになるからだ。そこで,既にパッチが出尽くしたと考えられる,一昔前の“枯れた”OSおよびアプリケーションでシステムを構築することが,負担を軽減する一つの方法と考えられる。このようなシステムでは,新たなセキュリティ・ホールが見つかる可能性は比較的小さい。

 しかし,デメリットもいくつかある。まず,セキュリティの観点からは,古いOS/アプリケーションのセキュリティ・ホールについては,その開発元やベンダーが対応してくれないということが挙げられる。

 セキュリティ・ホールが見つかっても,古いバージョンについては修正パッチを公開せず,バージョン・アップのみを回避方法とする場合は少なくない。そのような状況では,古いバージョンのOS/アプリケーションを使い続けることはできないだろう。

 新機能を使用できないことも,利便性の上では大きなデメリットである。例えばOSがバージョンアップされる際には,暗号化や動的コンテンツに関する新たな機能が搭載される場合がある。こういった新機能の中には,枯れたOSでは使用できない機能がある。

 枯れたOSでは,新しいハードウエアをサポートしない場合があることにも注意しなくてはならない。例えば,USBの機器を利用したくても,Windows NT では利用できない。ドライバの問題もある。OSがサポートしていても,現在使用しているOS用のドライバをメーカーが用意してくれなければ,その機器を利用できない場合がほとんどだろう。

セキュアOSを利用する

 最近セキュアであることをうたったOS,すなわち「セキュアOS」がいくつか出ている。セキュアOSを導入することで,管理者の負担を軽減できないだろうか。

 市場に出ているセキュアOSとしては,例えば,「hp secure Linux」「Trusted Solaris」などが挙げられる。

 米国家安全保障局(NSA)でもセキュリティ機能を拡張したLinux「Security-Enhanced Linux」を開発しており,FreeBSD Projectでも高信頼性のOS「TrustedBSD」を開発している。情報処理振興事業協会(IPA/ISEC)ではこれらを調査し,その結果を「オペレーティングシステムのセキュリティ機能拡張の調査」として公開している。

 “うたい文句”どおり,これらを使用すれば,OS自体はよりセキュアにできるので,OSに関する管理の負荷は軽減されるだろう。しかし,その上で動いているアプリケーションまで管理不要になるわけではない。また,セキュアOSにより,そのシステムへの侵入の危険性を減らせても,DoS攻撃などのネットワークをターゲットとした攻撃を防ぐことは当然できない。

 利便性の低下も避けられない。このようなOSでは,メモリーの使い方などが厳しく制限されているため,ユーザーが作成したアプリケーションをはじめ,そのペンダー以外が提供するソフトウエアは動作しない恐れがある。

 コストの問題もある。通常のOSより,導入や管理にコストがかかる場合がある。企業にとっては,無視できない問題だろう。

バッファ・オーバーフローを防ぐ

 3月3日に公開されたsendmailのセキュリティ・ホール同様,深刻なセキュリティ・ホールの多くはバッファ・オーバーフローが原因である。バッファ・オーバーフローを防ぐことで,今のシステムをより安全に使用することはできないだろうか。

 バッファ・オーバーフローの発生を防ぐ方法としては,OSのカーネル・オプションを変更する方法や,バッファ・オーバーフローの発生を抑えるライブラリを利用する方法などが考えられる。以前のコラム「バッファ・オーバーフローの発生を抑える方法」で紹介した通りである。新たにOSを導入することを考えれば,これらは比較的容易に実施できる。

 とはいえ,万全ではない。カーネル・オプションの変更で対処できるOSおよびハードウエアは限られているし,バッファ・オーバーフローの発生を抑えるライブラリを導入しても,防げない種類のバッファ・オーバーフローが存在する。これも以前のコラムで紹介した通りだ。

 結局これらの方法も,パッチ適用までの時間的猶予を稼ぐ方法の一つに過ぎないのである。

ソフトウエアの種類とバージョンを把握する

 以上,システムをセキュアにする方法をいくつか紹介した。それぞれのメリットとデメリットが分かっていただけただろうか。

 いずれも,管理者の負担を軽減するには有効な手段ではあるが,管理者をパッチ適用の苦労から解放するには至らない。技術だけでは解決できないのである。

 前述の手段でシステムのセキュリティを高めたとしても,セキュリティ・ホールが見つかった際には,やはり,管理者が対応しなければならないのである。そして,セキュリティ・ホールが見つかった際にあわてないようにするためには,日ごろの備えが重要になってくる。

 このコラムで何度か書いているように,まず,システムで使用されているソフトウエアの種類とそのバージョンを把握しておくことが重要である。

 例えば,sendmailのセキュリティ・ホールについても,組織内のどのシステムで,どのバージョンを稼働させているのかを把握している管理者ならば,即座に対応できただろう(関連記事)。

 今回の記事の“本筋”からは若干はずれてしまうが,重要なトピックなので,sendmailのセキュリティ・ホールについてもう少し説明しよう。今回のセキュリティ・ホールについては,修正パッチに併せて,セキュリティ・ホールを修正した最新バージョンが公開された。そのため,対応策としては以下の3つが考えられる。

(1)現在利用中のバージョンにパッチを適用する
(2) 最新版sendmail 8.12.8 にバージョン・アップする
(3)他のMTA(メール・サーバー)に乗り換える

 できるだけダウンタイムを短くしたいシステムについては(1)の対応策を採ることになるだろう。先のことを考えれば,(2)あるいは(3)の対応策も有力だ。ただし,現在 sendmail 8.11.x 以前のバージョンを使用していて,(2)のバージョン・アップを実施する場合には注意が必要である。sendmail 8.12.x からは,メールを処理するためのキューの取り扱いが変更されているため,バージョンアップに伴い,sendmail を実行するためのユーザーの追加やディレクトリ構成の修正が必要となるからだ。

 今回のセキュリティ・ホールはリモートから悪用可能な深刻なものである。セキュリティ・ホールを検証するためのツールも出回っている。しかし,現時点でのセキュリティ・ホールの解析状況(例えば,「[LSD] Technical analysis of the remote sendmail vulnerability」)を見ると,セキュリティ・ホールを悪用してシステムのroot権限を奪取するのはそれほど容易ではなさそうだ。

 とはいえ,安心はできない。これは,あくまでも現時点での状況であり,潜在的な危険性は否定できない。時間が経てば,root権限を奪取するようなツールが出回る可能性は十分にある。sendmailの管理者は,一刻も早く対応すべきである。

ライブラリの確認も不可欠

 さて,話を戻そう。種類やバージョンを把握しておく必要があるのは,サーバー・ソフトやクライアント・ソフトといったアプリケーションに限らない。ライブラリのバージョンを確認しておくことも重要だ。ライブラリにセキュリティ・ホールが見つかると,そのライブラリを利用するアプリケーションすべてが影響を受けることになるからだ。

 例えば,2003年に見つかった「OpenSSL」のセキュリティ・ホールでは,Webサーバー「Apache」をはじめ,さまざまなアプリケーションが影響を受けた(関連記事1関連記事2)。こういった事態に適切に対応するには,ライブラリのバージョンについても確認しておかなければならない。

検証用システムの準備や“インシデント訓練”も

 どのシステムで,どのアプリケーション/ライブラリが稼働しているのかを把握しておけば,適用すべきパッチなどはすぐに分かる。次に気になるのは,パッチを適用した後に不都合が起きないかどうかである。万全を期するためには,パッチを検証できる環境を準備しておきたい。

 実際のシステムと同じ構成の検証用システムを用意して,そのシステムに対してまずパッチを適用する。そうすることにより,適用手順やパッチに不備があっても事前に確認できる。

 また,いくら対策を施しても,セキュリティに万全はない。このコラムで繰り返し解説している通りだ。万が一の事態,すなわち,インシデントが発生した際の備えも重要である。ぜひ,「セキュリティ・インシデント訓練」を実施しておきたい

 バックアップからの復旧作業といったシステムの対応にとどまらず,対外的な対応についても事前に考えておきたい。このコラムでは過去に「信頼を得るための,企業のセキュリティ・ホール対応」「『セキュリティ・ホールを指摘された』――その時企業はどうするべきか 」といった記事を公開しているので,ぜひ参考にしていただきたい。


阿部正道 (ABE Masamichi) masamichi.abe@lac.co.jp
株式会社ラック JSOC事業本部


 IT Proセキュリティ・サイトが提供する「今週のSecurity Check [一般編]」は,その週に起きたUNIX関連およびセキュリティ全般のニュースや動向をまとめた週刊コラムです。セキュリティ・ベンダーである「株式会社ラック」のスタッフの方を執筆陣に迎え,専門家の立場から解説していただきます。