「システムのセキュリティ・レベルを維持するには,絶えず最新のセキュリティ・ホール情報を入手し,適切に対策を施す必要がある」――。このコラムで繰り返し述べていることだ。ただし,言うほど容易なことではない。適切に対応できていない管理者は少なくないだろう。そこで今回の記事では,見落としがちなポイントを2つ紹介したい。

 まず,自分が管理するシステムを,日ごろから把握しておくことが挙げられる。さもないと,公開されたセキュリティ・ホールがシステムに影響をおよぼすかどうかを判断できない。もう一点が,セキュリティ・ホールの影響を過小評価しないことである。「自分のシステムは攻撃されない」などと勝手に考えて対策を怠ると,取り返しのつかない事態を招きかねない。

稼働しているアプリケーションを把握する

 まずは,自分が管理するシステム(コンピュータ)で稼働しているアプリケーションを,日ごろから把握しておく必要がある。さもないと,セキュリティ・ホール情報が公開された際に,そのセキュリティ・ホールが自システムに影響を与えるかどうか判断できない。

 容易に思えるが,実はこれが難しいのである。というのも,現在のOSのパッケージにはさまざまなアプリケーションが同梱されているからだ。インストールの際の設定にもよるが,知らないうちに起動されているアプリケーションは少なくない。

 Webサーバーの管理者ならば,例えば Apache HTTP Serverのセキュリティ・ホール情報を目にすれば,即座に“反応”するだろう。同様に,メール・サーバーの管理者ならばSendmail,DNSサーバー管理者ならば ISC BINDの情報に自然と反応するはずだ。これらのアプリケーションは,管理者が意識して稼働させているからである。

 しかし,意識して稼働させていないアプリケーションについてはどうだろうか。例えば,以下の4種類のアプリケーション(サービス)のセキュリティ・ホール情報を目にしたとき,自分が運用しているシステムに関係があるかどうか即座に分かるだろうか。

  1. X Font Service (XFS)
  2. Cache File System (CacheFS)
  3. Common UNIX Printing System (CUPS)
  4. libpng
1 および 2 は Sun Solaris,3 および 4 は Red Hat Linux に同梱されているアプリケーションあるいはライブラリである。これらのいずれにも,リモートから攻撃可能なセキュリティ・ホールが過去に見つかっている。セキュリティ情報の“タイトル”だけ見て,「自分のシステムには関係ない」と早合点して放置しておくと,深刻な事態を招く恐れがある。

 普段は直接触れることのないアプリケーションにも,セキュリティ・ホールは潜んでいる。そういったアプリケーションに関するセキュリティ情報を見落とすことがないように,自システムで稼働しているアプリケーションの種類およびそのバージョン情報をきちんと把握しておく必要があるのだ。これは,管理者の“義務”であると考えてほしい。

 「稼働しているアプリケーションをすべて把握することなんて無理だ」という管理者は,もう一度確認してほしい。そのようなシステムでは,必ずといっていいほど不要なアプリケーションが稼働している。不要なセキュリティ・ホールを抱え込まないため,管理者がアプリケーションの種類やバージョンを把握できるようにするために,不要なアプリケーションはすべて停止しておくことが重要である。

リスク分析は甘すぎず

 システムで稼働しているアプリケーションを把握していれば,公開されたセキュリティ・ホールの影響を受けるかどうかを適切に判断できるだろう。

 もし影響を受けるようなら,公開されている情報などを基に,影響の程度とその対策を調べる必要がある。対策は一つではない場合がほとんどである。多くの場合,「パッチの適用あるいはバージョンアップ」,「設定変更」,「アプリケーションの停止」――など,複数の選択肢がある。自システムに対する影響(リスク)の大きさを考えて,適切な対策を選択することになる。これが「リスク分析」である。ここで注意しなければならないのは,「リスク分析を甘くしない」ことである。

 まだ攻撃を受けていないために見えにくい脅威と,サーバーを止めてパッチを適用するデメリットを天秤にかけた結果,後者が勝ってしまう場合も少なからずあるのではないだろうか。その結果,「セキュリティ・ホールが公開されたからといって,自分が運用しているシステムがすぐに影響を受けるわけではないだろう」という“勝手な”根拠に基づいて,「対策しない」という対策を選択するケースは少なくないようだ。

 しかし,これは大きな間違いである。

 放置したセキュリティ・ホールを攻撃された場合を想定してほしい。例えばそれが DoS(サービス妨害)攻撃であれば,パッチを適用するために必要な時間以上,サーバーを停止させられることになる。

 加えて,予想外のサービス停止により,顧客(ユーザー)の信頼を失うことになるし,サービス再開のために余計な工数を必要とするだろう。

 管理者権限が奪取された場合には,顧客情報の漏えいや情報の改ざんなども発生しうるので,その損害は計り知れないものとなる。

 対策を施すのは管理者自身であるため,リスクをできるだけ低く見積もって,できるだけ安易な対策を選択してしまうことは心情的には分からなくもない。しかし,最悪の事態が発生した場合,その火の粉はそのまま管理者に降り注ぐ。自分が運用するシステムに関係するセキュリティ・ホールが見つかった場合には,そのリスクを“適切”に評価し,早急に対策を施す必要があるのだ。


石山和行 (ISHIYAMA Kazuyuki) kazuyuki.ishiyama@lac.co.jp
株式会社ラック セキュアネットサービス事業本部


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