Cisco Intrusion Detection System アプライ アンスおよびモジュール インストレーション コンフィギュレーション ガイド
侵入検知システムのアーキテクチャ
侵入検知システムのアーキテクチャ
発行日;2012/02/05 | 英語版ドキュメント(2010/02/22 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 10MB) | フィードバック

目次

侵入検知システムのアーキテクチャ

システムの概要

ソフトウェア アーカイブの概要

show version コマンドの出力

ユーザ対話

バージョン 4.x の新機能

システムのコンポーネント

MainApp

SensorApp

AuthenticationApp

ユーザの認証

センサーにおける認証の設定

TLS および SSH 信頼関係の管理

LogApp

NAC

NAC について

NAC 制御デバイス

NAC の機能

ACL と VACL

再起動時の状態の維持

接続ベースおよび無条件のブロッキング

PIX Firewall によるブロッキング

Catalyst 6000 によるブロッキング

TransactionSource

WebServer

CLI

ユーザ アカウント ロール

サービス アカウント

CLI の動作

正規表現の構文

EventStore

EventStore について

主なデータ構造

IDS イベント

システム アーキテクチャの詳細

通信

IDAPI

RDEP

センサーのディレクトリ構造

アプリケーションの概要

侵入検知システムのアーキテクチャ

この付録では、IDS 4.x のシステム アーキテクチャについて説明します。この付録は、次の内容で構成されています。

「システムの概要」

「システムのコンポーネント」

「システム アーキテクチャの詳細」

「アプリケーションの概要」

システムの概要

Cisco IDS ソフトウェアは、アプライアンスとモジュールの 2 つのプラットフォームにインストールできます(現在のアプライアンスとモジュールについては、「サポートされるセンサー」を参照してください)。

ここでは、次の内容について説明します。

「ソフトウェア アーカイブの概要」

「show version コマンドの出力」

「ユーザ対話」

「バージョン 4.x の新機能」

ソフトウェア アーカイブの概要

IDS ソフトウェアは、Linux オペレーティング システム上で動作します。Linux OS を強化するために、不要なパッケージの削除、使用しないサービスの無効化、ネットワーク アクセスの制限、およびシェルへのアクセスの停止を行いました。

図 A-1 に、ソフトウェア アーキテクチャを示します。

図 A-1 システム設計

 

IDS ソフトウェアには、次の IDS アプリケーションが含まれています。


) 各アプリケーションには、それぞれ独自の XML 形式の構成ファイルがあります。


MainApp:システムの初期化、他のアプリケーションの起動および停止、OS の構成、およびプラットフォームのアップデートを行います。

SensorApp(分析エンジン):パケットのキャプチャと分析を行います。

AuthenticationApp(認証):ユーザが CLI、IDM、または Remote Data Exchange Protocol(RDEP)アクションを実行できることを確認します。

LogApp(ロガー):アプリケーションのすべてのログ モジュールをログ ファイルに書き出し、エラー メッセージは EventStore に書き出します。

NAC(ネットワーク アクセス):alert イベントが発生したときにリモート ネットワーク デバイス(PIX Firewall、ルータ、およびスイッチ)がブロッキング機能を発動するように管理します。Network Access Controller(NAC)は、制御対象のネットワーク デバイスに関してアクセス コントロール リスト(ACL)を作成して管理したり、他の RDEP サーバに対して shun コマンドを使用します(PIX Firewall)。

ctlTransSource(トランザクション ソース):センサーに制御トランザクションの送信を許可します。これは、NAC のマスター ブロッキング センサー(MBS)機能を有効化するために使用されます。

cidwebserver(WebServer):IDS サービスを提供するいくつかのサーブレットを使用することにより、Web インターフェイス、および RDEP を使用した他の IDS デバイスとの通信を提供します。これらのサーブレットは、実行時に cidWebserver プロセスにロードされる共有ライブラリです。

IDM:Web ベースの IDM 管理インターフェイスを提供します。

イベント サーバ:Security Monitor などの外部管理アプリケーションに、イベントを提供するために使用されます。

トランザクション サーバ:IDS MC などの外部管理アプリケーションに、センサーに対する制御トランザクションの送信を許可します。

IP ログ サーバ:外部システムに IP ログを提供するために使用されます。

cidcli(CLI):Telnet または SSH を通じてセンサーに正しくログインすると実行されるインターフェイス。CLI で作成されたすべてのアカウントは、CLI をアカウントのシェルとして使用します(サービス アカウントは例外。許可されるサービス アカウントは 1 つだけです)。使用できる CLI コマンドは、ユーザの権限に依存します。

EventStore:IDS イベント(error、status、alert の各システム メッセージ)を格納するために使用され、CLI、IDM、または RDEP からアクセスできるインデックス付きストア。

show version コマンドからの出力例については、「show version コマンドの出力」を参照してください。センサー アプリケーションのリストと、そのステータスが示されています。

すべての IDS アプリケーションは、共通 API(IDAPI)を通じて相互に通信します。リモート アプリケーション(他のセンサー、管理アプリケーション、およびサードパーティ ソフトウェア)は、RDEP および Intrusion Detection Interchange and Operations Messages(IDIOM)プロトコルを通じて他のセンサーと通信します。

センサーには、次のパーティションがあります。

アプリケーション パーティション:フル IDS システム イメージ。

メンテナンス パーティション:IDSM-2 のアプリケーション パーティションのイメージを再作成するために使用される、特殊な目的の IDS イメージ。すべての設定が失われます。

リカバリ パーティション:アプライアンスのリカバリに使用される、特殊な目的のイメージ。リカバリ パーティションで起動すると、アプリケーション パーティションを完全に再作成することができます。ネットワーク設定は保存されますが、それ以外のすべての設定は失われます。


) IDSM-2 と NM-CIDS には、リカバリ パーティションはありません。


show version コマンドの出力

show version コマンドのサンプル出力を次に示します。すべてのセンサー アプリケーションと、その現在のステータスが表示されます。

sensor# show version
Application Partition:
 
Cisco Systems Intrusion Detection Sensor, Version 4.1(3)S61
 
OS Version 2.4.18-5smpbigphys
Platform: IDS-4235
Sensor up-time is 20 days.
Using 214319104 out of 921522176 bytes of available memory (23% usage)
Using 596M out of 15G bytes of available disk space (5% usage)
 
 
MainApp 2003_Oct_10_11.16 (Release) 2003-10-10T11:01:13-0500 Running
AnalysisEngine 2003_Oct_10_11.16 (Release) 2003-10-10T11:01:13-0500 Running
Authentication 2003_Oct_10_11.16 (Release) 2003-10-10T11:01:13-0500 Running
Logger 2003_Oct_10_11.16 (Release) 2003-10-10T11:01:13-0500 Running
NetworkAccess 2003_Oct_10_11.16 (Release) 2003-10-10T11:01:13-0500 Running
TransactionSource 2003_Oct_10_11.16 (Release) 2003-10-10T11:01:13-0500 Running
WebServer 2003_Oct_10_11.16 (Release) 2003-10-10T11:01:13-0500 Running
CLI 2003_Oct_10_11.16 (Release) 2003-10-10T11:01:13-0500
 
 
Upgrade History:
 
* IDS-K9-min-4.1-1-S47 12:00:00 UTC Thu Jun 30 2005
IDS-K9-sp-4.1-3-S61.rpm.pkg 14:14:55 UTC Fri Feb 20 2004
 
Recovery Partition Version 1.2 - 4.1(1)S47
 

ユーザ対話

IDS は、CLI、IDM、または IDS MC か、RDEP を使用する他のアプリケーションから設定できます。

IDS ソフトウェアとは、次の方法で対話できます。

センサーのパラメータを設定する。

CLI で setup を使用して、IDS の初期設定を生成します。具体的には、ネットワーク パラメータ、時刻、および許可されるホストを設定します。通常、これは新しいセンサーに関して 1 回だけ行います。

ブロッキングおよびインターフェイスを設定する。

設定を調整する。

通常、デフォルトの設定には変更を加える必要があります。これは、主に、ネットワーク トラフィックを監視するアプリケーションの一部であるセンシング エンジン(SensorApp)について行います。ネットワークに IDS を初めてインストールした後、IDS が効率的に動作し、役に立つと考えられる情報だけを生成するようになるまで調整を加えることができます。

IDS をアップデートする。

自動アップデートをスケジュールすることも、アプリケーションおよびシグニチャ データ ファイルに今すぐアップデートを適用するように要求することもできます。

情報を取得する。

システムからデータ(status、error、alert の各メッセージ)および iplogs を取得できます。また、統計情報および診断情報も取得できます。

バージョン 4.x の新機能

IDS 4.x システム アーキテクチャには、次の新機能があります。

XML ドキュメントによってトークンおよびコンフィギュレーション ファイルを置き換え

センサー設定、制御、ログ、およびイベント情報の伝達と保管には、IDIOM 使用によって規定される XML ドキュメントが使用されます。

ポストオフィス プロトコルから RDEP への変更

RDEP は、HTTP/HTTPS プロトコルを使用して、センサーと外部システムの間で XML ドキュメントを伝達します。ポストオフィスは、アラームをプッシュすることと、センサーごとに 1000 個までのアラームをキューイングすることによって動作していました。RDEP クライアントでは、センサーからアラートをプルし、アラートを見逃す確率が低下します。

バージョン 4.x のオープン システム化


) 「オープン」とは、シスコが仕様を提供することにより、センサーを設定したりセンサーによって生成されたイベントを監視するアプリケーションを人々が作成できるということを意味します。


アラームおよび設定は、オープン標準である HTTP/HTTPS および XML に基づく RDEP と IDIOM を使用して伝えられます。標準的な通信プロトコルを使用したセキュアでオープンなシステムを提供することで、内部での統合もサードパーティとの統合も促進されます。

バージョン 4.x のスケーラビリティ拡張

ギガビット センシングを提供

ポストオフィス アーキテクチャ固有のスケーリングおよびパフォーマンス上の制限に対処

管理コンソールがサポートするセンサーの数の増加を可能にする、プッシュ モデルからプル モデルへの変更

センサーの大規模な展開、管理に対するサポートの強化

バージョン 4.x のセキュリティ拡張

OS シェル アクセスから CLI への変更

以前のシングル netrangr アカウントから、マルチレベル パーミッション(administrator、operator、viewer、service)によるマルチユーザ サポートへの変更

Solaris OS から強化された Linux OS への変更

ログ ファイルおよびログ ファイル管理からメモリマップ式循環バッファ EventStore に変更(sapd は使用しません)

CSPM および UNIX Director から、サポート対象シスコ管理オプションである CLI、IDM、または IDS MC に変更

信頼性の拡張

通信障害があってもアラームは失われない。

ネイティブ シェルによる設定ではなく CLI による設定による設定ミスの可能性の削減。センサーは、ワークステーションで実行されるアプリケーションのグループではなく、本来の意味のアプライアンスになりました。

バージョン 4.x は、次を含めた今後の IDS ロードマップをサポートするインフラストラクチャを確立

1 つのセンサーにつき複数のインターフェイスおよび VLAN

AAA 認証

false positive の減少

インラインの侵入防御

システムのコンポーネント

ここでは、IDS のコンポーネントをさらに詳しく説明します。

ここでは、次の内容について説明します。

「MainApp」

「SensorApp」

「ユーザの認証」

「LogApp」

「NAC」

「TransactionSource」

「WebServer」

「CLI」

「EventStore」

MainApp

MainApp には、次の役割があります。

すべての IDS コンポーネントおよびアプリケーションを初期化し、起動する。

MainApp は、オペレーティング システムによって起動されます。MainApp はアプリケーションを次の順序で起動します。

1. 動的および静的な設定を読み取り、検証します。

2. 動的設定データをシステム ファイルに書き込んで、データの 2 つの表し方が一致していることを確認します(たとえば、動的設定の IP アドレスは、システムのネットワーク ファイルと一致している必要があります)。

3. 共有システム コンポーネントである EventStore および IDAPI を作成します。

4. ステータス イベント サブスクリプションを開きます。

5. IDS アプリケーションを起動します(順序は静的設定で指定されます)。

6. 各アプリケーションからの初期化ステータス イベントを待機します。

60 秒間待機した後で、すべてのステータス イベントが受信されていない場合、MainApp は、起動していないアプリケーションを明らかにするエラー イベントを生成します。

7. ステータス イベント サブスクリプションを閉じます。

8. アップグレード スケジューラを起動します。

9. 制御トランザクション要求に登録し、受け取った内容に応じてサービスを提供します。

ソフトウェアのアップグレードをスケジュール、ダウンロード、およびインストールする。


) レガシー アプリケーションは idsupdate です。


通信ネットワーク インターフェイスを設定する。

MainApp は、ホスト名、IP アドレス、ネットマスクのほか、センサーのコマンドおよび制御インターフェイスにおけるデフォルトのゲートウェイを設定します。また、ネットワーク アクセス リストも設定します。


) レガシー アプリケーションは sysconfig-sensor です。


システム クロックを管理する。

次の 3 つのクロック管理モードがあります。

NTP:NTP サーバを使用してセンサーのクロックを同期します。

Manual:アプライアンスでのみ使用されます。このモードは、センサーのシステム クロックに依存します。

Switch/Router:IDSM-2 および NM-CIDS でのみ使用されます。

IDSM-2 は、スイッチ制御プロトコルを使用してクロックをスイッチ スーパーバイザのクロックと同期します。NM-CIDS は、ルータ/ブレード制御プロトコルを使用してクロックを親ルータのクロックに同期させます。


) 信頼性が高いため、NTP 時刻を使用することを推奨します。詳細については、「センサーでの時刻の設定」を参照してください。


自身をシャットダウンし、すべての IDS コンポーネントおよびアプリケーションをクリーンにシャットダウンする。

MainApp は、それ自身とすべての IDS コンポーネントおよびアプリケーションを次の順序でシャットダウンします。

1. 制御トランザクション要求の登録を解除します。

2. アップデート スケジューラを停止します。

3. evStatus イベント サブスクリプションを開きます。

4. 静的設定に指定されている順序の逆順で、IDS アプリケーションを停止します。

各アプリケーションに、シャットダウンするように通知する割り込み信号が送信されます。

5. 各アプリケーションからの exit evStatus イベントを待機します。

60 秒間待機した後で、すべてのステータス イベントが受信されていない場合、mainApp は、エラー メッセージを生成し、続行します。

6. evStatus イベント サブスクリプションを閉じます。

7. オペレーティング システムのシャットダウンをトリガーする前に MainApp が終了するまで待機するユーティリティを起動します。

8. 共有システム コンポーネントである EventStore および IDAPI を破棄します。

9. MainApp を終了します。

10. オペレーティング システムをリブートします。


) システム リブートは、オペレーティング システムのリブートがトリガーされる点を除いて、システム シャットダウンと機能的に同じです。


MainApp は、 show version コマンドへの応答として次の情報を表示します。

センサーのビルド バージョン

MainApp のバージョン

実行中の各アプリケーションのバージョン

インストールされている各アップグレードのバージョンおよびタイムスタンプ

インストールされている各アップグレードの次のダウングレード バージョン

プラットフォームのバージョン(IDS-4240、WS-SVC-IDSM2 など)

他のパーティションにあるセンサーのビルドのバージョン

MainApp は、ホストの統計情報も収集します。

SensorApp

センシング エンジンである SensorApp は、VirtualSensor と VirtualAlarm という 2 つの主要なコンポーネントから構成されています。これらは、次の 9 個の主要な機能ユニットから構成されています。


) VirtualSensor を使用すると、1 つのアプライアンスで複数の仮想センサーを実行し、それぞれに異なるシグニチャの動作とトラフィック供給を設定できますが、現在の IDS 4.x でサポートする仮想センサーは 1 つだけです。



) レガシー アプリケーションは packetd です。


カーネル メモリ管理モジュール(KMMM):リング バッファへのアクセスを調停することにより、リングおよびデータの整合性を維持します。

パケット キャプチャ モジュール(PCM):パケットをキャプチャして、その後の処理のためにカーネル/ユーザ共有メモリ リング バッファに配置します。

L2/L3/L4 パーサー(L2/L3/L4P):L2/3/4 パケット情報を解析して、必要な情報を IDS ヘッダーに配置します。必要な場合、パケットの IDS ヘッダーは、フラグメント再構築ユニットによる再構築に備えてマークされます。

フラグメント再構築ユニット(FRU):処理を要求するマークの付いたパケットを処理します。FRU には、再構築プロセスのために独自のリング バッファがあります。

TCP ストリーム再構築ユニット(SRU):パケットが既知のストリームに属しているか、新しいストリームの最初のパケットであるかを判断します。SRU は、事前定義済みの再構築制約に従って、パケットをダウンストリーム処理のためにキューイングするか、ドロップするかを決定します。

正規表現検索エンジン(RSSE):ストリームおよびパケット ペイロードに、他のデータと組み合わせると、攻撃されていることが判明する場合がある特定のパターンの存在を分析する際に使用されます。

シグニチャ マクロエンジン(SME):一定のカテゴリのさまざまなシグニチャをサポートします。エンジンは、パーサーとインスペクタで構成されています。各エンジンには規定のパラメータのセットがあり、パラメータには使用可能な範囲や値のセットがあります。

アラート生成モジュール(AGM):alert イベントの生成を求めるすべての要求を処理します。次に AGM は、適切なアラート メッセージを生成して、IDAPI インターフェイスに表示します。また AGM は、TCP リセット、IP セッション ログインについてログに記録されるパケットのルーティング、およびブロックのための NAC への通知も発行します。

構成管理モジュール(CMM):センサーの設定を管理します。

AuthenticationApp

AuthenticationApp には、次の役割があります。

ユーザの ID を認証する。

ユーザのアカウント、権限、キー、および証明書を管理する。

AuthenticationApp、およびセンサー上の他のアクセス サービスで使用する認証方法を設定する。

ここでは、次の内容について説明します。

「ユーザの認証」

「センサーにおける認証の設定」

「TLS および SSH 信頼関係の管理」

ユーザの認証

ユーザが WebServer や CLI などのサービスを通じてセンサーにアクセスしようとするときは、ユーザの ID を認証し、ユーザの権限を確立する必要があります。ユーザにアクセスを提供するサービスは、ユーザの ID を認証するために、AuthenticationApp に対して execAuthenticateUser 制御トランザクション要求を開始します。通常、制御トランザクション要求にはユーザ名とパスワードが含まれています。または、SSH によって確認されたキーによってユーザの ID を認証できます。

AuthenticationApp は、execAuthenticateUser 制御トランザクション要求に対して、ユーザの ID の認証を試みることによって応答します。AuthenticationApp は、ユーザの認証ステータスおよび権限を含む制御トランザクション応答を返します。ユーザの ID を認証できない場合、AuthenticationApp は、非認証ステータスと匿名ユーザ権限を制御トランザクション応答として返します。制御トランザクション応答は、アカウントのパスワードが期限切れであるかどうかも示します。execAuthenticateUser 制御トランザクションを開始することによってユーザを認証するユーザ インターフェイス アプリケーションは、ユーザにパスワードの変更を要求します。

AuthenticationApp は、基盤となるオペレーティング システムを使用してユーザの ID の認証を確認します。すべての IDS アプリケーションは、AuthenticationApp に制御トランザクションを送信します。AuthenticationApp は、オペレーティング システムを使用してその応答を作成します。

リモート シェル サービスである Telnet と SSH は、IDS アプリケーションではありません。これらは、オペレーティング システムを直接呼び出します。ユーザが認証されていれば、オペレーティング システムは IDS CLI を起動します。この場合、CLI は特殊な形式の execAuthenticateUser 制御トランザクションを送信することにより、ログイン ユーザの権限レベルを判断します。次に CLI は、この権限レベルに応じて、使用可能にするコマンドを用意します。

センサーにおける認証の設定

ユーザ アクセスに適切なセキュリティを確立するために、センサーで認証を設定する必要があります。センサーをインストールすると、初期アカウントとして、パスワードの期限が切れている cisco というアカウントが作成されます。センサーに対する管理アクセス権を持ったユーザは、デフォルトの管理アカウント(cisco)を使用してセンサーにログインすることにより、CLI または IDS マネージャを通じてセンサーにアクセスします。CLI で、管理者はパスワードの変更を要求されます。IDS マネージャは、setEnableAuthenticationTokenStatus 制御トランザクションを開始することによってアカウントのパスワードを変更します。

CLI または IDS マネージャを通じて、管理者は、ユーザ名とパスワード、SSH 認証キーなどの使用する認証方法を設定します。管理者用のアプリケーションは、認証設定を確立するために setAuthenticationConfig 制御トランザクションを起動します。

認証設定には、アカウント ロッキングの処理方法を指定するログイン試行の上限値が含まれています。アカウント ロッキングは、ログインの試みが連続して失敗した回数が、指定されたログイン試行の上限値を超えると起動されます。アカウントがロックされると、その後のログインの試行はすべて拒否されます。アカウントのロックを解除するには、setEnableAuthenticationTokenStatus 制御トランザクションを使用してアカウントの認証トークンをリセットします。アカウント ロッキング機能は、ログイン試行の上限値を 0 に設定すると無効になります。

管理者は、CLI または IDS マネージャから新しいユーザ アカウントを追加できます。詳細については、「ユーザ アカウント ロール」を参照してください。

TLS および SSH 信頼関係の管理

IP ネットワーク上の暗号化通信は、パケット内のデータを復号化するために必要な秘密鍵を、交換されるパケットだけから受動的攻撃者が発見できないようにすることで、データ プライバシーを実現します。

しかし、同じような危険性を持つ攻撃ベクトルとして、接続のサーバ側であるように装う詐称があります。すべての暗号化プロトコルには、クライアントがこの種の攻撃から身を守るための手段が用意されています。IDS は、SSH と TLS という 2 つの暗号化プロトコルをサポートしています。また、AuthenticationApp は、センサーが暗号化通信のクライアントまたはサーバになる場合の信頼を管理するのに役立ちます。

IDS WebServer および SSH サーバは、暗号化通信のサーバ エンドポイントです。これらは、秘密鍵によって ID を保護し、接続してくるクライアントに公開鍵を提供します。TLS では、この公開鍵は X.509 証明書の中に含まれています。X.509 証明書には他の情報も格納されています。センサーに接続するリモート システムは、接続確立時に受け取った公開鍵が、目的のものであることを確認する必要があります。

クライアントは、中間者攻撃を防御するため、信頼できる公開鍵のリストを維持する必要があります。この信頼性を確立するための詳細な手順は、プロトコルおよびクライアント ソフトウェアによって異なります。一般的に、クライアントは 16~20 バイトのフィンガープリントを表示します。クライアントが信頼を確立するように設定する人間のオペレータは、信頼の確立を試行する前に、アウトオブバンド方式を使用してサーバのキー フィンガープリントを取得する必要があります。フィンガープリントが一致すると信頼関係が確立され、その後、クライアントは自動的にそのサーバに接続でき、リモート サーバが詐称者でないことを確信できます。

show ssh server-key および show tls fingerprint を使用して、センサーのキー フィンガープリントを表示できます。センサー コンソールに直接接続したときにこれらのコマンドの出力を記録しておくと、後から信頼関係を確立する際、その情報を使用することにより、ネットワークを通じてセンサーの ID を確認できます。

たとえば、最初に Microsoft Internet Explorer(MSIE)Web ブラウザーを通じてセンサーに接続したときには、証明書が信頼されていないというセキュリティ警告のダイアログボックスが表示されます。MSIE のユーザ インターフェイスを使用して証明書のサムプリントを調べます。この値は、 show tls fingerprint コマンドによって表示される SHA1 フィンガープリントに正確に一致する必要があります。確認が終わったら、この証明書をブラウザーの信頼済み Certificate Authorities(CA)のリストに追加して、永続的な信頼を確立します。

この信頼性を確立するための手順は、TLS クライアント(IEV、IDS Security Monitor など)ごとに異なります。センサー自体に TLS クライアントが含まれており、制御トランザクションを他のセンサーに送信したり、アップグレードおよびコンフィギュレーション ファイルを TLS Web サーバからダウンロードするために使用されます。センサーの通信相手となる TLS サーバの信頼性を確立するには、 tls trusted-host コマンドを使用します。

同様に、センサーには SSH クライアントが含まれており、管理対象ネットワーク デバイスとの通信、アップグレードのダウンロード、リモート ホストへのコンフィギュレーション ファイルおよびサポート ファイルのコピーに使用されます。センサーが接続する SSH サーバとの信頼関係を確立するには、 ssh host-key コマンドを使用します。

TLS trusted certificate および SSH 既知ホストのリストは、 service TrustedCertificates コマンドおよび service SshKnownHosts コマンドで管理できます。

X.509 証明書には、信頼関係のセキュリティを向上させる追加情報が含まれていますが、これは混乱を招く場合があります。たとえば、X.509 証明書には、その証明書を信頼できる有効期間が含まれています。通常、これは証明書が作成された瞬間から始まる数年の期間です。使用時点で X.509 証明書が有効であることを厳密に確認するには、クライアント システムで正確なクロックを維持する必要があります。

また、X.509 証明書は、特定のネットワーク アドレスと結び付けられています。センサーはこのフィールドに、センサーのコマンドおよびコントロール インターフェイスの IP アドレスを挿入します。そのため、センサーのコマンドおよびコントロール IP アドレスを変更すると、サーバの X.509 証明書は再生成されます。新しい IP アドレスでこのセンサーを見つけ、新しい証明書を信頼するには、以前の証明書を信頼していた、ネットワーク上のすべてのクライアントを再設定しなければなりません。

AuthenticationApp の SSH 既知ホストおよび TLS 信頼済み証明書サービスを使用することにより、センサーを高いセキュリティ レベルで運用することができます。

LogApp

センサーは、すべてのイベント(alert、error、status、debug の各メッセージ)を永続的な循環バッファに記録します。また、センサーは IP ログも生成します。このメッセージと IP ログには、CLI、IDM、および RDEP クライアントからアクセスできます。


レガシー アプリケーションは loggerd および sapd です。


IDS アプリケーションは、LogApp を使用してメッセージを記録します。LogApp は、ログ メッセージを debug、timing、warning、error、fatal の 5 段階の重大度のいずれかで送信します。LogApp は、ログ メッセージを、循環式のテキスト ファイルである /usr/cids/idsRoot/log/main.log に書き込みます。ファイルがサイズの上限に達すると、古いメッセージは新しいメッセージによって上書きされます。したがって、main.log では、最後に書き込まれたメッセージが末尾にあるとは限りません。main.log に書き込まれた最新の行を見つけるには、「= END OF FILE =」を検索してください。

main.log は、 show tech support コマンドの出力に含まれます。メッセージが warning またはそれよりも上(error または fatal)のレベルで記録されると、LogApp はメッセージを evError イベントに変換して(対応するエラーの重大度で)、EventStore に挿入します。


) 技術サポート情報を表示する手順については、「技術サポート情報の表示」を参照してください。イベントを表示する手順については、「イベントの表示およびクリア」を参照してください。


LogApp は、informational 以上のレベルで cron メッセージ以外のすべての syslog メッセージ(*.info;cron.none)を受信し、エラーの重大度を Warning に設定してから evErrors として EventStore に挿入します。LogApp およびアプリケーションのロギングは、service logger コマンドによって制御されます。

LogApp は、ロギング ゾーンごとにロギング重大度を制御することにより、各アプリケーションが生成するログ メッセージを制御できます。ユーザは、TAC のエンジニアまたは開発者の依頼および指示の下で、ロガー サービスの individual-zone-control にのみアクセスします。トラブルシューティングのために、TAC はデバッグ ロギングを依頼することがあります。詳細については、「デバッグ ロギングをイネーブルにする」を参照してください。

NAC

ここでは、ルータ、スイッチ、および PIX Firewall でブロックを起動および停止する IDS アプリケーションである NAC について説明します。 block は、特定のホスト IP アドレスまたはネットワーク アドレスに関する受信/送信トラフィックをブロックするために、デバイス設定または ACL で使用するエントリです。


) レガシー アプリケーションは managed です。


ここでは、次の内容について説明します。

「NAC について」

「NAC 制御デバイス」

「NAC の機能」

「ACL と VACL」

「再起動時の状態の維持」

「接続ベースおよび無条件のブロッキング」

「PIX Firewall によるブロッキング」

「Catalyst 6000 によるブロッキング」

NAC について

NAC アプリケーションの主な役割は、イベントをブロックすることです。NAC アプリケーションはブロックに対応するとき、管理対象のデバイスと直接対話してブロックを有効化するか、Control Transaction Server を通じてマスター ブロッキング センサーにブロック要求を送信します。マスター ブロッキング センサー上の WebServer は、制御トランザクションを受け取るとそれを Control Transaction Server に渡し、Control Transaction Server は NAC アプリケーションに渡します。次に、マスター ブロッキング センサー上の NAC アプリケーションは、管理対象のデバイスと対話してブロックを有効化します。図 A-2 に、NAC アプリケーションを示します。

図 A-2 NAC アプリケーション

 


) NAC アプリケーションのインスタンスは、ネットワーク デバイスを制御できない場合、1 つだけ制御できる場合、多数を制御できる場合があります。NAC は、他の NAC アプリケーション、IDS 管理ソフトウェア、他のネットワーク管理ソフトウェア、システム管理者との間でネットワーク デバイスの制御を一切共有しません。1 つのセンサーについて実行できる NAC アプリケーションのインスタンスは 1 つだけです。


NAC は、次のいずれかに対応してブロックを開始します。

ブロック アクションが設定されたシグニチャから生成された alert イベント

CLI、IDM、または IDS MC から手動で設定されたブロック

ホストまたはネットワーク アドレスに対して永続的に設定されたブロック

NAC がデバイスをブロックするように設定すると、NAC はそのデバイスとの間で Telnet または SSH 接続を開始します。NAC は、デバイスごとに接続を維持します。ブロックが開始されると、NAC は制御対象の各デバイスに新しい設定または ACL のセットを(インターフェイス方向ごとに 1 つずつ)プッシュします。ブロックが完了すると、すべての設定または ACL はブロックを削除するようにアップデートされます。

NAC 制御デバイス

NAC は、次のデバイスを制御できます。

Cisco IOS 11.2 以降を実行する Cisco ルータ

スーパーバイザ エンジン上で実行される Supervisor Engine ソフトウェア 5.3(1) 以降、および RSM 上で実行される IOS 11.2(9)P 以降を使用する Catalyst 5000


) ブロッキングは RSM 上で実行されるため、RSM が必要です。


PFC がインストールされ、Catalyst ソフトウェア 5.3 以降が実行される Catalyst 6000

Catalyst ソフトウェア 5.4(3) 以降、および MSFC2 上の Cisco IOS 12.1(2)E 以降を使用する Catalyst 6000 MSFC2

NAC の機能

NAC には、次の機能があります。

3DES(デフォルト)または DES 暗号化を使用する Telnet および SSH 1.5

そのデバイスの NAC 設定で指定されたプロトコルのみが試行されます。何らかの理由で接続が失われると、NAC は再確立を試みます。

ルータ上の既存 ACL およびスイッチ上の既存 VACL

既存 ACL が、NAC によって制御されるルータのインターフェイス/方向に存在する場合は、この ACL を NAC によって生成される設定にマージするように指定できます。これは、preblock ACL を指定するとすべてのブロックの前に、postblock ACL を指定するとブロックの後に行われます。Catalyst 6000 VACL デバイス タイプには、NAC が制御するインターフェイスごとに preblock および postblock VACL を指定できます。PIX Firewall デバイス タイプでは、ブロックを実行するために別の API が使用され、NAC は PIX Firewall 上の既存 ACL には影響を与えません。


) Catalyst 5000 RSM および Catalyst 6000 MSFC2 ネットワーク デバイスは、Cisco ルータとして同じようにサポートされます。


詳細については、「ACL と VACL」を参照してください。

リモート センサーのリストに対するブロックの転送

NAC は、リモート センサーのリストにブロックを転送できます。そのため、複数のセンサーが実質的に集団となって 1 つのネットワーク デバイスを制御することができます。このようなリモート センサーをマスター ブロッキング センサーと言います。マスター ブロッキング センサーの詳細については、「センサーをマスター ブロッキング センサーにする設定」を参照してください。

ネットワーク デバイスのインターフェイスに対するブロッキングの指定

ルータの NAC 設定で、ブロッキングが実行されるインターフェイス/方向を指定できます。VACL 設定では、ブロッキングが実行されるインターフェイスを指定できます。


) PIX Firewall は、インターフェイスまたは方向に基づくブロックは行いません。したがって、この設定が PIX Firewall で指定されることはありません。


NAC は、同時に 250 までのインターフェイスを制御できます。

ホストまたはネットワークに対する指定された時間のブロッキング

NAC は、分単位で指定された時間だけ、または永続的にホストまたはネットワークをブロックできます。NAC は、ブロックの期限がいつ切れたかを判断し、期限切れになるとホストまたはネットワークのブロックを解除します。

重要なイベントのロギング

NAC は、ブロックまたはブロック解除アクションが正常に完了するか何らかのエラーが発生すると、確認イベントを書き込みます。また、NAC は、ネットワーク デバイスの通信セッションの切断と回復、コンフィギュレーション エラー、ネットワーク デバイスから報告されるエラーなどの重要なイベントも記録します。

詳細については、「NAC イベント」を参照してください。

NAC 再起動時におけるブロッキング状態の維持

シャットダウン/再起動が発生したとき、NAC は期限が切れていないブロックを再適用します。シャットダウン中に期限が切れたブロックは削除されます。


) NAC がブロッキング状態を正しく維持するためには、アプリケーションのシャットダウン中にシステムの時刻が変更されないことが条件です。


詳細については、「再起動時の状態の維持」を参照してください。

ネットワーク デバイス再起動時におけるブロッキング状態の維持

ネットワーク デバイスがシャットダウンされ、再起動されると、NAC は必要に応じてブロックを再適用したり、期限が切れたブロックを削除します。NAC は、NAC のシャットダウンおよび再起動が同時に、または重複して発生しても影響を受けません。

認証と認可

NAC は、リモート TACACS+ サーバの使用を含め、AAA 認証および認可を使用するネットワーク デバイスとの間で通信セッションを確立できます。

2 種類のブロッキング

NAC は、ホスト ブロックとネットワーク ブロックをサポートしています。ホスト ブロックは、接続ベースまたは無条件です。ネットワーク ブロックは、常に無条件です。

詳細については、「接続ベースおよび無条件のブロッキング」を参照してください。

NAT アドレス指定

NAC は、センサーに対して Native Address Translation(NAT)アドレスを使用するネットワーク デバイスを制御できます。ネットワーク デバイスを設定する際に NAT アドレスを指定すると、そのデバイスに対するブロックからセンサーのアドレスがフィルタ処理されるときに、ローカル IP アドレスの代わりにそのアドレスが使用されます。

シングル ポイント制御

NAC はネットワーク デバイスの制御を管理者や他のソフトウェアとの間で共有しません。設定をアップデートする必要がある場合は、変更が完了するまで NAC をシャットダウンしておきます。NAC は、IDS CLI または任意の IDS マネージャからイネーブル/ディセーブルにすることができます。NAC は、再イネーブルされると、自身を完全に初期化し直します。これには、制御対象のネットワーク デバイスごとに現在の設定の再読み込みすることも含まれます。


) PIX Firewall を含むすべてのネットワーク デバイスを設定する際は、NAC によるブロッキングを無効にすることを推奨します。


常に最大 250 のアクティブなブロック

NAC は、同時に 250 までのアクティブなブロックを維持できます。NAC は 65535 までのブロックをサポートしていますが、設定は 250 までにすることを推奨します。


) ブロックの数は、インターフェイス/方向の数とは異なります。


ACL と VACL

NAC が制御するインターフェイス/方向のパケットをフィルタ処理する場合は、すべてのブロックの前に ACL を適用したり(preblock ACL)、すべてのブロックの後に ACL を適用する(postblock ACL)ように NAC を設定できます。これらの ACL は、ネットワーク デバイス上で非アクティブな ACL として設定されます。preblock および postblock ACL は、インターフェイスおよび方向ごとに定義できます。NAC は、ネットワーク デバイス上のアクティブな ACL をアップデートする際、リストを取得してキャッシュしてから、ブロッキング Access Control Entries(ACE; アクセス コントロール エントリ)にマージします。ほとんどの場合は、ブロックの効果を妨げないように、既存 ACL を postblock ACL として指定します。ACL はパケットを、最初に検索された ACE エントリと照合することにより機能します。最初の ACE エントリでパケットが許可された場合、その後の拒否エントリは検索されません。

インターフェイス/方向ごとに異なる preblock および postblock ACL を指定することも、同じ ACL を複数のインターフェイス/方向に再利用することもできます。preblock リストを適用しない場合は、ホストやネットワークに対して never block オプションを使用したり、既存の設定ステートメントを使用して常にブロックしたりすることができます。forever block は、normal block でタイムアウト値を -1 にした場合と同じです。

NAC は、所有する ACL のみを変更します。NAC は、ユーザによって定義された ACL は変更しません。NAC が維持する ACL は、ユーザ定義の ACL では使用が禁じられている特殊な形式になっています。命名規則は、 IDS_<ifname>_[in|out]_[0|1] です。<ifname> は、ブロッキング インターフェイスに対して NAC 設定で指定された名前に対応します。

Catalyst スイッチでは、これは、ブロッキング インターフェイスの VLAN 番号です。これらの名前は、preblock および postblock ACL では使用しないでください。

Catalyst 6000 VACL では、preblock および postblock VACL を指定できます。また、インターフェイスのみが指定可能です(VLAN では方向は使用されません)。

PIX Firewall では、ブロッキングに異なる API が使用されるため、preblock または postblock ACL は使用できません 代わりに、PIX Firewall では ACL を直接作成する必要があります。詳細については、「PIX Firewall によるブロッキング」を参照してください。

再起動時の状態の維持

ブロックされているホストまたはネットワークのリストが変更されたときは、NAC が維持しているローカル ファイル(nac.shun.txt)に新しいリスト(および開始時のタイムスタンプ)が書き込まれます。NAC が起動すると、このファイルを使用して、制御対象のネットワーク デバイスにブロックのアップデートが必要かどうかが判断されます。ファイル内に期限が切れていないブロックが見つかると、ネットワーク デバイスの起動時に適用されます。NAC がシャットダウンするときは、有効なブロックが存在していても ACL に対して特別なアクションは行われません。nac.shun.txt ファイルが正確であるためには、NAC が実行されていない間にシステムの時刻が変更されないことが必要です。


注意 nac.shun.txt ファイルには手動による変更を加えないでください。

次のシナリオに、NAC が再起動時にどのように状態を維持するかを示します。

シナリオ 1

NAC が停止したときには 2 つのブロックが有効で、そのうちの 1 つは NAC が再起動する前に期限が切れます。再起動した NAC は、最初に nac.shun.txt ファイルを読み取ります。次に、preblock および postblock ACL または VACL を読み取ります。アクティブな ACL または VACL は、次の順序で構築されます。

1. allow sensor_ ip_address コマンド( allow sensor shun コマンドが設定されていない場合)

2. preblock ACL

3. 設定にある always block コマンドのエントリ

4. nac.shun.txt にある期限が切れていないブロック

5. postblock ACL

NAC 設定でホストが never block と指定されている場合、ACL の permit ステートメントには変換されません。代わりに、NAC にキャッシュされて、受信 addShunEvent イベントおよび addShunEntry 制御トランザクションをフィルタ処理するために使用されます。

シナリオ 2

preblock ACL および postblock ACL は指定されていませんが、アクティブな ACL が存在しています。新しい ACL は、次の順序で構築されます。

1. allow sensor_ ip_address コマンド( allow sensor shun コマンドが設定されていない場合)

2. 設定にある always block コマンドのエントリ

3. nac.shun.txt にある期限が切れていないブロック

4. permit IP any any コマンド

接続ベースおよび無条件のブロッキング

NAC は、ホストに関しては 2 種類、ネットワークに関しては 1 種類のブロッキングをサポートしています。ホスト ブロックは、接続ベースまたは無条件です。ネットワーク ブロックは、常に無条件です。

NAC は、ホスト ブロックを受信すると、その connectionShun 属性を調べます。connectionShun が true に設定されていると、NAC は接続ブロッキングを実行します。すべてのホスト ブロックは、宛先 IP アドレス、ソース ポート、宛先ポート、プロトコルといったオプションのパラメータを含むことができます。接続ブロックが実行されるためには、少なくともソース IP アドレスが存在している必要があります。

次の条件のとき、NAC は必要に応じて接続タイプからブロックを変換して、ブロックを無条件にします。

指定されたソース IP アドレスに対して、いずれかのタイプのブロックがアクティブである。

そのソース IP アドレスに対して、いずれかのタイプの新しいブロックが受信された。

新しいブロックのいずれかのオプション パラメータ(ソース ポートを除く)が以前のブロックと異なる。

ブロックがアップデートされると(既存のブロックがすでに有効になっているソース IP アドレスやネットワークに関して新しいブロックが受信された場合など)、既存のブロックの残り時間(分)が決定されます。新しいブロックの時間がこの残り時間以下の場合、アクションは何も発生しません。そうでない場合は、新しいブロックのタイムアウトによって既存のブロックのタイムアウトが置き換えられます。


注意 PIX Firewall は、ホストの接続ブロッキングをサポートしません。接続ブロックが適用されると、PIX Firewall は接続ブロックを無条件ブロックのように扱います。PIX Firewall は、ネットワーク ブロッキングもサポートしません。NAC が PIX Firewall に対してネットワーク ブロックの適用を試みることはありません。

PIX Firewall によるブロッキング

ここでは、PIX Firewall とブロッキングについて説明します。

ここでは、次の内容について説明します。

「shun コマンド」

「PIX Firewall と AAA」

「アドレス変換とブロッキング」

shun コマンド

NAC は、 shun コマンドを使用することにより、PIX Firewall に対してブロックを実行します。 shun コマンドの形式は次のとおりです。

IP アドレスをブロックする。

shun srcip [destip sport dport [port]]
 

IP アドレスのブロックを解除する。

no shun ip
 

すべてのブロックをクリアする。

clear shun
 

アクティブなブロック、または実際にブロックされているグローバル アドレスを表示する。

show shun [ip_address]
 

NAC は、 show shun コマンドに対する応答を使用して、ブロックが実行されたかどうかを判断します。

shun コマンドは既存の ACL、条件、アウトバウンド コマンドを置き換えるものではないので、既存の PIX Firewall 設定をキャッシュしたり、ブロックを PIX 設定にマージする必要はありません。


注意 NAC の実行中は、手動でブロックを実行したり既存の PIX Firewall 設定を変更したりしないでください。

block コマンドでソース IP アドレスのみを指定すると、既存のアクティブな TCP 接続は維持されますが、ブロックされたホストからの着信パケットはすべてドロップされます。

NAC が最初に起動したとき、PIX Firewall でアクティブなブロックが内部のブロッキング リストと比較されます。内部のリストに対応するエントリがないブロックは削除されます。

詳細については、「ブロッキング デバイスの設定」を参照してください。

PIX Firewall と AAA

NAC は、PIX Firewall での認証をサポートするためにローカル ユーザ名または TACACS+ サーバを使用します。PIX Firewall で認証に AAA を使用して TACACS+ サーバは使用しないように設定すると、NAC は PIX Firewall との通信に予約済のユーザ名 pix を使用します。

PIX Firewall で認証に TACACS+ サーバを使用する場合は、TACACS+ ユーザ名を使用します。AAA ログインを使用する一部の PIX Firewall 設定では、3 つのパスワード プロンプトが表示されます。初期 PIX Firewall パスワード、AAA パスワード、イネーブル パスワードです。NAC では、初期 PIX Firewall パスワードと AAA パスワードを同じにすることが要求されます。

アドレス変換とブロッキング

NAT または PAT を使用するように PIX Firewall を設定し、ネットワーク外にある PIX Firewall 上のパケットをセンサーがチェックする場合、ネットワーク内の PIX Firewall から開始されたホスト攻撃が検出されると、センサーは PIX Firewall から提供された変換アドレスのブロックを試みます。ダイナミック NAT アドレッシングを使用している場合は、ブロックが効果を発揮しなかったり、無害なホストがブロックされることがあります。PAT アドレッシングを使用している場合は、PIX Firewall が内部ネットワーク全体をブロックする可能性があります。これらの状況を回避するには、センサーを内部インターフェイスに配置するか、センサーがブロックを行わないように設定します。

Catalyst 6000 によるブロッキング

PFC カードが取り付けられた Catalyst 6000 スイッチは、VACL を使用してパケットをフィルタ処理します。VACL は、VLAN 間および VLAN 内のすべてのパケットをフィルタ処理します。

WAN カードが取り付けられている場合は MSFC ルータ ACL がサポートされ、MSFC2 を通じてセンサーがインターフェイスを制御するようにすることができます。


) MSFC2 カードは、Catalyst 6000 で VACL によるブロッキングを行うための設定の一部として必要なわけではありません。



注意 Catalyst 6000 で NAC を設定する場合は、制御インターフェイスで方向を指定しないでください。インターフェイス名は VLAN 番号です。preblock および postblock のリストは、VACL である必要があります。

Catalyst 6000 VACL に対しては、次のコマンドを使用できます。

既存の VACL を表示する。

show security acl info {aclname}
 

アドレスをブロックする(address spec は、ルータの ACL で使用されるものと同じです)。

set security acl ip {aclname} deny {address spec}
 

リストの構築後に VACL をアクティブにする。

commit security acl all
 

1 つの VACL をクリアする。

clear security acl map {aclname}
 

すべての VACL をクリアする。

clear security acl map all
 

VACL を VLAN にマップする。

set sec acl {aclname} {vlans}
 

詳細については、「ブロッキング デバイスの設定」を参照してください。

TransactionSource

TransactionSource は、ローカルで開始されたリモート制御トランザクションを RDEP および HTTP プロトコルを使用してリモートの宛先に転送するアプリケーションです。TransactionSource は、TLS または非 TLS 接続を開始し、その接続を使用してリモート制御トランザクションを HTTP サーバに伝えます。

TransactionSource は、リモート HTTP サーバでリモート制御トランザクションを実行するために必要なクレデンシャルを確立する必要があります。TransactionSource は、リモート ノード上の HTTP サーバにユーザ名/パスワードの形式で ID を提示することによってクレデンシャルを確立します(基本認証)。認証されると、ユーザ認証を含むクッキーが割り当てられます。この接続に関するすべての要求では、このクッキーを提示する必要があります。

CtlTransSource サーバ内の transactionHandlerLoop メソッドは、リモート制御トランザクションに対するプロキシとして機能します。ローカル アプリケーションがリモート制御トランザクションを起動すると、IDAPI は最初にトランザクションを TransactionSource に送信します。transactionHandlerLoop メソッドは、TransactionSource に送信されたリモート制御トランザクションを待機するループです。図 A-3 に、CtlTransSource 内の transactionHandlerLoop メソッドを示します。

図 A-3 CtlTransSource

 

transactionHandlerLoop は、リモート アドレッシングされたトランザクションを受信すると、そのリモート制御トランザクションをリモートの宛先に転送するように試みます。transactionHandlerLoop は、トランザクションを RDEP 制御トランザクション メッセージの形式にします。transactionHandlerLoop は、HttpClient クラスを使用して、リモート ノード上の HTTP サーバに対する RDEP 制御トランザクション要求を発行します。リモート HTTP サーバは、リモート制御トランザクションを処理し、適切な RDEP 応答メッセージを HTTP 応答として返します。リモート HTTP サーバが CIDS WebServer である場合、WebServer は Transaction Server サーブレットを使用してリモート制御トランザクションを処理します。

transactionHandlerLoop は、リモート制御トランザクションの発信側に対する制御トランザクションの応答として、RDEP 応答または失敗応答を返します。HTTP サーバが非認証ステータス応答(HTTP クライアントが HTTP サーバに対する十分なクレデンシャルを持っていないことを示す)を返す場合、transactionHandlerLoop は TransactionSource 専用のユーザ名とパスワードを使用してリクエスタの ID を認証して、トランザクション要求を再発行します。transactionHandlerLoop は、終了を指示する制御トランザクションを受信するか終了イベントが発生するまでループします。

WebServer

WebServer は、IDM に対して設定のサポートを提供します。また、IDS RDEP も提供します。これによってセンサーは、セキュリティ イベントの報告、IDIOM トランザクションの受信、および IP ログの提供が可能になります。

WebServer は、HTTP 1.0 および 1.1 をサポートしています。WebServer との通信には、パスワードなどの機密情報が関係することがよくあります。これらを攻撃者が盗聴することが可能になると、システムの安全性が大きく損なわれます。そのため、センサーは TLS がイネーブルな状態で出荷されます。TLS プロトコルは、SSL と互換性のある暗号化プロトコルです。

CLI

CLI は、Telnet、SSH、シリアル インターフェイスなどのすべての直接ノード アクセスについて、センサーのユーザ インターフェイスを提供します。センサー アプリケーションは CLI で設定します。基盤となる OS への直接接続は、サービス ロールを通じて許可されます。

ここでは、次の内容について説明します。

「ユーザ アカウント ロール」

「CLI の動作」

「サービス アカウント」

「正規表現の構文」

ユーザ アカウント ロール

ユーザ アカウントには、ロールが関連付けられています。このロールにより、ユーザが実行できる操作が決定されます。アカウントに関連付けることができるロールは、次の 4 つです。

administrator(管理者):このユーザ ロールは、最高レベルの権限を持っています。

管理者はセンサーに対するすべての機能を実行できます。これには次が含まれます。

ユーザの追加およびパスワードの割り当て

物理的なインターフェイスおよびインターフェイス グループの制御をイネーブル化およびディセーブル化

物理センシング インターフェイスのインターフェイス グループへの割り当て

設定エージェントまたは表示エージェントとしてセンサーへの接続を許可されているホストのリストの変更

センサーのアドレス設定の変更

シグニチャの調整

インターフェイス グループへの仮想センサー設定の割り当て

ルータの管理

operator(オペレータ):このユーザ ロールは、2 番目に高い権限を持っています。

オペレータは、センサーに関するすべての表示操作と一部の管理操作を実行できます。これには次が含まれます。

パスワードの変更

シグニチャの調整

ルータの管理

viewer(ビューア):このユーザ ロールは、最も低いレベルの権限を持ちます。

ビューアは、イベントの表示や一部のコンフィギュレーション ファイルの表示など、すべての表示操作を実行できます。唯一、管理操作として実行できるのは、自分のパスワードを変更することです。


ヒント 監視アプリケーションに必要なのは、センサーに対する viewer アクセス権だけです。CLI を使用して、ユーザ アカウントに viewer 権限を設定してから、監視アプリケーションがこのアカウントを使用してセンサーに接続するように設定します。


service(サービス):このユーザ アカウントは、CLI に直接アクセスできません。サービス アカウントのユーザは、CLI シェルではなく bash シェルに直接ログインします。詳細については、「サービス アカウント」を参照してください。

サービス アカウント

サービス アカウントは、サポートとトラブルシューティングのツールです。これによって TAC は、CLI シェルではなくネイティブ オペレーティング システムのシェルにログインすることができます。これは、デフォルトではセンサーには存在しません。センサーのトラブルシューティングのために TAC がこれを使用できるようにするためには、ユーザが作成する必要があります。サービス アカウントを作成する手順については、「サービス アカウントの作成」を参照してください。

1 つのセンサーで使用できるサービス アカウントは 1 つだけです。また、1 つのサービス ロールで使用できるアカウントも 1 つだけです。サービス アカウントのパスワードが設定またはリセットされると、ルート アカウントのパスワードが同じパスワードに設定されます。そのため、サービス アカウントのユーザはこの同じパスワードを使用して、root に su できます。サービス アカウントが削除されると、ルート アカウントのパスワードはロックされます。

サービス アカウントは、設定の目的で使用されることを想定していません。TAC の指示に基づき、サービス アカウントからセンサーに対して加えられた変更だけがサポートされます。サービス アカウントからオペレーティング システムに追加のサービスを加えること、およびそれを実行することは、他の IDS サービスの適切な実行に影響するため、シスコシステムズはこれをサポートしません。TAC は、追加のサービスが加えられたセンサーをサポートしません。

サービス アカウントへのログインは、ログ ファイル /var/log/.tac を確認することによって追跡できます。このファイルは、サービス アカウントによるログインの記録でアップデートされます。

CLI の動作

IDS CLI は、次のように動作します。

プロンプト

CLI コマンドの入力を求めるプロンプトは変更できません。

システムが質問を表示する場合やユーザ入力を待機する場合には、ユーザ インタラクティブ プロンプトが表示されます。角カッコ [ ] の中にデフォルト入力が表示されます。デフォルト入力をそのまま使用する場合は、 Enter キーを押します。

ヘルプ

コマンドのヘルプを表示するには、コマンドの後ろに ? と 入力します。また、入力を完了していないトークンの後ろに ? を 入力すると、コマンドを完成させるトークンが表示されます。次の例に、2 つの出力の比較を示します。

sensor# configure ?

terminal Configure from the terminal

sensor# configure

sensor (config)# ip n ?

name-server nat

sensor (config)# ip n


) 入力を完了していないトークンと ? の間にスペースを入力して ip n ? のようにすると、% Ambiguous command: ip n というエラーが返されます。


ヘルプでは、現在のモードで使用可能なコマンドだけが表示されます。

タブ補完

コマンドの完全な構文が不明な場合は、コマンドの一部を入力して Tab キーを押すと、コマンドを完成させることができます。

タブ補完に該当するコマンドが複数ある場合は、何も表示されず、入力した現在の行がそのまま返されます。

タブ補完およびヘルプでは、現在のモードで使用可能なコマンドだけが表示されます。

呼び出し

あるモードで入力されたコマンドを呼び出すには、上向きまたは下向きの矢印キーを使用するか、Ctrl キーを押した状態で P キー( Ctrl+P )または N キー( Ctrl+N )を押します。


ヘルプとタブ補完の要求は、呼び出しリストには記録されません。


空のプロンプトは、呼び出しリストの末尾を表します。

大文字と小文字の区別

CLI では、大文字と小文字は区別されませんが、エコーバックは大文字または小文字で入力したとおりに表示されます。たとえば、

sensor# CONF と入力してから Tab キーを押すと、センサーには次のように表示されます。

sensor# CONFigure

表示オプション

--More-- は、端末の出力が割り当てられた表示領域を超過したことを示すインタラクティブなプロンプトです。残りの出力を表示するには、Space キーを押して出力の次のページを表示するか、 Enter キーを押して一度に 1 行ずつ出力を表示します。

現在の行の内容をクリアして空白のコマンドラインに戻すには、Ctrl キーを押した状態で C キーを押すか( Ctrl+C )、 Q キーを押します。

キーワード

一般的に、コマンドの no 形式によって機能や関数をディセーブルにすることができます。キーワード no なしでそのコマンドを使用すると、ディセーブルになっていた機能または関数をイネーブルにすることができます。たとえば、コマンド shutdown はインターフェイスをディセーブルにし、コマンド no shutdown はインターフェイスをイネーブルにします。個別のコマンドのリスト、およびそのコマンドの no 形式でそれぞれ何が実行されるかの詳細な説明については、『 Cisco Intrusion Detection System Command Reference Version 4.1 』を参照してください。

設定ファイル内でデフォルト値を指定する service や tune-micro-engines などの設定コマンドでは、 default 形式を使用できます。コマンドの default 形式を使用すると、コマンドの設定がデフォルト値に戻されます。

正規表現の構文

正規表現は、一致する文字列を検索するために使用されるテキスト パターンです。正規表現は、プレーン テキストと特殊文字の組み合わせを含む文字列で、実行する検索の内容を表します。たとえば、数字を検索する場合の正規表現は「[0-9]」です。角カッコは、比較対象の文字が角カッコで囲まれた文字のいずれかに一致する必要があることを表します。0 と 9 の間のダッシュ(-)は、0 から 9 までの範囲を表します。したがって、この正規表現は 0 から 9 までの間の任意の文字、つまり数字に一致します。特定の特殊文字を検索する場合は、その特殊文字の前にバックスラッシュを使用する必要があります。たとえば、「\*」という単一文字の正規表現は、1 つのアスタリスクに一致します。

ここで定義されている正規表現は、POSIX Extended Regular Expression 定義のサブセットと類似しています。特に、「[..]」、「[==]」、および「[::]」という表現はサポートされていません。また、単一文字を表すエスケープ表現はサポートされています。

文字列の先頭の ^--「^A」は、文字列の先頭でのみ「A」に一致します。

左角カッコ([)の直後に置かれた ^--角カッコ内の他の文字をターゲット文字列から除外します。「[^0-9]」という表現は、ターゲット文字が数字でないことを表します。

$--ドル記号($)は文字列の末尾に一致します。「abc$」は、文字列の末尾にある部分文字列「abc」にのみ一致します。

|--選択文字(|)は、この文字の左右どちらにある表現もターゲット文字列に一致します。表現「a|b」は、「a」と「b」のどちらにも一致します。

.--ドット(.)は、任意の文字に一致します。

*--アスタリスク(*)は、表現の中でアスタリスクの左側にある文字が 0 回以上一致することを表します。

次の表現は、文字 a が存在しない場合も含めて、文字 a の任意の回数の繰り返しに一致します。

a*
 

+--プラス(+)は、アスタリスクに似ていますが、表現の中で + 記号の左側にある文字と少なくとも 1 回の一致が必要です。

次のパターンは、一致対象の文字列の中に少なくとも 1 文字存在していることが必要です。

a+
 

?--疑問符(?)は、その左側の文字と 0 回または 1 回一致します。

次のパターンは、文字列 bb または bab に一致します。

ba?b
 

()--カッコは、パターンが評価される順番に影響します。また、一致した部分文字列を別の表現に置き換える際のタグ付き表現としても使用されます。

[]--一連の文字を囲む角カッコ([ および ])は、角カッコ内の任意の文字がターゲット文字と一致できることを表します。

\--エスケープ文字は、エスケープ文字がないと特殊文字として解釈される文字を指定します。\xHH は、その値が (HH)、つまり 16 進数値 [0-9A-Fa-f] で表される値と同じ文字を示します。値は、ゼロ以外でなければなりません。BEL は \x07、BS は \x08、FF は \x0C、LF は \x0A、CR は \x0D、TAB は \x09、VT は \x0B と同じです。それ以外の文字「c」について、「\c」は「c」と同じです。

次の文字列は、任意の数のアスタリスク(*)に一致します。

\**
 

複数文字のパターンに繰り返し記号を適用するには、パターンをカッコで囲みます。次の例に示すパターンは、複数文字による文字列 ab の任意の回数の繰り返しに一致します。

(ab)*
 

次のパターンは、英数字ペアの 1 つ以上のインスタンスに一致しますが、存在しない場合には一致しません(空の文字列とは一致しません)。

([A-Za-z][0-9])+
 

繰り返し記号(*、+、または ?)を使用した一致の順番は、最も長い構成要素が最初に適用されます。ネストされた構成要素は、外側から内側の順番で一致が適用されます。結合された構成要素は、左側の構成要素から一致が適用されます。したがって、この正規表現は文字が数字の前に指定されているので、A9b3 には一致しますが 9Ab3 とは一致しません。

また、単一文字または複数文字のパターンをカッコで囲むことにより、パターンを記憶して正規表現内の別の場所で使用できるようにすることができます。出現済みのパターンを呼び出す正規表現を作成するには、カッコを使用することで特定のパターンを記憶することを示し、バックスラッシュ(\)の後に数字を続けることで記憶されているパターンを再利用します。数字は、正規表現パターン内でのカッコの出現位置を指定します。正規表現内の複数のパターンを記憶させた場合、\1 は最初に記憶されたパターン、\2 は 2 番目に記憶されたパターンとなります。次の正規表現では、カッコによって呼び出しを行っています。

a(.)bc(.)\1\2
 

この正規表現は、 a 、任意の 1 文字、 bc 、任意の 1 文字、最初の 任意の 文字、2 番目の 任意の 文字が順番に並んだ文字列に一致します。たとえば、aZbcTZT に一致します。ソフトウェアは、最初の文字が Z であることと、2 番目の文字が T であることを記憶し、この Z と T をその後の正規表現の中で使用します。

EventStore

ここでは、EventStore とその役割について説明します。

ここでは、次の内容について説明します。

「EventStore について」

「主なデータ構造」

「IDS イベント」

EventStore について

各 IDS イベントは、タイムスタンプ、および一意で単純な昇順の ID と共に EventStore に格納されます。このタイムスタンプを主キーとして使用することにより、固定サイズのインデックス化された EventStore にイベントをインデックス付けします。循環式の EventStore が設定済みサイズに達すると、最も古いイベントを上書きして新しいイベントが格納されます。EventStore に alert イベントを書き込むアプリケーションは SensorApp だけです。log、status、error イベントは、すべてのアプリケーションが EventStore に書き込みます。

固定サイズのインデックス化された EventStore では、時刻、タイプ、プライオリティ、および限られた数のユーザ定義属性に基づいて、シンプルなイベントのクエリーを実行できます。侵入イベントのそれぞれに low、medium、または high のプライオリティを割り当てると、1 回のイベント クエリーで目的のイベント タイプ、侵入イベントのプライオリティ、および時間範囲のリストを指定できます。

表 A-1 に、いくつかの例を示します。

 

表 A-1 IDS イベントの例

IDS イベント
タイプ
侵入イベントのプライオリティ
開始タイムスタンプ値
停止タイムスタンプ値
意味

status

--

0

最大値

格納されているすべての status イベントを取得します。

error、status

--

0

65743

時刻 65743 よりも前に格納されたすべての error および status イベントを取得します。

status

--

65743

最大値

時刻 65743 以降に格納された status イベントを取得します。

intrusion、network access

low

0

最大値

プライオリティ low で格納されているすべての intrusion および network access イベントを取得します。

network access、error、status、intrusion

medium、high

4123000000

4123987256

時刻が 4123000000 から 4123987256 の間に格納された、プライオリティが medium または high の network access、error、status、および intrusion イベントを取得します。

EventStore のサイズは、センサーが IDS イベント コンシューマに接続されていないときに IDS イベントをバッファリングするのに十分な大きさです。バッファリングが十分であるかどうかは、ユーザの要件と、使用するノードの能力に依存します。循環バッファ内の最も古いイベントは、最新のイベントによって置き換えられます。

主なデータ構造

さまざまな機能ユニットが、次の 7 種類のデータをやり取りします。

intrusion イベント:SensorApp によって生成されます。intrusion イベントはセンサーが検出します。

error イベント:ハードウェアまたはソフトウェアの不具合によって発生します。

status イベント:設定がアップデートされたなどの、アプリケーションのステータスの変更を報告します。

control transaction log イベント:センサーが制御トランザクションの結果を記録します。

network access イベント:ブロック要求などの NAC 向けアクション。

debug イベント:アプリケーションのステータスの変更に関するきわめて詳細なレポートで、デバッグに使用されます。

制御トランザクション データ:制御トランザクションに関連するデータ。たとえば、アプリケーションの診断データ、セッション ログ、およびアプリケーションとやり取りされる設定データ。

これら 7 種類のデータを IDS データ と総称します。6 つのイベント タイプ(intrusion、error、status、control transaction log、network access、debug)は特徴が似ており、 IDS イベント と総称されます。IDS イベントは、IDS を構成する数種類のアプリケーションによって生成され、他の IDS アプリケーションに受信されます。IDS イベントには、次のような特徴があります。

IDS イベントを生成するように設定されているアプリケーション インスタンスによって、自然発生的に生成されます。特定のイベントを生成するように他のアプリケーション インスタンスから要求されることはありません。

特定の宛先はありません。1 つまたは複数のアプリケーションによって格納され、その後、取得されます。

制御トランザクションは、次のタイプの要求に関係します。

アプリケーション インスタンスの設定データをアップデートする要求

アプリケーション インスタンスの診断データを求める要求

アプリケーション インスタンスの診断データをリセットする要求

アプリケーション インスタンスを再起動する要求

ブロック要求などの NAC 向け要求

制御トランザクションには、次のような特徴があります。

常に、1 つの応答を伴う 1 つの要求によって構成されます。要求と応答には、任意の量のデータが関連付けられる可能性があります。すべての応答には、少なくとも肯定応答または否定応答が含まれます。

ポイントツーポイントのトランザクションです。1 つのアプリケーション インスタンス(発信側)からもう 1 つのアプリケーション インスタンス(応答側)に送信されます。

IDS データは、XML 形式で XML ドキュメントとして表されます。システムには、ユーザ設定可能なパラメータがいくつかの XML ファイルで格納されます。

IDS イベント

IDS アプリケーションは、ある種のできごとが発生したことを報告するために IDS イベントを生成します。イベントは、sensorApp が生成するアラートやアプリケーションが生成するエラーなどのデータです。イベントは、EventStore というローカル データベースに格納されます。

5 種類のイベントがあります。

evAlert:ネットワーク アクティビティによってシグニチャがトリガーされたことを報告する alert イベント メッセージ

evStatus:IDS アプリケーションのステータスとアクションを報告する status イベント メッセージ

evError:応答アクションの試行中に発生したエラーを報告する error イベント メッセージ

evLogTransaction:各センサー アプリケーションによって生成された制御トランザクションを報告する log transaction メッセージ

evShunRqst:NAC がいつ shun 要求を発行したかを報告する shun 要求メッセージ

status メッセージおよび error メッセージは、CLI、IDM、および IEV を使用して表示できます。

SensorApp および NAC は、応答アクション(TCP リセット、IP ロギングの開始と停止、ブロッキングの開始と停止、トリガー パケット)をステータス メッセージとしてログに記録します。

ここでは、次の内容について説明します。

「alert イベント」

「status イベント」

「error イベント」

「log イベント」

「NAC イベント」

「イベント アクション」

alert イベント

alert イベントは、侵入攻撃が進行中であるか試みられたことを示す可能性がある、ある種の疑わしいアクティビティを通知します。alert イベントは、IDS シグニチャがネットワーク アクティビティによってトリガーされるときは常に、SensorApp アプリケーションによって生成されます。

alert イベントの例を次に示します。

evAlert: eventId=1066276939791336085 severity=informational
originator:
hostId: sensor
appName: sensorApp
appInstanceId: 3627
time: 2003/10/16 16:50:11 2003/10/16 11:50:11 CDT
interfaceGroup: 0
vlan: 0
signature: sigId=1001 sigName=Record Packet Rte subSigId=0 version=S37
participants:
attack:
attacker: proxy=false
addr: locality=OUT 4.1.1.2
victim:
addr: locality=OUT 10.2.1.2
alertDetails: Traffic Source: int0 ;
 

) alertDetails フィールドは、アラートの発生元になった特定のインターフェイスを示します。


status イベント

status イベントは、あるアプリケーションの状態変更が発生すると常に、IDS アプリケーションによって生成されます。evStatus の内容は、アプリケーションの状態のどの側面が変化したかを明らかにする要素と、状態の新しい値です。報告される状態情報はアプリケーションによって異なり、状態要素の多くはアプリケーションに固有です。


) エラーと警告は状態情報とは見なされず、evStatus ではなく evError を使用して報告されます。


evStatus イベント メッセージには、次の要素が含まれます。

applicationStarted:発生元のアプリケーションは実行を開始し、初期化を完了しました。このイベント メッセージは、アプリケーションのバージョンを示し、アプリケーションが正常に開始したことを確認するためのものです。

applicationStopped:指定されたアプリケーションは、意図せずシャットダウンされました。このイベント メッセージは、シャットダウンされたアプリケーションではなく、アプリケーションのシャットダウンを受け持つ管理アプリケーションによって送信されます。

certificatesChanged:ホストの X.509v3 証明書が変更されたことを示します。

configChanged:コンフィギュレーション ファイルが setConfig 制御トランザクション要求によって変更されたことを示します。

ipLogAdded:新しい IP ロギング セッションが要求されました。このイベント メッセージには、ログに記録されるアドレス、開始された時刻、および新しく作成されたロギング セッションの ID も含まれます。

ipLogCompleted:IP ロギング セッションが(パケット数またはタイムアウトのために)終了しました。イベント メッセージには、ログ セッションの ID が含まれます。

ipLogRemoved:IP ロギング ドキュメントを取得できなくなりました。参照するときのために、イベント メッセージには元のロギング セッションの ID が含まれていますが、ドキュメントが削除されているため、この ID は無効です。

ipLogStarted:IP ロギング セッションが開始し、少なくとも 1 つのパケットがログに記録されました。イベント ドキュメントには、ログに記録されるアドレス、開始された時刻、およびログ セッションの ID が含まれます。

loginAction:ユーザのログインやログアウトなどのログイン アクションが発生しました。

error イベント

error イベントは、IDS アプリケーションがエラー条件または警告条件を検出したときに、IDS アプリケーションが生成します。evError イベントには、エラー コードとテキストによるエラーの説明が含まれます。


注意 evError と <error> 要素は別のものであることに注意してください。evError は、イベントのタイプであり、イベント取得操作が正常に完了したときに返されるイベント ドキュメントの一部です。<error> 要素はドキュメントのルート要素の 1 つであり、失敗した操作(制御トランザクションなど)への応答として返されます。

error イベントの例を次に示します。

evError: eventId=1077226078696330133 severity=warning
originator:
hostId: firesafe
appName: login(pam_unix)
appInstanceId: 7475
time: 2004/03/03 17:05:56 2004/03/03 17:05:56 UTC
errorMessage: name=errSyslog session opened for user cisco by (uid=0)
 

log イベント

log イベントは、センサー アプリケーションによって制御トランザクションが処理されるたびに通知を行います。

log イベントの例を次に示します。

evLogTransaction: command=getVersion eventId=1077226078696330135 successful=true
originator:
hostId: sensor
appName: mainApp
appInstanceId: 1048
time: 2004/03/03 17:05:56 2004/03/03 17:05:56 UTC
requestor:
user: cids
application:
hostId: CONSOLE
appName: -cidcli
appInstanceId: 7476
 

NAC イベント

NAC は、IDIOM 制御トランザクションおよびイベントを通じて他の IDS アプリケーションと通信します。NAC は、内部状態が変化すると evStatus イベントを生成し、エラーが検出されると evError を生成します。

evShunRqst NAC イベントの例を次に示します。

evShunRqst: eventId=1094239199791041344
originator:
deviceName: Sensor1
appName: NetworkAccessControllerApp
appInstance: 654
time: 2004/09/21 18:43:10 1988/05/20 22:21:38
shunEntry:
shunInfo:
host: connectionShun=false
srcAddr: 1.1.1.1
destAddr: 0
srcPort: 0
destPort: 0
protocol: numericType=0 other
timeoutMinutes: 70
evAlertRef: hostId=esendHost 123456789012345678

イベント アクション

alert イベントによって、次のアクションをトリガーできます。


) これらのアクションは、CLI、IDM、または IDS MC で設定できます。


IP ロギング:イベントの構成要素に関係する、未加工の変更されていないパケットをキャプチャできます。ログ内の情報は、確認、ダメージ評価、および法的な証拠として使用されます。

IP ロギング システムは、すべてのストレージを起動時に割り当てます。その後、このデータ ストアは同じサイズのページに分割されます。ログは、書き込み時、ページに格納されます。使用可能なすべてのページがいっぱいになると、最も古いページが上書きされます。ページのマスター リストとページの内容は、システムによって保持されます。古いページが新しいログのために使用されると、マスター リストは、上書きするログの新しい開始時刻を示すようにアップデートされます。

TCP リセット:現在アクティブな TCP 接続上で検出された alert イベントへの応答として、その接続をリセットできます。

TCP リセットは、SensorApp によって実行されます。リセットを実行するように設定されたイベントの結果として、1 つの方向につき 100 個のリセット パケットが送信されます。リセットが設定されていても、TCP プロトコルを使用するように設定されていないアラートは、無視されます。

ブロッキング:イベントの結果としてルータおよび他のデバイス上の ACL を変更して、ネットワークに対するアクセス ポリシーに動的に影響を与えることができます。

ブロック要求は NAC に送られます。パフォーマンスへの影響と制御トランザクションの遅れを回避するために、要求はイベントの形式を取ります。

CapturePacket:アラート トリガー パケットをキャプチャできます。evAlert には不正なパケットが含まれます。シグニチャがこのアクションを実行するように設定するには、マスター エンジン パラメータ CapturePacket を True に設定します。True に設定すると、アラートが SummaryAlarm でない場合、現在のパケットが evAlert メッセージに付加されます。

IP ログ システムに問い合せを行って、ログ内の特定の時刻のパケットだけを取得することはできません。時間の範囲を与えると、要求された時間範囲を含むすべての内部ブロックから構成される 1 つのファイルが返されます。パケットのフィルタ処理はセンサー プラットフォームに大きな負荷がかかるため、さらにログ ファイルを絞り込むためには別のプラットフォームが必要です。IP ログ ファイルのフィルタ処理やそれ以外の操作を行うことができる数多くのツールが用意されています。

インターフェイスからログ ファイルをアクティブにするためには、そのインターフェイスがアクティブになっている必要があります。IP ログを消去したりセンサーをクリアする手段は用意されていません。すべてのログ ファイルを削除するには、センサーのイメージを再作成する必要があります。


) IDS 管理システムは、IP ログ情報を表示できませんが、CLI を使用することにより、CapturePacket フィールドを HEX および ASCII Base64 でデコードして表示できます。


システム アーキテクチャの詳細

ここでは、システム アーキテクチャの詳細について説明します。

ここでは、次の内容について説明します。

「通信」

「IDAPI」

「RDEP」

「センサーのディレクトリ構造」

通信

IDS アプリケーションは、Intrusion Detection Application Program Interface(IDAPI)というプロセス間通信 API を使用して内部的な通信を処理します。IDAPI はイベント データを読み書きし、制御トランザクションのメカニズムを提供します。IDAPI がどのように動作するかについては、「IDAPI」を参照してください。

外部との通信には、RDEP を使用します。RDEP は、IDS クライアントと IDS サーバの間で IDS イベント、IP ログ、設定、および制御メッセージを交換するために使用される、アプリケーション レベルの通信プロトコルです。RDEP 通信は、要求メッセージと応答メッセージで構成されます。RDEP クライアントが RDEP サーバへの要求メッセージを開始します。RDEP サーバが要求メッセージに対して応答メッセージで応答します。RDEP がどのように動作するかについては、「RDEP」を参照してください。

RDEP は、要求メッセージと応答メッセージに関して、イベント メッセージ、IP ログ メッセージ、トランザクション メッセージの 3 つのクラスを定義しています。イベント メッセージには、IDS の alert、status、および error メッセージが含まれます。クライアントは、IP ログ要求を使用してサーバから IP ログ データを取得します。トランザクション メッセージは、IDS サーバを設定および制御するために使用されます。

RDEP は、業界標準の HTTP、TLS/SSL、および XML を使用することにより、標準化されたインターフェイスを RDEP エージェント間で実現します。RDEP プロトコルは HTTP/1.1 プロトコルのサブセットです。すべての RDEP メッセージは、HTTP/1.1 メッセージとして有効です。RDEP は、RDEP エージェント間でのメッセージ交換に HTTP のメッセージ フォーマットおよびメッセージ交換プロトコルを使用します。

IDS マネージャを使用して、ネットワーク経由でセンサーにアクセス可能なホストを指定します。センサーは、同時に 1 つから 10 個の RDEP クライアントからの接続を受け入れます。クライアントは、時間範囲、イベントのタイプ(alert、error、または status)、およびレベル(alert = high、medium、low、または informational。error = high、medium、または low)に基づいて選択的にデータを取得します。イベントは、クエリー(1 回のバルク取得)、サブスクリプション(リアルタイムの永続的接続)、またはその両方によって取得されます。通信は TLS または SSL によって保護されます。


postofficedfileXferd、および IPSec の各レガシー アプリケーションは RDEP に置き換えられました。


IDIOM は、IDS によって報告されるイベント メッセージ、および侵入検知システムの設定と制御に使用される操作メッセージを定義するデータ形式の標準です。これらのメッセージは、IDIOM XML スキーマに準拠した XML ドキュメントによって構成されています。

IDIOM は、イベントと制御トランザクションという 2 種類のインタラクションをサポートしています。イベント インタラクションは、alert などの IDS イベントを交換するために使用されます。IDIOM は、イベント インタラクションにイベント メッセージとエラー メッセージという 2 種類のメッセージを使用します。制御トランザクションは、ホストが別のホストでアクションを開始したり、別のホストの状態を変更または読み取るための手段です。制御トランザクションでは、要求、応答、設定、エラーの 4 種類の IDIOM メッセージが使用されます。1 つのホスト内のアプリケーション インスタンス間で通信されるイベントおよび制御トランザクションは、ローカル イベントまたはローカル制御トランザクションと呼ばれ、ローカル IDIOM メッセージと総称されます。異なるホスト間で RDEP プロトコルを使用して通信されるイベントおよび制御トランザクションは、リモート イベントおよびリモート制御トランザクションと呼ばれ、リモート IDIOM メッセージと総称されます。

IDAPI

IDAPI は、すべてのアプリケーションが通信の際に使用するインターフェイスです。

SensorApp は、そのインターフェイス上のネットワーク トラフィックをキャプチャし、分析します。シグニチャが一致すると、SensorApp はアラートを生成します。このアラートは EventStore に格納されます。シグニチャがブロッキング応答アクションを実行するように設定されていると、SensorApp はブロック イベントを生成します。このイベントも EventStore に格納されます。図 A-4 に、IDAPI インターフェイスを示します。

図 A-4 IDAPI

 

各アプリケーションは、イベントおよび制御トランザクションを送受信するように IDAPI に登録します。IDAPI は次のサービスを提供します。

制御トランザクション

制御トランザクションを開始する。

インバウンド制御トランザクションを待機する。

制御トランザクションに応答する。

IDS イベント

リモート IDS イベントをサブスクライブする。受信したリモート IDS イベントは、EventStore に格納されます。

ローカル EventStore から IDS イベントを読み取る。

ローカル EventStore に IDS イベントを書き込む。

IDAPI は、アトミックなデータ アクセスを実現するために必要な同期メカニズムを備えています。

RDEP

リモート アプリケーションは、センサーから RDEP を通じてイベントを取得できます。リモート クライアントは、RDEP イベント要求をセンサーの WebServer に送信します。WebServer は、それを EventServer に渡します。EventServer は、IDAPI を通じて EventStore にクエリーを行い、結果を返します。図 A-5 に、RDEP を通じてセンサーからイベントを取得するリモート アプリケーションを示します。

図 A-5 RDEP を通じたイベントの取得

 

リモート アプリケーションは、RDEP を通じてセンサーにコマンドを送信できます。リモート クライアントは、RDEP 制御トランザクションをセンサーの WebServer に送信します。WebServer は、それを Control Transaction Server に渡します。Control Transaction Server は IDAPI を通じて制御トランザクションを適切なアプリケーションに渡し、アプリケーションが応答するまで待機してから、結果を返します。図 A-6 に、RDEP を通じてセンサーにコマンドを送信するリモート アプリケーションを示します。

図 A-6 RDEP を通じたコマンドの送信

 

センサーのディレクトリ構造

IDS 4.x のディレクトリ構造は次のとおりです。

/usr/cids/idsRoot:メイン インストール ディレクトリ。

/usr/cids/idsRoot/shared:システムのリカバリの際に使用されるファイルが格納されます。

/usr/cids/idsRoot/var:センサーの実行中に動的に作成されるファイルが格納されます。

/usr/cids/idsRoot/var/updates:アップデート インストレーション用のファイルとログが格納されます。

/usr/cids/idsRoot/var/virtualSensor:SensorApp が正規表現を分析するために使用するファイルが格納されます。

/usr/cids/idsRoot/var/eventStore:EventStore アプリケーションが含まれます。

/usr/cids/idsRoot/var/core:システムのクラッシュ時に作成される重要なファイルが格納されます。

/usr/cids/idsRoot/var/iplogs:iplog ファイルのデータが格納されます。

/usr/cids/idsRoot/bin:バイナリ実行可能ファイルが含まれます。

/usr/cids/idsRoot/bin/authentication:認証アプリケーションが含まれます。

/usr/cids/idsRoot/bin/cidDump:技術サポート向けのデータを収集するスクリプトが含まれます。

/usr/cids/idsRoot/bin/cidwebserver:WebServer アプリケーションが含まれます。

/usr/cids/idsRoot/bin/cidcli:CLI アプリケーションが含まれます。

/usr/cids/idsRoot/bin/nac:NAC アプリケーションが含まれます。

/usr/cids/idsRoot/bin/logApp:ロガー アプリケーションが含まれます。

/usr/cids/idsRoot/bin/mainApp:メイン アプリケーションが含まれます。

/usr/cids/idsRoot/bin/sensorApp:センサー アプリケーションが含まれます。

/usr/cids/idsRoot/bin/falcondump:IDS-4250-XL および IDSM-2 のセンシング ポートでパケット ダンプを取得するアプリケーションが含まれます。

/usr/cids/idsRoot/etc:センサーのコンフィギュレーション ファイルが含まれます。

/usr/cids/idsRoot/htdocs:WebServer の IDM ファイルおよび NSDB ファイルが含まれます。

/usr/cids/idsRoot/lib:センサー アプリケーションのライブラリ ファイルが含まれます。

/usr/cids/idsRoot/log:デバッグ用のログ ファイルが含まれます。

/usr/cids/idsRoot/tmp:センサーの実行中に作成される一時ファイルが格納されます。

アプリケーションの概要

表 A-2 に、IDS を構成するアプリケーションの概要を示します。

 

表 A-2 アプリケーションの概要

アプリケーション
説明

AuthenticationApp

IP アドレス、パスワード、デジタル証明書に基づいてユーザを許可および認証します。

CLI

コマンドライン入力を受け付け、IDAPI を使用してローカル設定を変更します。

IDS Event Viewer(IEV)1

intrusion、network access、status、error の各イベントをサブスクライブし、GUI にイベント情報を表示します。

EventServer2

リモート クライアントからイベントの RDEP 要求を受け付けます。

MainApp

設定を読み取ってアプリケーションを起動し、アプリケーションの開始および終了とノードの再起動を扱い、ソフトウェアのアップグレードを処理します。

NetworkAccessControllerApp(NAC)3

NAC は、各センサー上で実行されます。各 NAC は、ローカル EventStore の network access イベントをサブスクライブします。NAC の設定には、そのローカル NAC が制御するセンサーおよびネットワーク アクセス デバイスのリストが含まれます。network access イベントをマスター ブロッキング センサーに送信するように設定されている NAC は、デバイスを制御するリモート NAC にネットワーク アクセス制御トランザクションを送信します。これらのネットワーク アクセス アクション制御トランザクションは、IDS マネージャがネットワーク アクセス アクションを発行するときにも使用されます。

SensorApp4

監視されているネットワーク上のトラフィックをキャプチャして分析し、intrusion および network access イベントを生成します。ロギングをオン/オフする IP ロギング制御トランザクション、および IP ログ ファイルを送信および削除する IP ロギング制御トランザクションに応答します。

Control Transaction Server(CT Server)5

リモート RDEP クライアントからの制御トランザクションを受け付け、ローカル制御トランザクションを開始して、リモート クライアントに応答を返します。

Control Transaction Source(CT Source)6

リモート アプリケーションに向けられた制御トランザクションを待機し、RDEP を使用して制御トランザクションをリモート ノードに転送し、応答を発信側に返します。

IDS Device Manager(IDM)

HTML IDS 管理インターフェイスを提供する WebServer サーブレット。

WebServer

リモート HTTP クライアント要求を待機し、適切なサーブレット アプリケーションを呼び出します。

Syslog Monitoring アプリケーション

syslog および SNMP イベントをキャプチャして分析し、intrusion および network access イベントを生成します。

Alarm Channel アプリケーション

アラートを EventStore に送信する前に、フィルタ処理と関連付けを行います。

1.これは、リモート アプリケーションです。

2.これは、WebServer サーブレットです。

3.NAC は、レガシー IDS では managed と呼ばれていました。

4.SensorApp は、レガシー IDS では packetd と呼ばれていました。

5.これは、WebServer サーブレットです。

6.これは、リモート制御トランザクション プロキシです。