マイクロソフトの Securing Windows 2000 Server ソリューション

トピック

	監査
	侵入とセキュリティ イベントの監視
	まとめ

いかに安全な環境であっても、積極的に侵入と攻撃に対する監視を行う必要があります。安全のためのシステムを設置しても、攻撃されることはないだろうと決め込んで監査を行なわないとしたら、正反対の結果が生じてしまいます。

次のような理由から、侵入の監視と監査を行うことは非常に重要です。

この章では、お使いの環境での攻撃の発見や追跡の可能性が最も高くなる監査方法について説明します。また、攻撃が生じていることを示す動作を特定するために特に設計されたソフトウェアである侵入探知システムの使用など、侵入の監視方法についても調べます。

監査

セキュリティ戦略全体の一部として、お使いの環境に適した監査のレベルを決定してください。監査は、成功と不成功とを問わず、リスク評価において重要と判断された、ネットワークやリソースに危険をもたらす攻撃を識別できるものでなければなりません。

どの程度の監査を行うかを決定する際には、多くの監査を行って多くのイベントを生成するほど、重要なイベントの特定が難しくなるという点を念頭に置いておきます。広範な監査を行う場合には、より重要なイベントを見分ける助けとして、Microsoftｮ Operations Manager (MOM) のような付加のツールを使用することを十分に考慮する必要があります。

監査イベントは、成功イベントと失敗イベントの 2 種類に分類できます。成功イベントは、ユーザーがリソースへのアクセス権を獲得できたこと、失敗イベントはそれに失敗したことを示します。

失敗イベントは、環境に対して試みられた攻撃を追跡する上で非常に役立ちますが、成功イベントは解釈がずっと困難です。成功した監査イベントの大多数は、単に通常の活動を示しているに過ぎませんが、攻撃者がシステムへのアクセスを取得できた場合にも成功イベントが生成されます。多くの場合、イベントのパターンは、イベント自体と同じほど重要です。たとえば、一連の失敗の後に成功が続いた場合、攻撃の試みが最後に成功したことを示している可能性があります。

できる限りにおいて、監査イベントとユーザーに関する他の情報とを組み合わせます。たとえば、ユーザーが休暇で不在にする場合、その間アカウントを無効にしておき、再度有効にしたときに監査を行うようにします。

監査を有効にするには

監査は、グループ ポリシーを使用して、サイト、ドメイン、OU (組織単位)、またはローカル コンピュータのレベルで有効にします。監査ポリシーの設定は、次の場所にあります。

コンピュータの構成\Windows の設定\セキュリティの設定\ローカル ポリシー\監査ポリシー

監査は一般に、Microsoftｮ Active Directoryｮ ディレクトリ サービス階層内の高いレベルで実行すべきです。そうすれば、監査設定の一貫性を保ちやすくなるからです。Contoso では、メンバ サーバーとドメイン コントローラ OU レベルの両方で監査を実行しました。詳細については、第 6 章 「Base Windows 2000 Server のハードニング」を参照してください。

ドメインから切り離したサーバーがあるかもしれません。これらのコンピュータでの監査は、ローカル コンピュータのグループ ポリシーを編集するか、または「Windows 2000 Server リソースキット」の Auditpol.exe ユーティリィティを使用して構成できます。

注 ローカル コンピュータのグループ ポリシーにアクセスするには、Microsoft 管理コンソール (MMC) を起動してから、グループ ポリシー スナップインを追加します。[ローカル コンピュータ ポリシー] を選択してください。

イベント ログ設定の定義

監査により生成されたイベントはすべて、イベント ビューアに表示されます。生成されたイベントをイベント ログにどう保存するかは決めておかなければなりません。それぞれの設定は、イベント ビューアで直接、またはグループ ポリシーで定義できます。このガイドでは、イベント ビューアの設定をグループ ポリシーで定義しています。推奨設定についての詳細は、第 6 章 「Base Windows 2000 Server のハードニング」を参照してください。

グループ ポリシーからイベント ビューアの設定を削除した場合には、代りにイベント ビューアで直接定義できます。ただし、同様のコンピュータ全体で一貫した設定を行うために、グループ ポリシーでイベント ビューアの設定を定義することが推奨されています。

Contoso の環境では、グループ ポリシーは、セキュリティ ログが容量の限界に達した場合でも、組織内のシステムをシャットダウンするように構成されてはいません。その代わり、システムは、必要に応じてイベント ログを上書きするよう構成されています。

監査するイベント

Microsoftｮ Windowsｮ 2000 は、セキュリティ イベントに関していくつかのカテゴリの監査を提供しています。エンタープライズ レベルの監査戦略を設計する際には、セキュリティ監査イベントとして、次のカテゴリを含めるかどうかを決定してください。

次のセクションでは、特定のカテゴリについて監査を有効にした場合に返される、一般的なイベント ID のいくつかを詳しく説明します。

注 イベント ログ情報の検索と収集のために使用するツールについては、後述の「受動的な検知方法」の章で説明します。

ログオン イベント

ログオン イベントを監査する場合、ユーザーがコンピュータにログオンまたはログオフするたびに、ログオンを行ったコンピュータのセキュリティ ログにイベントが記録されます。また、ユーザーがリモート サーバーに接続すると、リモート サーバーのセキュリティ ログにログオン イベントが記録されます。ログオン イベントは、ログオン セッションとトークンが作成または破棄されるたびに作成されます。

ログオン イベントは、サーバーへの対話的なログオンの試みを追跡する、または特定のコンピュータから開始された攻撃を調査するのに役立ちます。ログオンが成功すると、成功の監査が監査エントリを生成し、ログオンが失敗すると、失敗の監査が監査エントリを生成します。

注 ログオン イベントには、コンピュータ ログオンとユーザー ログオンの両方のイベントが含まれます。Microsoftｮ Windows NT&reg または Windows 2000 ベースのコンピュータからネットワーク接続を試行した場合には、コンピュータ アカウントとユーザー アカウントの両方について、別々のセキュリティ イベント ログ エントリが記録されます。Windows 9x ベースのコンピュータは、ディレクトリ内にコンピュータ アカウントを持たないので、ネットワーク ログオン イベントでコンピュータ ログオン イベントエントリを生成しません。

メンバ サーバーおよびドメイン コントローラのベースライン ポリシーの一部として、成功および失敗のログオン イベントの監査が有効になっています。そのため、対話型のログオン、およびターミナル サービスを実行しているコンピュータに接続するターミナル サービス ログオンでは、次のイベント ID が記録されることになります。

表 9.1 セキュリティ イベント ログに記録されるログオン イベント

以下のセキュリティ イベントは、ログオン イベント エントリを使用して診断できます。

Contoso では、多数のログオン試行の失敗と、多数のアカウント ロックアウトを監視しています。ユーザーが正当な理由に基づいてターミナル サービス セッションを切断したままにしておく場合のある環境では珍しいことではありません。

アカウント ログオン イベント

ユーザーがドメインにログオンした場合、ログオンはドメイン コントローラで処理されます。ドメイン コントローラでアカウント ログオンのイベントを監査すれば、このログオンの試行がアカウントを検証するドメイン コントローラに記録されます。アカウント ログオン イベントは、認証パッケージがユーザーの資格情報を検証したときに記録されます。ドメインの資格情報を使用した場合には、アカウント ログオン イベントは、ドメイン コントローラのイベント ログにのみ記録されます。提示された資格情報がローカルの Security Accounts Manager (SAM) データベースの資格情報である場合は、アカウント ログオン イベントはサーバーのセキュリティ イベント ログに記録されます。

アカウント ログオン イベントは、ドメイン内の有効なドメイン コントローラのどれにでも記録される可能性があるので、ドメイン コントローラ全体のセキュリティ ログを統合して、ドメインのアカウント ログオン イベントをすべて分析できるようにしなければなりません。

注 ログオン イベントの場合と同様に、アカウント ログオン イベントには、コンピュータ ログオンとユーザー ログオンの両方のイベントが含まれます。

メンバ サーバーおよびドメイン コントローラのベースライン ポリシーの一部として、成功および失敗のアカウント ログオン イベントの監査が有効になっています。そのため、ネットワーク ログオンおよびターミナル サービス認証では、次のイベント ID が記録されることになります。

表 9.2 イベント ログに記録されるアカウント ログオン イベント

これらのイベントごとに、それぞれのログオン固有の詳細情報がイベント ログに記録されます。次のセキュリティ イベントは、アカウント ログオン イベント エントリを使用して診断できます。

Contoso は現在、かなり多くのドメイン ログオン試行の失敗を監視しています。環境からすると、他のイベントは該当しません。これらの設定を構成する際、最良のアプローチは比較的厳しい設定から開始し、間違った警報の数が減少するまでそれを緩めていくことであると判断しました。現在、10 分以内に生じた 10 回のログイン失敗のケースをすべて監視しています。これらの数値は環境ごとに異なるでしょう。

アカウント管理

アカウント管理の監査は、ユーザーやグループがいつ作成、変更、または削除されたかを記録するために使用されます。この監査は、セキュリティ プリンシパルがいつ作成されたか、また誰がそのタスクを実行したかを記録するために使用することができます。

メンバ サーバーおよびドメイン コントローラのベースライン ポリシーの一部として、成功および失敗のアカウント管理の監査が有効になっています。そのため、セキュリティ ログには、次のイベント ID が記録されることになります。

表 9.3 イベント ログに記録されるアカウント管理イベント

以下のアカウント管理イベントは、セキュリティ ログ エントリを使用して診断できます。

Contoso はかなり大きな企業なので、毎日相当な数のアカウント メンテナンスが行われます。これらのイベントすべてを監視するとすれば、あまりにも多くの警告が生じるため、環境内で適切に対処することはできないでしょう。

オブジェクト アクセス

Windows 2000 ベースのネットワーク上にあるすべてのオブジェクトに対する監査は、システム アクセス制御リスト (SACL) を使用して有効にできます。SACL にはオブジェクト操作を行った場合に監査の対象とするユーザーおよびグループのリストが含まれます。Windows 2000 でユーザーが操作できるほとんどすべてのオブジェクトが SACL を持っています。これには NTFS ファイル システム ドライブ上のファイルとフォルダ、プリンタ、およびレジストリ キーが含まれます。

SACL はアクセス制御エントリ (ACE) から構成されます。各 ACE には以下の 3 つの情報が含まれています。

セキュリティ ログにイベントを記録するには、[オブジェクト アクセスの監査] を有効にしてから、監査するオブジェクトごとに SACL を定義します。

Windows 2000 での監査は、オブジェクトへのハンドルが開かれた時点で生成されます。Windows 2000 はプログラムがカーネル経由でのみオブジェクトにアクセスできるカーネルモード セキュリティ サブシステムを使用しています。これにより、プログラムがセキュリティ システムをバイパスできないようにします。カーネルのメモリ空間はユーザー モードのプログラムから分離されているため、プログラムはハンドルと呼ばれるデータ構造を通してオブジェクトを参照します。典型的なアクセス試行は次のように行われます。

監査が行われイベントが生成されただけでは、オブジェクトにはまだ何も行われていないことに注意してください。これは、監査イベントを解釈する場合に重要です。書き込み監査はファイルへの書き込みが行われる前に、読み取り監査はファイルの読み取りが行われる前に発生します。

すべての監査と同様、オブジェクト アクセスの監査では対象をしぼることが非常に重要です。監査の計画では、監査するオブジェクトの種類を決定してから、監査対象のオブジェクトの種類ごとに監視するアクセス試行の種類 (成功、失敗、または両方) を決定します。監査の範囲を広げすぎると、システムのパフォーマンスが悪化するとともに、必要以上、または利用できる以上の大量のデータを収集してしまうことになります。

一般には、信頼されていないアカウントからのアクセスを含め、選択したオブジェクトに対するすべてのアクセスの監査を行うものと考えられます。そのためには、監査するオブジェクトの SACL に Everyone グループを追加します。セキュリティ ログに大量の監査エントリが生成されるため、オブジェクト アクセスの成功の監査には十分注意してください。ただし、たとえば重要なファイルの削除を調査する場合には、成功監査イベントを調べてどのユーザー アカウントがファイルを削除したのかを判別する必要があります。

メンバ サーバーおよびドメイン コントローラのベースライン ポリシーでは、オブジェクト アクセスの成功と失敗の両方を監査するように設定されています。しかし、オブジェクト自体に SACL が設定されていない場合には、お使いの環境での必要に応じて SACL を設定する必要があります。SACL は、オブジェクトに直接定義することもできますし、グループ ポリシーを使用して定義することもできます。監査が必要なオブジェクトが複数のコンピュータ上に存在する場合は、グループ ポリシーで SACL を定義してください。

オブジェクト アクセスの監査では以下のイベントがセキュリティ ログに記録されます。

表 9.4 イベント ログに記録されるオブジェクト アクセス イベント

特定のオブジェクト アクセス イベントを探す場合には、まずイベント ID 560 のイベントを調べます。イベントの詳細には有用な情報が含まれているので、特定のイベントを見つけるにはイベントの詳細を検索することが必要になります。次の表は、実行すべき操作とその実行方法を示しています。

表 9.5 オブジェクト アクセス イベント 560 に関連する主な監査操作の実行方法

Contoso ではすべてのオブジェクト アクセス イベントを監視しているわけではありませんが、一部のファイルのオブジェクト アクセスを監査しています。この情報は、セキュリティ上の問題に対応する際に非常に有用なものとなり得ます。

ディレクトリ サービス アクセス

Active Directory オブジェクトは、SACL が関連付けられているので、監査することができます。前に述べたように、Active Directory のユーザー アカウントとグループ アカウントの監査は、アカウント管理を監査することで行います。ただし、構成やスキーマの名前付けコンテキストなど、他の名前付けコンテキストにあるオブジェクトの変更を監査する場合は、オブジェクト アクセスを監査してから、監査する特定のコンテナに SACL を定義する必要があります。Active Directory オブジェクトの SACL に列挙されているユーザーがそのオブジェクトへのアクセスを試行すると、監査エントリが生成されます。

構成名前付けコンテキスト (および他の名前付けコンテキスト) 内のコンテナとオブジェクトの SACL は、ADSIEDIT MMC スナップインを使用して変更できます。この変更は、ADSIEDIT コンソールに必要なコンテキストを表示してから、[セキュリティの詳細設定] ダイアログ ボックスでオブジェクトの SACL を変更することで行います。

ディレクトリ サービス アクセスのイベントは大量に発生するため (そのほとんどは無害なものです)、その中から特定のイベントを発見することは非常に困難です。この理由で、メンバ サーバーおよびドメイン コントローラのベースライン ポリシーでは、ディレクトリ サービス アクセスの失敗イベントのみを監査するようになっています。このことは、攻撃者が Active Directory へ不正にアクセスしたことを識別するのに役立ちます。

ディレクトリ アクセスの試行は、イベント ID 565 のディレクトリ サービス イベントとしてセキュリティ ログに記録されます。どのオブジェクトにイベントが対応しているのかを判断するには、セキュリティ イベントの詳細を調べなければなりません。

Contoso では、すべてのディレクトリ サービス アクセス イベントを監視しているわけではありませんが、一部のファイルのオブジェクト アクセスを監査しています。この情報は、セキュリティ上の問題に対応する際、非常に有用なものとなり得ます。

特権の使用

ユーザーは IT 環境で作業する際に、定義されたユーザー権利を行使します。特権使用の成功と失敗を監査すると、ユーザーがユーザー権利を行使しようとするたびにイベントが生成されます。

特権の使用を監査しても、すべてのユーザー権利が監査されるわけではありません。既定では、次のユーザー権利が除外されます。

バックアップと復元のユーザー権利を監査しないという既定の設定は、グループ ポリシーの [バックアップと復元の特権の使用を監査する] セキュリティ オプションを有効にすることで変更できます。

特権使用の成功を監査すると、セキュリティ ログに非常に多くのエントリが記録されるため、メンバ サーバーおよびドメイン コントローラのベースライン ポリシーでは、特権使用の失敗イベントのみを監査するようになっています。

特権使用の監査を有効にすると、次のイベントが記録されます。

表 9.6 イベント ログに記録される特権使用イベント

Contoso では、リモート システムからの通常のシャットダウンや強制的なシャットダウンを示す、また、監査ログやセキュリティ ログが変更されたことを示す、すべてのイベントを監視しています。

プロセスの追跡

Windows 2000 ベースのコンピュータ上で実行されているプロセスの詳細な追跡情報を監査する場合、プロセスを作成および終了しようとすると、イベント ログに記録されます。また、プロセスがオブジェクトへのハンドルを生成しようとした場合、またはオブジェクトへの間接アクセスを取得しようとした場合にもイベント ログに記録されます。

作成される監査エントリが非常に大量になるため、メンバ サーバーおよびドメイン コントローラのベースライン ポリシーではプロセス追跡の監査は有効になっていません。しかし、成功と失敗の監査を選択すると、次のイベント ID がイベント ログに記録されます。

表 9.7 イベント ログに記録されるプロセス追跡イベント

Contoso では、プロセス追跡イベントを監視してはおらず、どのサーバー ポリシーでも有効にしていません。

システム イベント

システム イベントは、ユーザーまたはプロセスがコンピュータ環境の状態を変更した場合に生成されます。コンピュータのシャットダウン、システム時刻の変更など、システムに対する変更の試行を監査できます。

システム イベントを監査する場合は、セキュリティ ログの消去も監査してください。攻撃者が環境に変更を加えた場合、その証拠を消そうとすることが多いため、この点は非常に重要です。

メンバ サーバーおよびドメイン コントローラのベースライン ポリシーでは、システム イベントの成功と失敗を監査するようになっています。この場合、次のイベント ID がイベント ログに記録されます。

表 9.8 イベント ログに記録されるシステム イベント

これらのイベント ID を使用すると、次のようなセキュリティ問題の発生を把握できます。

Contoso では、コンピュータのシャットダウンや再起動、およびセキュリティ ログの消去の両方を監視しています。

ポリシーの変更

監査ポリシーでは、環境のどのような変更を監査するかを定義して、環境に対する攻撃が行われたかどうかを判断するために役立てます。しかし、悪質な攻撃者は、自分たちが加える変更が監査されないように、監査ポリシーそのものを変更することを試みます。

ポリシーの変更を監査すれば、他のポリシーやユーザー権利の変更と共に監査ポリシーの変更も見つけられます。メンバ サーバーおよびドメイン コントローラのベースライン ポリシーでは、監査ポリシー変更の成功と失敗を監査します。次のイベントがイベント ログに記録されます。

表 9.9 イベント ログに記録されるポリシー変更イベント

ここで探す必要のある最も重要な 2 つのイベントは、イベント ID 608 と 609 です。攻撃を何度も試みると、これらのイベントが記録されます。次の例ではいずれも、ユーザー権利が割り当てられる場合にはイベント ID 608 が、削除される場合には 609 が生成されます。いずれの場合も、イベントの詳細には、ユーザー権利が割り当てられた特定の SID、およびその権利を割り当てたセキュリティ プリンシパルのユーザー名が含まれます。

注 これらの監査イベントは、ユーザー権利が特定のセキュリティ プリンシパルに割り当てられていることを特定するだけです。セキュリティ プリンシパルがユーザー権利を使用してタスクを実行したことを意味するものではありません。監査イベントでは、ユーザー権利ポリシーが変更された日時を判断できます。

Contoso では現在、ポリシー変更イベントを監視していません。これらのイベントは、トラブルシューティングや問題への対応のために使用できます。

ポリシー変更イベントの監視は非常に困難で、多数の間違った警告が発生します。これは主に、グループ ポリシー編集用の MMC スナップインである gpedit.msc が常にポリシーの読み取りおよび書き込みの両方の特権で開くからです。後述のようにポリシーが変更されていない場合でも、ドメイン コントローラのセキュリティ ログにはイベント 578 が書き込まれます。

Windows Server 2003 の出荷直後に無償のダウンロードとしてリリースが予定されているグループ ポリシー管理コンソールでは、権限のあるユーザーは gpedit.msc で開かなくてもグループ ポリシー設定を表示できるようになり、このような問題の解決に役立つでしょう。

イベント ログの保護

将来の参照用にイベント ログ エントリを確実に維持するには、以下を含むいくつかのステップに従ってイベント ログのセキュリティを保護する必要があります。

Contoso では、メンバ サーバーとドメイン コントローラのグループ ポリシー オブジェクトで、これらの設定を実装しました。これらの設定についての詳細は、第 6 章 「Base Windows 2000 Server のハードニング」と第 7 章 「特定サーバーの役割のハードニング」を参照してください。

イベント ログ情報を可能な限り保護するために、これらのステップに加えて以下のような実際的な手段を実行してください。

注 イベント ログへのゲスト アクセスを禁止しても、ドメイン以外のメンバの、イベント ログへのアクセスを制限することにしかなりません。既定では、ドメインのすべてのユーザーは、システム ログとアプリケーション ログにアクセスできます。制限されているのは、セキュリティ ログへのアクセスだけです。[監査とセキュリティ ログの管理] のユーザー権利が割り当てられているセキュリティ プリンシパルは、セキュリティ ログにアクセスできます。既定では、この権限は、Administrators と Exchange Enterprise Servers にのみ割り当てられています。

監査に関するその他のベスト プラクティス

監査の構成のほかに、サーバー環境のセキュリティを効果的に監査するためには以下のような作業を実行しておく必要があります。

イベント ログを定期的に確認するようスケジュールを立てる

前述のように、セキュリティ ログや、可能であればイベント ログも、確認を行うためにリムーバブル メディアに記録するか、1 か所にまとめる必要があります。これらのログの確認は、監査のステップの中でも最も見落とされることの多いものです。

Contoso では、1 人の個人またはチームが定期的なタスクとしてイベント ログを確認する責任を負うように取り決めるという、大規模な作業を完了しました。このようなイベント ログの確認は、セキュリティ ログに集められるデータの量に応じて、毎日、または毎週行うように予定できます。これは通常、ネットワーク上に実装された監査のレベルに基づいて決めます。監査に含められたイベントが多いほど、ログ エントリの量は大きくなります。イベント ログを定期的に確認するようにスケジュールを立てれば、以下の事柄を達成するのに役立ちます。

他のアプリケーションのログ ファイルも確認する

Windows 2000 イベント ログでセキュリティ イベントを確認することに加えて、各アプリケーションが作成したログも確認してください。アプリケーションのログには攻撃の可能性についての重要な情報が含まれている場合があります。これはイベント ログに記録された情報を補完するものとなります。使用環境に応じて異なりますが、次のようなログ ファイルもチェックする必要があります。

注 ログ ファイルを記録するすべてのコンピュータでは、システム時刻を同期させる必要があります。これにより、管理者は各コンピュータとサービスのイベントを比較できるので、攻撃者がどのような操作を行ったのかを明確にすることが可能になります。時刻同期の詳細については、この章の「時刻同期の重要性」を参照してください。

インストールされているサービスとドライバを監視する

コンピュータに対する攻撃の多くは、ターゲット コンピュータにインストールされているサービスを攻撃するか、正しいドライバを攻撃者がターゲット コンピュータにアクセスできるようにする、トロイの木馬の機能を含むドライバで置き換えることで行われます。

コンピュータにインストールされているサービスやドライバを監視するには、次のツールを使用できます。

注 必ずしもすべてのサービスを直接停止できるわけではありませんが、照会することはできます (ワークステーション サービスなど)。ユーザーが使用しているアクティブな接続が多い場合には、リモートでサービスを強制的に停止することはできませんが、そのサービスの一時停止と照会は行えます。あるサービスは、他のサービスから依存されています。このようなサービスの停止は、そのサービスに依存しているサービスを先に停止しないと失敗します。

開いているポートを監視する

攻撃は多くの場合、ターゲット コンピュータで実行中の既知のサービスを特定するポート スキャンを実行することから始まります。そのため、サーバー上でどのポートが開かれているのかを注意深く監視する必要があります。この監視は通常、アクセス可能な対象を判断するために、自分自身でポートをスキャンすることを意味します。

ポート スキャンを実行する際には、ターゲット コンピュータ上でのローカルのスキャンと、リモート コンピュータからのスキャンの両方を実行する必要があります。コンピュータが公共のネットワークからアクセス可能な場合には、使用しているファイアウォール ソフトウェアが目的のポートへのアクセスだけを許可していることを確認するために、ポート スキャンを外部コンピュータから実行する必要があります。

Netstat.exe は、TCP (Transmission Control Protocol) と UDP (User Datagram Protocol) の両方の開かれたポートをすべて表示する、コマンド ライン ユーティリティです。Netstat コマンドでは、次の構文を使用します。

NETSTAT [-a] [-e] [-n] [-s] [-p proto] [-r] [interval]

ここで、各スイッチは次のことを示します。

ローカル コンピュータで開かれた TCP と UDP ポートを一覧表示すると、ポート番号は、\%WinDir%\System32\Drivers\Etc フォルダにある services ファイルのエントリに基づいて名前に変換されます。ポート番号だけを表示するには、-n スイッチを使用します。

開かれたポートで認識できないものがある場合は、これらのポートを調査し、ポートに対応するサービスがそのコンピュータ上で必要かどうかを判断してください。不要な場合には、そのサービスを無効にするか削除し、コンピュータがそのポートをリッスンしないようにします。このガイドに含まれているメンバ サーバーおよびドメイン コントローラのベースライン ポリシーでは、数多くのサービスが無効にされています。

多くのサーバーは、ファイアウォール、つまりパケット フィルタリング ルーターによって保護されているので、リモート コンピュータからもポート スキャンを実行することを推奨します。多くのサードパーティが、フリーウェアも含めて、リモート ポート スキャンを実行できるツールを提供しています。リモート ポート スキャンを実行すると、外部ユーザーがコンピュータへの接続を試みた場合にどのポートが利用可能なのかが明らかになります。

注 ポート スキャンは、使用している侵入検知システムで、ポート スキャンが実行されていることを確実に検知できるかどうかのテストにも使用することができます。侵入検知システムの詳細については、この章の「能動的な検知方法」を参照してください。

ページのトップへ

侵入とセキュリティ イベントの監視

侵入とセキュリティ イベントの監視には、受動的なタスクと能動的なタスクの両方が含まれます。侵入の多くは、攻撃が発生した後に、ログ ファイルの調査によって検知されます。このような攻撃後の検知は、しばしば受動的な侵入検知と呼ばれます。ログ情報に基づく、攻撃の確認と再構成は、ログ ファイルの調査を通してのみ行えます。

これ以外に、攻撃の発生時に侵入試行を検知可能な場合もあります。この方法は能動的な侵入検知と呼ばれており、既知の攻撃パターンやコマンドを探して、コマンドの実行を阻止します。

ここでは、ネットワークを攻撃から保護する、これら 2 種類の侵入検知方法の両方を実装するために使用できる手段について説明します。

時刻同期の重要性

複数のコンピュータで侵入とセキュリティ イベントの両方を監視する場合には、各コンピュータの時刻が同期していることが不可欠です。時刻が同期していれば、管理者は、複数のコンピュータに対する攻撃中に何が発生したのかを再構成できます。時刻が同期していないと、特定のイベントの発生時刻と、それらのイベントの関連性を正確に判断することは非常に難しくなります。時刻同期の詳細については、第 5 章 「ドメイン インフラストラクチャをセキュリティで保護する」を参照してください。

受動的な検知方法

受動的な侵入検知システムには、イベント ログとアプリケーション ログを手作業で確認することが含まれます。この調査では、イベント ログ データに記録された攻撃パターンの分析と検知を行います。イベント ログの確認に役立つツール、ユーティリティ、およびアプリケーションがいくつかあります。ここでは、情報を整理するための各ツールの使用方法について、その概要を説明します。

イベント ビューア

Windows 2000 のセキュリティ ログは、Windows 2000 イベント ビューア MMC コンソールを使用して確認できます。イベント ビューアを使用して、アプリケーション、セキュリティ、およびシステム ログを表示できます。特定のイベントを検索するには、イベント ビューアでフィルタを定義します。

イベント ビューアでフィルタを定義するには

[プロパティ] ダイアログ ボックスの [フィルタ] タブでは、イベント エントリをフィルタするための次の属性を定義できます。

指定したフィルタを適用したら、フィルタされたイベントの一覧をデータベース アプリケーションでインポートできるようにカンマ区切りまたはタブ区切りのデータとしてファイルにエクスポートすることができます。

前述のように、Contoso には管理上の役割ごとに、イベント ログの調査の責任を負う複数の担当者がいます。彼らは責任の一環として、監視システムが記録しなかったセキュリティ関連のイベントがないかどうか、毎日ログを確認します。

Dump Event Log ツール (Dumpel.exe)

Dump Event Log はコマンド ライン ツールで、『Windows 2000 Server Resource Kit, Supplement One』 (Microsoft Press、ISBN : 0-7356-1279-X) に含まれています。このダンプ ツールは、ローカルまたはリモート システムのイベント ログをタブ区切りデータのテキスト ファイルとしてダンプします。ダンプしたファイルは、スプレッドシートやデータベースにインポートして調査できます。このツールは、特定のイベントの種類をフィルタで取り出すため、または除外するために使用することもできます。

dumpel.exe ツールでは次の構文を使用します。

dumpel -f file [-s \\server] [-l log [-m source]] [-e n1 n2 n3...] [-r]
[-t] [-d x]

ここで、各スイッチは次のことを示します。

注 Dumpel がレコードを検索できるのは、システム、アプリケーション、またはセキュリティ ログ ファイルに限られています。ファイル複製サービス、DNS、またはディレクトリ サービスのイベント ログからレコードを検索するのに Dumpel を使用することはできません。

EventCombMT

EventCombMT はマルチスレッド ツールで、複数のサーバーのイベント ログを同時に解析し、検索条件に含まれるサーバーごとに、別の実行スレッドを生成します。このツールを使用すると、以下の操作を行えます。

ツールのインストール

ツールをインストールするには、このガイドに付属する自己展開型ファイル SecWin2k.exe の内容を展開します。C:\SCI\scripts\EventComb フォルダが作成されます。ファイルを展開したら、EventCombMT.exe ファイルをダブルクリックして EventCombMT ツールを実行します。

EventComb ツールの実行

EventComb ツールを使用するための最初のステップは、イベント ログ検索に含めるコンピュータを定義することです。

コンピュータを検索対象に追加するには

1.	EventCombMT ユーティリティで、正しいドメインがドメイン名のボックスに自動検知されていることを確認します。別のドメインのイベント ログを検索するには、[Domain] ボックスにそのドメイン名を入力します。
2.	検索一覧にコンピュータを追加するには、[Select to Search/Right Click to Add] ボックスを右クリックします。次の図のように、ポップアップ メニューが表示されます。 図 9.1: EventCombMT のダイアログ ボックス設定を使用して、自動検知されなかったコンピュータを検索一覧に追加する 拡大表示する 使用できるオプションは次のとおりです。 • [Get DCs in Domain] - 現在のドメインにあるすべてのドメイン コントローラを検索一覧に追加します。 • [Add Single Server] - 名前を指定して 1 台のサーバーまたはワークステーションを検索一覧に追加します。 • [Add all GCs in this domain] - 選択したドメインにある、グローバル カタログ サーバーとして構成されているすべてのドメイン コントローラを追加します。 • [Get All Servers] - ブラウザ サービスを使用して、ドメイン内で見つかったすべてのサーバーを追加します。これは、ドメイン コントローラを除くすべてのサーバーになります。 • [Get Servers from File] - 検索範囲に含めるすべてのサーバーを記したテキスト ファイルをインポートします。このファイルでは、1 行に 1 台ずつサーバーを記述します。
3.	サーバーを検索一覧に追加したら、検索対象のサーバーを選択する必要があります。サーバーを選択すると、検索一覧内で強調表示になります。複数のサーバーを選択するには、Ctrl キーを押しながらクリックします。

検索するイベント ログとイベントの種類を指定する

イベント ログ検索に含めるサーバーを選択したら、検索に含めるイベント ログとイベントの種類を選択して、検索範囲を狭めることができます。

EventCombMT ユーティリティでは、検索対象として次のイベント ログを選択できます。

また、次のイベントの種類 を検索に含めることもできます。

注 イベント ID が記録されているイベント ログや、そのイベント ID のイベントの種類がわかっている場合には、検索時間を短縮するためにこれらの情報を検索条件に必ず含めてください。

検索条件の保存

EventCombMT では、検索条件を保存しておき、後で読み込むことができます。EventCombMT を頻繁に使用する場合には、この保存機能は便利です。たとえば、 IIS サーバーでイベントの特定のセットを検索し、ドメイン コントローラでは別のセットを検索するといった場合です。

検索条件は、レジストリの HKLM\Software\Microsoft\EventCombMT の下に保存され、編集も簡単です。

検索結果のファイル

検索結果は、既定では C:\Temp フォルダに保存されます。検索結果には EventCombMT.txt という名前のサマリ ファイルが含まれます。また、イベント ログ検索に含まれているコンピュータごとに、<コンピュータ名>-<イベント ログ名>_LOG.txt という名前の個別のテキスト ファイルが作成されます。これらの個々のテキスト ファイルには、イベント ログから抽出された指定した検索条件を満たしたすべてのイベントが含まれます。

EventCombMT の使用例

EventCombMT の使用方法を示すために、ドメイン コントローラの再起動とアカウント ロックアウトを検知するように構成した場合を例に取り上げます。

EventCombMT を使用してドメイン コントローラの再起動を検索するには

1.	EventCombMT ツールで、ドメインが正しいドメイン名で構成されていることを確認します。
2.	ドメイン名の下の [Select to Search/Right Click to Add] ボックスを右クリックして、ポップアップ メニューの [Get DCs in Domain] をクリックします。 注 アカウント ログオン、アカウント管理などのイベントを検索する場合には、必ずすべてのドメイン コントローラを検索してください。これは、Windows 2000 ではアカウント管理にマルチマスタ モデルを使用しているため、アカウントの追加、変更、削除は、ドメイン内のどのドメイン コントローラでも行えるからです。同様に認証も、ドメイン内のどのドメイン コントローラでも検証できます。このため、更新や認証がどこで行われるのかを予測することはできません。
3.	[Select to Search/Right Click to Add] ボックスを右クリックし、次に [Select All Servers in List] をクリックします。
4.	[Choose Log Files to search] セクションの [System] チェック ボックスのみをオンにします。
5.	[Event Types] セクションの [Error] と [Informational] チェック ボックスをオンにします。
6.	[Event IDs] ボックスにイベント ID として「1001 6005 6006 6008」を入力します。
7.	[Search] ボタンをクリックする前に、検索条件が次の図のようになっていることを確認し、[Search] をクリックします。 図 9.2: [Event Comb MT] ダイアログ ボックスで検索条件を定義する 拡大表示する

検索が完了したら、ログ ディレクトリに保存された検索結果を表示できます。検索結果は、検索が完了すると自動的に表示されます。

ログ エントリを確認するには

1001,INFORMATIONAL,Save Dump,Wed Nov 28 05:45:50 2001,,The computer
has rebooted from a bugcheck. The bugcheck was: 0x000000d1
(0x00000004, 0x00000002, 0x00000000, 0x84c983dc). A dump was saved
in: C:\WINDOWS\MEMORY.DMP.
6005,INFORMATIONAL,EventLog,Wed Nov 28 05:45:46 2001,,The Event log
service was started.
6008,ERROR,EventLog,Wed Nov 28 05:45:46 2001,,The previous system
shutdown at 5:33:47 AM on 11/28/2001 was unexpected.
6005,INFORMATIONAL,EventLog,Tue Nov 27 14:10:53 2001,,The Event log
service was started.
6006,INFORMATIONAL,EventLog,Tue Nov 27 14:09:26 2001,,The Event log
service was stopped.
6005,INFORMATIONAL,EventLog,Tue Nov 27 10:11:37 2001,,The Event log
service was started.

イベント 6006 は、ドメイン コントローラをシャットダウンできるユーザー権利を持ったユーザーにより、計画的なシャットダウンが開始されたことを示しています。イベント 6005 は、イベント ログ サービスが開始されたことを示しています。このイベントは、スタートアップ時に発生します。

イベント 6008 と 1001 は、コンピュータが、シャットダウンされずに電源が切られたか、フリーズしたために再起動したか、停止エラーが発生したかのいずれかを示しています。イベント 1001 が存在する場合、停止エラーが発生していて、関連するデバッグ情報とデバッグ ファイルへの参照が含まれます。

EventCombMT ツールが返したイベントは、既知のダウンタイムと照合します。一致しないイベントがあれば、調査してサーバーが攻撃を受けたかどうか確認する必要があります。

EventCombMT にはあらかじめ設定された検索条件がいくつか含まれていて、セキュリティ イベントの検索に使用できます。たとえば、アカウント ロックアウト イベントを検索するための定義済み検索条件があります。

EventCombMT を使用してアカウント ロックアウトを検索するには

注 EventCombMT に含まれる他の定義済みの検索条件としては、ファイル複製サービスの検索条件、重複した SID と NETLOGON DNS 登録の失敗を調べる Active Directory の検索条件、ハードウェア ディスク エラー、および DNS インターフェイス エラーなどが含まれています。また、独自の検索条件を定義して保存することもできます。

Contoso では、特別な事態に対応する場合に、問題の診断や原因の判断を試みるために EventCombMT を使用します。さらに、ドメイン コントローラ全体でアカウント ロックアウトや不正なパスワードを定期的にチェックしています。このようにすることは、監視システムでは検知されない可能性のある異常なパターンすべてを手作業で識別するのに役立ちます。

イベントの収集

監査の主な目的の 1 つは、ネットワーク上の攻撃者が行った操作を特定することです。攻撃者は、ネットワーク上の複数のコンピュータとデバイスに攻撃を試みる可能性があります。そのため、攻撃の範囲を把握するために、数多くのコンピュータからの情報を結びつけ統合できるようでなければなりません。

ログ ユーティリティからデータベースにインポートが行えれば、複数のログからの情報を結びつけることが容易になります。すべてのコンピュータで時刻が同期していれば、時刻順に並べ替えることができ、時間差に基づいてイベントを追跡することが容易になります。

次のセクションでは、イベント ログの情報を 1 か所に集中して収集するために使用できるツールやユーティリティをいくつかとりあげて、それらの概要を説明します。

スクリプト

イベント ログ情報をリモート コンピュータから収集し、収集した情報を一元的に保存するスクリプトを記述できます。スクリプトを使えば、スクリプトの実行日時をスケジュール タスクを使用して選択したり、イベント ログを中央の場所にコピーした後に行う操作を選択したりすることができます。

簡単な例としては、『Windows 2000 Server リソース キット』に付属している Dumpel.exe を使用するバッチ ファイルを作成し、このバッチ ファイルを [コントロールパネル] の [タスク] を使用して定期的に起動することです。

『Windows 2000 Resource Kit, Supplement One』には、Eventquery.pl が収録されています。これは、Perl スクリプトで、Windows 2000 が動作しているローカルおよびリモート コンピュータ上のイベント ビューアのログからイベントを表示します。また、特定のイベントの検索に役立つ、幅広い設定が可能なフィルタを提供します。

注 このスクリプトを使用するには、『Windows 2000 Server リソース キット』から ActivePerl をインストールしておく必要があります。

Contoso では現在のところ、イベント収集のソリューションを利用していません。しかし、近くリリースされる、Microsoft Audit Collection System (MACS) を利用することを予定しています。MACS は圧縮、署名、および暗号化を利用して、安全な方法でイベントを収集するセキュリティ イベント収集ツールです。収集したイベントは、SQL データベースに読み込み、分析のために最適化できます。

Microsoft Operations Manager

Microsoft Operations Manager 2000 は、包括的なツールのセットを提供しており、これを使用すれば、Windows 2000 とそのアプリケーションの組み込みイベント レポートとパフォーマンス モニタを徹底的に分析できます。MOM 2000 は、リモート コンピュータのインテリジェント エージェントを使用して、イベントとパフォーマンス データを 1 か所で収集、保存、および報告することができるので、管理者は収集された情報を中央から確認することができます。

MOM 2000 の中心的な管理パックは、システム、アプリケーション、およびセキュリティ イベント ログに記録されたイベントを収集し、その結果を中央のイベント リポジトリに集約します。

注 MOM 2000 は収集した情報を SQL データベースに格納し、それらのデータを検索し分析する手段をいくつか提供しています。管理者は、Operations Manager Administrator Console、Web Console、または Operations Manager Reporting を使用して、データの表示、印刷、または公開を行うことができます。各ビューには、保存したデータを分析するための定義済みのビューがあり、カスタマイズしたビューやレポートを定義するのに使用できます。

イベント ログを収集するサードパーティのソリューション

イベント ログの一元的な収集や検査を行う、サードパーティの製品がいくつか販売されています。サードパーティの製品を評価する際には、次の機能を評価対象に含めてください。

イベント収集機能があるサードパーティ製品には次の製品があります。

能動的な検知方法

能動的な侵入検知システムは、着信するネットワーク トラフィックをアプリケーション層で解析し、既知の攻撃手法がないかどうか、またはアプリケーション層ペイロードに疑わしいものがないかどうかを監視します。疑わしいパケットが着信すると、侵入検知システムは、通常、そのパケットを破棄し、ログ ファイルにエントリを記録します。侵入検知システムの中には、重大な攻撃を検知した場合には、管理者に警告を発信するものもあります。

侵入検知用サードパーティ ソリューション

ネットワークおよびエンドポイントの両方で使用できるサードパーティの侵入検知システム ソリューションがあります。これらのサードパーティ ソリューションは、HTTP (Hypertext Transfer Protocol) 以外のプロトコルもサポートしており、ネットワーク化されたコンピュータに対する既知の攻撃もスキャンします。

侵入検知システムが特定する一般的な攻撃の種類としては、以下のものがあります。

優れた侵入検知システムは、以上 3 つの種類の攻撃をすべて特定できなければなりません。攻撃の特定には、次の 2 つの方法を使用します。

テストおよび展開が可能なものとして、以下のようなサードパーティの製品があります。

脆弱性の評価

受動的および能動的な侵入検知の実行に加えて、脆弱性の評価も定期的に行ってください。脆弱性の評価では、ネットワークに対する攻撃をシミュレートし、攻撃者が見つける可能性がある脆弱性の検知を行います。

定期的に評価することで、攻撃者が脆弱性を見つける前に検知してネットワークの弱い部分をセキュリティで保護し、脆弱性を保護することができます。

脆弱性の評価ツールを調査する場合は、意思決定プロセスで次の要件を満たす必要があります。

Windows 2000 ネットワークに対して脆弱性の評価を行うものとして、以下のようなサードパーティのツールがあります。

また、サードパーティのコンサルタントに依頼して、脆弱性に関する評価を実施してもらうことが適切な場合もあります。サードパーティのサービスを利用する利点は、使用しているネットワークについての事前の知識がないため、外部の攻撃者と同じ立場で作業を開始できることです。多くの場合、外部の評価チームは、中立の立場で調査にあたって、非常に有用な情報を提供することができます。

ページのトップへ

まとめ

監査と侵入検知は、環境を効果的に防衛する上で重要な部分です。リスク管理プロセスの一環として、どの程度の監査および侵入検知が使用しているネットワーク環境に適切かどうかを判断する必要があります。複数のプロトコルにわたって侵入検知を行うには、サードパーティのツールを検討することもお勧めします。

詳細情報

ユーザー権利の使用についての詳細は、『Writing Secure Code』、Michael Howard、David LeBlanc 共著、MS Press、ISBN : 0735615888 を参照してください。

ISA Server パートナーについて
http://www.microsoft.com/japan/isaserver/partners/

ISA Server ソフトウェア開発キット (SDK)
http://www.microsoft.com/downloads/details.aspx?FamilyId=5C8121CD-3AFF-43D3-BC09-BF3FDDD2B9E3&displaylang=en

ページのトップへ

10 of 17