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 Update the IDP Signature Database Manually.

AppID is enabled by default only if the requesting service, like IDP, AppFW, AppTrack, or AppQoS, is set to invoke it. AppID does not trigger automatically if no policies or configurations exist. However, when you specify an application in the policy rule, IDP uses the specified application rather than the application identification result. For instructions on specifying applications in policy rules, see Example: Configuring IDP Applications and Services.

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 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 in active/active chassis clusters has a limitation. For time-binding scope source traffic, attacks from a source with multiple destinations might not be detected. Active sessions distributed across nodes cause this issue 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).

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.

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 AppID and also limit memory usage for AppID.

Memory limit for a session—You can configure the maximum amount of memory bytes that can be used to save packets for AppID for one TCP or UDP session. You can also configure a limit for global memory usage for application identification. AppID 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 AppID by purposefully sending large client-to-server packets.

• Number of sessions—You can configure the maximum number of sessions that can run AppID at the same time. AppID 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.

Use Feature Explorer to confirm platform and release support for specific features. Additional platforms may be supported.

See the Additional Platform Information section for more information about the capacity of central point (CP) session numbers.

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

• Purpose
• Action
• Meaning

Use Feature Explorer to confirm platform and release support for specific features. Additional platforms might be supported.

Use the following table to review additional platform information.

Use Feature Explorer to confirm platform and release support for specific features.

Use the following table to review platform-specific behaviors for your platform.