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 Firewalls, 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.

On all branch SRX Series Firewalls, 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.

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).

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.

This example shows how to configure the IDP policies for 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.

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

• Purpose
• Action
• Meaning