マイクロソフトの Securing Windows 2000 Server ソリューション: 第 9 章 ‐ 監査と侵入検出

第 9 章 ‐ 監査と侵入検出

トピック

監査

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

まとめ

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

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

  • どんな機能的なコンピュータ環境も攻撃に対して潜在的に無防備です。セキュリティのレベルがどれほど高くても、攻撃されるリスクは常に存在します。

  • 多くの場合、攻撃の成功は一連の不成功の後に生じます。攻撃を監視していないと、攻撃が成功する以前に検知できません。

  • 攻撃が成功したとしても、発見が早いほど損害が小さくて済みます。

  • 攻撃から復旧するには、どのような損害が生じたかを知る必要があります。

  • 監査と侵入検知は、攻撃者を突き止めるのに役立ちます。

  • 監査と侵入検知を組み合わせれば、情報を関連させて、攻撃のパターンを識別するのに役立ちます。

  • セキュリティ ログを定期的に調査すれば、不適切なアクセス許可やアカウント ロックアウト設定の緩さなど、それまで気がつかなかったセキュリティ構成上の問題を識別するのに役立ちます。

  • 攻撃を検知した場合、監査によってどのネットワーク リソースに危険が生じたのかを知る手がかりが得られます。

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

監査

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

どの程度の監査を行うかを決定する際には、多くの監査を行って多くのイベントを生成するほど、重要なイベントの特定が難しくなるという点を念頭に置いておきます。広範な監査を行う場合には、より重要なイベントを見分ける助けとして、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 セキュリティ イベント ログに記録されるログオン イベント

イベント ID 説明
528 ユーザーが正常にコンピュータにログオンしました。
529 不明なユーザー名で、または既知のユーザー名に対し無効なパスワードでログオンしようとしました。
530 ユーザー アカウントが認められた時間外にログオンしようとしました。
531 無効なアカウントを使用してログオンしようとしました。
532 期限切れのアカウントを使用してログオンしようとしました。
533 このコンピュータへのログオンが認められていないユーザーがログオンしようとしました。
534 ネットワーク、対話型、バッチ、サービス、リモート対話型など、認められていないログオンの種類を使用してユーザーがログオンしようとしました。
535 指定されたアカウントのパスワードの期限は切れています。
536 Net Logon サービスが有効ではありません。
537 その他の理由でログオンが失敗しました。
538 ユーザーがログオフしました。
539 ログオンしようとした時点でアカウントがロックアウトされていました。このイベントは、パスワード攻撃が失敗したためにアカウントがロックアウトされた可能性があることを示しています。
540 ネットワーク ログオンに成功しました。このイベントは、リモート ユーザーがネットワークからサーバー上のローカル リソースに正常に接続し、そのネットワーク ユーザー用のトークンが生成されたことを示します。
682 ユーザーが切断されたターミナル サービス セッションに再接続しました。このイベントは、以前のターミナル サービス セッションに接続されたことを示します。
683 ユーザーはログオフせずにターミナル サービス セッションを切断しました。このイベントは、ユーザーがネットワーク経由でターミナル サービス セッションに接続した場合に生成されます。このイベントはターミナル サーバー上に記録されます。

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

  • ローカル ログオンの失敗 - イベント ID 529、530、531、532、533、534、および 537 はログオンの失敗を示しています。攻撃者がローカル アカウントのユーザー名とパスワードの組み合わせを推測しようとして失敗した場合には、イベント 529 と 534 が記録されます。ただし、これらのイベントは、ユーザーがパスワードを忘れた、または [マイ ネットワーク] からネットワークの参照を開始した場合にも記録されます。

    大規模な環境ではこれらのイベントを効果的に解釈するのは困難かもしれません。基本的には、これらのパターンが繰り返し生じるか、他の異常な要素が伴っている場合に調査を行ってください。たとえば、真夜中に複数の 529 イベントが生じ、それから 528 イベントが生じた場合には、パスワード攻撃が成功した可能性があります (また、非常に疲れていた管理者による単純なミスかもしれません)。

  • アカウントの誤用 - イベント ID 530、531、532、および 533 は、すべてユーザー アカウントの誤用を示しています。これらのイベントは、アカウントとパスワードの組み合わせを正しく入力したものの、他の制限のために正常にログ オンできなかったことを示しています。可能な限りこれらのイベントを調査し、誤用が本当に生じたのかどうか、また、現在の制限を修正する必要があるかどうかを判断してください。たとえば、特定のアカウントのログオン可能時間を延長する必要があるかもしれません。

  • アカウント ロックアウト - イベント 539 は、アカウントがロックアウトされたことを示しています。これは、パスワード攻撃が失敗したことを示している可能性があります。同じユーザー アカウントで以前にも 529 イベントが生じていないかどうか確かめ、ログオン試行のパターンを識別するように努めてください。

  • ターミナル サービス攻撃 - ターミナル サービスセッションは、セッションの終了後にもプロセスを継続するため、接続状態のままにしておくことができます。イベント ID 683 はユーザーがターミナル サービス セッションからログアウトしなかったときに生じ、イベント ID 682 は以前に切断されたセッションに接続したときに生じます。

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

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

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

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

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

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

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

イベント ID 説明
672 認証サービス (AS) チケットが正常に発行され、検証されました。
673 チケット保証サービス (TGS) のチケットが許可されました。
674 セキュリティ プリンシパルが AS チケットまたは TGS チケットを更新しました。
675 事前認証が失敗しました。
676 認証チケット要求が失敗しました。
677 TGS チケットが許可されませんでした。
678 アカウントはドメイン アカウントに正常にマップされました。
680 成功したログオンで使用されたアカウントであることを特定しました。このイベントは、アカウントの認証に認証パッケージが使用されたことも示しています。
681 ドメイン アカウントのログオンが試行されました。
682 ユーザーが切断されたターミナル サービス セッションに再接続しました。
683 ユーザーは、ログオフせずにターミナル サービス セッションを切断しました。

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

  • ドメイン ログオンの失敗 - イベント ID 675 と 677 は、ドメインへのログインが失敗したことを示しています。

  • 時刻同期の問題 - クライアント コンピュータの時刻が認証を行うドメイン コントローラの時刻と 5 分以上 (デフォルトの設定) 異なる場合には、イベント ID 675 がセキュリティ ログに記録されます。

  • ターミナル サービス攻撃 - ターミナル サービスセッションは、ターミナル サーバー セッションの終了後にもプロセスを継続するため、接続状態のままにしておくことができます。イベント ID 683 は、ユーザーがターミナル サービス セッションからログアウトしなかったときに生じ、イベント ID 682 は、以前に切断されたセッションに接続したときに生じます。切断を防ぐ、または切断されたセッションを終了するには、[Terminal Services Configuration] コンソールの [RDP-TCP protocol] のプロパティで、切断されたセッションを終了するまでの時間を指定します。

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

アカウント管理

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

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

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

イベント ID 説明
624 ユーザー アカウントが作成されました。
625 ユーザー アカウントの種類が変更されました。
626 ユーザー アカウントが有効にされました。
627 パスワードの変更が試行されました。
628 ユーザー アカウントのパスワードが設定されました。
629 ユーザー アカウントが無効にされました。
630 ユーザー アカウントが削除されました。
631 セキュリティが有効なグローバル グループが作成されました。
632 セキュリティが有効なグローバル グループ メンバが追加されました。
633 セキュリティが有効なグローバル グループ メンバが削除されました。
634 セキュリティが有効なグローバル グループが削除されました。
635 セキュリティが無効なローカル グループが作成されました。
636 セキュリティが有効なローカル グループ メンバが追加されました。
637 セキュリティが有効なローカル グループ メンバが削除されました。
638 セキュリティが有効なローカル グループが削除されました。
639 セキュリティが有効なローカル グループが変更されました。
641 セキュリティが有効なグローバル グループが変更されました。
642 ユーザー アカウントが変更されました。
643 ドメイン ポリシーが変更されました。
644 ユーザー アカウントがロック アウトされました。

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

  • ユーザーアカウントの作成 - イベント ID 624 と 626 は、ユーザー アカウントが作成され、有効にされたことを示します。アカウントの作成を、組織内の特定の人物のみに制限している場合、これらのイベントを使用して権限のない人物がユーザー アカウントを作成したかどうかを特定できます。

  • ユーザー アカウント パスワードの変更 - パスワードがそのユーザー以外の人物によって変更された場合、そのアカウントは他のユーザーによって乗っ取られた可能性があります。パスワードの変更が試行され、成功したことを示す、イベント ID 627 および 628 を探してください。これらのイベントの詳細を調べ、変更が別のアカウントで行われたかどうかを判断し、そのアカウントがユーザー アカウントのパスワードをリセットできるヘルプ デスク、または他のサービス チームのメンバのものであるかどうかを判断します。

  • ユーザー アカウントの状態の変更 - 攻撃者は、攻撃時に使用したアカウントを無効にしたり削除したりすることで、攻撃の証拠を消そうとすることがあります。イベント ID 629 および 630 をすべて調査して、これらのイベントが正当な操作であることを確認してください。また、イベント ID 626 が発生してから短時間でイベント ID 629 が発生しているものを探します。このパターンは、無効なアカウントを有効にして使用し、その後で再び無効にした可能性を示しています。

  • セキュリティ グループの変更 - ドメイン管理者、管理者、オペレータ グループのいずれか、または管理機能が委任されているカスタム グローバル、ユニバーサル、またはドメイン ローカルの各グループに対するメンバシップの変更は必ず調査してください。グローバル グループ メンバシップの変更については、イベント ID 632 および 633 を調べます。ドメイン ローカル グループ メンバシップの変更については、イベント ID 636 と 637 を調べます。

  • アカウントのロックアウト - アカウントがロックアウトされた場合、2 つのイベントがプライマリ ドメイン コントローラ (PDC) エミュレータの操作マスタに記録されます。イベント ID 644 はアカウント名がロックアウトされたことを示します。次に 642 イベントが記録され、そのアカウントがロックアウトされたため、ユーザー アカウントが変更されたことを示します。このイベントは、PDC エミュレータでのみ記録されます。

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

オブジェクト アクセス

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

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

  • 監査するセキュリティ プリンシパル

  • 監査の対象とする特定のアクセス タイプ (アクセス マスクと呼ばれます)

  • 監査の対象を示すフラグ。失敗したアクセス、成功したアクセス、または両方の監査を行うかどうかを示します。

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

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

  1. ユーザーは、オブジェクトにアクセスするようにプログラムに指示します (例 : ファイル/開く)。

  2. プログラムは希望するアクセスの種類 (読み取り、書き込みなど) を指定して、システムにハンドルを要求します。

  3. セキュリティ サブシステムは要求されたオブジェクトの随意アクセス コントロール リスト (DACL) とユーザーのトークンとを比較して、DACL 内のエントリから、ユーザーまたはユーザーが属するグループと一致し、プログラムが要求したアクセス権があるエントリを探します。

  4. システムは、要求されたオブジェクトの SACL とユーザーのトークンとを比較し、SACL のエントリから、プログラムに返された有効な権限、またはプログラムが要求した権限と一致するものを探します。一致の失敗を監査する ACE が要求されたものの許可されなかったアクセスと一致すると、失敗の監査イベントが生成されます。一致の成功を監査する ACE が許可されたアクセスと一致すると、成功の監査イベントが生成されます。

  5. なんらかのアクセス権が許可されると、システムはハンドルをプログラムに返し、プログラムはこのハンドルを使用して、オブジェクトにアクセスします。

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

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

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

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

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

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

イベント ID 説明
560 アクセスは既存のオブジェクトに対して許可されました。
562 オブジェクトへのハンドルが閉じられました。
563 オブジェクトを削除する目的でオブジェクトを開こうとしました(これは、FILE_DELETE_ON_CLOSE フラグを指定している場合に、ファイル システムによって使用されます)。
564 保護されていたオブジェクトが削除されました。
565 アクセスは既存のオブジェクトの種類に対して許可されました。

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

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

監査操作 実行方法
特定のファイル、フォルダ、またはオブジェクトの検索 イベント 560 の詳細で操作を確認するファイルまたはフォルダのフル パスを検索します。
特定のユーザーによる操作の判別 560 イベントで特定のユーザーを識別するフィルタを定義します。
特定のコンピュータで実行された操作の判別 560 イベントでタスクが実行された特定のコンピュータ アカウントを識別するフィルタを定義します。

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

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

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

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

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

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

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

特権の使用

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

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

  • スキャン チェックのバイパス

  • プログラムのデバッグ

  • トークン オブジェクトの作成

  • プロセス レベル トークンの置き換え

  • セキュリティ監査の生成

  • ファイルとディレクトリのバックアップ

  • ファイルとディレクトリの復元

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

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

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

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

イベント ID 説明
576 指定された特権がユーザーのアクセス トークンに追加されました (このイベントは、ユーザーがログオンすると記録されます)。
577 ユーザーが特権の必要なシステム サービス操作を実行しようとしました。
578 保護されたオブジェクトへの既に開かれているハンドル上で特権が使用されました。

  • オペレーティング システムの一部として機能 - SeTcbPrivilege アクセス特権が示されているイベント ID 577 と 578 を探します。このユーザー権利を使用したユーザー アカウントは、イベントの詳細で特定できます。このイベントは、オペレーティング システムの一部として動作することにより、ユーザーがセキュリティ特権を引き上げようとした可能性があることを示しています。たとえば、ユーザーがこの特権を使用する Administrators グループに自分のアカウントを追加しようとする GetAdmin 攻撃があります。このイベントで記録されるエントリは、System アカウントとこのユーザー権利に割り当てられたサービス アカウントだけです。

  • システム時刻の変更 - SeSystemtimePrivilege アクセス特権が示されているイベント ID 577 と 578 を探します。このユーザー権利を使用したユーザー アカウントは、イベントの詳細で特定できます。このイベントは、イベントが発生した実際の時刻を隠そうとして、ユーザーがシステム時刻を変更しようとした可能性があることを示しています。

  • リモート システムからの強制シャットダウン - ユーザー権利 SeRemoteShutdownPrivilege アクセス特権が示されているイベント ID 577 と 578 を探します。イベントの詳細には、ユーザー権利が割り当てられた特定のセキュリティ識別子 (SID)、および権利を割り当てたセキュリティ プリンシパルのユーザー名が含まれます。

  • デバイス ドライバのロードとアンロード - SeLoadDriverPrivilege アクセス特権が示されているイベント ID 577 と 578 を探します。このユーザー権利を利用したユーザー アカウントは、イベントの詳細で特定できます。このイベントは、不正なデバイス ドライバ、またはトロイの木馬型 (悪意あるコードの一種) のデバイス ドライバを、ユーザーがロードしようとした可能性があることを示しています。

  • 監査ログとセキュリティ ログの操作 - SeSecurityPrivilege アクセス特権が示されているイベント ID 577 と 578 を探します。このユーザー権利を利用したユーザー アカウントは、イベントの詳細で特定できます。このイベントは、イベント ログが消去された場合、および特権使用のイベントがセキュリティ ログに記録された場合の両方で発生します。

  • システムのシャットダウン - SeShutdownPrivilege アクセス特権が示されているイベント ID 577 を探します。このユーザー権利を利用したユーザー アカウントは、イベントの詳細で特定できます。このイベントは、コンピュータをシャットダウンしようとした場合に発生します。

  • ファイルや他のオブジェクトの所有権の取得 - SeTakeOwnershipPrivilege アクセス特権が示されているイベント ID 577 と 578 を探します。このユーザー権利を使用したユーザー アカウントは、イベントの詳細で特定できます。このイベントは、攻撃者がオブジェクトの所有権を取得することにより、現在のセキュリティ設定をバイパスしようとした可能性があることを示しています。

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

プロセスの追跡

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

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

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

イベント ID 説明
592 新しいプロセスが作成されました。
593 プロセスが終了しました。
594 オブジェクトへのハンドルが複製されました。
595 オブジェクトへの間接アクセスが取得されました。

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

システム イベント

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

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

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

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

イベント ID 説明
512 Windows が起動します。
513 Windows がシャットダウンします。
514 認証パッケージがローカル セキュリティ機関により読み込まれました。
515 信頼されているログオン プロセスがローカル セキュリティ機関に登録されました。
516 セキュリティ イベント メッセージをキューに登録するために割り当てられた内部リソースをすべて使用したため、一部のセキュリティ イベント メッセージが失われました。
517 セキュリティ ログが消去されました。
518 認証パッケージがローカル セキュリティ機関により読み込まれました。

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

  • コンピュータのシャットダウンと再起動 - イベント ID 513 は、Windows がシャットダウンされたことを示します。サーバーがいつシャットダウン、または再起動されたのかを知ることは重要です。正当な理由も数多くあります。たとえば、再起動が必要なドライバやアプリケーションのインストール、メンテナンスのためのサーバーのシャットダウンや再起動です。しかし、攻撃者が、システムの起動中にアクセスを取得するため、サーバーを強制的に再起動る可能性もあります。コンピュータがシャットダウンされた場合にはすべてチェックし、イベント ログと比較してください。

    多くの攻撃にはコンピュータの再起動が関連しています。イベント ログを調査すれば、サーバーの再起動の日時を知り、それが計画されていたものか、計画外のものかを知ることができます。イベント ID 512 は、Windows の起動を示しており、自動的に発生する他の一連のイベントとともに、システム ログに記録されます。これらのイベントには、イベント ログ サービスの開始を示すイベント ID 6005 が含まれます。

    システム ログ内で、このエントリ以外の 1,2 のイベント ログ エントリが存在していないかどうかを探します。直前のシャットダウンが、管理者による再起動目的など、問題のないものであれば、システム ログにイベント ID 6006 (「イベント ログ サービスが停止されました」) が記録されています。エントリの詳細を調査すれば、どのユーザーがシャットダウンを開始したのかを判別できます。

    再起動が予定外の再起動によるものであれば、システム ログにイベント ID 6008 (「以前のシステム シャットダウン (日付 時刻) は予期されていませんでした」) が記録されています。これは、コンピュータのシャットダウンを引き起こすサービス拒否攻撃 (DoS) の発生を示している可能性があります。しかし、このような再起動は、電源異常やデバイス ドライバの障害による場合もあります。

    再起動がブルー スクリーンを表示するような停止エラーによるものであれば、イベント ID 1001 がダンプと共にシステム ログに記録されています。実際の停止エラー メッセージは、イベントの詳細で確認できます。

    イベント ID 1001 のエントリも記録するようにするには、コントロール パネルの [システム] の [詳細] - [起動/回復] のセクションで、[システム ログにイベントを書き込む] チェック ボックスをオンにする必要があります。

  • セキュリティ ログの変更と消去- 攻撃者は、検知されないようにするために、セキュリティ ログを変更したり、攻撃中の監査を無効にしたり、またはセキュリティ ログを消去することを試みたりします。長時間、セキュリティ ログにエントリが記録されていないことに気付いたら、イベント ID 612 と 517 を探して、監査ポリシーを変更したユーザーを特定してください。発生したイベント ID 517 のすべてについて、セキュリティ ログを消去したすべての日時を記録した物理ログと比較します。セキュリティ ログの不正な消去は、以前のセキュリティ ログ内のイベントを隠すために行われた可能性があります。ログを消去したユーザーの名前はイベントの詳細に含まれています。

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

ポリシーの変更

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

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

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

イベント ID 説明
608 ユーザー権利が割り当てられました。
609 ユーザー権利が削除されました。
610 他のドメインとの信頼関係が作成されました。
611 他のドメインとの信頼関係が削除されました。
612 監査ポリシーが変更されました。
768 あるフォレストと他のフォレストの名前空間の要素の間で競合が検知されました (あるフォレストと他のフォレストの名前空間の要素とが重複している場合に発生します)。

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

  • オペレーティング システムの一部として機能 - イベントの詳細でユーザー権利 seTcbPrivilege が示されているイベント ID 608 と 609 を探します。

  • ドメインにワークステーションを追加 - イベントの詳細でユーザー権利 SeMachineAccountPrivilege が示されているイベントを探します。

  • ファイルとディレクトリのバックアップ - イベントの詳細でユーザー権利 SeBackupPrivilege が示されているイベントを探します。

  • スキャン チェックのバイパス - イベントの詳細でユーザー権利 SeChangeNotifyPrivilege が示されているイベントを探します。このユーザー権利は、ディレクトリにアクセスする他の許可を持っていない場合でも、ディレクトリ ツリーをスキャンすることを可能にするものです。

  • システム時刻の変更 - イベントの詳細でユーザー権利 SeSystemtimePrivilege が示されているイベントを探します。このユーザー権利を使用すると、セキュリティ プリンシパルはシステム時刻を変更できます。イベントが発生した時間を偽装できる可能性があります。

  • 永続的共有オブジェクトの作成 - イベントの詳細でユーザー権利 SeCreatePermanentPrivilege が示されているイベントを探します。このユーザー権利の所有者は、ファイルおよびプリンタの共有を作成できます。

  • プログラムのデバッグ - イベントの詳細でユーザー権利 SeDebugPrivilege が示されているイベントを探します。既定では、この権利は Administrators にのみ割り当てられています。

  • リモート システムからの強制シャットダウン - イベントの詳細でユーザー権利 SeRemoteShutdownPrivilege が示されているイベントを探します。

  • スケジュール優先順位の繰り上げ - イベントの詳細でユーザー権利 SeIncreaseBasePriorityPrivilege が示されているイベントを探します。この権限を持つユーザーは、プロセスの優先順位を変更できます。

  • デバイス ドライバのロードとアンロード - イベントの詳細でユーザー権利 SeLoadDriverPrivilege が示されているイベントを探します。このユーザー権利を持つユーザーは、トロイの木馬型のデバイス ドライバをロードすることができます。

  • 監査ログとセキュリティ ログの操作 - イベントの詳細でユーザー権利 SeSecurityPrivilege が示されているイベントを探します。このユーザー権利を持つユーザーは、セキュリティ ログの表示と消去を行えます。

  • プロセス レベル トークンの置き換え - イベントの詳細でユーザー権利 SeAssignPrimaryTokenPrivilege が示されているイベントを探します。このユーザー権利を持つユーザーは、開始されたサブプロセスに関連付けられた既定のトークンを変更できます。

  • ファイルとディレクトリの復元 - イベントの詳細でユーザー権利 SeRestorePrivilege が示されているイベントを探します。

  • システムのシャットダウン - イベントの詳細でユーザー権利 SeShutdownPrivilege が示されているイベントを探します。このユーザー権利を持つユーザーは、新しいデバイス ドライバのインストールを初期化するために、システムをシャットダウンすることができます。

  • ファイルや他のオブジェクトの所有権の取得 - イベントの詳細でユーザー権利 SeTakeOwnershipPrivilege が示されているイベントを探します。このユーザー権利を持つユーザーは、オブジェクトまたはファイルの所有権を取得することにより、NTFS ディスク上のどのオブジェクトやファイルにでもアクセスできます。

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

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

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

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

イベント ログの保護

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

  • すべてのイベント ログの保存、上書き、および維持についてのポリシーを定義します。このポリシーでは、必要なすべてのイベント ログ設定を定義します。グループ ポリシーで適用してください。

  • このポリシーには、いっぱいになったイベント ログ、特にセキュリティ ログの取り扱い方法を含めます。セキュリティ ログがいっぱいになった場合は、サーバーをシャットダウンするように指定することを推奨します。これは、環境によっては実際的でない場合もありますが、必ず考慮してください。

  • ローカルの Guest がシステム、アプリケーション、およびセキュリティ ログにアクセスできないようにするセキュリティ ポリシーを有効にして、イベント ログへのゲスト アクセスを防止します。

  • システム イベントは、成功と失敗の両方を監査し、セキュリティ ログの内容を消去する試みがあったかどうかを判断できるようにします。

  • 監査設定を表示または変更する権限を持っているセキュリティ プリンシパルでは、複雑なパスワードを使用するか、スマート カードを使用したログオンなど 2 つの要素による認証方法を使用する必要があります。監査情報にアクセスするための、これらのアカウントへの攻撃を防止するためです。

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

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

  • セキュリティ計画には、すべてのサーバーに対する物理的なセキュリティを含めます。攻撃者が、監査を実行しているコンピュータに物理的にアクセスできないようにするためです。攻撃者は、ローカル ディスク サブシステム上の物理的な *.evt ファイルを変更または削除すれば、監査エントリを削除できるからです。

  • イベント ログを削除したり、物理サーバーとは別の場所に保管したりする方法を実装します。このような方法としては、スケジュール タスクを使用して、イベント ログを定期的に CD-R、つまり 1 回だけ書き込みを行えるメディアや、サーバーとは別のネットワーク上の場所に書き込む方法があります。バックアップをバックアップ テープ、CD-R メディアなどの外部メディアにコピーする場合には、火災や天災に備えて、同じ敷地内ではなく、別の場所に保管します。

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

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

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

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

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

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

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

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

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

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

  • セキュリティ問題の早期検知 - イベント ログを毎日確認すればセキュリティ イベントが 24 時間以上放置されることはなくなります。これにより、セキュリティに関する脆弱性を早期に発見し、修復することが可能になります。

  • 責任を明確にする - イベント ログを定期的に確認する必要がある場合は、ログ ファイルの確認の担当者が、攻撃の可能性を識別する点での最終的な責任を負うようにすることができます。

  • イベントの上書き、またはサーバー ダウンのリスクを軽減する - イベント ログの確認を終えたら、ログ ファイルのイベントを将来の確認用に別のファイルに保存し、現在のイベント ログから削除します。これによって、イベント ログがいっぱいになるリスクを軽減できます。

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

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

  • IIS (Internet Information Services) - IIS は、Web、FTP (ファイル転送プロトコル)、NTP (Network Time Protocol)、および SMTP サービスへの接続試行を追跡するログ ファイルを作成します。IIS の下で実行されているサービスは、それぞれ別のログ ファイルを管理します。これらのログ ファイルは World Wide Web Consortium (W3C) 拡張ログ ファイル形式で %WinDir%\System32\Logfiles フォルダに保存されます。各サービスは、ログ情報をさらに別々のフォルダに分類します。または、IIS を構成することによりログを Microsoft SQL Server などの Open Database Connectivity (ODBC) 準拠のデータベースに格納することもできます。

  • Microsoft Internet Security and Acceleration (ISA) Server - ISA Server は、ログをパケット フィルタである ISA Server Firewall Service および ISA Server Web Proxy Service に提供します。IIS の場合と同様に、このログは既定で W3C 拡張ログ ファイル形式で保存されますが、ODBC 準拠のデータベースに記録することもできます。ISA Server のログ ファイルは、既定で C:\Program Files\Microsoft ISA Server\ISALogs フォルダに保存されます。

  • インターネット認証サービス (IAS) - IAS は、リモート認証ダイヤルイン ユーザー サービス (RADIUS) プロトコルを使用して、リモート アクセス認証用の集中認証とアカウンティングを提供します。アカウンティング要求、認証要求、および定期的な状態情報要求は、既定で %WinDir%\System32\Logfiles フォルダにある IASlog.log ファイルに記録されます。または、IAS 形式ではなく、データベース互換形式で保存することもできます。

  • サードパーティのツール - サードパーティのアプリケーションの中には、アプリケーションについての詳細情報を提供するローカル ログ記録機能を実装しているものがあります。詳細については、ご使用のアプリケーションのヘルプ ファイルを参照してください。

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

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

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

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

  • サービス コンソール - [サービス] MMC コンソールは、ローカル コンピュータやリモート コンピュータのサービスの監視のために使用できます。管理者はこのコンソールから、インストールされているすべてのサービスの構成、一時停止、停止、開始、および再開を行えます。自動的に起動するように設定しているサービスのいずれかが開始していないかどうかを判断するには、このコンソールを使用します。

  • Netsvc.exe - このコマンド ライン ツールは、『Windows 2000 Server リソース キット』に付属しています。管理者は、コマンド ラインからリモートで各サービスの開始、一時停止、続行、およびその状態の照会を行えます。

  • SvcMon.exe - サービス監視ツールです。このツールは、ローカルおよびリモート コンピュータ上のサービスの状態 (開始、停止など) が変わっていないかどうかを監視します。これらの変化を検知するために、このツールにはポーリング システムが実装されています。監視しているサービスが停止または開始すると、ツールは電子メールによって通知します。サービス監視構成ツール (smconfig.exe) を使用して、監視するサーバー、ポーリング間隔、およびサービスを構成する必要があります。

  • Drivers.exe - このツールは、ツールを実行したコンピュータにインストールされているすべてのデバイス ドライバを表示します。このツールの出力情報には、ドライバのファイル名、ドライバのディスク上のサイズ、およびドライバのリンクが行われた日付が含まれます。ドライバのリンク日付は、新しくインストールされたドライバを特定するために使用できます。更新されているドライバを最近インストールしたことがなければ、置き換えられたドライバである可能性があります。この情報は、イベント ビューアに表示されるシステムの再起動イベントと関連付けてください。

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

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

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

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

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

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

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

  • -a 接続、およびリッスンしているポートをすべて表示します。

  • -e イーサネットの統計情報を表示します。これは -s スイッチと組み合わせて使用できます。

  • -n アドレスとポート番号を数値形式で表示します。

  • -p proto proto で指定されたプロトコル用の接続を表示します。proto には TCP または UDP を指定できます。プロトコルごとの統計情報を表示する -s スイッチと一緒に使用する場合、proto には TCP、UDP、または IP (Internet Protocol) を指定できます。

  • -r ルーティング テーブルを表示します。

  • -s プロトコルごとの統計情報を表示します。既定では、TCP、UDP、および IP の統計情報を表示します。-p スイッチを使用すると、そのうちの特定のものを指定できます。

  • interval 選択した統計情報を指定した間隔 (秒) で再表示します。統計情報の再表示を停止するには、Ctrl + C キーを押します。省略すると、現在の構成情報を 1 回印刷します。

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

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

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

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

ページのトップへ

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

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

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

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

時刻同期の重要性

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

受動的な検知方法

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

イベント ビューア

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

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

  1. コンソール ツリーで目的のイベント ログを選択します。

  2. [表示] メニューの [フィルタ] をクリックします。

  3. フィルタに使用するパラメータを選択します。

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

  • [イベントの種類] - このフィルタでは、イベントの種類を [情報]、[警告]、[エラー]、[成功の監査]、[失敗の監査] のいずれか、またはそれらの組み合わせに限定できます

  • [イベント ソース] - イベントを生成した特定のサービスまたはドライバです。

  • [分類] - このフィルタで、特定のカテゴリのイベントに限定できます。

  • [イベント ID] - 探すイベント ID がわかっている場合には、その特定のイベント ID だけを表示するように限定できます。

  • [ユーザー] - 特定のユーザーによって生成されたイベントだけを表示するように限定できます。

  • [コンピュータ] - 特定のコンピュータによって生成されたイベントだけを表示するように限定できます。

  • [開始] と [終了] - 特定の開始日時と終了日時の間に発生したイベントだけを表示するように限定できます。

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

前述のように、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]  

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

  • -f file 出力ファイル名を指定します。-f には既定値はないので、出力ファイル名を必ず指定します。

  • -s server イベント ログのダンプ対象のサーバーを指定します。サーバー名の前のバックスラッシュ記号 (\\) は省略できます。

  • -l log ダンプするログ (system、application、または security) を指定します。有効でないログ名を指定した場合は、application ログがダンプされます。

  • -m source ダンプ レコードへのソースを指定します (rdr (リダイレクタ)、serial など)。指定できるソースは 1 つだけです。このスイッチを省略した場合、すべてのイベントがダンプされます。レジストリに登録されていないソースを指定した場合、その種類のレコードがあるかどうか、アプリケーション ログを検索します。

  • -e n1 n2 n3 フィルタするイベント ID nn (10 個まで指定できます)。-r スイッチを省略した場合は、この種類のレコードだけがダンプされます。-r を指定した場合は、この種類以外のレコードがすべてダンプされます。このスイッチを省略した場合、指定した source からのすべてのイベントが選択されます。このスイッチを使用する場合は、-m スイッチを必ず指定します。

  • -r 指定したソースまたはレコードを取り出すのか、またはそれらを除外するのかを指定します。

  • -t 各文字列をタブで区切るように指定します。-t を省略した場合、各文字列は空白で区切られます。

  • -d x 過去 x 日以内のイベントをダンプします。

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

EventCombMT

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

  • 検索対象として単一のイベント ID または複数のイベント ID を定義する - 単一のイベント ID を指定できます。または空白で区切ることで複数のイベント ID を指定できます。

  • 検索するイベント ID の範囲を指定する - 指定した範囲の両端は含まれます。たとえば、イベント ID 528 から 540 までの範囲のイベントを、その両端も含めて検索する場合には、検索範囲を 528 > ID < 540 として定義します。イベント ログへの記録を行うほとんどのアプリケーションは、イベント ID を連番で使用するので、この機能は便利です。

  • 検索対象を特定のイベント ログに制限する - 検索対象としてシステム、アプリケーション、およびセキュリティ ログを選択できます。ドメイン コントローラでローカルに実行する場合は、FRS、DNS、および AD のログも検索対象として選択できます。

  • 検索対象のイベント メッセージを特定の種類に制限する - 検索対象の種類をエラー、情報、警告、成功の監査、失敗の監査、または成功イベントに限定できます。

  • 検索対象を特定のイベント ソースに制限する - 検索対象を特定のイベント ソースのイベントに限定できます。

  • イベント説明内の特定の文字列を検索する - 各イベントで、特定の文字列を検索できます。この機能は、特定のユーザーまたはグループを追跡する場合に便利です。

    検索対象の文字列に AND、OR、NOT などの論理演算子を含めることはできません。また、引用符で文字列を区切ることもできません。

  • 期間を定義して、現在の日時からどの程度前のものまでスキャンの対象とするかを指定する - これにより、検索対象のイベントを、過去の 1 日間、1 週間、または 1 か月間に限定できます。

ツールのインストール

ツールをインストールするには、このガイドに付属する自己展開型ファイル 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 ユーティリティでは、検索対象として次のイベント ログを選択できます。

  • System (システム)

  • Application (アプリケーション)

  • Security (セキュリティ)

  • FRS (ファイル複製サービスのログ)

  • DNS (DNS サーバーのログ)

  • AD (ディレクトリ サービスのログ)

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

  • [Error] (エラー) - アプリケーションおよびシステム ログに記録されているものと、FRS、DNS、およびディレクトリ サービスのログに記録されているものです。

  • [Informational] (情報) - アプリケーションおよびシステム ログに記録されているものと、FRS、DNS、およびディレクトリ サービスのログに記録されているものです。

  • [Warning] (警告) - アプリケーションおよびシステム ログに記録されているものと、FRS、DNS、およびディレクトリ サービスのログに記録されているものです。

  • [Success Audit] (成功の監査) - セキュリティ ログに記録されているものと、アプリケーションが成功の監査をアプリケーション ログに記録している場合のものです。たとえば、Active Directory 移行ツール (ADMT) は、成功の監査イベントをアプリケーション ログに記録します。

  • [Failure Audit] (失敗の監査) - セキュリティ ログに記録されているものと、アプリケーションが失敗の監査をアプリケーション ログに記録している場合のものです。たとえば、ADMT は、失敗の監査イベントをアプリケーション ログに記録します。

  • [Success] (成功) - このイベントが記録されるのは非常にまれですが、アプリケーションまたはシステム ログ、また FRS、DNS、およびディレクトリ サービスのログに記録されます。イベント ビューアでは、成功イベントは情報のイベント種類として表示されます。

イベント 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] ダイアログ ボックスで検索条件を定義する

    拡大表示する

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

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

  1. [File] メニューの [Open Log Directory] をクリックします。

  2. C:\Temp フォルダでドメイン コントローラに関する出力ファイルをダブルクリックし、EventCombMT ツールが記録したイベントを表示します。出力は、次のようなものになります。

    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 を使用してアカウント ロックアウトを検索するには

  1. EventCombMT ツールで、ドメインが正しいドメイン名で構成されていることを確認します。

  2. ドメイン名の下の [Select to Search/Right Click to Add] ボックスを右クリックし、ポップアップ メニューの [Get DCs in Domain] をクリックします。

  3. [Select to Search/Right Click to Add] ボックスを右クリックし、次に [Select All Servers in List] をクリックします。

  4. [Searches] メニューの [Built In Searches] をクリックし、次に [Account Lockouts] をクリックします。EventCombMT ユーティリィティは次の図のように構成されます。

  5. [Search] をクリックします。

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

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 を使用して、データの表示、印刷、または公開を行うことができます。各ビューには、保存したデータを分析するための定義済みのビューがあり、カスタマイズしたビューやレポートを定義するのに使用できます。

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

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

  • Windows 2000 のログをすべてサポート - アプリケーション、セキュリティ、およびシステム ログのサポートに加えて、DNS サーバー、ディレクトリ サービス、および FRS のログをサポートしている必要があります。

  • バックエンド データベースの使用 - イベント ログは、複数のサーバーで記録されたイベントの傾向分析と関連付けを行うために以前のイベント ログ エントリの検査が可能なデータベースの構造で保存できる必要があります。

  • 検索およびレポート機能 - 指定した検索条件に基づいて特定のイベントを検索できる必要があります。検索結果は、読み取り可能な形式で提供される必要があります。

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

能動的な検知方法

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

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

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

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

  • 偵察 - これは、脆弱性がないかどうか、侵入者がネットワークを探る場合に発生します。攻撃としては、ping スイープ、DNS ゾーン転送、電子メールアドレスの調査、ポート スキャン、および Web サイト コンテンツをダウンロードして脆弱なスクリプトやサンプル ページを検索することなどが考えられます。

  • 脆弱性を悪用した攻撃 - この攻撃は、侵入者がシステムにアクセスするために隠し機能や障害を利用する場合に発生します。多くの場合、攻撃ポイントは以前の攻撃を基に特定されます。

  • サービス拒否 (DoS) 攻撃 - 侵入者が、ネットワーク リンク、CPU、ディスク サブシステムなどのリソースに大きな負荷をかけることで、コンピュータ上で実行しているサービスをクラッシュさせようとする場合に発生します。侵入者の目的は、情報の入手ではなく、コンピュータを使用不能に陥れることです。

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

  • 異常検知 - ネットワーク上のコンピュータのベースラインに基づきます。ベースラインからの偏差により、侵入試行を判別します。たとえば、オフピーク時にログオン試行が増加している場合、コンピュータに脅威が迫っている可能性があります。異常検知の利点は、攻撃方法を正確に知らなくても、攻撃であることを識別できることです。

  • 攻撃パターンの認知 -攻撃の既知のパターンに基づいて攻撃であることを識別します。たとえば、ほとんどの Web サーバー攻撃では、容易に識別可能な共通のパターンがあります。着信するアプリケーション トラフィックとデータベース化した攻撃パターンとを比較することで、侵入検知システムは攻撃を識別しますこの方法の短所は、新たな攻撃パターンを識別するために、攻撃パターンのデータベースを頻繁に更新する必要があることです。

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

脆弱性の評価

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

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

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

  • データベースの更新メカニズム - ツールが短期間で陳腐化することがないように、脆弱性の署名を更新するための、自動化された方法が用意されていることが必要です。

  • 脆弱性の誤認を最小限にする - セキュリティとは無関係のイベントの検査で時間を無駄にすることのないように、脆弱性の疑いのある場合でも、対象を絞り込むことが必要です。

  • 結果をデータベースに保存できる機能 - 長期的なセキュリティ上の傾向分析および変更点の検知を実施できるように、スキャン結果を保存できることが必要です。

  • 脆弱性対応のソリューション - 脆弱性が見つかった場合、脆弱性の改善方法に関するドキュメントを提供、または脆弱性を保護するタスクを実行するスクリプトを提供しているものであるべきです。

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

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

ページのトップへ

まとめ

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

詳細情報

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

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

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

ページのトップへ

目次

ページのトップへ