IDPアプリケーションの識別

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

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

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

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

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

すべての支社/拠点デバイスで、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にバインドされ、アプリケーション識別が有効になり、サービスフィールド SMTP が無視されます。

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

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

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

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

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

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

アプリケーションのIDSルールを設定している間、オプション any は非推奨です。

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

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

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

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

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

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

• セッション数—AppIDを同時に実行できるセッションの最大数を設定できます。システムが指定されたセッション数に達すると、AppIDは無効になります。セッション数を制限することで、サービス拒否(DOS)攻撃を防ぐことができます。DOS攻撃は、システムに割り当てられたリソースが多すぎると圧倒され、使い果たされた場合に発生します。

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

中央ポイント(CP)セッション番号の容量の詳細については、「 補足プラットフォーム情報 」セクションを参照してください。

この例では、IDP AppIDサービスのメモリ制限を設定する方法を示しています。

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

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

プラットフォームの追加情報を確認するには、以下の表を使用してください。

機能エクスプローラーを使用して、特定の機能のプラットフォームとリリースのサポートを確認します。

お使いのプラットフォームに固有の動作を確認するには、以下の表を使用してください。