Secure Firewall Management Center Event Streamer バージョン 7.2.0 統合ガイド
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2022年9月26日月曜日
章のタイトル： eStreamer アプリケーション プロトコルについて
- 接続の仕様
- eStreamer 通信段階について
- eStreamer メッセージ タイプについて
- ヌル メッセージの形式
- エラー メッセージの形式
- イベント ストリーム要求メッセージの形式
- イベント データ メッセージの形式
- ホスト要求メッセージの形式
- ルール ドキュメンテーションのメッセージ形式
- ホスト データおよびマルチ ホスト データ メッセージの形式
- ストリーミング情報メッセージの形式
- ストリーミング要求メッセージの形式
- ストリーミング サービス要求の構造
- ドメイン ストリーミング要求メッセージの形式
- ストリーミング イベント タイプの構造
- 拡張要求メッセージの例
- メッセージ バンドルの形式
- メタデータについて
eStreamer アプリケーション プロトコルについて
Cisco Secure Firewall システム Event Streamer（eStreamer）は、メッセージ指向のプロトコルを使用して、イベントおよびホスト プロファイル情報をクライアント アプリケーションにストリーミングします。クライアントは、Management Center からイベント データとホスト プロファイル データを要求でき、管理対象デバイスからは侵入イベント データのみを要求できます。クライアント アプリケーションは、送信されるデータを指定する要求メッセージを送信することでデータ ストリームを開始し、ストリーミング開始後に Management Center または管理対象デバイスからのメッセージ フローを制御します。
このドキュメントでは、Management Center または管理対象デバイス上の eStreamer サービスを eStreamer サーバーまたは eStreamer と呼ぶことがあります。
以下の項では、eStreamer サービスに接続するための要件を説明し、eStreamer プロトコルで使用されるコマンドとデータ形式について紹介します。
- 接続の仕様では、eStreamer サービスとクライアントとの間の通信フローについて説明し、クライアントがそのサービスとどのようにやりとりするかについて説明します。
- eStreamer 通信段階についてでは、クライアント アプリケーションがデータ要求を eStreamer サーバーに送信し、eStreamer が要求された情報をクライアントに配信するための通信プロトコルについて説明します。
- eStreamer メッセージ タイプについてでは、eStreamer プロトコルで使用されるメッセージ タイプについて説明し、侵入イベント データ、検出イベント データ、メタデータ、およびホスト データをクライアントに返すために eStreamer によって使用されるデータ パケットの基本構造について説明します。また、eStreamer メッセージを解釈できるクライアントの作成に役立つその他の情報を提供します。
接続の仕様
eStreamer 通信段階について
クライアントと eStreamer サービスとの間には、次の 4 つの主要な通信段階があります。
1.
クライアントは eStreamer サーバーとの接続を確立し、接続が両方の当事者によって認証されます。
詳細については、認証された接続の確立を参照してください。
2. クライアントは eStreamer サービスからデータを要求し、ストリーミングされるデータのタイプを指定します。単一のイベント要求メッセージは、イベント メタデータを含む利用可能なイベント データの任意の組み合わせを指定できます。単一のホスト プロファイル要求では、単一のホストまたは複数のホストを指定できます。
イベント データを要求するための 2 つの要求モードを使用できます。
–– イベント ストリーム要求：クライアントは、要求されたイベント タイプと各タイプのバージョンを指定する要求フラグを含むメッセージを送信し、eStreamer サーバーは要求されたデータをストリーミングすることで応答します。
–– 拡張要求：クライアントは、イベント ストリーム要求と同じメッセージ形式で要求を送信しますが、拡張要求用のフラグを設定します。これにより、クライアントと eStreamer サーバー間のメッセージのやりとりが開始され、クライアントはイベント ストリーム要求では利用できない追加の情報とバージョンの組み合わせを要求します。
データの要求の詳細については、eStreamer からのデータの要求を参照してください。
3. eStreamer は要求されたデータ ストリームをクライアントに確立します。
詳細については、eStreamer からのデータの受け取りを参照してください。
4. 接続が終了します。
詳細については、接続の終了を参照してください。
認証された接続の確立
クライアントが eStreamer からデータを要求できるようになるには、事前に eStreamer サービスとの SSL 対応 TCP 接続を開始する必要があります。クライアントは、Management Center または管理対象デバイス上の設定済みの管理インターフェイスで要求できます。クライアント接続は管理インターフェイスのトラフィック チャネル構成を強制しないため、接続用のインターフェイスを選択する場合は構成を無視できます。クライアントが接続を開始すると、eStreamer サーバーが応答し、クライアントとの SSL ハンドシェイクを開始します。SSL ハンドシェイクの一部として、eStreamer サーバーはクライアントの認証証明書を要求し、証明書が有効である（eStreamer サーバーで内部認証局（内部 CA）によって署名されている）ことを確認します。
（注） Cisco は、クライアントが eStreamer サーバーによって提示された証明書が信頼できる認証局によって署名されていることを確認するように要求することを推奨しています。これは PKCS＃12 ファイルに含まれる内部 CA 証明書で、Cisco では、新しい eStreamer クライアントを Management Center または管理対象デバイスに登録するときに提供しています。詳細については、eStreamer クライアントの認証の追加を参照してください。
SSL セッションが確立された後、eStreamer サーバーは証明書の追加の接続後検証を実行します。この検証では、クライアント接続が証明書で指定されたホストから始まり、証明書のサブジェクト名に適切な値が含まれているか確認されます。いずれかの接続後のチェックが失敗すると、eStreamer サーバーは接続を閉じます。必要に応じて、クライアント ホスト名のチェックを実行しないように eStreamer サービスを設定できます（詳細については、eStreamer サービスのオプションを参照）。
クライアントは接続後の検証を実行する必要はありませんが、Cisco では、クライアントがこの検証手順を実行することを推奨しています。認証証明書には、証明書のサブジェクト名に次のフィールド値が含まれています。
|
|
|
|---|---|
|
|
|
|
|
|
eStreamer からのデータの要求
クライアントが実行する、データ要求の管理におけるタスクの概略は次のとおりです。
- 要求セッションの初期化：セッションの確立を参照してください。
- eStreamer イベント アーカイブからのイベントの要求：イベント ストリーム要求と拡張要求を使用したイベント ストリーミングの開始。
- ホスト データの要求：ホスト データの要求を参照してください。
- 要求の変更：要求の変更を参照してください。
- 完全修飾イベントのリクエスト：次を参照してください。 完全修飾イベントのリクエスト
セッションの確立
クライアントは、eStreamer サービスに最初のイベント ストリーム要求を送信することによってセッションを確立します。
この最初のメッセージでは、データ要求フラグを含めるか、または後続のメッセージでデータ要求を送信することができます。この最初のイベント ストリーム要求メッセージ自体は、イベント データ用であれ、ホスト データ用であれ、すべての eStreamer 要求の前提条件です。イベント ストリーム要求メッセージの使用方法については、イベント ストリーム要求メッセージの形式を参照してください。
（注） eStreamer クライアントは、Management Center または管理対象デバイス上の設定済みの管理インターフェイスで要求できます。クライアント接続は管理インターフェイスのトラフィック チャネル構成を強制しないため、接続用のインターフェイスを選択する場合は構成を無視できます。
イベント ストリーム要求と拡張要求を使用したイベント ストリーミングの開始
eStreamer サービスでは、イベント ストリーミング用の 2 つの要求モードが提供されます。モードを組み合わせた要求も可能です。どちらのモードでも、クライアントはイベント ストリーム要求メッセージで要求を開始しますが、要求フラグ ビットは別々に設定します。イベント ストリームのメッセージ形式に関する詳細については、イベント ストリーム要求メッセージの形式を参照してください。
eStreamer はイベント ストリーム要求メッセージを受信すると、次のようにクライアント要求を処理します。
- 要求メッセージが要求フラグ フィールドにビット 30 を設定していない場合、eStreamer は要求フラグ フィールド内の他のセット ビットによって要求されたイベントのストリーミングを開始します。詳細については、イベント ストリーム要求の送信を参照してください。
- イベント ストリーム要求でビット 30 が設定されている場合、eStreamer は拡張要求処理を行います。このビットが設定されている場合は、拡張要求フラグを送信する必要があります。詳細については、拡張要求の送信を参照してください。eStreamer は重複する要求をすべて解決することに注意してください。複数のフラグまたは複数の拡張要求のいずれかによって同じデータの複数のバージョンを要求する場合は、最新のバージョンが使用されます。たとえば、eStreamer が検出イベント バージョン 1 および 6 のフラグ要求と、バージョン 3 の拡張要求を受信すると、バージョン 6 が送信されます。
イベント ストリーム要求の送信
- クライアントは、開始日時と、データ ストリームに含めるイベントとそのバージョン レベルを指定する要求フラグ フィールドを含む要求メッセージを eStreamer サービスに送信します。
- eStreamer は、指定された時刻にイベントのストリーミングを開始します。ストリーミング プロトコルについては、eStreamer からのデータの受け取りを参照してください。
クライアントのイベント ストリーム要求メッセージの形式と内容については、イベント ストリーム要求メッセージの形式を参照してください。
クライアントが要求できるイベントのタイプとイベントのバージョンについては、表 2-6を参照してください。
拡張要求の送信
イベント ストリーム要求メッセージの要求フラグ フィールドにビット 30 を設定すると、拡張要求が開始され、サーバーとのネゴシエーションが開始されます。このビットが設定されている場合は、拡張要求フラグを送信する必要があります。拡張要求で使用可能なイベント タイプについては、表 2-22を参照してください。
- クライアントは、イベント ストリーミング要求メッセージを、要求フラグ ビット 30 を
1に設定（拡張要求を示す）して eStreamer に送信します。メッセージ形式の詳細については、イベント ストリーム要求メッセージの形式を参照してください。 - eStreamer は、クライアントが使用可能なサービスのリストをアドバタイズするストリーミング情報メッセージで応答します。ストリーミング情報メッセージの詳細については、ストリーミング情報メッセージの形式を参照してください。
- クライアントは、使用したいサービスを示すストリーミング要求メッセージと、そのサービスから使用可能なイベントのタイプとバージョンの要求リストを返します。要求リストは、標準イベント ストリーム要求を行う場合の要求フラグ フィールドの設定ビットに対応します。ストリーミング要求メッセージを使用してイベントを要求する方法の詳細については、“拡張要求メッセージの例” sectionを参照してください。
- eStreamer は、クライアントのストリーミング要求メッセージを処理し、メッセージで指定された時刻にデータのストリーミングを開始します。ストリーミング プロトコルについては、eStreamer からのデータの受け取りを参照してください。
完全修飾イベントのリクエスト
複雑なバイナリ形式でイベントを受信する代わりに、クライアントがこのオプションを使用して、JSON や CSV などのテキスト形式で完全修飾イベントをリクエストすることを推奨します。このオプションを使用する場合、バイナリ形式について説明しているこのドキュメントの大部分は無関係です。SDK パッケージの python_client サブディレクトリには、このオプションを使用するためのサンプルコードが含まれています。
このオプションは現在、接続イベント、侵入イベント、侵入パケット、ファイルイベントなど、いくつかのイベントタイプに関する情報の要求のみをサポートしています。他のイベントタイプをバイナリ形式で受信する必要がある場合は、完全修飾およびバイナリイベント形式に個別のクライアント接続を使用する必要があります。
完全修飾イベントを要求するには、文書化されている「イベントストリーム要求メッセージ」を使用し、メッセージの最後に JSON 形式の構成ブロックを追加します。リクエストには、以下に示す通常の 5 つのバイナリ整数が含まれ、その後に次のような JSON 形式の構成の詳細が続きます。
バイナリメッセージ長フィールドには、バイナリヘッダーの長さと JSON ブロックの長さが含まれている必要があります。JSON ブロックの後の終了 Null 文字はオプションですが、Null が含まれる場合、メッセージ長には Null 文字を含める必要があります。要求フラグフィールドでは、ビット 23（拡張イベントヘッダー）のみがサポートされます。他のビットはすべてゼロ、特に、ビット 30（拡張要求）はゼロである必要があります。
クライアントが要求メッセージを送信すると、要求されたイベントタイプがサーバー側 [UI eStreamer 設定（UI eStreamer Configuration）] ページで有効になっている場合、eStreamer サービスはすぐにイベントデータの送信を開始します。
JSON ファイルの形式
この例は、eStreamer SDK の json_request.json ファイルにも含まれています。
Events セクションで、クライアントが受信するイベントタイプごとにブロックを指定します。4 つのサンプルタイプ（ ConnectionEvent 、 IntrusionEvent 、 IntrusionPacket 、および FileEvent ）がサポートされています。各イベントの FieldSetDef セクションでは、そのイベントタイプのイベントに含まれるフィールドまたはフィールドセットをリストする OutputFieldSet を指定する必要があります。サンプルファイルではフィールドセットのみを指定していますが、フィールド名とフィールドセットの任意の組み合わせを使用できます。
各イベントタイプで使用可能なフィールドのリスト、および事前定義されたフィールドセットは、Firepower Management Center の /etc/sf/EventHandler/EventCatalog/EventCatalog.json ファイルにあります。ファイルの末尾にある Fields セクションで、目的のイベントタイプ（ IntrusionEvent など）を探し、次に Fields ブロックと FieldSetDef ブロックを参照して、そのイベントタイプで使用可能な内容を確認します。
OutputFormat セクションには、出力の設定があります。 Transform フィールドは常に Text であり、 TransformConfig フィールドで出力変換形式を指定します。例に示されているのは JSON ですが、 CSV も指定できます。 FlatBuffer と同様に他のテキスト形式も使用できますが、使用する形式のドキュメントを要求する必要があります。
JSON 出力が TransformConfig で指定されている場合、出力には、要求された各フィールドの名前と値のペアが含まれますが、イベントに関係のないフィールドはスキップされます（たとえば、SSL フィールドを要求し、イベントで SSL が使用されなかった場合、出力には SSL フィールドは含まれません）。
TransformConfig で CSV 出力が指定されている場合、出力には、構成にリストされている順序で目的のフィールドが含まれています。フィールドがイベントに関連していない場合、CSV にはそのフィールドのコンマのみが含まれます。バージョン間でフィールドセットが変更され、CSV の互換性がなくなる可能性があるため、CSV を要求する際には事前定義されたフィールドセットを使用しないでください。
完全修飾イベントメッセージ
イベントメッセージは、「メッセージ バンドル フォーマット」、メッセージタイプ 4002 の eStreamer ドキュメントで説明されているようにバンドルに含まれています。
記載されているように、クライアントは、eStreamer サーバーに Null メッセージを送信して、受信した各データバンドルを確認し、追加のデータの受け入れが可能なことを示す必要があります。
サポートされているすべてのイベントタイプについて、イベントデータメッセージは、「相関レコードヘッダー」など、さまざまなイベントタイプの eStreamer ドキュメントで説明されているバイナリヘッダーで始まります。唯一の違いは、データブロックの形式が要求された形式（JSON、CSV など）である点です。クイックリファレンスとして、基本構造を次に示します。
ホスト データの要求
セッションを確立すると、ホスト データの要求をいつでも送信できます。eStreamer は、要求されたホストの情報を Cisco Secure Firewall システム ネットワーク マップから生成します。
要求の変更
eStreamer からのデータの受け取り
（注） eStreamer サーバーは、送信したイベントの履歴を保持しません。クライアント アプリケーションは重複したイベントがないかチェックする必要があります。イベントの重複は、いくつかの理由で不注意に発生する可能性があります。たとえば、新しいストリーミング セッションを開始するときに、新しいセッションの開始点としてクライアントによって指定された時間に複数のメッセージがあり、前のセッションで送信されたものもあれば、送信されていないものもある可能性があります。eStreamer は、指定された要求基準を満たすすべてのメッセージを送信します。アプリケーションは、結果の重複を検出する必要があります。
非アクティブの期間中、eStreamer はクライアントに定期的なヌル メッセージを送信して、接続を開いたままにします。クライアントまたは中間ホストからエラー メッセージを受信すると、接続を終了します。
イベント ストリーム要求
クライアントがイベント ストリーム要求を送信すると、eStreamer はメッセージごとにデータ メッセージを返します。クライアントの確認応答を待つことなく、複数のメッセージを連続して送信することができます。特定の時点で、中断し、クライアントの応答を待ちます。クライアント オペレーティング システムは、受信したデータをバッファリングし、クライアントが独自のペースで処理できるようにします。
クライアント要求にメタデータの要求が含まれている場合、eStreamer は最初にメタデータを送信します。クライアントは、後続のイベント レコードを処理するときに使用できるように、それをメモリに保存する必要があります。
拡張要求
クライアントが拡張要求を送信すると、eStreamer はメッセージをキューに入れてバンドルで送信します。eStreamer は、クライアントの確認応答を待つことなく、複数のバンドルを連続して送信することができます。特定の時点で、中断し、クライアントの応答を待ちます。クライアント オペレーティング システムは、受信したデータをバッファリングし、クライアントが独自のペースで読み取ることができるようにします。
クライアントは各バンドルをメッセージごとに解凍し、レコードとブロックの長さを使用して各メッセージを解析します。各メッセージ ヘッダーのメッセージ全体の長さを使用して、各メッセージの終わりに達した時点を計算し、バンドル全体の長さを使用して、バンドルの終わりに達した時点を知ることができます。バンドルを正しく解析するためにそのコンテンツのインデックスは必要ありません。
メッセージのバンドリング メカニズムについては、メッセージ バンドルの形式を参照してください。
クライアントが追加のフロー制御に使用できるヌル メッセージについては、ヌル メッセージの形式を参照してください。
接続の終了
eStreamer サーバーは、接続を閉じる前にエラー メッセージの送信を試行します。エラー メッセージについては、エラー メッセージの形式を参照してください。
eStreamer サーバーは、次の理由でクライアント接続を閉じる可能性があります。
- メッセージを送信するとエラーが発生する。これには、非アクティブの期間中に eStreamer が送信するイベント データ メッセージとヌル キープアライブ メッセージの両方が含まれます。
- クライアント要求の処理中にエラーが発生する。
- クライアント認証が失敗する（エラー メッセージは送信されません）。
- eStreamer サービスがシャットダウンしている（エラー メッセージは送信されません）。
クライアントはいつでも eStreamer サーバーへの接続を閉じることができ、エラー メッセージ形式を使用して理由を eStreamer サーバーに通知することを試行する必要があります。
eStreamer メッセージ タイプについて
eStreamer アプリケーション プロトコルは、標準メッセージ ヘッダーと、メッセージのペイロードを含むレコード データが続く様々なサブヘッダー フィールドを含む単純なメッセージ形式を使用します。メッセージ ヘッダーはすべての eStreamer メッセージ タイプで同じです。詳細については、eStreamer メッセージ ヘッダー（Message Header）を参照してください。
|
|
|
|
|---|---|---|
eStreamer サーバーとクライアントの両方が、データ フローを制御するためのヌル メッセージを送信します。詳細については、ヌル メッセージの形式を参照してください。 |
||
eStreamer サーバーとクライアントの両方がエラー メッセージを使用して、接続が閉じた理由を示します。詳細については、エラー メッセージの形式を参照してください。 |
||
クライアントは、このメッセージ タイプを eStreamer サービスに送信して、新しいストリーミング セッションを開始し、データを要求します。詳細については、イベント ストリーム要求メッセージの形式を参照してください。 |
||
eStreamer サービスは、このメッセージ タイプを使用して、イベント データとメタデータをクライアントに送信します。詳細については、イベント データ メッセージの形式を参照してください。 |
||
クライアントはこのメッセージ タイプを eStreamer サービスに送信し、ホスト データを要求します。セッションは、すでにイベント ストリーム要求メッセージを介して開始されていなければなりません。詳細については、ホスト要求メッセージの形式を参照してください。 |
||
eStreamer サービスは、このメッセージ タイプを使用して、クライアントが要求した単一のホスト データを送信します。詳細については、ホスト データおよびマルチ ホスト データ メッセージの形式を参照してください。 |
||
eStreamer サービスは、このメッセージ タイプを使用して、クライアントが要求した複数のホスト データを送信します。詳細については、ホスト データおよびマルチ ホスト データ メッセージの形式を参照してください。 |
||
クライアントは、このメッセージ タイプを拡張要求で使用して、希望するストリーム情報メッセージからアドバタイズされたイベントを指定します。詳細については、拡張要求メッセージの例を参照してください。 |
||
eStreamer サービスは、このメッセージ タイプを拡張要求で使用して、クライアントが使用可能なサービスのリストをアドバタイズします。詳細については、ストリーミング情報メッセージの形式を参照してください。 |
||
eStreamer サービスは、このメッセージ タイプを使用して、クライアントにストリーミングするメッセージをパッケージ化します。詳細については、メッセージ バンドルの形式を参照してください。 |
eStreamer メッセージ ヘッダー（Message Header）
すべての eStreamer メッセージは、次の図に示すメッセージ ヘッダーで始まります。次の表では、フィールドについて説明しています。
|
|
|
|
|---|---|---|
メッセージで使用されるヘッダーのバージョンを示します。eStreamer の現在のバージョンの場合、この値は常に |
||
送信されるメッセージのタイプを示します。現在の値のリストについては、表 2-2を参照してください。 |
||
後続のコンテンツの長さを示し、メッセージ ヘッダー自体のバイトを除外します。ヘッダーがありデータのないメッセージのメッセージ長はゼロです。 |
ヌル メッセージの形式
クライアント アプリケーションと eStreamer サービスの両方がヌル メッセージを送信します。ヌル メッセージのタイプは 0 で、メッセージ ヘッダーの後ろにデータはありません。
クライアントは、追加のデータを受け入れる準備ができていることを示すために、ヌル メッセージを eStreamer サーバーに送信します。eStreamer サービスは、データが送信されていないときに接続のアクティブ状態を維持するために、ヌル メッセージをクライアントに送信します。ヌル メッセージのメッセージ長の値は、常に 0 に設定されています。
ヒント 本書のデータ構造図では、（1）や（115）のようなカッコ内の整数は、定数フィールド値を表します。たとえば、ヘッダー バージョン（1）は、議論中のデータ構造のフィールドが常に 1 の値を持つことを意味します。
ヌル メッセージの形式を以下に示します。メッセージ内のゼロ以外の値のみがヘッダー バージョンです。
バイナリ形式のヌル メッセージの例を次に示します。ゼロ以外の値だけが、ヘッダー バージョン値 1 を示す 2 番目のバイトに存在することに注目してください。メッセージのタイプと長さのフィールド（網掛け）の値はそれぞれ 0 です。
ヒント このガイドの例は、どのビットが設定されているかを明確に示すためにバイナリ形式で表示されています。これは、イベント要求メッセージ フィールドやイベント影響フィールドなど、一部のメッセージにとって重要です。
エラー メッセージの形式
クライアント アプリケーションと eStreamer サービスの両方でエラー メッセージが使用されます。エラー メッセージのメッセージタイプは 1 で、ヘッダー、エラー コード、エラー テキスト長、および実際のエラー テキストが含まれています。エラー テキストには、0 ～ 65,535 バイトを含めることができます。
クライアント アプリケーションのカスタム エラー メッセージを作成する場合、Cisco は、エラー コードとして -1 を使用することを推奨します。
次の図は、基本的なエラー メッセージの形式を示しています。網掛けのフィールドは、エラー メッセージに固有のフィールドです。
次の表では、エラー コード メッセージの各フィールドについて説明します。
|
|
|
|
|---|---|---|
イベント ストリーム要求メッセージの形式
eStreamer クライアントは、イベント ストリーム要求メッセージを使用して、ストリーミング セッションを開始します。要求メッセージには、開始時間と、eStreamer サービスが含むべきデータを指定するためのビット フラグ フィールドが含まれ、イベントの任意の組み合わせ、および侵入イベントの追加データやメタデータにすることができます。イベント ストリーム要求メッセージは、イベント ストリーム要求と拡張要求の両方を開始することができます。メッセージ タイプは 2 です。
ホスト プロファイル情報専用の要求を含む、すべてのデータ要求に対するイベント ストリーム要求メッセージを送信する必要があります。このような場合は、最初にイベント ストリーム要求メッセージを送信し、次にホスト要求メッセージ（タイプ 5）を送信してホスト データを指定します。
次の図に、イベント ストリーム要求メッセージの形式を示します。このメッセージは、標準ヘッダーを使用しています。網掛けのフィールドは要求メッセージに固有のフィールドで、次の表で説明します。
次の表では、イベント ストリーム要求メッセージの各フィールドについて説明します。
|
|
|
|
|---|---|---|
詳細については、以下の最初のタイムスタンプを参照してください。 |
||
イベント ストリーム要求で返されるイベントとメタデータのタイプとバージョンを指定します。フラグの定義については、要求フラグを参照してください。 |
最初のタイムスタンプ
（注） 以下で説明するように、クライアント アプリケーションは、イベント ストリーム要求を送信するときに、[最初のタイムスタンプ（Initial Timestamp）] フィールドのアーカイブ タイムスタンプを使用する必要があります。これにより、誤ってイベントを除外しないようにします。デバイスは、送信遅延を伴う「ストア アンド フォワード」メカニズムを使用して、データを Management Center に送信します。検出したデバイスによって割り当てられた生成タイムスタンプによってイベントを要求した場合、遅延イベントが除外される可能性があります。
セッションを開始するときは、前のセッションの最後のレコードのアーカイブ タイムスタンプ（「サーバー タイムスタンプ」とも呼ばれる）から起動することを推奨します。これは技術的な要件ではありませんが、強く推奨されます。前回のセッションで使用した最後のレコードのアーカイブ タイムスタンプを使用しても、eStreamer サービスによって以前のレコードまたはメタデータが再送されることはありません。特定の状況下では、生成タイムスタンプを使用すると、意図せずに新しいストリーミング セッションからイベントを除外してしまう可能性があります。
ストリーミングされたイベントにアーカイブ タイムスタンプを含めるには、要求フラグ フィールドにビット 23 を設定する必要があります。
時間ベースのイベントだけがアーカイブ タイムスタンプを持つことに注意してください。ビット 23 が設定された拡張イベント ヘッダーが要求された場合、メタデータなどの eStreamer が生成するイベントのこのフィールドはゼロになります。
要求フラグ
eStreamer が送信するイベントのタイプを選択するには、イベント データ要求のフラグ フィールドにビット 0 ～ 29 を設定します。拡張要求モードをアクティブにするには、ビット 30 を設定します。ビット 30 を設定しても、データは直接要求されません。このビットが設定されている場合は、拡張要求フラグを送信する必要があります。クライアントは、イベント ストリーム要求メッセージの送信後のサーバー/クライアント メッセージ ダイアログ中にデータを要求します。拡張要求については、eStreamer からのデータの要求を参照してください。
[要求フラグ（Request Flags）] フィールドのビット設定の定義については、表 2-6を参照してください。異なるフラグは、異なるバージョンのイベント データを要求します。たとえば、4.10 形式ではなく Cisco Secure Firewall システム 4.9 形式でデータを取得するには、異なるフラグ ビットを設定します。特定の製品バージョンのデータを要求するときに使用するフラグの固有情報については、表 2-7を参照してください。
個々のメタデータ レコードではなく、バージョン別にメタデータを要求することに注意してください。サポートされている各メタデータのバージョンについては、要求フラグを参照してください。
次の図では、現在使用されているフラグ フィールドのビットを網掛けにしています。
|
|
|
|---|---|
侵入イベントに関連付けられたパケット データの送信を要求します。 |
|
侵入、検出、相関、および接続イベントに関連するバージョン 1 メタデータの送信を要求します。 メタデータを使用して、イベントのコード化されたフィールドおよび数値フィールドを解決できます。eStreamer がメタデータをクライアントに送信する方法と、クライアントがメタデータを使用する方法に関する一般的な情報については、メタデータについてを参照してください。 |
|
侵入イベントの送信を要求します。ビット 2、ビット 6、またはビット 2 および 6 の両方が レコード タイプの要求の詳細については、拡張要求の送信を参照してください。 ビット 2、ビット 6、ビット 30 がすべて |
|
検出データ バージョン 1（Management Center 3.2）の送信を要求します。 検出イベントの詳細については、検出と接続データ構造の概要を参照してください。 |
|
相関データ バージョン 1（Management Center 3.2）の送信を要求します。 |
|
影響相関イベント（侵入影響アラート）の送信を要求します。 侵入影響アラートの詳細については、侵入の影響アラート データ 5.3 以上を参照してください。 |
|
ビット 6 は、ビット 2 と同じ方法で使用されます。ビット 2を参照してください。 |
|
検出データ バージョン 2（Management Center 4.0 ～ 4.1）の送信を要求します（ |
|
接続データ バージョン 1（Management Center 4.0 ～ 4.1）の送信を要求します（ |
|
相関データ バージョン 2（Management Center 4.0 ～ 4.1.x）の送信を要求します（ |
|
検出データ バージョン 3（Management Center 4.5 ～ 4.6.1）の送信を要求します（ レガシー検出イベントの詳細については、レガシー ディスカバリ データ構造を参照してください。 |
|
接続データ バージョン 3（Management Center 4.5 ～ 4.6.1）の送信を要求します（ |
|
相関データ バージョン 3（Management Center 4.5 ～ 4.6.1）の送信を要求します。 |
|
侵入、検出、相関、および接続イベントに関連するバージョン 2 メタデータの送信を要求します。 eStreamer がメタデータをクライアントに送信する方法と、クライアントがメタデータを使用する方法に関する一般的な情報については、メタデータについてを参照してください。 |
|
侵入、相関、検出、および接続イベントに関連するバージョン 3 メタデータの送信を要求します。 eStreamer がメタデータをクライアントに送信する方法と、クライアントがメタデータを使用する方法に関する一般的な情報については、メタデータについてを参照してください。 |
|
検出データ バージョン 4（Management Center 4.7 ～ 4.8.x）の送信を要求します。 |
|
接続データ バージョン 4（Management Center 4.7 ～ 4.9.0.x）の送信を要求します（ |
|
相関データ バージョン 4（Management Center 4.7）の送信を要求します。 Management Center 4.7 形式で送信される相関イベントについては、レガシー相関イベントのデータ構造を参照してください。 |
|
侵入、検出、ユーザー アクティビティ、相関、および接続イベントに関連するバージョン 4 メタデータの送信を要求します。
ビット 22 を使用してビット 20 を要求すると、ユーザーのメタデータも送信されます。 eStreamer がメタデータをクライアントに送信する方法と、クライアントがメタデータを使用する方法に関する一般的な情報については、メタデータについてを参照してください。 |
|
バージョン 1 ユーザー イベントの送信を要求します。ユーザー イベントの詳細については、ユーザー レコードを参照してください。 |
|
相関データ バージョン 5（Management Center 4.8.0.2 ～ 4.9.1）の送信を要求します。 ビット 22 を使用してビット 20 を要求すると、ユーザーのメタデータも送信されます。 レガシー相関（コンプライアンス）イベントの詳細については、レガシー相関イベントのデータ構造を参照してください。 |
|
拡張イベント ヘッダーを要求します。 イベント メッセージ ヘッダーについては、eStreamer メッセージ ヘッダー（Message Header）を参照してください。 |
|
検出データ バージョン 5（Management Center 4.9.0.x）の送信を要求します。 検出イベントの詳細については、検出と接続データ構造の概要を参照してください。 |
|
検出データ バージョン 6（Management Center 4.9.1+）の送信を要求します。 検出イベントの詳細については、検出と接続データ構造の概要を参照してください。 |
|
接続データ バージョン 5（Management Center 4.9.1 ～ 4.10.x）の送信を要求します（ |
|
追加データ レコード内の侵入イベントに関連するイベント追加データを要求します。 イベント データの詳細については、侵入イベント追加データのデータ ブロック フィールドを参照してください。 |
|
検出データ バージョン 7（Management Center 4.10.0+）の送信を要求します。 検出イベントの詳細については、検出と接続データ構造の概要を参照してください。 |
|
相関データ バージョン 6（Management Center 4.10 ～ 4.10.x）の送信を要求します。 |
|
eStreamer への拡張要求を示します。このビットが設定されている場合は、拡張要求フラグを送信する必要があります。拡張要求については、拡張要求の送信を参照してください。 |
特定のバージョンのデータを要求するために使用するフラグを決定するには、次の表を参照してください。バージョン 5.0 以降の場合は、ビット 30 の使用の詳細について、拡張要求の送信を参照してください。
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|
バージョン 5.x より前のすべてのイベント タイプでは、参照クライアントは、
検出エンジン ID フィールドを
センサー ID とラベル付けします。
次の例では、バージョン 1 のメタデータとパケット フラグの両方を使用して、タイプ 7（Cisco Secure Firewall システム 3.2+ と互換性あり）の侵入イベントを要求しています。
Cisco Secure Firewall システム 3.2 と互換性のあるデータ（侵入イベント、パケット、メタデータ、影響アラート、ポリシー違反イベント、およびバージョン 2.0 イベントを含む）のみを要求するには、以下を使用します。
侵入影響アラート、相関イベント、検出イベント、接続イベント、およびパケットとバージョン 3 メタデータを含むタイプ 7 の侵入イベントを Management Center 4.6.1+ 形式で要求するには、以下を使用します。
イベント データ メッセージの形式
eStreamer サービスは、イベント要求を受信すると、イベント データと関連するメタデータをクライアントに送信します。イベント データ メッセージのメッセージ タイプは 3 です。各メッセージには、イベント データまたはメタデータのいずれかを含む単一のデータ レコードが含まれています。
タイプ 3 のメッセージは、イベント データとメタデータのみを伝送することに注意してください。eStreamer は、タイプ 6（単一ホスト）とタイプ 7（マルチホスト）のメッセージ内のホスト情報を送信します。ホスト メッセージ形式については、ホスト データおよびマルチ ホスト データ メッセージの形式を参照してください。
イベント データ メッセージの構成について
eStreamer が送信するイベント データおよびメタデータ メッセージには、次のセクションが含まれています。
- eStreamer メッセージ ヘッダー：eStreamer メッセージ ヘッダー（Message Header）で定義されている標準メッセージ ヘッダー。
- イベント固有のサブヘッダー：追加のイベントの詳細を記述し、後続のペイロード データの構造を決定するコードを含む、イベント タイプによって異なるフィールドのセット。
- データ レコード：固定長フィールドとデータ ブロック。
（注） クライアントは、フィールド長に基づいてすべてのメッセージを展開する必要があります。
イベント タイプ別のイベント メッセージ形式については、以下を参照してください。
- 侵入イベント データ レコードとすべてのメタデータ レコードについては 侵入イベントとメタデータ メッセージの形式。これらのメッセージは固定長フィールドを持ちます。
- 検出イベントまたはユーザー イベント データを含むメッセージについては 検出イベント メッセージの形式。標準の eStreamer メッセージ ヘッダーおよび侵入イベント メッセージに類似したレコード ヘッダーに加えて、検出メッセージには、イベント タイプとサブタイプ フィールドが含まれた独特の検出イベント ヘッダーがあります。検出イベント メッセージ内のデータ レコードは、可変長フィールドとカプセル化されたブロックの複数の層を持つことができるシリーズ 1 ブロックにパッケージ化されます。
- 接続統計情報を含むメッセージについては 接続イベント メッセージの形式。それらの一般的な構造は、検出イベント メッセージと同じです。ただし、データ ブロック タイプは接続統計情報に固有のものです。
- 相関（コンプライアンス）イベント データを含むメッセージについては 相関イベント メッセージの形式。これらのメッセージのヘッダーは侵入イベント メッセージと同じですが、データ ブロックはシリーズ 1 ブロックです。
- 可変長フィールドおよび侵入イベントの追加データなどのネストされたデータ ブロックの複数の層を含む侵入関連レコード タイプを配信する一連のメッセージについては イベント追加データ メッセージの形式。このメッセージ シリーズの構造に関する一般的な情報については、イベント追加データ メッセージの形式を参照してください。シリーズ 1 ブロックに類似しているが、個別に番号が付けられているこのシリーズのブロックの構造に関する情報については、データ ブロック ヘッダーを参照してください。
侵入イベントとメタデータ メッセージの形式
次の図に、侵入イベントおよびメタデータ メッセージの一般的な構造を示します。
| eStreamer メッセージ ヘッダー（Message Header）を参照してください |
||||||||||||||||||||||||||||||||
次の図に、侵入イベントおよびメタデータ メッセージ形式のレコード ヘッダー部分の詳細を示します。レコード ヘッダー フィールドは網掛けされています。その次にある表では、フィールドを定義しています。
| 表 3-1を参照してください |
||||||||||||||||||||||||||||||||
| eStreamer サーバー タイムスタンプ（eStreamer Server Timestamp） |
||||||||||||||||||||||||||||||||
次の表に、侵入イベントおよびメタデータ メッセージのヘッダーの各フィールドについて説明します。
|
|
|
|
|---|---|---|
このフィールドの第 1 ビットは、ヘッダーがアーカイブ タイムスタンプを含む拡張ヘッダーであるかどうかを示すフラグです。残りの 15 ビットは、イベントが検出されたドメインの Netmap ID を含むオプションのフィールドです。このフィールドは、使用されていない場合は空のままです。Netmap ID は、メタデータで提供されるドメインにマップされます。 |
||
データ レコードのコンテンツ タイプを識別します。レコード タイプのリストについては、侵入イベントと一般的なメタデータのレコード タイプを参照してください。 |
||
レコード ヘッダーの後のメッセージのコンテンツの長さ。レコード ヘッダーの 8 または 16 バイトは含まれません。（レコード長 + レコード ヘッダーの長さは、メッセージ長と等しくなります。） |
||
イベントが eStreamer サーバーによってアーカイブされたときに適用されるタイムスタンプを示します。アーカイブ タイムスタンプとも呼ばれます。 |
||
検出イベント メッセージの形式
次の図に、検出イベント メッセージの構造を示します。標準の eStreamer メッセージ ヘッダーとイベント レコード ヘッダーの後には、検出イベント メッセージとユーザー イベント メッセージでのみ使用される検出イベント ヘッダーが続きます。メッセージの検出イベント ヘッダー セクションには、検出イベント タイプおよびサブタイプ フィールドが含まれており、これらのフィールドが一緒になって後続のデータ ブロックへのキーを形成します。現在の検出イベント タイプおよびサブタイプについては、タイプ/サブタイプ別のディスカバリ イベントと接続イベントを参照してください。
| eStreamer メッセージ ヘッダー（Message Header）を参照してください |
||||||||||||||||||||||||||||||||
| フィールドの詳細については、検出イベント メッセージ ヘッダーを参照してください。 |
||||||||||||||||||||||||||||||||
| フィールドの詳細については、ディスカバリ イベント ヘッダー 5.2+を参照してください。 |
||||||||||||||||||||||||||||||||
| ディスカバリ（シリーズ1）ブロックを参照してください |
||||||||||||||||||||||||||||||||
検出イベント メッセージ ヘッダー
次の図の網掛け部分は、検出イベント データ メッセージ形式のレコード ヘッダーのフィールドを示し、それに続くイベント ヘッダーの位置を示しています。次の表では、検出イベント メッセージ ヘッダーのフィールドを定義しています。
| ディスカバリ イベントと接続イベントのレコード タイプを参照してください |
||||||||||||||||||||||||||||||||
| 検出イベント ヘッダー |
||||||||||||||||||||||||||||||||
| ディスカバリ（シリーズ1）ブロックを参照してください |
||||||||||||||||||||||||||||||||
次の表では、検出イベント メッセージのレコード ヘッダーとイベント ヘッダーのフィールドについて説明します。
|
|
|
|
|---|---|---|
このフィールドの第 1 ビットは、ヘッダーがアーカイブ タイムスタンプを含む拡張ヘッダーであるかどうかを示すフラグです。残りの 15 ビットは、イベントが検出されたドメインの Netmap ID を含むオプションのフィールドです。このフィールドは、使用されていない場合は空のままです。Netmap ID は、メタデータで提供されるドメインにマップされます。 |
||
データ レコードのコンテンツ タイプを識別します。レコード タイプのリストについては、ディスカバリ イベントと接続イベントのレコード タイプを参照してください。 |
||
レコード ヘッダーの後のメッセージのコンテンツの長さ。レコード ヘッダーの 8 または 16 バイトは含まれません。（レコード長 + レコード ヘッダーの長さは、メッセージ長と等しくなります。） |
||
イベントが eStreamer サーバーによってアーカイブされたときに適用されるタイムスタンプを示します。アーカイブ タイムスタンプとも呼ばれます。イベント ストリーム要求の要求フラグ フィールドにビット 23 が設定されている場合にのみ存在するフィールド。 |
||
今後使用するために予約されています。要求メッセージ フラグにビット 23 が設定されている場合にのみ表示されるフィールド。 |
||
イベント タイプとサブタイプを含む複数のフィールドが含まれており、これらが一緒になって後続のデータ構造への固有キーを形成します。検出イベント ヘッダーのフィールドの定義については、ディスカバリ イベント ヘッダー 5.2+を参照してください。 |
接続イベント メッセージの形式
接続統計情報を含むメッセージの構造は、検出イベント メッセージと同じです。一般的なメッセージ形式の情報については、検出イベント メッセージの形式を参照してください。接続イベント メッセージは、それらが組み込むデータ ブロック タイプの点で区別されます。
相関イベント メッセージの形式
次の図に、相関（コンプライアンス）イベント メッセージの一般的な構造を示します。標準の eStreamer メッセージ ヘッダーとレコード ヘッダーの直後には、メッセージのデータ レコード セクションのデータ ブロックが続きます。相関メッセージは、シリーズ 1 データ ブロックを使用します。
| eStreamer メッセージ ヘッダー（Message Header）を参照してください |
||||||||||||||||||||||||||||||||
| フィールドの詳細については、相関レコード ヘッダーを参照してください。 |
||||||||||||||||||||||||||||||||
相関レコード ヘッダー
次の図の網掛け部分は、相関イベント メッセージのレコード ヘッダーのフィールドを示しています。相関メッセージはシリーズ 1 データ ブロックを使用することに注意してください。ただし、検出イベント メッセージに表示される検出ヘッダーは含まれていません。それらのヘッダー フィールドは、侵入イベント メッセージのヘッダー フィールドに似ています。次の図に続く表では、相関イベントのレコード ヘッダー フィールドを定義しています。
| レコード タイプ |
||||||||||||||||||||||||||||||||
| eStreamer サーバー タイムスタンプ（eStreamer Server Timestamp） |
||||||||||||||||||||||||||||||||
| シリーズ 1 ブロックを使用します（ディスカバリ（シリーズ1）ブロックを参照）。 |
||||||||||||||||||||||||||||||||
次の表では、相関イベント メッセージのレコード ヘッダーの各フィールドについて説明します。
|
|
|
|
|---|---|---|
このフィールドの第 1 ビットは、ヘッダーがアーカイブ タイムスタンプを含む拡張ヘッダーであるかどうかを示すフラグです。残りの 15 ビットは、イベントが検出されたドメインの Netmap ID を含むオプションのフィールドです。このフィールドは、使用されていない場合は空のままです。Netmap ID は、メタデータで提供されるドメインにマップされます。 |
||
データ レコードのコンテンツ タイプを識別します。侵入、相関、およびメタデータのレコード タイプのリストについては、表 3-1を参照してください。 |
||
レコード ヘッダーの後のメッセージのコンテンツの長さ。レコード ヘッダーの 8 または 16 バイトは含まれません。（レコード長 + レコード ヘッダーの長さは、メッセージ長と等しくなります。） |
||
イベントが eStreamer サーバーによってアーカイブされたときに適用されるタイムスタンプを示します。アーカイブ タイムスタンプとも呼ばれます。 要求メッセージ フラグにビット 23 が設定されている場合にのみ表示されるフィールド。 ホスト プロファイルやメタデータなど、Management Center によって生成されたデータの場合フィールドはゼロです。 |
||
イベント追加データ メッセージの形式
次の図に、イベント追加データ メッセージの構造を示します。侵入イベント追加データ メッセージは、このメッセージ グループの例です。
| eStreamer メッセージ ヘッダー（Message Header）を参照してください |
||||||||||||||||||||||||||||||||
| イベント追加データ メッセージのレコード ヘッダーを参照してください |
||||||||||||||||||||||||||||||||
| シリーズ 2 のデータ ブロックの概要を参照してください |
||||||||||||||||||||||||||||||||
イベント追加データ メッセージは、相関イベント メッセージと同じ形式で、レコード ヘッダーの直後にデータ ブロックがあります。相関メッセージとは異なり、シリーズ 1 データ ブロックではなくシリーズ 2 データ ブロックが使用され、個別のナンバリング シーケンスがあります。シリーズ 2 ブロックのタイプについては、シリーズ 2 のデータ ブロックの概要を参照してください。
イベント追加データ メッセージのレコード ヘッダー
次の図の網掛け部分は、イベント追加データ メッセージのレコード ヘッダーのフィールドを示しています。その次にある表では、イベント追加データ メッセージのレコード ヘッダー フィールドを定義しています。
| レコード タイプ |
||||||||||||||||||||||||||||||||
| eStreamer サーバー タイムスタンプ（eStreamer Server Timestamp） |
||||||||||||||||||||||||||||||||
| シリーズ 2 ブロックを使用します（シリーズ 2 のデータ ブロックの概要を参照）。 |
||||||||||||||||||||||||||||||||
次の表では、イベント追加データ メッセージのレコード ヘッダーの各フィールドについて説明します。
|
|
|
|
|---|---|---|
このフィールドの第 1 ビットは、ヘッダーがアーカイブ タイムスタンプを含む拡張ヘッダーであるかどうかを示すフラグです。残りの 15 ビットは、イベントが検出されたドメインの Netmap ID を含むオプションのフィールドです。このフィールドは、使用されていない場合は空のままです。Netmap ID は、メタデータで提供されるドメインにマップされます。 |
||
データ レコードのコンテンツ タイプを識別します。イベント追加データ レコード タイプのリストについては、侵入イベントと一般的なメタデータのレコード タイプを参照してください。 |
||
レコード ヘッダーの後のメッセージのコンテンツの長さ。レコード ヘッダーの 8 または 16 バイトは含まれません。（レコード長 + レコード ヘッダーの長さは、メッセージ長と等しくなります。） |
||
イベントが eStreamer サーバーによってアーカイブされたときに適用されるタイムスタンプを示します。アーカイブ タイムスタンプとも呼ばれます。 要求メッセージ フラグにビット 23 が設定されている場合にのみ表示されるフィールド。Management Center によって生成されたイベントの場合は、フィールドが存在しません。 |
||
| 要求メッセージ フラグにビット 23 が設定されている場合にのみ表示されるフィールド。Management Center によって生成されたイベントの場合は、フィールドが存在しません。 |
データ ブロック ヘッダー
シリーズ 1 ブロックとシリーズ 2 ブロックは、構造は類似していますが、ナンバリングが異なります。これらのブロックは、検出、相関、接続、またはイベント追加データ メッセージのデータ部分のどこにでも置くことができます。これらのブロックは、複数のネスティング レベルで他のブロックをカプセル化します。
第 1 シリーズと第 2 シリーズの両方のデータ ブロックは、次の図に示すヘッダー構造で始まります。次の表に、ヘッダー フィールドに関する情報を示します。ヘッダーの直後には、データ ブロック タイプに関連付けられたデータ構造が続きます。
|
|
|
|
|---|---|---|
シリーズ 1 ブロックのタイプについては、ディスカバリ（シリーズ1）ブロックを参照してください。 シリーズ 2 ブロックのタイプについては、シリーズ 2 のブロック タイプを参照してください。 |
||
データ ブロックの長さ。データのバイト数に 2 つのデータ ブロック ヘッダー フィールドの 8 バイトを加えたバイト数です。 |
ホスト要求メッセージの形式
ホスト プロファイルを受信するには、ホスト要求メッセージを送信します。IP アドレス範囲で定義された単一のホストまたは複数のホストのデータを要求できます。
イベント ストリーム要求メッセージを送信することによって、ホスト プロファイル情報の要求を含むすべてのデータ要求で最初にセッションを初期化することが必須であることに注意してください。ホスト データをストリーミングするだけのために設定するには、最初のイベント ストリーム要求メッセージで次のいずれかの要求フラグ設定を使用できます。
- 適切なバージョンのメタデータのビットを設定する（これは、ホスト データをストリーミングする場合に有益です）
- 要求フラグを設定しない
- ビット 11 を設定する（eStreamer のレガシー バージョンを使用する場合は、デフォルトのイベント ストリーミングを抑制するため）
最初のメッセージの後、ホスト要求メッセージ（タイプ 5）を使用してホストを指定します。
（注） デフォルトのイベント ストリーミングを使用するレガシー eStreamer バージョンの場合、ホスト プロファイル データのみをストリーミングする場合は、デフォルトのイベント メッセージを抑制する必要があります。最初に、要求フラグ フィールドのビット 11 を 1 に設定したイベント ストリーム要求メッセージをサーバーに送信します。その後、ホスト要求メッセージを送信します。
次の図に、ホスト要求メッセージの形式を示します。網掛けのフィールドはホスト要求メッセージの形式に固有であり、次の表で定義されています。上記の 3 つのフィールドは、標準のメッセージ ヘッダーです。
|
|
|
|
|---|---|---|
次のコードを使用して、単一のホストまたは複数のホストのデータを要求します。
|
||
データを返す必要があるホストの IP アドレス（要求が単一ホストに対する場合）、または IP アドレス範囲の開始アドレス（要求が複数のホストに対する場合）。IPv4 または IPv6 アドレスにできます。 |
||
IP アドレス範囲の終了アドレス（要求が複数のホストに対する場合）、または開始 IP アドレスの値（要求が単一ホストに対する場合）。IPv4 または IPv6 アドレスにできます。 |
次の図に、レガシーのホスト要求メッセージの形式を示します。eStreamer は引き続きこの要求に応答します。現在の要求との唯一の違いは、IPv4 アドレス フィールドが小さいという点です。網掛けのフィールドはホスト要求メッセージの形式に固有であり、次の表で定義されています。上記の 3 つのフィールドは、標準のメッセージ ヘッダーです。
|
|
|
|
|---|---|---|
次のコードを使用して、単一のホストまたは複数のホストのデータを要求します。
|
||
データを返す必要があるホストの IP アドレス（要求が単一ホストに対する場合）、または IP アドレス範囲の開始アドレス（要求が複数のホストに対する場合）。IP アドレス オクテットでアドレスを指定します。 |
||
IP アドレス範囲の終了アドレス（要求が複数のホストに対する場合）、または開始 IP アドレスの値（要求が単一ホストに対する場合）。 |
ルール ドキュメンテーションのメッセージ形式
ルール ドキュメンテーション プロファイルを受信するには、ルール ドキュメンテーション メッセージを送信します。ジェネレータ ID、署名 ID、およびリビジョンでこれらを要求します。
ルール ドキュメンテーション情報の要求を含むすべてのデータ要求では、イベント ストリーム要求メッセージを送信することで、最初にセッションを初期化しておく必要があります。ホスト データをストリーミングするだけのために設定するには、最初のイベント ストリーム要求メッセージで次のいずれかの要求フラグ設定を使用できます。
- 適切なバージョンのメタデータのビットを設定する（これは、ホスト データをストリーミングする場合に有益です）
- 要求フラグを設定しない
- ビット 11 を設定する（eStreamer のレガシー バージョンを使用する場合は、デフォルトのイベント ストリーミングを抑制するため）
最初のメッセージの後、ルール ドキュメンテーション メッセージ（タイプ 10）を使用してルールを指定します。
以下のグラフィックに、ルール ドキュメンテーション メッセージの形式を示します。網掛けされたフィールドは、ルール ドキュメンテーションのメッセージ形式に固有です。これを次の表で定義します。上記の 3 つのフィールドは、標準のメッセージ ヘッダーです。
|
|
|
|
|---|---|---|
ルール ドキュメンテーション データ ブロックのデータを要求します。この値は常に |
||
ホスト データおよびマルチ ホスト データ メッセージの形式
eStreamer は、完全なホスト プロファイル データ ブロックをそれぞれ含む、ホスト データ メッセージを送信することによって、ホスト要求に応答します。eStreamer は、要求で指定された各ホストに対し 1 つのホスト データ メッセージを送信します。eStreamer は、タイプ 6 のメッセージを使用して単一のホスト プロファイルの要求に応答し、タイプ 7 のメッセージを使用して複数のホストの要求に応答します。タイプ 6 およびタイプ 7 のメッセージの形式は同一であり、メッセージ タイプのみが異なります。
ホスト データ メッセージには、レコード タイプ フィールドはありません。メッセージの構造は、メッセージ タイプと、メッセージに含まれる完全なホスト プロファイルのデータ ブロック タイプによって伝達されます。完全なホスト プロファイル データ ブロックは、一連のブロックのグループです。
次の図はホスト データ メッセージの形式を示しており、その次の表では網掛けフィールドを定義しています。
| ホスト ディスカバリと接続データ ブロック タイプを参照してください |
||||||||||||||||||||||||||||||||
|
|
|
|
|---|---|---|
メッセージに含まれる完全なホスト プロファイル データのブロック タイプを指定します。ホスト ディスカバリと接続データ ブロック タイプを参照してください。 |
||
ホストのデータ。現在の完全なホスト プロファイル データ ブロックの定義へのリンクについては、ホスト ディスカバリと接続データ ブロック タイプを参照してください。 |
ストリーミング情報メッセージの形式
eStreamer サービスは、拡張要求の要求を受信すると、以下に説明するストリーミング情報メッセージをクライアントに送信します。このメッセージは、サーバーの使用可能なサービスのリストをアドバタイズします。現在、関連する唯一のオプションは eStreamer サービス（6667）ですが、メッセージには他のサービスがリストされる場合があり、それらは無視する必要があります。アドバタイズされた各サービスは、ストリーミング サービス要求の構造で説明するストリーミング サービス要求構造によって表されます。
次の図に、ストリーミング情報メッセージの形式を示します。網掛けのフィールドは、このメッセージ タイプに固有のものです。上記の 3 つのフィールドは、標準のメッセージ ヘッダーです。
| サービス... |
||||||||||||||||||||||||||||||||
|
|
|
|
|---|---|---|
メッセージ ヘッダーの後のメッセージのコンテンツの長さ。[ヘッダー バージョン（Header Version）]、[メッセージ タイプ（Message Type）]、および [メッセージ長（Message Length）] フィールドのバイトは含まれません。 |
||
使用できるサービスのリスト。ストリーミング サービス要求の構造を参照してください。 |
ストリーミング要求メッセージの形式
クライアントは、ストリーミング要求メッセージを使用して、使用するストリーミング情報メッセージで eStreamer サービスに指定し、その後にストリーミングされるイベント タイプおよびバージョンの要求のセットを指定します。次の図はメッセージの構造を示し、次の表ではフィールドを定義しています。要求されたサービスは、ストリーミング サービス要求の構造で説明するストリーミング サービス要求構造によって表されます。
次の図に、ストリーミング情報メッセージの形式を示します。網掛けのフィールドは、このメッセージ タイプに固有のものです。上記の 3 つのフィールドは、標準のメッセージ ヘッダーです。
| サービス... |
||||||||||||||||||||||||||||||||
|
|
|
|
|---|---|---|
メッセージ ヘッダーの後のメッセージのコンテンツの長さ。[ヘッダー バージョン（Header Version）]、[メッセージ タイプ（Message Type）]、および [メッセージ長（Message Length）] フィールドのバイトは含まれません。 |
||
要求されたサービス構造のリスト。ストリーミング サービス要求の構造を参照してください。 |
ストリーミング サービス要求の構造
eStreamer サービスは、アドバタイズする各サービスについて、ストリーミング情報メッセージで 1 つのストリーミング サービス要求のデータ構造を送信します。eStreamer サービスは、ストリーミング サービス要求の最後のフィールドを使用しません。このフィールドは、含まれる予定のイベント タイプのリストを規定します。
クライアントは、eStreamer からのストリーミング サービス要求構造を処理し、サーバーに返す応答で同じ構造を使用します。クライアントがサーバーに送信するストリーミング サービス要求には、最初に、eStreamer によってアドバタイズされるサービスに対する要求が含まれ、2 番目に、クライアントが受信する要求されたイベント タイプを指定するストリーミング イベント タイプ構造のリストが含まれます。
各ストリーミング イベント タイプ構造には、要求された各イベント タイプのイベント タイプとバージョンを指定する 2 つのフィールドが含まれています。ストリーミング イベント タイプの構造については、を参照してください。
次の図に、ストリーミング サービス要求構造のフィールドを示します。その次にある表では、フィールドを定義しています。
ストリーミング サービス要求構造のフィールドは次のとおりです。
|
|
|
|
|---|---|---|
| eStreamer サーバー メッセージでは、これによって利用可能なサービスがアドバタイズされます。 |
||
サービス要求の長さ。タイプと長さを含むサービス要求の長さを表します。 長さには、メッセージ内のすべてのストリーミング イベント タイプのレコードと、終端レコードを含める必要があることに注意してください。 |
||
ドメイン ストリーミング要求メッセージの形式
クライアントは、ドメイン ストリーミング要求メッセージを使用して、eStreamer の特定のドメインからのイベントを要求します。次の図はメッセージの構造を示し、次の表ではフィールドを定義しています。網掛けのフィールドは、このメッセージ タイプに固有のものです。上記の 3 つのフィールドは、標準のメッセージ ヘッダーです。
ドメイン ストリーミング要求メッセージのフィールドは次のとおりです。
ストリーミング イベント タイプの構造
eStreamer クライアントは、ストリーミング イベント タイプ構造を使用して、イベントのバージョンとバージョンを指定します。各イベント バージョンとタイプの組み合わせは、イベント ストリームの要求です。
ストリーミング イベント タイプ構造のリストは、すべてのフィールドがゼロに設定された構造で終了する必要があります。具体的な場所は次のとおりです。
Event Version = 0
Event Type = 0
次の図に、ストリーミング イベント タイプ構造の形式を示します。
ストリーミング イベント タイプ構造のフィールドは次のとおりです。
|
|
|
|
|---|---|---|
イベント タイプのバージョン番号。各イベント タイプでサポートされているバージョンのリストについては、拡張要求のイベント タイプとバージョンを参照してください。 |
||
要求されたイベント タイプのコード。有効なイベント タイプとバージョン コードの現在のリストについては、拡張要求のイベント タイプとバージョンを参照してください。 |
次の表に、クライアントが拡張要求で指定できるイベントのタイプとバージョンを示します。表には、各イベント タイプのバージョンに対応する Management Center のソフトウェア バージョンが示されています。たとえば、バージョン 4.8.0.2 ～ 4.9.1 で Management Center によってサポートされていた相関イベントを要求するには、イベント タイプ 31、バージョン 5 を要求する必要があります。イベントが異なるイベント タイプで記録されていた場合は、要求されたイベント タイプの形式に一致するようにアップグレードまたはダウングレードされます。
拡張要求メッセージの例
ストリーミング情報メッセージ
次の例では、サーバーは 2 つのサービス、第 1 のタイプ 6667 （eStreamer）と第 2 のタイプ 5000 をアドバタイズします。サーバーからのストリーミング情報メッセージでは、[フラグ（flags）] フィールドと [最初のタイムスタンプ（initial timestamp）] フィールドはゼロであり、メッセージではイベント タイプは指定されていません。
ストリーミング要求メッセージ
以下は、クライアントがサービス タイプ 6667 （eStreamer）を要求し、接続イベントのバージョン 6（イベント タイプ 71 ）とメタデータのバージョン 4 （イベント タイプ 21 ）の 2 つのイベント タイプを指定するストリーミング要求メッセージです。
メッセージ バンドルの形式
クライアントが拡張要求を送信すると、eStreamer サーバーはバンドル形式でメッセージを送信します。
クライアントはヌル メッセージで応答し、バンドル全体の受信の確認応答を行います。クライアントは、バンドル内の個々のメッセージの受信を確認応答するべきではありません。
メッセージ バンドルのメッセージ タイプは 4002 です。
次の図に、メッセージ バンドルの構造を示します。網掛けのフィールドは、バンドル メッセージ タイプに固有のものです。次の表に、フィールドとデータ構造の内容を示します。
メッセージ バンドル メッセージのフィールドは次のとおりです。
メタデータについて
eStreamer サーバーは、要求されたイベント レコードとともにメタデータを提供できます。メタデータを受信するには、明示的に要求する必要があります。特定のバージョンのメタデータを要求する方法については、要求フラグを参照してください。メタデータは、イベント レコードのコードおよび数値識別子のコンテキスト情報を提供します。たとえば、侵入イベントには検出デバイスの内部識別子のみが含まれ、メタデータはデバイスの名前を提供します。
要求されたメタデータと環境によって、送信されるメタデータの量が大幅に異なる可能性があります。
メタデータの伝送
要求メッセージがメタデータを指定する場合、eStreamer は関連するメタデータ レコードを送信してから、関連するイベント レコードを送信します。
eStreamer は、クライアントに送信したメタデータを追跡し、同じメタデータ レコードを再送しません。クライアントは、受信した各メタデータ レコードをキャッシュする必要があります。キャッシュ サイズが制限されているクライアント アプリケーションでキャッシュがいっぱいになった場合は、クライアントがストリーミング中のイベントのメタデータ値をすべて受信できるようにキャッシュを消去して eStreamer サービスに再接続する必要があります。eStreamer は、あるセッションから次のセッションへのメタデータ送信の履歴を保持しないため、新しいセッションが開始され、要求メッセージがメタデータを指定すると、eStreamer は最初からメタデータのストリーミングを再スタートします。再接続すると、クライアントは要求メッセージで「最初のタイムスタンプ」を指定して、イベントの重複や不足を回避できるようになります。
フィードバック