Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    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.

      : (“http-test”
      	  :application (“http”)
      	  :service (“smtp”)
      	  :rectype (signature)
      	  :signature (
      		   :pattern (“.*TERM=xterm; export TERM=xterm; exec bash – i\x0a\x.*”)
      		   :type (stream)
      	  )
      	  :type (attack-ip)
      )
      
    • 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).

    Published: 2012-06-29