Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

IDP アプリケーション識別

ジュニパーネットワークスは、非標準ポートで実行されている TCP(Transmission Control Protocol)アプリケーションと UDP(ユーザー データグラム プロトコル)アプリケーションを検出する、事前定義されたアプリケーション シグネチャを提供します。

詳細については、以下のトピックを参照してください。

IDP アプリケーション識別について

ジュニパーネットワークスは、非標準ポートで実行されている TCP(Transmission Control Protocol)アプリケーションと 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 同期が必要です。

攻撃オブジェクトによるIDPサービスとアプリケーションのバインディングについて

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

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

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

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

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

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

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

    攻撃オブジェクトフィールド

    バインディング動作

    アプリケーション識別

    :application (http)

    :service (smtp)

    • アプリケーション HTTP にバインドします。

    • サービスフィールドは無視されます。

    有効

    :service (http)

    アプリケーション HTTP にバインドします。

    有効

    :service (tcp/80)

    TCP ポート 80 にバインドします。

    無効

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

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

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

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

    ポリシー内のアプリケーション タイプ

    バインディング動作

    アプリケーション識別

    Default

    攻撃オブジェクト定義で設定されたアプリケーションまたはサービスにバインドします。

    • アプリケーションベースの攻撃オブジェクトに対して有効

    • サービスベースの攻撃オブジェクトで無効化

    Specific application

    攻撃オブジェクト定義で指定されたアプリケーションにバインドします。

    無効

    Any

    すべてのアプリケーションにバインドします。

    無効

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

メモ:

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

アプリケーションの IDS ルールの設定中、 オプション any は非推奨です。

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

ネストされたアプリケーションの IDP アプリケーション識別について

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

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

例:アプリケーション識別のための IDP ポリシーの設定

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

要件

開始する前に、以下を行います。

  • ネットワーク インターフェイスを設定します。

  • アプリケーション パッケージをダウンロードします。

概要

この例では、IDP ポリシー ABC を作成し、IPS ルールベースでルール 123 を定義します。IDP ポリシー ルールでは、デフォルトをアプリケーション タイプとして指定します。既定のアプリケーションではなくアプリケーションを指定した場合、このルールのアプリケーション識別機能は無効になり、IDP はトラフィックと指定されたアプリケーション タイプと一致します。現時点では、アプリケーション識別で定義されたアプリケーションを直接参照することはできません。

構成

手順

手順

アプリケーション識別用に IDP ポリシーを設定するには、次の手順に示します。

  1. IDP ポリシーを作成します。

  2. アプリケーションタイプを指定します。

  3. 一致条件が満たされたときに実行するアクションを指定します。

  4. デバイスの設定が完了したら、設定をコミットします。

検証

設定が正常に機能していることを確認するには、 コマンドを show security idp 入力します。

IDP アプリケーション識別のメモリ制限設定について

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

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

  • セッション数 — アプリケーション識別を同時に実行できる最大セッション数を設定できます。アプリケーション識別は、システムが指定されたセッション数に達した後に無効になります。セッション数を制限することで、サービス拒否(DOS)攻撃を防ぐことができます。DOS攻撃は、多すぎる接続要求がシステム上の割り当てられたすべてのリソースを圧倒し、枯渇した場合に発生します。

表 3 は、SRX3400、SRX3600、SRX5600、SRX5800 デバイスの中央ポイント(CP)セッション番号の容量を示しています。

表 3:最大 CP セッション数

SRX シリーズ デバイス

最大セッション数

中央ポイント(CP)

SRX3400

225 万

コンボモードCP

SRX3600

225 万

コンボモードCP

SRX5600

900 万

225 万

フルCP

コンボモードCP

SRX5800

1000万

225 万

フルCP

コンボモードCP

例:IDP アプリケーション識別サービスのメモリー制限の設定

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

要件

開始する前に、以下を行います。

概要

この例では、1 つの TCP セッションのアプリケーション識別用のパケットを保存するために使用できるメモリの最大量として 5,000 メモリ バイトを設定します。

構成

手順

手順

IDP アプリケーション識別サービスのメモリおよびセッション制限を設定するには、次の手順に示します。

  1. アプリケーション識別のメモリ制限を指定します。

  2. デバイスの設定が完了したら、設定をコミットします。

検証

設定が正常に機能していることを確認するには、 コマンドを show security idp memory 入力します。

アプリケーション識別プロセス用の IDP カウンターの検証

目的

アプリケーション識別プロセスの IDP カウンターを検証します。

アクション

CLI から、 コマンドを show security idp counters application-identification 入力します。

サンプル出力

コマンド名

意味

出力は、アプリケーション識別カウンターの概要を示しています。以下の情報を確認します。

  • AI キャッシュがヒット — アプリケーション識別キャッシュのヒット数を表示します。

  • AIキャッシュミス — アプリケーションが一致するが、アプリケーション識別キャッシュエントリーが追加されない回数を表示します。

  • AI一致 — アプリケーションが一致する回数を表示し、アプリケーション識別キャッシュエントリーが追加されます。

  • AI no-matchs — アプリケーションが一致しない回数を表示します。

  • AI 対応セッション — アプリケーション識別が有効になっているセッション数を表示します。

  • AI無効セッション — アプリケーション識別が無効になっているセッション数を表示します。

  • キャッシュヒットによるAI無効セッション — キャッシュエントリーが一致した後にアプリケーション識別が無効になるセッション数を表示します。このセッションでは、アプリケーション識別プロセスは中止されています。

  • 設定によるAI無効セッション —センサー設定によりアプリケーション識別が無効になっているセッション数を表示します。

  • プロトコルの再マッピングによるAI無効化セッション — IDPポリシールール定義で特定のサービスを設定したため、アプリケーション識別が無効になっているセッション数を表示します。

  • 非 TCP/UDP フローによる AI 無効セッション — セッションが TCP または UDP セッションではないため、アプリケーション識別が無効になっているセッションの数を表示します。

  • AIシグネチャがないためにAIを無効にしたセッション — アプリケーション識別シグネチャに一致するものが見つからないため、アプリケーション識別が無効になっているセッション数を表示します。

  • セッション制限によるAI無効化 — セッションが設定された最大制限に達したために、アプリケーション識別が無効になっているセッション数を表示します。今後のセッションでは、アプリケーション識別も無効になっています。

  • セッションパケットメモリ制限によるAI無効 — セッションがTCPまたはUDPフローの最大メモリ制限に達したために、アプリケーション識別が無効になっているセッションを表示します。今後のセッションでは、アプリケーション識別も無効になっています。

  • グローバルなパケットメモリ制限によりAIを無効にする — 最大メモリ制限に達したためにアプリケーション識別が無効になっているセッションを表示します。今後のセッションでは、アプリケーション識別も無効になっています。