システム アプリケーション
(注) 各アプリケーションには、それぞれ独自の XML 形式の構成ファイルがあります。
Cisco IPS ソフトウェアには、次のアプリケーションが含まれています。
• MainApp:システムの初期化、他のアプリケーションの起動および停止、OS の構成、およびプラットフォームのアップグレードを行います。次のコンポーネントで構成されています。
– ctlTransSource(Control Transaction Server):センサーで制御トランザクションを送信できます。Attack Response Controller(以前の名称は Network Access Controller)のマスター ブロッキング センサー機能をイネーブルにするために使用されます。
– Event Store:IPS イベント(error、status、alert の各システム メッセージ)を格納するために使用され、CLI、IDM、IME、ASDM、または SDEE からアクセスできるインデックス付きストア。
– InterfaceApp:バイパス設定と物理設定を処理し、対になったインターフェイスを定義します。物理設定とは、速度、デュプレックス、および管理状態です。
– Logger:アプリケーションのすべてのログ メッセージをログ ファイルに書き込み、アプリケーションのエラー メッセージをイベント ストアに書き込みます。
– Attack Response Controller(以前の名称は Network Access Controller):alert イベントが発生したときのブロッキング機能を実装するためにリモート ネットワーク デバイス(ファイアウォール、ルータ、およびスイッチ)を管理します。ARC は、制御対象のネットワーク デバイス上で ACL を作成および適用するか、 shun コマンドを使用します(ファイアウォール)。
– NotificationApp:アラート ステータス イベントおよびエラー イベントによってトリガーされたときに SNMP トラップを送信します。NotificationApp は、パブリック ドメイン SNMP エージェントを使用します。SNMP GET は、センサーの全般的な健全性に関する情報を提供します。
– Web サーバ(HTTP SDEE サーバ):Web インターフェイスを持ち、複数のサーブレットを使用しながら SDEE プロトコルを介して他の IPS デバイスと通信して、IPS サービスを提供します。
– AuthenticationApp:CLI、IDM、IME、ASDM、または SDEE のアクションを実行する許可がユーザに付与されているかどうかを確認します。
• SensorApp(分析エンジン):パケットのキャプチャと分析を行います。
• CollaborationApp:IDAPI 制御トランザクション、セマフォ、共有メモリ、ファイル交換などのさまざまなプロセス間通信テクノロジーを使用して、MainApp および SensorApp とインターフェイスします。
• CLI:Telnet または SSH を通じてセンサーに正しくログインすると実行されるインターフェイス。CLI で作成されたすべてのアカウントは、CLI をアカウントのシェルとして使用します(サービス アカウントは例外。許可されるサービス アカウントは 1 つだけです)。使用できる CLI コマンドは、ユーザの権限によって異なります。
すべての Cisco IPS アプリケーションは、IDAPI という共通 API を通じて相互に通信します。リモート アプリケーション(他のセンサー、管理アプリケーション、およびサードパーティ ソフトウェア)は、SDEE プロトコルを通じてセンサーと通信します。
センサーには、次のパーティションがあります。
• アプリケーション パーティション:フル IPS システム イメージ。
• メンテナンス パーティション:IDSM2 のアプリケーション パーティションのイメージを再作成するために使用される、特殊な目的の IPS イメージ。メンテナンス パーティションのイメージを再作成すると、すべてのコンフィギュレーション設定が失われます。
• リカバリ パーティション:センサーのリカバリに使用される、特殊な目的のイメージ。リカバリ パーティションで起動すると、アプリケーション パーティションを完全に再作成することができます。ネットワーク設定は保存されますが、それ以外のすべての設定は失われます。
MainApp
ここでは、MainApp について説明します。次の事項について説明します。
• 「MainApp について」
• 「MainApp の役割」
• 「イベント ストア」
• 「NotificationApp」
• 「CtlTransSource」
• 「Attack Response Controller」
• 「Logger」
• 「AuthenticationApp」
• 「Web サーバ」
MainApp について
MainApp には、SensorApp と CLI 以外のすべての IPS コンポーネントが含まれています。起動時にオペレーティング システムによってロードされ、SensorApp をロードします。MainApp は、次に、次のサブシステム コンポーネントを起動します。
• 認証
• ロガー
• ARC
• Web サーバ
• 通知(SNMP)
• 外部製品インターフェイス
• インターフェイス マネージャ
• イベント ストア
• 健全性とセキュリティのモニタリング
MainApp の役割
MainApp には、次の役割があります。
• シスコでサポートしているハードウェア プラットフォームの検証
• ソフトウェア バージョンおよび PEP 情報の報告
• IPS コンポーネントの起動、停止、バージョンの報告
• ホスト システム設定の指定
• システム クロックの管理
• イベント ストアの管理
• ソフトウェア アップグレードのインストールとアンインストール
(注) Cisco IPS では、シグニチャおよびシグニチャ エンジンのアップデートを Cisco.com から MainApp で自動的にダウンロードできます。
• オペレーティング システムのシャットダウンまたはリブート
MainApp は、 show version コマンドへの応答として次の情報を表示します。
• センサーのビルド バージョン
• MainApp のバージョン
• 実行中の各アプリケーションのバージョン
• インストールされている各アップグレードのバージョンおよびタイムスタンプ
• インストールされている各アップグレードの次のダウングレード バージョン
• プラットフォームのバージョン
• 他のパーティションにあるセンサーのビルドのバージョン
MainApp では、ホスト統計情報の収集と、健全性およびセキュリティ モニタリング状況の報告も行います。
イベント ストアについて
各 IPS イベントは、タイムスタンプ、および一意で単純な昇順の ID と共にイベント ストアに格納されます。このタイムスタンプをプライマリ キーとして使用することにより、固定サイズのインデックス化されたイベント ストアにイベントをインデックス付けします。循環式のイベント ストアが設定済みサイズに達すると、最も古いイベントを上書きして新しいイベントが格納されます。イベント ストアに alert イベントを書き込むアプリケーションは SensorApp だけです。log、status、error イベントは、すべてのアプリケーションがイベント ストアに書き込みます。
固定サイズのインデックス化されたイベント ストアでは、時刻、タイプ、プライオリティ、および限られた数のユーザ定義属性に基づいて、シンプルなイベントのクエリーを実行できます。イベントのそれぞれに low、medium、または high のプライオリティを割り当てると、1 回のイベント クエリーで目的のイベント タイプのリスト、侵入イベントのプライオリティ、および時間範囲を指定できます。
表 A-1 に、いくつかの例を示します。
表 A-1 IPS イベントの例
|
|
|
|
|
status |
-- |
0 |
最大値 |
格納されているすべての status イベントを取得します。 |
error status |
-- |
0 |
65743 |
時刻 65743 よりも前に格納されたすべての error および status イベントを取得します。 |
status |
-- |
65743 |
最大値 |
時刻 65743 以降に格納された status イベントを取得します。 |
intrusion attack response |
low |
0 |
最大値 |
プライオリティ low で格納されているすべての intrusion および attack response イベントを取得します。 |
attack response error status intrusion |
medium high |
4123000000 |
4123987256 |
時刻が 4123000000 から 4123987256 の間に格納された、プライオリティが medium または high の attack response、error、status、および intrusion イベントを取得します。 |
イベント ストアのサイズは、センサーが IPS イベント コンシューマに接続されていないときに IPS イベントをバッファリングするのに十分な大きさです。バッファリングが十分であるかどうかは、ユーザの要件と、使用するノードの能力に依存します。循環バッファ内の最も古いイベントは、最新のイベントによって置き換えられます。
イベント データの構造
さまざまな機能ユニットが、次の 7 種類のデータをやり取りします。
• intrusion イベント:SensorApp によって生成されます。intrusion イベントはセンサーが検出します。
• error イベント:ハードウェアまたはソフトウェアの不具合によって発生します。
• status イベント:設定がアップデートされたなどの、アプリケーションのステータスの変更を報告します。
• control transaction log イベント:センサーが制御トランザクションの結果を記録します。
• attack response イベント:ブロック要求などの ARC 向けアクション。
• debug イベント:アプリケーションのステータスの変更に関するきわめて詳細なレポートで、デバッグに使用されます。
• 制御トランザクション データ:制御トランザクションに関連するデータ。たとえば、アプリケーションの診断データ、セッション ログ、およびアプリケーションとやり取りされる設定データ。
この全 7 種類のデータを IPS データ と総称します。6 つのイベント タイプ(intrusion、error、status、control transaction log、network access、debug)は特徴が似ており、 IPS イベント と総称されます。IPS イベントは、IPS を構成する数種類のアプリケーションによって生成され、他の IPS アプリケーションに受信されます。IPS イベントには、次のような特徴があります。
• IDS イベントを生成するように設定されているアプリケーション インスタンスによって、自然発生的に生成されます。特定のイベントを生成するように他のアプリケーション インスタンスから要求されることはありません。
• 特定の宛先はありません。1 つまたは複数のアプリケーションによって格納され、その後、取得されます。
制御トランザクションは、次のタイプの要求に関係します。
• アプリケーション インスタンスの設定データに対する更新の要求
• アプリケーション インスタンスの診断データの要求
• アプリケーション インスタンスの診断データのリセット要求
• アプリケーション インスタンスを再起動する要求
• ブロック要求などの ARC 向け要求
制御トランザクションには、次のような特徴があります。
• 常に、1 つの応答を伴う 1 つの要求によって構成されます。
要求と応答には、任意の量のデータが関連付けられる可能性があります。すべての応答には、少なくとも肯定応答または否定応答が含まれます。
• ポイントツーポイントのトランザクションです。
制御トランザクションは、1 つのアプリケーション インスタンス(発信側)からもう 1 つのアプリケーション インスタンス(応答側)に送信されます。
IPS データは、XML 形式で XML ドキュメントとして表されます。システムには、ユーザ設定可能なパラメータがいくつかの XML ファイルで格納されます。
IPS イベント
IPS アプリケーションは、ある種のできごとが発生したことを報告するために IPS イベントを生成します。イベントは、SensorApp が生成するアラートやアプリケーションが生成するエラーなどのデータです。イベントは、イベント ストアというローカル データベースに格納されます。
5 種類のイベントがあります。
• evAlert:ネットワーク アクティビティによってシグニチャがトリガーされたことを報告する alert イベント メッセージ
• evStatus:IPS アプリケーションのステータスとアクションを報告する status イベント メッセージ
• evError:応答アクションの試行中に発生したエラーを報告する error イベント メッセージ
• evLogTransaction:各センサー アプリケーションによって生成された制御トランザクションを報告する log transaction メッセージ
• evShunRqst:ARC がいつブロック要求を発行したかを報告するブロック要求メッセージ
status メッセージおよび error メッセージは、CLI、IME、および ASDM を使用して表示できます。
SensorApp および ARC は、応答アクション(TCP リセット、IP ロギングの開始と停止、ブロッキングの開始と停止、トリガー パケット)をステータス メッセージとしてログに記録します。
NotificationApp
NotificationApp によって、センサーでは、アラートおよびシステム エラー メッセージを SNMP トラップとして送信できます。イベント ストア内のイベントをサブスクライブして、SNMP MIB に変換し、パブリック ドメイン SNMP エージェントを介して目的の場所に送信します。NotificationApp は、set および get の送信をサポートしています。SNMP GET では、センサーの健全性に関する基本情報を取得できます。
スパース モードでは、NotificationApp は、evAlert イベントから次の情報を送信します。
• 発信者情報
• イベント ID
• イベントの重大度
• 時刻(UTC および現地時間)
• シグニチャ名
• シグニチャ ID
• サブシグニチャ ID
• 参加者情報
• アラームの特性
詳細モードでは、NotificationApp は、evAlert イベントから次の情報を送信します。
• 発信者情報
• イベント ID
• イベントの重大度
• 時刻(UTC および現地時間)
• シグニチャ名
• シグニチャ ID
• サブシグニチャ ID
• バージョン
• サマリー
• インターフェイス グループ
• VLAN
• 参加者情報
• アクション
• アラームの特性
• シグニチャ
• IP ログの ID
NotificationApp は、定義されたフィルタに従って、トラップとして送信する evError イベントを決定します。エラーの重大度(error、fatal、warning)に基づいてフィルタリングできます。NotificationApp は、evError イベントから次の情報を送信します。
• 発信者情報
• イベント ID
• イベントの重大度
• 時刻(UTC および現地時間)
• エラー メッセージ
NotificationApp は、センサーからの次の一般的な健全性情報およびシステム情報の GET をサポートします。
• パケット損失
• パケット拒否数
• 生成されたアラーム数
• FRP 内のフラグメント数
• FRP 内のデータグラム数
• 初期状態の TCP ストリーム数
• 確立状態の TCP ストリーム数
• 終了状態の TCP ストリーム数
• システム内の TCP ストリーム数
• 再構成用にキューイングされた TCP パケット数
• アクティブ ノードの合計数
• 両方の IP アドレスと両方のポートでキー付けされた TCP ノード数
• 両方の IP アドレスと両方のポートでキー付けされた UDP ノード数
• 両方の IP アドレスでキー付けされた IP ノード数
• センサー メモリの臨界状態
• インターフェイスのステータス
• コマンド/コントロール パケットの統計情報
• フェールオーバーの状態
• システムの稼動時間
• CPU 使用率
• システムのメモリ使用量
• PEP
(注) 一部の IPS プラットフォームでは、PEP をサポートしていません。
NotificationApp には次の統計情報があります。
• エラー トラップの数
• イベント アクション トラップの数
• SNMP GET 要求の数
• SNMP SET 要求の数
CtlTransSource
CtlTransSource は、ローカルで開始されたリモート制御トランザクションを HTTP プロトコルを使用してリモートの宛先に転送するアプリケーションです。CtlTransSource は、TLS または非 TLS 接続を開始し、その接続を使用してリモート制御トランザクションを HTTP サーバに伝えます。
CtlTransSource は、リモート HTTP サーバでリモート制御トランザクションを実行するために必要な資格を得る必要があります。CtlTransSource は、リモート ノード上の HTTP サーバにユーザ名とパスワードの形式でアイデンティティを提示することによって資格を得ます(基本認証)。正常に認証されると、ユーザ認証を含む Cookie がリクエスタに割り当てられます。この接続に関するすべての要求では、このクッキーを提示する必要があります。
CtlTransSource サーバ内の transactionHandlerLoop メソッドは、リモート制御トランザクションに対するプロキシとして機能します。ローカル アプリケーションがリモート制御トランザクションを起動すると、IDAPI は最初にトランザクションを CtlTransSource に送信します。transactionHandlerLoop メソッドは、CtlTransSource に送信されたリモート制御トランザクションを待機するループです。
図 A-2 に、CtlTransSource 内の transactionHandlerLoop メソッドを示します。
図 A-2 CtlTransSource
transactionHandlerLoop は、リモート アドレッシングされたトランザクションを受信すると、そのリモート制御トランザクションをリモートの宛先に転送するように試みます。transactionHandlerLoop は、トランザクションを制御トランザクション メッセージの形式にします。transactionHandlerLoop は、HttpClient クラスを使用して、リモート ノード上の HTTP サーバに対する制御トランザクション要求を発行します。リモート HTTP サーバは、リモート制御トランザクションを処理し、適切な応答メッセージを HTTP 応答として返します。リモート HTTP サーバが IPS Web サーバである場合、この Web サーバは CtlTransSource サーブレットを使用してリモート制御トランザクションを処理します。
transactionHandlerLoop は、制御トランザクションの応答として、応答または失敗応答のいずれかを、リモート制御トランザクションの発信側に返します。HTTP サーバが非認証ステータス応答(HTTP クライアントが HTTP サーバに対する十分な資格を持っていないことを示す)を返す場合、transactionHandlerLoop では指定された CtlTransSource のユーザ名とパスワードを使用してトランザクション要求を再発行することにより、リクエスタのアイデンティティを認証します。transactionHandlerLoop は、終了を指示する制御トランザクションを受信するか終了イベントが発生するまでループします。
ARC について
ARC の主な役割は、イベントをブロックすることです。NAC アプリケーションはブロックに対応するとき、管理対象のデバイスと直接対話してブロックを有効化するか、Control Transaction Server を通じてマスター ブロッキング センサーにブロック要求を送信します。マスター ブロッキング センサー上の Web サーバは、制御トランザクションを受け取るとそれを Control Transaction Server に渡し、Control Transaction Server は ARC に渡します。次に、マスター ブロッキング センサー上の ARC は、管理対象のデバイスと対話してブロックをイネーブルにします。
は ARC を図示したものです。図 A-3
図 A-3 ARC
(注) ARC のインスタンスは、ネットワーク デバイスを制御できない場合、1 つだけを制御できる場合、または複数を制御できる場合があります。ARC は、他の ARC アプリケーション、IPS 管理ソフトウェア、他のネットワーク管理ソフトウェア、システム管理者との間でネットワーク デバイスの制御を一切共有しません。1 つのセンサーについて実行できる ARC のインスタンスは 1 つだけです。
ARC は、次のいずれかに対応してブロックを開始します。
• ブロック アクションが設定されたシグニチャから生成された alert イベント
• CLI、IDM、IME、または ASDM から手動で設定されたブロック
• ホストまたはネットワーク アドレスに対して永続的に設定されたブロック
デバイスをブロックするように ARC を設定すると、ARC はそのデバイスとの間で Telnet または SSH 接続を開始します。ARC は、各デバイスとの接続を維持します。ブロックが開始されると、ARC は制御対象の各デバイスに新しい設定または ACL のセットを(インターフェイス方向ごとに 1 つずつ)プッシュします。ブロックが完了すると、すべての設定または ACL はブロックを削除するようにアップデートされます。
ARC の機能
ARC には、次の機能があります。
• 3DES(デフォルト)または DES 暗号化を使用する Telnet および SSH 1.5。
そのデバイスの ARC 設定で指定されたプロトコルのみが試行されます。何らかの理由で接続が失われると、ARC は再確立を試みます。
• ルータ上の既存 ACL およびスイッチ上の既存 VACL。
既存 ACL が、ARC によって制御されるルータのインターフェイスまたは方向に存在する場合は、この ACL を ARC によって生成される設定にマージするように指定できます。これは、preblock ACL を指定するとすべてのブロックの前に、postblock ACL を指定するとブロックの後に行われます。Catalyst 6000 VACL デバイス タイプには、ARC が制御するインターフェイスごとに preblock および postblock VACL を指定できます。ファイアウォール デバイス タイプでは、ブロックを実行するために別の API が使用され、ARC はファイアウォール上の既存 ACL には影響を与えません。
(注) Catalyst 5000 RSM および Catalyst 6000 MSFC2 ネットワーク デバイスは、Cisco ルータとして同じようにサポートされます。
• リモート センサーのリストに対するブロックの転送
ARC は、リモート センサーのリストにブロックを転送できます。そのため、複数のセンサーが実質的に集団となって 1 つのネットワーク デバイスを制御することができます。このようなリモート センサーをマスター ブロッキング センサーと言います。
• ネットワーク デバイスのインターフェイスに対するブロッキングの指定
ルータの ARC 設定で、ブロッキングが実行されるインターフェイスおよび方向を指定できます。VACL 設定では、ブロッキングが実行されるインターフェイスを指定できます。
(注) Cisco ファイアウォールは、インターフェイスおよび方向に基づくブロックを行いません。したがって、この設定が Cisco ファイアウォールで指定されることはありません。
ARC は、同時に 250 までのインターフェイスを制御できます。
• ホストまたはネットワークに対する指定された時間のブロッキング
ARC は、分単位で指定された時間だけ、または永続的にホストまたはネットワークをブロックできます。ARC は、ブロックの期限がいつ切れたのかを判断し、期限切れになるとホストまたはネットワークのブロックを解除します。
• 重要なイベントのロギング
ARC は、ブロックまたはブロック解除アクションが正常に完了するか何らかのエラーが発生すると、確認イベントを書き込みます。また、ARC は、ネットワーク デバイスの通信セッションの切断と回復、コンフィギュレーション エラー、ネットワーク デバイスから報告されるエラーなどの重要なイベントも記録します。
• ARC 再起動時全体におけるブロッキング状態の維持
シャットダウンまたは再起動が発生したとき、ARC は期限が切れていないブロックを再適用します。シャットダウン中に期限が切れたブロックは ARC によって削除されます。
(注) ARC がブロッキング状態を正しく維持するためには、アプリケーションのシャットダウン中にシステムの時刻が変更されないことが条件です。
• ネットワーク デバイス再起動時におけるブロッキング状態の維持
ネットワーク デバイスがシャットダウンされ、再起動されると、ARC は必要に応じてブロックを再適用したり、期限が切れたブロックを削除したりします。ARC は、ARC のシャットダウンおよび再起動が同時に、または重複して発生しても影響を受けません。
• 認証と認可
ARC は、リモート TACACS+ サーバの使用を含め、AAA 認証および認可を使用するネットワーク デバイスとの間で通信セッションを確立できます。
• 2 種類のブロッキング
ARC は、ホスト ブロックとネットワーク ブロックをサポートしています。ホスト ブロックは、接続ベースまたは無条件です。ネットワーク ブロックは、常に無条件です。
• NAT アドレス指定
ARC は、センサーに対して NAT アドレスを使用するネットワーク デバイスを制御できます。ネットワーク デバイスを設定する際に NAT アドレスを指定すると、そのデバイスに対するブロックからセンサーのアドレスがフィルタ処理されるときに、ローカル IP アドレスの代わりにそのアドレスが使用されます。
• シングル ポイント制御
ARC はネットワーク デバイスの制御を管理者や他のソフトウェアとの間で共有しません。設定をアップデートする必要がある場合は、変更が完了するまで ARC をシャットダウンしておきます。ARC は、CLI または任意の Cisco IPS マネージャからイネーブルまたはディセーブルにすることができます。イネーブルにし直された ARC は、自身を完全に初期化し直します。これには、制御対象のネットワーク デバイスごとに現在の設定を再読み込みすることも含まれます。
(注) ファイアウォールなどの任意のネットワーク デバイスを設定する際は、ARC によるブロッキングを無効にすることを推奨します。
• 常に最大 250 のアクティブなブロックを維持
ARC は、同時に 250 までのアクティブなブロックを維持できます。ARC では 65535 個までのブロックをサポートできますが、1 度に 250 個までを許可することを推奨します。
(注) ブロックの数は、インターフェイスおよび方向の数とは異なります。
サポートされているブロッキング デバイス
ARC は、次のデバイスを制御できます。
• Cisco IOS 11.2 以降を実行する Cisco ルータ
(注) レート制限を実行するには、ルータで Cisco IOS 12.3 以降を実行する必要があります。
• スーパーバイザ エンジン上で実行される 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
• 次の Cisco ASA 500 シリーズ スイッチのモデルASA 5510、ASA 5520、および ASA 5540
• FWSM
(注) FWSM はマルチモードの管理コンテキストではブロックを実行できません。
ACL と VACL
ARC が制御するインターフェイスまたは方向のパケットをフィルタ処理する場合は、すべてのブロックの前に ACL を適用したり(preblock ACL)、すべてのブロックの後に ACL を適用する(postblock ACL)ように ARC を設定したりできます。これらの ACL は、ネットワーク デバイス上で非アクティブな ACL として設定されます。preblock および postblock ACL は、インターフェイスおよび方向ごとに定義できます。ARC は、ネットワーク デバイス上のアクティブな ACL をアップデートする際、リストを取得してキャッシュしてから、ブロッキング ACE にマージします。ほとんどの場合は、ブロックの効果を妨げないように、既存 ACL を postblock ACL として指定します。ACL はパケットを、最初に検索された ACE と照合することにより動作します。最初の ACE でパケットが許可された場合、その後の拒否ステートメントは検索されません。
インターフェイスおよび方向ごとに異なる preblock および postblock ACL を指定することも、同じ ACL を複数のインターフェイスおよび方向に再利用することもできます。preblock リストを適用しない場合は、ホストやネットワークに対して never block オプションを使用したり、既存の設定ステートメントを使用して常にブロックしたりすることができます。forever block は、normal block でタイムアウト値を -1 にした場合と同じです。
ARC は、所有する ACL のみを変更します。ユーザによって定義された ACL は変更されません。ARC が維持する ACL は、ユーザ定義の ACL では使用が禁じられている固有の形式になっています。命名規則は、 IPS_< interface_name >_[in | out]_[0 | 1] です。<interface_name> は、ブロッキング インターフェイスに対して ARC 設定で指定された名前に対応します。
Catalyst スイッチでは、これは、ブロッキング インターフェイスの VLAN 番号です。これらの名前は、preblock および postblock ACL では使用しないでください。
Catalyst 6000 VACL では、preblock および postblock VACL を指定できます。また、インターフェイスのみが指定可能です(VLAN では方向は使用されません)。
ファイアウォールでは、ブロッキングに異なる API が使用されるため、preblock ACL および postblock ACL を使用できません。代わりに、ファイアウォールでは ACL を直接作成する必要があります。
再起動時の状態の維持
センサーがシャットダウンすると、ARC は、すべてのブロックおよびレート制限(開始時のタイムスタンプ付き)を、ARC が保守しているローカル ファイル(nac.shun.txt)に書き込みます。起動した ARC は、このファイルを使用して、制御対象のネットワーク デバイスでブロック アップデートを必要とするかどうかを判断します。ファイル内に期限が切れていないブロックが見つかると、ネットワーク デバイスの起動時に適用されます。ARC がシャットダウンするときは、有効な未処理ブロックが存在していても ACL に対して特別なアクションは行われません。nac.shun.txt ファイルは、ARC の実行中にシステムの時刻が変更されていない場合に限り正確です。
注意
nac.shun.txt ファイルには手動による変更を加えないでください。
次のシナリオに、ARC が再起動時全体でどのように状態を維持するのかを示します。
シナリオ 1
ARC を停止する時点で 2 つのブロックが有効であり、そのうち 1 つは ARC の再起動よりも前に期限が切れます。再起動した ARC は、最初に 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
ARC 設定でホストが never block と指定されている場合、ACL の permit ステートメントには変換されません。代わりに、ARC にキャッシュされて、受信 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 コマンド
接続ベースおよび無条件のブロッキング
ARC は、ホストに関しては 2 種類、ネットワークに関しては 1 種類のブロッキングをサポートしています。ホスト ブロックは、接続ベースまたは無条件です。ネットワーク ブロックは、常に無条件です。
ARC は、ホスト ブロックを受信すると、そのホスト ブロックの connectionShun 属性を調べます。connectionShun が true に設定されていると、ARC は接続ブロッキングを実行します。すべてのホスト ブロックは、宛先 IP アドレス、ソース ポート、宛先ポート、プロトコルといったオプションのパラメータを含むことができます。接続ブロックが実行されるためには、少なくとも送信元 IP アドレスおよび宛先 IP アドレスが存在している必要があります。送信元ポートが接続ブロックに含まれている場合、その送信元ポートは無視され、ブロックに組み込まれません。
次の条件のとき、ARC は必要に応じて接続タイプからブロックを変換して、ブロックを無条件にします。
• 指定されたソース IP アドレスに対して、いずれかのタイプのブロックがアクティブである。
• そのソース IP アドレスに対して、いずれかのタイプの新しいブロックが受信された。
• 新しいブロックのいずれかのオプション パラメータ(ソース ポートを除く)が以前のブロックと異なる。
ブロックがアップデートされると(既存のブロックがすでに有効になっているソース IP アドレスやネットワークに関して新しいブロックが受信された場合など)、既存のブロックの残り時間(分)が決定されます。新しいブロックの時間がこの残り時間以下の場合、アクションは何も発生しません。そうでない場合は、新しいブロックのタイムアウトによって既存のブロックのタイムアウトが置き換えられます。
注意
Cisco ファイアウォールでは、ホストの接続ブロッキングをサポートしていません。接続ブロックが適用されると、ファイアウォールは接続ブロックを無条件ブロックのように扱います。Cisco ファイアウォールでは、ネットワーク ブロッキングもサポートしていません。ARC が Cisco ファイアウォールに対してネットワーク ブロックの適用を試みることはありません。
Cisco ファイアウォールを使用したブロッキング
ARC では、 shun コマンドを使用することにより、ファイアウォールでのブロックを実行します。 shun コマンドの形式は次のとおりです。
• IP アドレスをブロックする。
shun srcip [destination_ip_address source_port destination_port [port]]
• IP アドレスのブロックを解除する。
• すべてのブロックをクリアする。
• アクティブなブロック、または実際にブロックされているグローバル アドレスを表示する。
ARC は、 show shun コマンドに対する応答を使用して、ブロックが実行されたかどうかを判別します。
shun コマンドは既存の ACL、コンジット、アウトバウンド コマンドを置き換えるものではないため、既存のファイアウォール設定をキャッシュしたり、ブロックをファイアウォール設定にマージしたりする必要はありません。
注意 ARC の実行中は、手動でブロックを実行したり既存のファイアウォール設定を変更したりしないでください。
block コマンドでソース IP アドレスのみを指定すると、既存のアクティブな TCP 接続は維持されますが、ブロックされたホストからの着信パケットはすべてドロップされます。
ARC が最初に起動したとき、ファイアウォールでアクティブなブロックが内部のブロッキング リストと比較されます。内部のリストに対応するエントリがないブロックは削除されます。
ARC は、ファイアウォールでの認証をサポートするためにローカル ユーザ名または TACACS+ サーバを使用します。ファイアウォールで認証には AAA を使用して TACACS+ サーバは使用しないように設定すると、ARC はファイアウォールとの通信に予約済みのユーザ名 pix を使用します。
ファイアウォールで認証に TACACS+ サーバを使用する場合は、TACACS+ ユーザ名を使用します。AAA ログインを使用する一部のファイアウォール設定では、3 つのパスワード プロンプトが表示されます。初期ファイアウォール パスワード、AAA パスワード、イネーブル パスワードです。ARC では、初期ファイアウォール パスワードと AAA パスワードを同じにすることが要求されます。
NAT または PAT を使用するようにファイアウォールを設定し、ネットワーク外にあるファイアウォール上のパケットをセンサーがチェックする場合、ネットワーク内のファイアウォールから開始されたホスト攻撃が検出されると、センサーはファイアウォールから提供された変換アドレスのブロックを試みます。ダイナミック NAT アドレッシングを使用している場合は、ブロックが効果を発揮しなかったり、無害なホストがブロックされることがあります。PAT アドレッシングを使用している場合は、ファイアウォールが内部ネットワーク全体をブロックする可能性があります。これらの状況を回避するには、センサーを内部インターフェイスに配置するか、センサーがブロックを行わないように設定します。
Catalyst スイッチを使用したブロッキング
PFC をインストールした Catalyst スイッチでは、VACL を使用してパケットをフィルタ処理します。VACL は、VLAN 間および VLAN 内のすべてのパケットをフィルタ処理します。
WAN カードが取り付けられている場合は MSFC ルータ ACL がサポートされ、MSFC2 を通じてセンサーがインターフェイスを制御するようにすることができます。
(注) MSFC2 カードは、Catalyst スイッチで VACL によるブロッキングを行うための設定の一部として必要なわけではありません。
注意 Catalyst スイッチで ARC を設定する場合は、制御インターフェイスで方向を指定しないでください。インターフェイス名は VLAN 番号です。preblock および postblock のリストは、VACL である必要があります。
Catalyst VACL に対しては、次のコマンドを使用できます。
• 既存の VACL を表示する。
show security acl info acl_name
• アドレスをブロックする( address_spec は、ルータの ACL で使用されるものと同一)。
set security acl ip acl_name deny address_spec
• リストの構築後に VACL をアクティブにする。
• 1 つの VACL をクリアする。
clear security acl map acl_name
• すべての VACL をクリアする。
clear security acl map all
• VACL を VLAN にマップする。
set sec acl acl_name vlans
Logger
センサーは、すべてのイベント(alert、error、status、debug の各メッセージ)を永続的な循環バッファに記録します。また、センサーは IP ログも生成します。このメッセージと IP ログには、CLI、IDM、ASDM、および SDEE クライアントからアクセスできます。
IPS アプリケーションは、Logger を使用してメッセージを記録します。Logger は、ログ メッセージを debug、timing、warning、error、fatal の 5 レベルの重大度のいずれかで送信します。Logger は、ログ メッセージを、循環式のテキスト ファイルである /usr/cids/idsRoot/log/main.log に書き込みます。ファイルがサイズの上限に達すると、古いメッセージは新しいメッセージによって上書きされます。したがって、main.log では、最後に書き込まれたメッセージが末尾にあるとは限りません。main.log に書き込まれた最新の行を見つけるには、ストリング「= END OF FILE =」を検索してください。
main.log は、 show tech-support コマンドの出力に含まれます。メッセージが warning またはそれよりも上(error または fatal)のレベルで記録されると、Logger はメッセージを evError イベントに変換して(対応するエラーの重大度で)、イベント ストアに挿入します。
Logger は、informational 以上のレベルで cron メッセージ以外のすべての syslog メッセージ(*.info;cron.none)を受信し、エラーの重大度を Warning に設定してから evErrors としてイベント ストアに挿入します。Logger およびアプリケーションのロギングは、service logger コマンドによって制御されます。
Logger は、ロギング ゾーンごとにロギング重大度を制御することにより、各アプリケーションが生成するログ メッセージを制御できます。ユーザは、TAC のエンジニアまたは開発者の依頼および指示の下で、ロガー サービスの individual-zone-control にのみアクセスします。トラブルシューティングのために、TAC はデバッグ ロギングを依頼することがあります。
AuthenticationApp について
AuthenticationApp には、次の役割があります。
• ユーザのアイデンティティを認証する。
• ユーザのアカウント、権限、キー、および証明書を管理する。
• AuthenticationApp、およびセンサー上の他のアクセス サービスで使用する認証方法を設定する。
ユーザの認証
ユーザ アクセスに適切なセキュリティを確立するために、センサーで認証を設定する必要があります。センサーをインストールすると、初期アカウントとして、パスワードの期限が切れている cisco というアカウントが作成されます。センサーに対する管理アクセス権を持ったユーザは、デフォルトの管理アカウント(cisco)を使用してセンサーにログインすることにより、CLI または IPS マネージャ(IDM、ASDM など)を通じてセンサーにアクセスします。CLI で、管理者はパスワードの変更を要求されます。IPS マネージャは、setEnableAuthenticationTokenStatus 制御トランザクションを開始することによってアカウントのパスワードを変更します。
CLI または IPS マネージャを通じて、管理者は、ユーザ名とパスワード、SSH 許可されたキーなど、使用する認証方法を設定します。管理者用のアプリケーションは、認証設定を確立するために setAuthenticationConfig 制御トランザクションを開始します。
認証設定には、アカウント ロッキングの処理方法を指定するログイン試行の上限値が含まれています。アカウント ロッキングは、ログインの試みが連続して失敗した回数が、指定されたログイン試行の上限値を超えると起動されます。アカウントがロックされると、その後のログインの試行はすべて拒否されます。アカウントのロックを解除するには、setEnableAuthenticationTokenStatus 制御トランザクションを使用してアカウントの認証トークンをリセットします。アカウント ロッキング機能は、ログイン試行の上限値を 0 に設定すると無効になります。
管理者は、CLI または IPS マネージャから新しいユーザ アカウントを追加できます。
センサーにおける認証の設定
ユーザが Web サーバや CLI などのサービスを通じてセンサーにアクセスしようとするときは、ユーザのアイデンティティを認証し、ユーザの権限を確立する必要があります。ユーザにアクセスを提供するサービスは、ユーザのアイデンティティを認証するために、AuthenticationApp に対して execAuthenticateUser 制御トランザクション要求を開始します。通常、制御トランザクション要求にはユーザ名とパスワードが含まれています。または、SSH 許可されたキーによってユーザのアイデンティティを認証できます。
AuthenticationApp は、execAuthenticateUser 制御トランザクション要求に対して、ユーザのアイデンティティの認証を試みることによって応答します。AuthenticationApp は、ユーザの認証ステータスおよび権限を含む制御トランザクション応答を返します。ユーザのアイデンティティを認証できない場合、AuthenticationApp は、非認証ステータスと匿名ユーザ権限を制御トランザクション応答として返します。制御トランザクション応答は、アカウントのパスワードが期限切れであるかどうかも示します。execAuthenticateUser 制御トランザクションを開始することによってユーザを認証するユーザ インターフェイス アプリケーションは、ユーザにパスワードの変更を要求します。
AuthenticationApp は、基盤となるオペレーティング システムを使用してユーザのアイデンティティを確認します。すべての IPS アプリケーションは、AuthenticationApp に制御トランザクションを送信します。AuthenticationApp は、オペレーティング システムを使用してその応答を作成します。
リモート シェル サービスである Telnet と SSH は、IPS アプリケーションではありません。これらは、オペレーティング システムを直接呼び出します。ユーザが認証されていれば、オペレーティング システムは IPS CLI を起動します。この場合、CLI は特殊な形式の execAuthenticateUser 制御トランザクションを送信することにより、ログイン ユーザの権限レベルを判断します。次に CLI は、この権限レベルに応じて、使用可能にするコマンドを用意します。
TLS および SSH 信頼関係の管理
IP ネットワーク上の暗号化通信は、パケット内のデータを復号化するために必要な秘密キーを、交換されるパケットだけから受動的攻撃者が発見できないようにすることで、データ プライバシーを実現します。
しかし、同じような危険性を持つ攻撃ベクトルとして、接続のサーバ側であるように装う詐称があります。すべての暗号化プロトコルには、クライアントがこの種の攻撃から身を守るための手段が用意されています。IPS は、SSH と TLS という 2 つの暗号化プロトコルをサポートしています。また、AuthenticationApp は、センサーが暗号化通信のクライアントまたはサーバになる場合の信頼を管理するのに役立ちます。
IPS Web サーバおよび SSH サーバは、暗号化通信のサーバ エンドポイントです。これらは、秘密キーによって ID を保護し、接続してくるクライアントに公開キーを提供します。TLS では、この公開キーは X.509 証明書の中に含まれています。X.509 証明書には他の情報も格納されています。センサーに接続するリモート システムは、接続確立時に受け取った公開キーが、目的のキーであることを確認する必要があります。
クライアントは、中間者攻撃を防御するため、信頼できる公開キーのリストを維持する必要があります。この信頼性を確立するための詳細な手順は、プロトコルおよびクライアント ソフトウェアによって異なります。一般的に、クライアントは 16 ~ 20 バイトのフィンガープリントを表示します。クライアントが信頼を確立するように設定する人間のオペレータは、信頼の確立を試行する前に、アウトオブバンド方式を使用してサーバのキー フィンガープリントを取得する必要があります。フィンガープリントが一致すると信頼関係が確立され、その後、クライアントは自動的にそのサーバに接続でき、リモート サーバが詐称者でないことを確信できます。
show ssh server-key および show tls fingerprint を使用して、センサーのキー フィンガープリントを表示できます。センサー コンソールに直接接続したときにこれらのコマンドの出力を記録しておくと、後から信頼関係を確立する際、その情報を使用することにより、ネットワークを通じてセンサーのアイデンティティを確認できます。
たとえば、最初に Microsoft Internet Explorer Web ブラウザを通じてセンサーに接続したときには、セキュリティ警告ダイアログボックスによって、証明書は信頼されていないと示されます。Internet Explorer のユーザ インターフェイスを使用して証明書のサムプリントを調べます。この値は、 show tls fingerprint コマンドによって表示される SHA1 フィンガープリントに正確に一致する必要があります。確認が終わったら、この証明書をブラウザの信頼済み CA のリストに追加して、永続的な信頼を確立します。
この信頼を確立する手順は、TLS クライアントごとに異なります。センサー自体に TLS クライアントが含まれており、制御トランザクションを他のセンサーに送信したり、アップグレードおよびコンフィギュレーション ファイルを TLS Web サーバからダウンロードするために使用されます。センサーの通信相手となる TLS サーバの信頼性を確立するには、 tls trusted-host コマンドを使用します。
同様に、センサーには SSH クライアントが含まれており、管理対象ネットワーク デバイスとの通信、アップグレードのダウンロード、リモート ホストへのコンフィギュレーション ファイルおよびサポート ファイルのコピーに使用されます。センサーが接続する SSH サーバとの信頼関係を確立するには、 ssh host-key コマンドを使用します。
TLS 信頼済み証明書および SSH 既知ホストのリストは、 service trusted-certificates コマンドおよび service ssh-known-hosts コマンドで管理できます。
X.509 証明書には、信頼関係のセキュリティを向上させる追加情報が含まれていますが、これは混乱を招く場合があります。たとえば、X.509 証明書には、その証明書を信頼できる有効期間が含まれています。通常、この期間は、証明書が作成された瞬間から始まる数年間です。使用時点で X.509 証明書が有効であることを厳密に確認するには、クライアント システムで正確なクロックを維持する必要があります。
また、X.509 証明書は、特定のネットワーク アドレスと結び付けられています。センサーはこのフィールドに、センサーのコマンドおよびコントロール インターフェイスの IP アドレスを挿入します。そのため、センサーのコマンドおよびコントロール IP アドレスを変更すると、サーバの X.509 証明書は再生成されます。新しい IP アドレスでこのセンサーを見つけ、新しい証明書を信頼するには、以前の証明書を信頼していた、ネットワーク上のすべてのクライアントを再設定しなければなりません。
AuthenticationApp の SSH 既知ホストおよび TLS 信頼済み証明書サービスを使用することにより、センサーを高いセキュリティ レベルで運用することができます。
Web サーバ
Web サーバは、SDEE サポートを提供します。これによってセンサーは、セキュリティ イベントの報告、IDIOM トランザクションの受信、および IP ログの提供が可能になります。
Web サーバでは、HTTP 1.0 と 1.1 をサポートしています。Web サーバとの通信には、パスワードなどの機密情報が関係することがよくあります。これらを攻撃者が盗聴することが可能になると、システムのセキュリティが大きく損なわれます。そのため、センサーは TLS がイネーブルな状態で出荷されます。TLS プロトコルは、SSL と互換性のある暗号化プロトコルです。
(注) RDEP イベント サーバ サービスは IPS 6.1 で非推奨になっており、現在の IPS システム アーキテクチャからは削除されています。Web サーバでは、SDEE イベント サーバを使用するようになりました。
詳細情報
SDEE の詳細については、「SDEE」を参照してください。
SensorApp
ここでは、SensorApp について説明します。次の事項について説明します。
• 「SensorApp について」
• 「インライン、正規化、およびイベント リスク レーティング機能」
• 「SensorApp の新機能」
• 「パケット フロー」
• 「シグニチャ イベント アクション プロセッサ」
SensorApp について
SensorApp は、パケットの取り込みと分析を実行します。ポリシー違反は、シグニチャを介して SensorApp で検出され、違反に関する情報がアラートの形式でイベント ストアに転送されます。
パケットは、センサー上のネットワーク インターフェイスからパケットを収集することを目的としたプロデューサが提供する、プロセッサのパイプラインを経由して流れます。
SensorApp では、次のプロセッサがサポートされています。
• タイム プロセッサ
このプロセッサは、時分割カレンダーに格納されているイベントを処理します。主なタスクは、古いデータベース エントリを期限切れにすること、および時間に依存する統計情報を計算することです。
• 拒否フィルタ プロセッサ
このプロセッサは、攻撃者の拒否機能を処理します。拒否された送信元 IP アドレスのリストを維持します。リスト内の各エントリは、グローバル拒否タイマーに基づいて期限切れになります。このタイマーは、仮想センサーの設定で指定できます。
• シグニチャ イベント アクション プロセッサ
このプロセッサでは、イベント アクションを処理します。次のイベント アクションをサポートしています。
– TCP フローのリセット
– IP ログ
– パケットの拒否
– フローの拒否
– 攻撃者の拒否
– アラート
– ホストのブロック
– 接続のブロック
– SNMP トラップの生成
– トリガー パケットのキャプチャ
イベント アクションは、イベント リスク レーティングしきい値と関連付けることができます。このしきい値を上回ることが、アクションを実行する前提になります。
• 統計情報プロセッサ
このプロセッサは、パケット カウント、パケット着信レートなどのシステム統計情報を追跡します。
• レイヤ 2 プロセッサ
このプロセッサでは、レイヤ 2 関連イベントを処理します。また、不正なパケットを識別し、処理パスから削除します。アラート、キャプチャ パケット、拒否パケットなど、不正なパケットを検出するための実行可能なイベントを設定できます。レイヤ 2 プロセッサは、設定されているポリシーが原因で拒否されたパケットに関する統計情報を更新します。
• データベース プロセッサ
このプロセッサは、シグニチャの状態およびフロー データベースを保守します。
• フラグメント再構成プロセッサ
このプロセッサは、フラグメント化された IP データグラムを再構成します。センサーがインライン モードの場合、IP フラグメントの正規化も処理します。
• ストリーム再構成プロセッサ
このプロセッサは、TCP ストリームをリオーダーして、さまざまなストリームベースのインスペクタにパケットが到着する順番を保証します。TCP ストリームの正規化も処理します。ノーマライザ エンジンを使用すると、アラートおよび拒否アクションをイネーブル化またはディセーブル化できます。
TCP ストリーム再構成プロセッサ ノーマライザは、ホールドダウン タイマーを備えています。このタイマーがあることで、再設定イベントの後にストリームの状態を再構築できます。このタイマーは設定できません。ホールドダウン間隔の間、システムでは、システムを通過するストリームの最初のパケットでストリームの状態を同期します。ホールドダウンの有効期限が切れると、SensorApp は設定されたポリシーを実施します。このポリシーで、3 ウェイハンドシェイクを使用して開かれていないストリームの拒否を要求する場合、ホールドダウン期間中に静止していた確立済みストリームは転送されず、タイムアウトが許可されます。ホールドダウン期間中に同期化されたストリームは、続行を許可されます。
• シグニチャ分析プロセッサ
このプロセッサは、ストリームベースではない、処理中のパケット用に設定されているインスペクタにパケットをディスパッチします。
• スレーブ ディスパッチ プロセス
デュアル CPU システムだけに存在するプロセスです。
一部のプロセッサは、シグニチャの分析を実行するためにインスペクタを呼び出します。すべてのインスペクタは、アラームチャネルを呼び出して、必要に応じてアラートを生成できます。
SensorApp は、次のユニットもサポートしています。
• 分析エンジン
分析エンジンは、センサーのコンフィギュレーションを処理します。インターフェイスのマッピングに加えて、この設定済みインターフェイスへのシグニチャおよびアラーム チャネル ポリシーのマッピングも行います。
• アラーム チャネル
アラームチャネルは、インスペクタによって生成されたすべてのシグニチャイベントを処理します。主な機能は、渡された各イベントのアラートを生成することです。
インライン、正規化、およびイベント リスク レーティング機能
(注) IPS SSP を搭載した Cisco ASA 5585-X では、正規化をサポートしていません。
SensorApp には、次のインライン機能、正規化機能、およびイベント リスク レーティング機能が含まれています。
• パケットのインライン処理
センサーがデータ パスのパケットを処理するときには、ポリシー設定で明示的に拒否されていない限り、すべてのパケットは一切変更されずに転送されます。TCP の正規化が原因で、一部のパケットは、適切なカバレッジを確保するために遅延することがあります。ポリシー違反が発生する場合は、SensorApp によってアクションを設定できます。パケットの拒否、フローの拒否、攻撃者の拒否など、追加のアクションをインライン モードで使用できます。
IPS にとって不明であるか、対象でないすべてのパケットは、分析されずにペアのインターフェイスに転送されます。すべてのブリッジング プロトコルおよびルーティング プロトコルは、そのまま転送されます。ただし、ポリシー違反が原因で拒否される場合があります。インライン データ処理(または混合データ処理)に使用されるインターフェイスには、IP スタックは関連付けられていません。混合モードにおける 802.1q パケットの現在のサポートが、インラインモードまで拡張されます。
• IP の正規化
IP データグラムのフラグメンテーションは、意図的であってもなくても不正利用の隠蔽につながり、不正利用の検出を困難または不可能にします。ファイアウォール上やルータ上と同様、フラグメンテーションもアクセス コントロール ポリシーを逃れるために使用される可能性があります。さまざまなオペレーティング システムがさまざまなメソッドを使用して、フラグメント化されたデータグラムをキューに入れたりディスパッチしたりします。エンド ホストがデータグラムを再構成する際に使用可能なすべての方法をセンサーでチェックする必要がある場合、センサーは DoS 攻撃に対して脆弱になります。フラグメント化したすべてのデータグラムをインラインで再構成して、完成したデータグラムのみを転送し、必要に応じてデータグラムを再度フラグメント化することが、この問題の解決策です。IP フラグメンテーション正規化装置がこの機能を実行します。
• TCP の正規化
意図的または意図しない TCP セッション セグメンテーションによって、いくつかの攻撃クラスが非表示になることがあります。ポリシーが false positive や false negative なしに実施されるようにするには、2 つの TCP エンドポイントの状態が追跡され、実際のホスト エンドポイントによって処理されたデータだけが渡される必要があります。TCP ストリームでオーバーラップが発生する可能性はあるものの、TCP セグメントの再送信以外では、非常にまれです。通常、TCP セッションでの上書きは発生しません。それでも上書きが発生するとしたら、セキュリティ ポリシーを意図的に回避しようとしている者があるか、TCP スタックの実装が破損しています。両方のエンドポイントの状態に関する全情報を保持できるのは、センサーが TCP プロキシとして動作している場合だけです。センサーが TCP プロキシとして動作する代わりに、セグメントが適切に並べられ、ノーマライザによって回避や攻撃に関係する異常なパケットが検索されます。
• イベント リスク レーティング
イベント リスク レーティングでは、潜在的に悪意のあるアクションを検出するだけでなく、次の追加情報も含んでいます。
– 成功した場合の攻撃の重大度
– シグニチャの忠実度
– ターゲットホストに関する潜在的な攻撃の関連性
– ターゲット ホスト全体の価値
イベント リスク レーティングはシステムからの false positive の減少に役立ち、アラーム発生原因のより適切な制御を可能にします。
SensorApp の新機能
SensorApp には、次の新機能があります。
• ポリシー テーブル:リスク カテゴリ設定(high、medium、および low)のリストを提供します。
• 回避保護:インライン インターフェイス モードのセンサーを、ノーマライザ用にストリクト モードから非同期モードに切り替えることができます。
• センサー健全性メーター:センサー全体の健全性の統計情報を提供します。
• トップサービス:TCP、UDP、ICMP、および IP プロトコルの上位 10 個のインスタンスを提供します。
• セキュリティ メーター:アラートをプロファイリングして脅威のカテゴリに入れ、この情報をレッド、イエロー、およびグリーンのバケットで報告します。これらのバケットの移行ポイントを設定できます。
• フロー状態のクリア:データベースをクリアできます。データベースをクリアすると、センサーが再起動時と同様に初期状態で起動します。
• 再起動ステータス:センサーの現在の起動段階および再起動段階を定期的に報告します。
パケット フロー
パケットは、NIC によって受信され、IPS 共有ドライバにより、ユーザによってマッピングされたカーネル内のメモリスペースに配置されます。パケットの前には、IPS ヘッダーが付加されます。各パケットには、パケットがシグニチャ イベント アクション プロセッサに到達したときにそのパケットを通過させるか拒否するかを示すフィールドも含まれています。
ユーザによってマッピングされた共有カーネルのパケット バッファからパケットが取り出され、センサーのモデルに適したプロセッサを実装する処理機能を呼び出します。次の順序になります。
• 単一プロセッサ実行
Time Processor --> Layer 2 Processor --> Deny Filters Processor --> Fragment Reassembly Processor --> Statistics Processor --> Database Processor --> Signature Analysis Processor --> Stream Reassembly Processor --> Signature Event Action Processor
• デュアル プロセッサ実行
実行スレッド 1 Time Processor --> Layer 2 Processor --> Deny Filters Processor --> Fragment Reassembly Processor --> Statistics Processor --> Database Processor --> Signature Analysis Processor --> Slave Dispatch Processor --> | 実行スレッド 2 Database Processor --> Stream Reassembly Processor --> Signature Event Action Processor
シグニチャ イベント アクション プロセッサ
シグニチャ イベント アクション プロセッサは、アラーム チャネル内のシグニチャ イベントから、シグニチャ イベント アクション オーバーライド、シグニチャ イベント アクション フィルタ、およびシグニチャ イベント アクション ハンドラを経由する処理までのデータ フローを調整します。次のコンポーネントで構成されています。
• アラーム チャネル
SensorApp 検査パスからシグニチャ イベント処理にシグニチャ イベントを通知する領域を表すユニット。
• シグニチャ イベント アクション オーバーライド
リスク レーティング値に基づいてアクションを追加します。シグニチャ イベント アクション オーバーライドは、設定したリスク レーティングしきい値の範囲に入るすべてのシグニチャに適用されます。各シグニチャ イベント アクション オーバーライドは独立しており、アクション タイプごとに個別の設定値を持ちます。
• シグニチャ イベント アクション フィルタ
シグニチャ イベントのシグニチャ ID、アドレス、およびリスク レーティングに基づいてアクションを削除します。シグニチャ イベント アクション フィルタへの入力は、シグニチャ イベント アクション オーバーライドによって追加される可能性のあるアクションを持つシグニチャ イベントです。
(注) シグニチャ イベント アクション フィルタが実行できるのはアクションの削除だけであり、新しいアクションの追加はできません。
シグニチャ イベント アクション フィルタには、次のパラメータが適用されます。
– シグニチャ ID
– サブシグニチャ ID
– 攻撃者のアドレス
– 攻撃者のポート
– 攻撃対象のアドレス
– 攻撃対象のポート
– リスク レーティングしきい値の範囲
– 削除するアクション
– シーケンス識別子(任意)
– ストップ ビットまたは継続ビット
– アクション フィルタ行をイネーブルにするビット
– 攻撃対象 OS との関連性または OS との関連性
• シグニチャ イベント アクション ハンドラ
要求されたアクションを実行します。シグニチャ イベント アクション ハンドラからの出力は、実行中のアクションであり、イベント ストアに evIdsAlert が書き込まれる場合があります。
図 A-4 に、シグニチャ イベント アクション プロセッサを通過するシグニチャ イベントの論理フローと、このイベントのアクションで実行される操作を示します。これは、アラーム チャネルで受信された設定済みアクションを持つシグニチャ イベントで開始され、シグニチャ イベント アクション プロセッサの機能コンポーネントを通過するシグニチャ イベントに合わせて上から下へ流れます。
図 A-4 シグニチャ イベント アクション プロセッサを通過するシグニチャ イベント
Cisco IPS ファイル構造
Cisco IPS のディレクトリ構造は次のとおりです。
• /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:イベント ストア アプリケーションが含まれます。
• /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:Web サーバ アプリケーションが含まれます。
• /usr/cids/idsRoot/bin/cidcli:CLI アプリケーションが含まれます。
• /usr/cids/idsRoot/bin/nac:ARC アプリケーションが含まれます。
• /usr/cids/idsRoot/bin/logApp:ロガー アプリケーションが含まれます。
• /usr/cids/idsRoot/bin/mainApp:メイン アプリケーションが含まれます。
• /usr/cids/idsRoot/bin/sensorApp:センサー アプリケーションが含まれます。
• /usr/cids/idsRoot/bin/collaborationApp:コラボレーション アプリケーションが含まれます。
• /usr/cids/idsRoot/bin/falcondump:IDSM2 のセンシング ポートでパケット ダンプを取得するアプリケーションが含まれます。
• /usr/cids/idsRoot/etc:センサーのコンフィギュレーション ファイルが含まれます。
• /usr/cids/idsRoot/htdocs:Web サーバの IDM ファイルが含まれます。
• /usr/cids/idsRoot/lib:センサー アプリケーションのライブラリ ファイルが含まれます。
• /usr/cids/idsRoot/log:デバッグ用のログ ファイルが含まれます。
• /usr/cids/idsRoot/tmp:センサーの実行中に作成される一時ファイルが格納されます。