IDPアプリケーション識別

ジュニパーネットワークスは、非標準ポートで実行されている伝送制御プロトコル(TCP)およびユーザーデータグラムプロトコル(UDP)アプリケーションを検出する、定義済みのアプリケーションシグネチャを提供します。これらのアプリケーションを特定することで、侵入検出および防御(IDP)は、非標準ポートで実行されているアプリケーションに適切な攻撃オブジェクトを適用できます。また、デコーダーのないアプリケーションの攻撃シグネチャの範囲を狭めることで、パフォーマンスも向上します。

IDPセンサーはネットワークを監視し、IDPルールベースで定義された特定のルールに基づいて、疑わしいネットワークトラフィックや異常なネットワークトラフィックを検出します。プロトコルまたはアプリケーションに基づいて、攻撃オブジェクトをトラフィックに適用します。アプリケーション シグネチャを使用すると、センサーは非標準ポートで実行されている既知および未知のアプリケーションを識別し、正しい攻撃オブジェクトを適用できます。

アプリケーション シグネチャは、ジュニパーネットワークスが提供するセキュリティ パッケージの一部として利用できます。定義済みのアプリケーション シグネチャは、セキュリティ パッケージの更新プログラムと共にダウンロードします。アプリケーション シグネチャは作成できません。セキュリティパッケージのダウンロードについては、 IDP署名データベースの手動更新の概要を参照してください。

すべての支社/拠点向けSRXシリーズファイアウォールでは、ASCテーブルでサポートされるエントリーの最大数は100,000エントリーです。ユーザーのランド・バッファーのサイズは制限として 1 MB に固定されているため、表には最大 38,837 個のキャッシュ・エントリーが表示されます。

サポートされる IDP セッションの最大数は、SRX320 デバイスで 16,384、SRX345 デバイスで 32,768 です。

サポートされる IDP セッションの最大数は、NFX150-C-S1 デバイスのデフォルトプロファイルで 8000、NFX150-C-S1 デバイスの SD-WAN プロファイルで 16,000 です。サポートされる IDP セッションの最大数は、NFX150-S1 のデフォルトプロファイルで 8000、NFX150-S1 デバイスの SD-WAN プロファイルで 64,000 です。

アプリケーション識別は、アプリケーション識別を要求するサービス(IDP、AppFW、AppTrack、AppQoSなど)がアプリケーション識別を呼び出すために有効になっている場合にのみ、デフォルトで有効になります。これらのポリシーまたは構成のいずれも存在しない場合、アプリケーションの識別は自動的にトリガーされません。ただし、ポリシー ルールでアプリケーションを指定すると、IDP はアプリケーションの識別結果ではなく、指定されたアプリケーションを使用します。ポリシールールでアプリケーションを指定する手順については、 例:IDPアプリケーションおよびサービスの設定を参照してください。

手記：

アプリケーション識別はデフォルトで有効になっています。CLI でアプリケーション識別を無効にするには、 Junos OS アプリケーション識別の無効化と再有効化を参照してください。

すべての支社/拠点向けSRXシリーズファイアウォールで、IDPはパケット以外のコンテキストのヘッダーチェックを許可しません。

アクティブ/アクティブおよびアクティブ/パッシブの両方のシャーシクラスターに導入されたIDPには、次の制限があります。

• フェールオーバーまたはフェールバックするセッションは検査されません。

• IP アクション テーブルは、ノード間で同期されません。

• セカンダリ ノードのルーティング エンジンは、パケット転送エンジンを介してのみ到達可能なネットワークに到達できない場合があります。

• SSL セッション ID キャッシュは、ノード間で同期されません。SSL セッションがセッション ID を再利用し、そのノードがセッション ID がキャッシュされているノード以外のノードで処理された場合、SSL セッションは復号化できず、IDP インスペクションのためにバイパスされます。

アクティブ/アクティブシャーシクラスターに導入されたIDPには、時間拘束範囲のソーストラフィックの場合、送信元(複数の宛先を持つ)からの攻撃にアクティブなセッションがノード全体に分散されている場合、時間制限カウントにはローカルノードのみのビューがあるため、攻撃が検出されない可能性があるという制限があります。この種の攻撃を検出するには、現在サポートされていない時間バインド状態の RTO 同期が必要です。

攻撃オブジェクトは、さまざまな方法でアプリケーションやサービスにバインドできます。

• アタック・オブジェクトは、暗黙的にアプリケーションにバインドでき、サービス定義を持つことはできません。これらは、コンテキストまたは異常の名前に基づいてアプリケーションにバインドされます。

• 攻撃オブジェクトは、サービス名を使用してサービスにバインドできます。

• 攻撃オブジェクトは、TCP または UDP ポート、ICMP の種類またはコード、または RPC プログラム番号を使用してサービスにバインドできます。

指定されたアプリケーションまたはサービスのバインディングが適用されるかどうかは、完全な攻撃オブジェクト定義とIDPポリシー構成によって異なります。

• アタック・オブジェクト定義でアプリケーションを指定した場合には、サービス・フィールドは無視されます。攻撃オブジェクトは、指定されたサービスではなく、アプリケーションにバインドされます。ただし、アタック・オブジェクト定義でサービスを指定し、アプリケーションを指定しない場合、アタック・オブジェクトはサービスにバインドされます。 表 1 は、アプリケーションおよびサービス・バインディングの動作と、アプリケーション識別を要約したものです。

  表 1: アプリケーションを識別するアプリケーションとサービス

  攻撃オブジェクトのフィールド	バインド動作	アプリケーション識別
  :application (http) :service (smtp)	アプリケーション HTTP にバインドします。 サービス フィールドは無視されます。	有効
  :service (http)	アプリケーション HTTP にバインドします。	有効
  :service (tcp/80)	TCP ポート 80 にバインドします。	無効

  例えば、以下のアタック・オブジェクト定義では、アタック・オブジェクトはアプリケーション HTTP にバインドされ、アプリケーション ID は使用可能になり、サービス・フィールド SMTP は無視されます。

• 攻撃オブジェクトがサービス固有のコンテキスト ( http-url など) と異常 ( tftp_file_name_too_long など) に基づいている場合、アプリケーション フィールドとサービス フィールドの両方は無視されます。サービス コンテキストと異常はアプリケーションを意味します。したがって、これらを攻撃オブジェクトで指定すると、アプリケーション識別が適用されます。

• ポリシーで特定のアプリケーションを構成すると、攻撃オブジェクトで指定されたアプリケーション バインドが上書きされます。 表 2 は、IDP ポリシーでのアプリケーション構成とのバインディングをまとめたものです。

  表 2: IDP ポリシーでのアプリケーション構成

  ポリシーのアプリケーションの種類	バインド動作	アプリケーション識別
  Default	攻撃オブジェクト定義で構成されているアプリケーションまたはサービスにバインドします。	アプリケーションベースの攻撃オブジェクトに対して有効 サービスベースの攻撃オブジェクトに対して無効
  Specific application	攻撃オブジェクト定義で指定されたアプリケーションにバインドします。	無効
  Any	すべてのアプリケーションにバインドします。	無効

• IDP ポリシーでアプリケーションを指定する場合、攻撃オブジェクト定義と IDP ポリシーで構成されたアプリケーション・タイプが一致する必要があります。ポリシー ルールでは、2 つの異なるアプリケーション (1 つは攻撃オブジェクト内、もう 1 つはポリシー内) を指定することはできません。

手記：

IDP設定で異なるアプリケーションに基づく攻撃が指定され、コミットに失敗した場合、アプリケーション any できません。代わりにデフォルトを使用してください。

アプリケーションの IDS ルールを設定する際、オプション any は非推奨になります。

ただし、アプリケーションが any され、IDP構成でカスタム攻撃グループが使用されている場合、コミットは正常に実行されます。したがって、コミットチェックはそのようなケースを検出しません。

アプリケーションプロトコルのカプセル化の使用が増えるにつれて、同じレイヤー7プロトコル上で実行されている複数の異なるアプリケーションの識別をサポートする必要が生じます。たとえば、Facebook や Yahoo Messenger などのアプリケーションはどちらも HTTP 上で実行できますが、同じレイヤー 7 プロトコルで実行されている 2 つの異なるアプリケーションとして識別する必要があります。これを行うために、現在のアプリケーション識別層は、レイヤー7アプリケーションとレイヤー7プロトコルの2つの層に分割されています。

レイヤー 7 アプリケーションを検出するために、定義済みのアプリケーション シグネチャが含まれていますが、既存のレイヤー 7 プロトコル シグネチャは引き続き同じように機能します。これらの定義済みのアプリケーション シグネチャは、攻撃オブジェクトで使用できます。

この例では、アプリケーション識別用に IDP ポリシーを設定する方法を示します。

IDP 署名データベースを使用してアプリケーション シグネチャを作成することはできませんが、センサー設定を構成して、アプリケーション識別を実行するセッションの数を制限し、アプリケーション識別のメモリ使用量を制限することもできます。

セッションのメモリ制限:1 つの TCP または UDP セッションのアプリケーション識別用にパケットを保存するために使用できるメモリの最大バイト数を設定できます。また、アプリケーションを識別するためにグローバル メモリ使用量の制限を構成することもできます。システムがセッションに指定されたメモリ制限に達すると、セッションのアプリケーション識別が無効になります。ただし、IDPは引き続きパターンと一致します。一致したアプリケーションはキャッシュに保存され、次のセッションで使用できるようになります。これにより、クライアントからサーバーへの大きなパケットを意図的に送信してアプリケーション識別をバイパスしようとする攻撃者からシステムを保護します。

• セッション数 - アプリケーション識別を同時に実行できるセッションの最大数を設定できます。システムが指定されたセッション数に達すると、アプリケーション識別は使用不可になります。セッションの数を制限して、あまりにも多くの接続要求がシステムに割り当てられたすべてのリソースを圧倒して使い果たしたときに発生するサービス拒否(DOS)攻撃を防ぐことができます。

表 3 に、SRX3400、SRX3600、SRX5600、および SRX5800 装置の中央点(CP)セッション番号の容量を示します。

表 3: 最大 CP セッション番号

SRXシリーズ デバイス	最大セッション数	セントラルポイント(CP)
SRX3400	225万人	コンボモードCP
SRX3600	225万人	コンボモードCP
SRX5600	900万 225万人	フルCP コンボモードCP
SRX5800	1,000万 225万人	フルCP コンボモードCP

この例では、IDP アプリケーション識別サービスのメモリ制限を設定する方法を示します。

• 目的
• アクション
• 意味