セキュリティ組織である米SANS（System Administration, Networking, and Security）Instituteは米国時間10月1日，「The Twenty Most CriticalInternet Security Vulnerabilities」と題したリストを公開した。これは，コンピュータ・システムのぜい弱性を危険度が高い順から記述して，対策の“優先順位”を示すリストである。このリストの上位2つが，「デフォルト・インストール」と「パスワード」に関するぜい弱性である。セキュリティの話題として取り上げられることが多いこの2つについて，今回は改めて考えてみたい。

攻撃対象となる“不要な”機能

　OS やアプリケーションをインストールする際には，ウイザード（インストール作業を支援するプログラム）に従ってインストールする機能やインストール先などの情報を入力したり選択したりすることが多い。このとき，明示的に設定を変更することなく作業を進めていくと，「デフォルトの設定」でインストールすることになる。多くの場合，デフォルトの設定では不要な機能がインストールされてしまう。

　これは，ベンダーがユーザーの利便性を重視した結果と考えられるが，その結果，潜在的な攻撃対象を生み出すことになっていることに注意すべきである。不要な機能をインストールするということは，極端な話，攻撃されるためにインストールするようなものなのである。

　そして，不要な機能がインストールされているという事実を，管理者が把握していないことも問題である。管理者はウイザードに従っただけで，それらの機能を明示的にインストールしたわけではない。そのため，デフォルトで入ってしまった不要な機能の存在を知らない。当然，それらの機能についてのセキュリティ対策もされない。

　例としては，Windows NT 4.0 Option Pack に含まれる「RDSコンポーネント」が挙げられる。RDS コンポーネントには，“有名な”セキュリティ・ホールが存在する（詳細については，「[IIS]RDS，IIS，ODBC のセキュリティ」や，過去の「今週のSecurity Check [Windows編]」などを参考のこと）。Windows NT 4.0 Option Pack では，デフォルトで RDS コンポーネントがインストールされる。筆者の経験上，意図して RDS コンポーネントをインストールしているサイトは少ないように思う。多くの場合，知らない間にインストールされているのである。

　その結果，RDS のセキュリティ・ホールを悪用した攻撃を受けてしまい，管理者はその時初めて RDS コンポーネントが自分のサーバーにインストールされていることを知るのである。

　OS やアプリケーションは，何らかの目的を持ってインストールするものである。ウイザードの言いなりになって，デフォルト・インストールをしてはいけない。運用目的に応じてインストールする機能をシビアに選択し，カスタム・インストールすべきである。

　セキュリティ対策の定石として，「不要なサービスを提供しない」というものがある。このことを確実に実践するには，インストール段階から考える必要がある。つまり，「不要なサービスをインストールしない」ということである。

　確かに，インストールの段階で設定をカスタマイズすることは面倒であるし，選択できるだけの知識を持ち合わせていない場合もあるかと思う。しかし，最初にこういった手間を省いてしまうと，後々にしわ寄せがくる場合が多いものだ。たとえ使っていない機能だとしても，ぜい弱性が発見されれば攻撃対象となる危険性があるので，パッチの適用や設定の変更などに追われることになる。結果的に，余計に手間がかかってしまうのである。

ぜい弱なパスワードの危険性を認識していない

　次に，パスワードについてである。ワンタイム・パスワードをはじめとする，よりセキュアな認証方式を実現する製品が市場に多く出ているものの，ユーザー名とパスワードによる単純な認証方式を採用しているシステムは依然として多い。そして，パスワードが設定されていない，あるいは推測可能なパスワードを使っているアカウントが存在するシステムも非常に多いのが現状である。

　なぜ，ぜい弱なパスワードが存在してしまうのだろうか。この原因としては，パスワード管理に対する，個々のユーザーの意識の低さがまず挙げられる。しかし，それだけではない。管理者にも問題がある。テスト用アカウントをはじめとする不要なアカウントや，アプリケーションにデフォルトで用意されているアカウントに使われているパスワードもぜい弱である。これらが放置されている例も多い。こういったアカウントは，セキュリティ上の弱点であるので，必要がない場合は削除しなければならない。仮に必要な場合は，パスワードを変更しなければならない。

　不要なアカウントが存在する背景として，安易にアカウントを作成してしまうことが挙げられる。実際に管理作業をするのは特定のユーザーであるにもかかわらず，管理者グループの一員であるという理由だけで，作業をしないユーザーに対しても，サーバーの構築時にアカウントを作成してしまう例がよくある。

　こういったアカウントには，比較的推測容易な“仮の”パスワードが付けられる。実際に使用するアカウントならば，そのユーザーが最初にログインした際に，推測困難なパスワードに変更されるが，上記のような場合には実際には一度も使用されることがなく変更されることもない。つまり，推測容易なままでシステムに存在してしまうのである。

　また，「アプリケーションにデフォルトで存在するアカウント」が存在する。これは，インストール時に自動的に作成されてしまう。例えば，データベース・サーバーである Oracle をインストールすると，「ユーザー名 oracle」，「パスワード oracle」というアカウントが自動的に作成される。

　インターネット上には，様々な製品のデフォルト・ユーザー名とパスワードを記載した一覧表まで存在する。デフォルト・アカウントが存在することは非常に危険なことであると認識しなくてはならない。このようなデフォルト・アカウントの存在を意識していない管理者は，今すぐにでも確認することをお勧めしたい。

◇　　　　　◇　　　　　◇　　　　　◇　　　　　◇　　　　　◇

　今回挙げた2つの問題は，「定期的なバージョンアップやパッチの適用」といった継続的な対策を必要とする問題ではなく，サーバーの構築時やアプリケーションの導入時に解決してしまうべき問題である。一度サーバーの運用を始めると，その後のメンテナンスは，（1）サーバーを止められない，（2）運用に合わせて設定などが変更されたりするので，現状を正確に把握することが難しい，（3）メンテナンスの人員を確保できない---など様々な理由で，なかなかスムーズにはいかないケースが多いと考えられる。つまり，運用前に打てる手はすべて打っておくことが肝要である。そうすることで，運用後の負担を減らすことができる。

矢次　弘志 (Hiroshi Yatsugi)
株式会社ラック　不正アクセス対策事業本部
yatsugi@lac.co.jp

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