Snort 3について：ステートフルシグニチャ評価Byte_Jump

はじめに

このドキュメントでは、7.4以降でSnort 3に追加された新しい手法について説明します。

バックグラウンド情報

• Snort 3検出モジュールは、ブロックモードで動作します。このアプローチではパフォーマンスが向上し、実装が比較的簡単になりますが、複数のデータブロックにまたがるシグニチャの検出には制限があります。
• ユーザエクスペリエンスを容易にするため、Snortには次のような改善点がすでに実装されています。
  1. フロービットを使用すると、ルールライタはネットワークフローにユーザ定義のプロパティをマークできます。このプロパティは、フローからの任意のパケットに対して設定、クリア、およびテストできます（これは、パケット上のいくつかの大きなシグニチャについて結論を出す方法です）。
• ストリームモジュールは、ワイヤパケットを再構成されたパケットに蓄積します。これは、生のパケットよりも大きく、より意味のあるブロックです。再構成されたパケットに対してIPSルールを評価することで、全体像を把握し、より大きなパターン（シグニチャ）に一致する機会が増えます。
• 再構築されたパケットが新しいデータを提示するだけでなく、検出によってすでに処理された以前のデータの一部を含む場合もあります。この場合も、累積されたデータのブロックによって、フロー上で逆方向に（ある程度）広がるシグニチャを検出できます。
• ストリームスプリッタはフローをブロックに分割しますが、カットポイントは、攻撃者がパターン検出を回避するために使用できる潜在的な弱点です。そのため、Snortには、分割を予測不可能にするために実装されたジッタ機構があります。これにより、攻撃者の分析がさらに複雑になります。

最新情報

ステートフルシグニチャ評価は、リストに追加できる新しい手法です。複数のブロックにわたってIPSルール評価を有効にすることによって、検出機能を拡張するしたがって、現在のブロックにデータがない場合、ルールは即座にミスマッチせず、代わりに、より多くのデータが到着するのを待ちます。

対応プラットフォーム

最低限のソフトウェアおよびハードウェアプラットフォーム

機能の詳細

機能の説明

この仕組みを説明しましょう

検出モジュールのワークフローが図に示されています。トラフィック処理段階では、モジュールにはすでにロードされているすべてのルールがあり、モジュールは1つずつデータブロックを受け入れ、ルールを評価し、プロセスステートフルシグニチャ評価ブロックに対して実行されるアクションを定義します。

スキームに関する注意：

1. 現在のデータ・ブロックにルール・サブセットが定義されると、そのルールの各ルールは、他のルールとは独立して評価されます。
2. 各データブロックは、他のブロックとは独立して評価されます。
3. データブロックは、現在のパケットに対して評価されるIPSバッファセットの抽象化です。
4. アクションは、現在のパケットに対して評価されたアクションのリストです。最終的な判定は後で決定されます。

ステートフルシグニチャ評価の仕組みを理解するには、共通のIPSルールがどのように評価され、データブロックがストリームをどのように形成できるかを確認します。

共通ルール評価

IPSルールは次の形式で表示できます。

action protocol source → destination ( option_1: parameters; option_2: parameters; 
option_3: parameters; gid: 1; sid: 1; meta_option_1; meta_option_2; meta_option_3; )

ここで、

action：ルールが起動した場合のパケットのIPSアクション

protocol：照合するプロトコル

source, destination:IPアドレスおよびポート

option_1、option_2、option_3：ルール評価の一部であるIPSオプション

gid、sid：ルールを識別する一意のペア（メタデータ・オプションに似ています）

meta_option_1、meta_option_2、meta_option3：メッセージ、クラス・タイプ、参照などのルール・メタデータ。これらのオプションはルール評価に関与しません。

• プロトコル、送信元、および宛先がルールヘッダーを形成します。これは、ネットワークフロー（評価のために受け入れるフロー）のフィルタのように機能します。 括弧内はすべてルール本文です。ルール本体のIPSオプション（ルールメタデータを除く）は、データブロックに対して評価されるオプションです。これらは次のステートメントに準拠しています。
• オプションは左から右の順に厳密に評価されます。
  1. 次の2つの主要なタイプのいずれかになります。
  2. オプションを使用すると、現在のパケットのIPSバッファが選択されます。
• その他（パターン検索、数値演算、カーソル操作、flowbit演算）
• カーソルは、選択したIPSバッファ内の位置を追跡するために使用されます。

• オプションは次のいずれかです。
  1. 'absolute'。カーソル位置に依存しないことを意味します。
  2. 'relative'は、カーソル位置から評価を開始することを意味します。
• オプションが選択したIPSバッファからカーソルを外そうとすると失敗し、ルール全体が不一致になります（データ不足のため）
• 最後の点は、検出モジュールの制限です。Snortのリソースが無制限の場合、データが使用可能になると（より多くの有線パケットが届くと）、ルールを評価するために検出されたすべてのデータが繰り返しキャッシュされます。

データストリームとIPSバッファ

• データストリームは、同じ送信元からの連続した形式のバイトのストリームです。これは、ステートフルな評価をサポートするために提示された新しい概念です。ブロック間のルール評価は、同じ論理データ内（ファイル、純粋なTCPストリーム、JavaScriptテキストなど）で行う必要があります。

• 一般に、検出モジュールで受信されるデータブロックは次のようになります。
  • 別のIPSバッファからコピーする（たとえば、pkt_dataとfile_dataは同じではありません）
  • 別のストリームに属する
  • ストリームを形成しない（rawパケットから生成されたバッファ）
  • 連続ストリームを形成しない(ICMP、UDP)
  • 順不同（HTTP部分応答）
  • 繰り返しデータを含む（http_inspect.script_detectionやHTTPチャンク応答などの累積ブロック）
• 検出モジュールは、同じストリームのブロックだけを連結するようにソートできます。ソートしないと、評価プロセスはブロックをインターリーブすることによって不要な干渉を検出します。 

注：次の例は、HTTPクライアントが複数のファイルを同時にアップロードおよびダウンロードするケースを示しています。

• 現在、ストリームを表すことができるのは、pkt_dataとfile_dataの2つのIPSバッファだけです。ここで、
  1. pkt_dataは、TCPプロトコルの2つのストリーム（クライアントからサーバへの方向とサーバからクライアントへの方向）を形成します。
  2. file_dataは、ファイル、MIME添付ファイル、およびその他のプロトコルデータ（HTTP HTMLページやその他のコンテンツタイプなど）のストリームを形成する必要があります
• ステートフル評価は、データストリーム内で厳密に実行されます。

ルールの続行

• 前述のセクションは、現在のIPSバッファからカーソルを外した場合にIPSオプションが一致しないという記述で終了しています。ただし、IPSバッファがデータストリームを形成する場合、ステートフルシグニチャ評価機能によって、ルール評価コンテキストがステップインされ、Snortフローオブジェクトに保存されます。保存された評価コンテキスト（状態）は、ルールの継続と呼ばれます。ステートフルシグニチャ評価は、より多くのデータが利用可能になるまで、ルールの最終判定を延期します。
• ルールの続行には、IPSバッファ名、バッファソース、およびターゲットカーソル位置の3つの主要部分があります（バッファソースはデータストリームの一意の識別子です）。
• データブロックが検出モジュールによって処理されると、後続のアクションが実行されます。
  
  • ステートフルシグニチャ評価は、次の場合にルールの継続を作成し、フローに付加します。
    • IPSオプション（byte_jump、content、pcreなど、カーソル位置を更新するもの）は、現在のIPSバッファの後にカーソルを設定する
    • 現在のIPSバッファはデータストリームをサポートします。
    • 現在のIPSバッファは、この時点でデータストリームを形成します。
• ステートフルシグニチャ評価では、次の場合に、直前に作成されたルールの続行が取り消され、フローから削除されます。
  • IPSルールが現在のデータブロックで起動しました（ルールはブロックの他の場所で一致します）
• ステートフルシグニチャ評価は、保留中のルール継続を拒否し、次の場合にはフローから削除します。
  • IPSバッファは連続したストリームを形成しません(たとえば、ブロック内に繰り返しデータがある、またはギャップがある（データの一部が失われた、またはブロックが正常に機能していない）。
• ステートフルシグニチャ評価は、次の場合に利用可能な新しいデータでターゲットカーソル位置を更新します。
  • ルールの継続からのバッファソースが、選択したバッファソースと同じです
  • IPSバッファが連続ストリームを形成
• ステートフルシグニチャ評価は、次の場合にIPSルールエンジンにルール継続を送信します。
  1. 選択したIPSバッファ内の目的のカーソル位置（つまり、最終的にルールの評価を完了するために必要なすべてのデータを受信しました）。

ユーザ設定

• ルールの連続にはメモリが必要なため、Snortでは連続したルールを無制限に保存することはできません。制限を制御するための設定オプションがあります。
  1. Detection.max_continuations_per_flow = 1024：フロー{ 0:65535 }に同時に格納される継続の最大数
• ステートフルシグニチャ評価が限界に達すると、最も古いルールの続きを新しいルールに置き換えます。
• フローに存在する最も古いルールの続きが長すぎるので、ルールの評価を再開するための条件を満たしていません。
• さらに、IPSルールを微調整するために使用できる多数のペグカウント（メインの焦点である必要があります）と制限（必要に応じて）があります。
  1. detection.cont_creations：作成された連続の合計数（合計）
  2. detection.cont_recalls：リコールされた継続回数の合計（合計）
  3. detection.cont_flows：継続を使用したフローの総数(sum)
  4. detection.cont_evals：条件を満たした継続回数の合計(sum)
  5. detection.cont_matches：一致した連続の総数（合計）
  6. detection.cont_mismatches：不一致の連続の総数（合計）
  7. detection.cont_max_num：フローごとの同時実行のピーク数（最大）
  8. detection.cont_match_distance：一致した連続によってジャンプされたバイトの総数（合計）
  9. detection.cont_mismatch_distance：不一致の連続によってジャンプされた合計バイト数(sum)

トラブルシューティング

この機能は既存の検出プロセスの拡張機能であるため、では明示的なトラブルシューティングを行うことはできません。検出に失敗した場合は、ルール、設定、またはトラフィックを調べる必要があります。

問題例

問題：説明

• たとえば、シグニチャがファイルの先頭と末尾を同時にチェックする必要があるとします。
• たとえば、この構造の対象ファイル（ヘッダー、本文、メタデータ）では、メタデータのいずれかが0の値を持つかどうかを確認する必要があります。

• ファイルバイト： e1 f3 22 03 7f ff xx ... xx 01 00 02 00

  • e1 f3 22 03：マジックナンバーの4バイト（ファイルタイプを示す）
  • 7f ff - 2バイト（本体サイズ）
  • xx xx ... xx – 一部のデータの32 kb
  • 01 00 02 00：タグ値形式の4バイトのメタデータ（各1バイト）
• IPSルールは次のようになります。アラートファイル( file_data; content:"|e1f32203|",fast_pattern; byte_jump:2,0,relative; content:"00",within:4, relative; sid: 1; )

  • どこから?

    • ファイルプロトコルにより、ルールは再構築されたパケットのみを受け入れる（rawパケットはステートフルシグニチャ評価に参加しない）
    • 'file_dataオプションは、ストリームを形成できるファイルデータバッファを選択します
    • 最初のコンテンツオプションは高速パターンであり、マジック番号をチェックします（それが目的のファイルタイプである場合）
    • byte_jumpオプションはファイル本体のサイズを読み込み、ファイル本体を飛び越える
    • 2番目のコンテンツオプションは、パラメータ制限検索の深さの範囲内でメタデータ値の最終チェックを実行し、オプションを相対的にします。

問題：ソリューション

ルールは次のように評価されます。

ファイルヘッダーと本文の一部を含む（8kBサイズの）最初のパケットで、次のように処理されます。

1. IPSバッファfile_dataが選択されています。カーソルは0番目のバイトe1を指しています。
2. fast patternオプションは、マジックナンバーの直後のバイト7fを指すカーソル位置に一致し、設定します。
3. byte_jumpオプションは、ファイル本体のサイズを2バイト読み込みます。この2バイトによってカーソルが更新されます。次にbyte_jumpは、32768バイトを超えるジャンプを計算します。
4. ステートフルシグニチャ評価は、24578バイト以上のルール継続を作成します( 32768 - （8kB - 4バイトのヘッダー – 2バイトの本文サイズ）)。
5. byte_jumpオプションではカーソル位置をそこまで設定できないため、ルール全体が一致しません。

2番目のパケット（16kBサイズ）で、ファイル本体部分を伝送する場合：

1. ステートフルシグニチャ評価では、保留中のルールの継続を確認します。
2. バッファはその名前で選択され、file_dataが使用可能であること、および新しいデータサイズが16384であることを確認します。
3. 更新されたカーソルは、8194バイトがまだ必要であることを示しています( 24578 ～ 16384 )
4. ルールは再開されていません。

3番目のパケット（サイズ8198）で、ファイル本体の部分とメタデータを伝送します。

1. ステートフルシグニチャ評価では、保留中のルールの継続を確認します。
2. バッファはその名前で選択され、file_dataが使用可能で、新しいデータサイズが8198であることがわかります。
3. 更新されたカーソルは、バッファに十分なデータがあることを示します。カーソル位置は8194です。
4. ステートフルシグニチャ評価では、ルールの続行が削除されます。
5. ステートフルシグニチャ評価は、カーソルがバイト01を指している2番目のコンテンツオプションからルール評価を再開します。
6. contentオプションは、検索された2番目のバイトで一致を見つけます。
7. ルール全体が最終的に起動します。

制限事項の詳細と一般的な問題

制限事項およびその他の考慮事項

• ステートフルシグニチャ評価の実装により、Snortは設定をリロードするときに、保留中のルールの継続をすべてドロップします。次のデータブロックが検出モジュールに送信されるまで、ドロップされてもルールの続行はSnortメモリを占有することに注意してください。
• ステートフル評価におけるIPSルールのルール遅延機能は、共通ルール評価と同様に動作します。異なるデータブロック上のルール部分の評価時間を要約する。時間が制限を超えると、ルール評価は短絡を行い、先に終了します。
• Flowbits操作の意味は保持されますが、'static'オプションと同様に動作します。
  フロービットセット/クリア/テスト操作は、現在既知のコンテキスト内で実行されます。したがって、flowbitオプションがルールの継続で評価される場合、ルールが評価を開始したときではなく、現在の環境（flowbitsセット）が考慮されます。 

また、ルールライターはファストパターンの場所に注意を払う必要があります。

ルールの任意の部分に含まれる場合でも、fast-patternオプションはルール全体よりも先に評価されます。ルールの評価がトリガーされます。ステートフルシグニチャ評価ベースのルールの場合、ルール継続ポイントはファストパターンオプションの後に配置する必要があります。
さらに、IPSルールの評価では、複数のルールの連続を指定できます（同時に指定することはできません）。 ルール本文の任意のオプションに継続を指定できるため、ルールライターは同じIPSルールを使用してデータストリームの異なる場所で追加のチェックを実行できます。