Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

IDP Application Identification

 

Juniper Networks provides predefined application signatures that detect Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) applications running on nonstandard ports.

For more information, see the following topics:

Understanding IDP Application Identification

Juniper Networks provides predefined application signatures that detect Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) applications running on nonstandard ports. Identifying these applications allows Intrusion Detection and Prevention (IDP) to apply appropriate attack objects to applications running on nonstandard ports. It also improves performance by narrowing the scope of attack signatures for applications without decoders.

The IDP sensor monitors the network and detects suspicious and anomalous network traffic based on specific rules defined in IDP rulebases. It applies attack objects to traffic based on protocols or applications. Application signatures enable the sensor to identify known and unknown applications running on nonstandard ports and to apply the correct attack objects.

Application signatures are available as part of the security package provided by Juniper Networks. You download predefined application signatures along with the security package updates. You cannot create application signatures. For information on downloading the security package, see Updating the IDP Signature Database Manually Overview.

On all branch SRX Series devices, the maximum supported number of entries in the ASC table is 100,000 entries. Because the user land buffer has a fixed size of 1 MB as a limitation, the table displays a maximum of 38,837 cache entries.

The maximum number of IDP sessions supported is 16,384 on SRX320 devices and 32,768 on SRX345 devices.

The maximum number of IDP sessions supported is 8000 on default profile of NFX150-C-S1 devices and 16,000 on SD-WAN profile of NFX150-C-S1 devices. The maximum number of IDP sessions supported is 8000 on default profile of NFX150-S1 and 64,000 on SD-WAN profile of NFX150-S1 devices.

Application identification is enabled by default only if the service requesting the application identification (such as IDP, AppFW, AppTrack or AppQoS) is enabled to invoke the application identification. If none of these policies or configurations exist, application identification will not be automatically triggered. However, when you specify an application in the policy rule, IDP uses the specified application rather the application identification result. For instructions on specifying applications in policy rules, see Example: Configuring IDP Applications and Services.

Note

Application identification is enabled by default. To disable application identification with the CLI see Disabling and Reenabling Junos OS Application Identification.

On all branch SRX Series devices, IDP does not allow header checks for nonpacket contexts.

IDP deployed in both active/active and active/passive chassis clusters has the following limitations:

  • No inspection of sessions that fail over or fail back.

  • The IP action table is not synchronized across nodes.

  • The Routing Engine on the secondary node might not be able to reach networks that are reachable only through a Packet Forwarding Engine.

  • The SSL session ID cache is not synchronized across nodes. If an SSL session reuses a session ID and it happens to be processed on a node other than the one on which the session ID is cached, the SSL session cannot be decrypted and will be bypassed for IDP inspection.

IDP deployed in active/active chassis clusters has a limitation that for time-binding scope source traffic, if attacks from a source (with more than one destination) have active sessions distributed across nodes, then the attack might not be detected because time-binding counting has a local-node-only view. Detecting this sort of attack requires an RTO synchronization of the time-binding state that is not currently supported.

Understanding IDP Service and Application Bindings by Attack Objects

Attack objects can bind to applications and services in different ways:

  • Attack objects can bind to an application implicitly and not have a service definition. They bind to an application based on the name of a context or anomaly.

  • Attack objects can bind to a service using a service name.

  • Attack objects can bind to a service using TCP or UDP ports, ICMP types or codes or RPC program numbers.

Whether the specified application or service binding applies or not depends on the complete attack object definition as well as the IDP policy configuration:

  • If you specify an application in an attack object definition, the service field is ignored. The attack object binds to the application instead of the specified service. However, if you specify a service and no application in the attack object definition, the attack object binds to the service. Table 1 summarizes the behavior of application and service bindings with application identification.

    Table 1: Applications and Services with Application Identification

    Attack Object Fields

    Binding Behavior

    Application Identification

    :application (http)

    :service (smtp)

    • Binds to the application HTTP.

    • The service field is ignored.

    Enabled

    :service (http)

    Binds to the application HTTP.

    Enabled

    :service (tcp/80)

    Binds to TCP port 80.

    Disabled

    For example, in the following attack object definition, the attack object binds to the application HTTP, the application identification is enabled, and the service field SMTP is ignored.

  • If an attack object is based on service specific contexts (for example, http-url) and anomalies (for example, tftp_file_name_too_long), both application and service fields are ignored. Service contexts and anomalies imply application; thus when you specify these in the attack object, application identification is applied.

  • If you configure a specific application in a policy, you overwrite the application binding specified in an attack object. Table 2 summarizes the binding with the application configuration in the IDP policy.

    Table 2: Application Configuration in an IDP Policy

    Application Type in the Policy

    Binding Behavior

    Application Identification

    Default

    Binds to the application or service configured in the attack object definition.

    • Enabled for application-based attack objects

    • Disabled for service-based attack objects

    Specific application

    Binds to the application specified in the attack object definition.

    Disabled

    Any

    Binds to all applications.

    Disabled

  • If you specify an application in an IDP policy, the application type configured in the attack object definition and in the IDP policy must match. The policy rule cannot specify two different applications (one in the attack object and the other in the policy).

Note

Application cannot be any when attacks based on different applications are specified in IDP configuration and commit fails. Use default instead.

While configuring IDS rules for application the option any is deprecated.

But, when application is any and custom-attack groups are used in IDP configuration, commit goes through successfully. So, commit check does not detect such cases.

Understanding IDP Application Identification for Nested Applications

With the greater use of application protocol encapsulation, the need arises to support the identification of multiple different applications running on the same Layer 7 protocols. For example, applications such as Facebook and Yahoo Messenger can both run over HTTP, but there is a need to identify them as two different applications running on the same Layer 7 protocol. In order to do this, the current application identification layer is split into two layers: Layer 7 applications and Layer 7 protocols.

Included predefined application signatures have been created to detect the Layer 7 applications whereas the existing Layer 7 protocol signatures still function in the same manner. These predefined application signatures can be used in attack objects.

Example: Configuring IDP Policies for Application Identification

This example shows how to configure the IDP policies for application identification.

Requirements

Before you begin:

  • Configure network interfaces.

  • Download the application package.

Overview

In this example, you create an IDP policy ABC and define rule 123 in the IPS rulebase. You specify default as the application type in an IDP policy rule. If you specify an application instead of default the application identification feature will be disabled for this rule and IDP will match the traffic with the specified application type. The applications defined under application-identification cannot be referenced directly at this time.

Configuration

Step-by-Step Procedure

To configure IDP policies for application identification:

  1. Create an IDP policy.
  2. Specify the application type.
  3. Specify an action to take when the match condition is meet.
  4. If you are done configuring the device, commit the configuration.

Verification

To verify the configuration is working properly, enter the show security idp command.

Understanding Memory Limit Settings for IDP Application Identification

Although you cannot create application signatures with the IDP signature database, you can configure sensor settings to limit the number of sessions running application identification and also limit memory usage for application identification.

Memory limit for a session—You can configure the maximum amount of memory bytes that can be used to save packets for application identification for one TCP or UDP session. You can also configure a limit for global memory usage for application identification. Application identification is disabled for a session after the system reaches the specified memory limit for the session. However, IDP continues to match patterns. The matched application is saved to cache so that the next session can use it. This protects the system from attackers trying to bypass application identification by purposefully sending large client-to-server packets.

  • Number of sessions—You can configure the maximum number of sessions that can run application identification at the same time. Application identification is disabled after the system reaches the specified number of sessions. You limit the number of sessions so that you can prevent a denial-of-service (DOS) attack, which occurs when too many connection requests overwhelm and exhaust all the allocated resources on the system.

Table 3 provides the capacity of a central point (CP) session numbers for SRX3400, SRX3600, SRX5600, and SRX5800 devices.

Table 3: Maximum CP Session Numbers

SRX Series Devices

Maximum Sessions

Central Point (CP)

SRX3400

2.25 million

Combo-mode CP

SRX3600

2.25 million

Combo-mode CP

SRX5600

9 million

2.25 million

Full CP

Combo-mode CP

SRX5800

10 million

2.25 million

Full CP

Combo-mode CP

Example: Setting Memory Limits for IDP Application Identification Services

This example shows how to configure memory limits for IDP application identification services.

Requirements

Before you begin:

Overview

In this example, you configure 5000 memory bytes as the maximum amount of memory that can be used for saving packets for application identification for one TCP session.

Configuration

Step-by-Step Procedure

To configure memory and session limits for IDP application identification services:

  1. Specify the memory limits for application identification.
  2. If you are done configuring the device, commit the configuration.

Verification

To verify the configuration is working properly, enter the show security idp memory command.

Verifying IDP Counters for Application Identification Processes

Purpose

Verify the IDP counters for the application identification processes.

Action

From the CLI, enter the show security idp counters application-identification command.

Sample Output

user@host> show security idp counters application-identification

Meaning

The output shows a summary of the application identification counters. Verify the following information:

  • AI cache hits—Displays the number of hits on the application identification cache

  • AI cache misses—Displays the number of times the application matches but the application identification cache entry is not added.

  • AI matches—Displays the number of times the application matches, and an application identification cache entry is added.

  • AI no-matches—Displays the number of times when application does not match.

  • AI-enabled sessions—Displays the number of sessions on which application identification is enabled.

  • AI-disabled sessions—Displays the number of sessions on which application identification is disabled.

  • AI-disabled sessions due to cache hit—Displays the number of sessions on which application identification is disabled after a cache entry is matched. Application identification process is discontinued for this session.

  • AI-disabled sessions due to configuration—Displays the number of sessions on which application identification is disabled because of the sensor configuration.

  • AI-disabled sessions due to protocol remapping—Displays the number of sessions for which application identification is disabled because you have configured a specific service in the IDP policy rule definition.

  • AI-disabled sessions due to non-TCP/UDP flows—Displays the number of sessions for which application identification is disabled because the session is not a TCP or UDP session.

  • AI-disabled sessions due to no AI signatures—Displays the number of sessions for which application identification is disabled because no match is found on the application identification signatures.

  • AI-disabled due to session limit—Displays the number of sessions for which application identification is disabled because sessions have reached the maximum limit configured. Application identification is disabled for future sessions too.

  • AI-disabled due to session packet memory limit—Displays the sessions for which application identification is disabled because sessions have reached the maximum memory limit on TCP or UDP flows. Application identification is disabled for future sessions too.

  • AI-disabled due to global packet memory limit—Displays the sessions for which application identification is disabled because the maximum memory limit is reached. Application identification is disabled for future sessions too.