Windowsサーバ入門(50) 進化する脅威に対抗! IISのセキュリティ強化策(前編)

さすがに最近では言われなくなったが、過去にワームに感染する騒ぎが起きて「IISは危険!」という主張が出回ったことがあった。そうした経験が、当座のセキュリティ強化策としての「IIS Lockdown Toolの配布」、「その後のIISの改良」といった話につながっている。

現在では過去のように「IISは危ない」と吹聴する声はなくなったが、そうはいっても脅威もどんどん進化しているのが実情。そこで、IISを安全に利用するための基本的な考え方についてまとめてみた。

鉄則は本当に必要な役割サービスだけを追加すること

そもそも、過去にIISあるいはWindowsサーバで問題視されたのは、セットアップ直後の状態ですでにさまざまなサーバ機能が動作していて、しかもそれをユーザーが見過ごしがちだった点だった。

だから、Windows Server 2003からは「初期状態では必要最低限の機能だけを動作させておき、必要に応じてユーザーが明示的に追加する」という形を取り入れた。Windows Server 2008はそれをさらに深度化させて、サーバーマネージャで「役割」や「役割サービス」や「機能」を個別に追加するようにしている。

IISも、その「役割」の1つであり、IISを構成するさまざまなサーバ機能などが個別の「役割サービス」になっている。そこで自分が本当に必要とする役割サービスだけを追加するように心掛けたい。「万が一の可能性の過大評価」というやつで、「ひょっとすると使うかもしれない」はえてして「使わずに終わる」ものである。

ただし、ある役割サービスを追加した時、自動的に道連れになって追加する役割サービスが発生することがある。これは必要なものだから、生兵法で削除してしまってはいけない。

その他のセキュリティ強化策いろいろ

不要な役割サービスを省くだけでなく、IISにはさらにいろいろと安全性を高めるためのポイントがある。

IISはドメインコントローラにしない

それなりのユーザー数を持つ企業ネットワークなら、Active Directoryを導入するほうが合理的だが、外部に公開するサーバは話が別である。インターネットからアクセスできる場所にドメインコントローラを配置すると、ユーザー情報などが漏洩する原因につながる。そのため、インターネット向けに公開するサーバはドメインコントローラにしないで、スタンドアロンサーバとして運用する必要がある。

ログ保存フォルダのアクセス権を強化する:

攻撃者が侵入の証拠を消すためにログを細工する事態を防ぐため、ログを保存するフォルダのアクセス権を厳格化して、管理者以外はアクセスできないようにする方法が考えられる。具体的には、「Administrators - フルコントロール」「System - フルコントロール」の2種類とする。もっとも、管理者のユーザーアカウントが奪取されないことが前提である。

ユーザー「IUSR_」のアカウント設定 :

IISが匿名アクセスに用いるユーザーアカウント「IUSR<コンピュータ名>」を不正侵入に利用されることを防ぐため、パスワードをユーザー自身が変更できないようにする方法が考えられる。これにより、攻撃者が勝手にパスワードを変えられないようにする。また、「IUSR<コンピュータ名>」によるローカルログオンを禁止する方法も考えられる。

インターネット向けのWebサーバでは匿名接続を行う場合が大半を占めるだろうが、ユーザー認証を行うサイトで匿名接続を必要としない場合には、このユーザーアカウントは無効化することもできる。

コンテンツの配置場所変更 :

IISのコンテンツ配置場所は、既定値で「C:\InetPub」以下となっている。ということは、このローカルパスを指定すればWebコンテンツにアクセスできるということになる。

その裏をかいて、コンテンツ配置用のフォルダを別の場所に設定し直すことで、不正侵入の被害に遭った際の被害拡大を抑制できる。Webサイトで使用するデータベースやスクリプトなどを仮想ディレクトリ機能で「C:\Inetpub」以下とは異なるフォルダに配置する方法も使える。

ネットワーク設定の変更

また、ネットワーク関連設定やサービスの動作内容変更も、不正侵入に貢献できる場合がある。

Windowsサーバの初期状態では、ファイル/プリンタ共有機能は動作している。この状態で、サーバ機能はServerサービス、クライアント機能はWorkstatonサービスで動作している。さらに、共有機能が使用するプロトコル、すなわちNBT(NetBIOS over TCP/IP)とダイレクトホスティングSMBは、ネットワーク接続設定のプロパティ画面で「バインド」してある。

ところが、インターネット向けに公開するWebサーバでWindowsファイル共有を使用する必然性はないし、コンテンツのアップロードもFTPサーバ機能を使えば実現できる。しかも、FTPサーバであればIPアドレスを用いたアクセス制限を行えるので、ユーザー認証に頼るよりも確実性が高い。

それであれば、Windowsファイル共有の機能を止めて、さらにネットワーク接続設定でバインドを外すことができる。

まず、Windowsファイル共有の機能を止めるには、[サービス]管理ツールを使ってServerサービスとWorkstatoinサービスを停止させた上で、さらにスタートアップの設定を[無効]に変更する。これで、Windowsファイル共有は利用できなくなる。一方、Windowsファイル共有機能のバインドを切るには、ネットワーク接続設定のプロパティ画面で[Microsoftネットワーク用クライアント]と[Microsoftネットワーク用ファイルとプリンタ共有]のチェックをオフにする。

そこで余談をひとつ。このダイアログからTCP/IPのプロパティ画面を呼び出して、さらに[詳細設定]をクリックする。続いて表示するダイアログで、[WINS]タブに移動すると、[NetBIOS over TCP/IPを無効にする]を選択することでNBTだけを無効化して、ダイレクトホスティングSMBだけが動作する状態に設定できる。インターネット向けのサーバでは片方だけ切っても意味はなさそうだが、「こんなこともできる」ということで覚えておくと、何か役立つことがあるかも知れない。