IDPアプリケーション識別

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

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

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

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

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

サポートされるIDPセッションの最大数は、NFX150-C-S1デバイスのデフォルトプロファイルで8,000、NFX150-C-S1デバイスのSD-WANプロファイルで16,000です。サポートされるIDPセッションの最大数は、NFX150-S1のデフォルトプロファイルでは8,000、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 は、アプリケーションとサービス バインディングの動作とアプリケーション ID をまとめたものです。

  表 1:アプリケーション識別機能を備えたアプリケーションとサービス

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

  例えば、以下の攻撃オブジェクト定義では、攻撃オブジェクトはアプリケーション HTTP にバインドされ、アプリケーション識別が有効になり、サービス フィールド SMTP は無視されます。

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

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

  表 2: IDP ポリシーのアプリケーション設定

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

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

手記：

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

アプリケーションの 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 アプリケーション識別サービスのメモリ制限を設定する方法を示します。

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

Feature Explorerを使用して、特定の機能に対するプラットフォームとリリースのサポートを確認します。追加のプラットフォームがサポートされる場合があります。

次の表を使用して、追加のプラットフォーム情報を確認してください。

SRXシリーズファイアウォール	最大セッション数	中央点(CP)
SRX5600	900万 225万人	フルCP コンボモードCP
SRX5800	1,000万 225万人	フルCP コンボモードCP

Feature Explorerを使用して、特定の機能に対するプラットフォームとリリースのサポートを確認します。

次の表を使用して、プラットフォームのプラットフォーム固有の動作を確認します。

プラットホーム	差
SRXシリーズファイアウォール	IDP AppIDをサポートするSRX320ファイアウォールは、最大16,384のIDPセッションをサポートします。 IDP AppIDをサポートするSRX345ファイアウォールは、最大32,768のIDPセッションをサポートします。