IDP Application-Level DDoS Protection Overview

Understanding the Application-Level DDoS Module

The application-level distributed denial-of-service (application-level DDoS) IDP module uses application-level metrics to differentiate between normal and malicious application requests. It then identifies the offending source addresses and can drop or deny these requests. Based on user-configured application thresholds, when the client application transactions exceed the defined thresholds, session and ip-actions are applied on traffic from the offending client address. This feature protects servers against DNS and HTTP application-level DDoS attacks.

To identify malicious bot clients, you create a policy with rulebase-ddos to monitor specific traffic and define application-level DDoS application metrics and thresholds to monitor that traffic. When the threshold are exceeded, your defined action is taken on the client to protect the application server.

IDP performs multistage analysis from connection monitoring, to protocol analysis, to bot client classification, and maintains the state for each protected server. You can configure connection-rate-threshold in the application-level DDoS application definition to monitor connection rate. When connection thresholds rate are exceeded, IDP transitions to protocol analysis for deep content inspection and maintains statistical data on application transactions. The application-level DDoS attacks can be classified into either heavy hitters or random hitters. Heavy hitters perform identical application transactions in a fast and repeated fashion, for example, querying a nonexisting domain name repeatedly. Random hitters perform random application transactions, for example, querying a random domain name, one per each request. You can configure context value-hit-rate-threshold to detect heavy hitters and context hit-rate-threshold to detect random hitters. If either of the context thresholds are exceeded, IDP transitions to the bot client classification stage, where it tracks the application transactions on a per-client basis based on user-configured time-binding thresholds. A benign client will not perform identical and repeated transactions, whereas malicious bot clients will. Once time-binding thresholds are exceeded, identified bot clients will be blocked with the configured ip-action and session actions.

You can also configure a list of regular expressions under exclude-context-values to exempt certain context values from being considered for application-level DDoS processing. This is helpful for requests for well-known resources that can often hit context thresholds, for example, a DNS query for domain name google.com.

Protocol analysis stage uses a default interval of 60 seconds for context hit-rate-threshold and value-hit-rate-threshold. For example, if you configure 10,000 as the value-hit-rate threshold, the context value would be monitored against a 10,000 hits limit in a 60–scond interval.

IDP also uses hysteresis for state transitions to avoid thrashing between the states. A default of 20 percent lower limit will be used from the configured connection and context thresholds for falling behind in state. For example. if you configure a context value-hit-rate-threshold of 10,000, IDP transitions from protocol analysis to bot client classification after 10,000 hits in 60 seconds for identical context values, and falls behind in state only when such hits are smaller than 8000 in 60 seconds.

We recommend configuring time-binding thresholds in the application-ddos definition, because it is critical to differentiate between benign clients and malicious bot clients. However, if you choose not to define time-binding thresholds, IDP will not do bot client classification. In this case, if application transactions exceed context thresholds, the configured ip-action and session actions will be performed. Note that without bot client classification, benign clients might get denied when making a request to the protected server.

IDP maintains application-level DDoS state for the current policy only. For more information, see the policy aging reference in Understanding Multiple IDP Detector Support. Traffic from sessions using older policy will not be inspected for application-level DDoS. If a new policy is loaded, application-level DDoS state for each protected server will be relearned.

Understanding the Application-Level DDoS Definition

You can only configure one application-ddos definition for each protected server. However, you can use the same application-ddos definition in two or more rules with specific destination-address, to-zone, or both to protect two or more servers with the same desired application-ddos thresholds.

Table 53 shows the parameters that can be set for application-ddos. For more details, see the JUNOS Software CLI Reference guide.

Note: Application-level denial-of-service (application-level DDoS) detection will not work if two rules with different application-level DDoS applications process traffic going to a single destination application server. When setting up application-level DDoS rules, make sure you do not configure rulebase-ddos rules that have two different application-ddos objects while the traffic destined to one application server can process more than one rule. Essentially, for each protected application server, you have to configure application-level DDoS rules so traffic destined for one protected server only hits one application-level DDoS rule.

application-level DDoS rules are terminal, which means that once traffic is processed by one rule, it will not be processed by other rules.

Table 53: Application DDoS Parameters

Parameter	Description
service service-name	The Application Layer service to be monitored, such as DNS or HTTP.
exclude-context-value	Configure a list of common context value patterns that should be excluded from application-level DDoS detection. For example, if you have a webserver that receives a high number of HTTP requests on the home/landing page, you can exclude it from application-level DDoS detection.
connection-rate threshold	The connections-per-second threshold at which to start monitoring the application context values.
context context-name	Name of the application context that the IDP protocol decoder generates while parsing the application protocol from traffic data.
hit-rate-threshold	Number of context hits in tick interval (60 seconds by default) to start bot client classification, if timebinding parameters are configured. If timebinding parameters are not configured, the configured policy actions are taken.
value-hit-rate-threshold	Number of context value hits in tick interval to start bot client classification, if timebinding parameters are configured. If time binding parameters are not configured, the configured policy actions are taken.
max-context-values	The top n context values that should be monitored, reported, or both.
time-binding-period	The time-binding period to determine if a client should be classified as a malicious bot client or not. This setting is used in conjunction with time-binding count to detect an attack if a client request for the same context value exceeds time-binding-count times in time-binding-period seconds.
time-binding-count	The number of context or context value hits from each client over the time binding period to determine if it should be considered a malicious bot client.

Understanding the Application-Level DDoS Rule

You configure one or more application-Level DDoS rules to define the traffic that should be monitored to protect your servers.

Table 54 shows the parameters that can be set for application-ddos.

Table 54: application-level DDoS Rule Parameters

Parameter	Description
from-zone	Match source zone.
source-address	Match source address.
to-zone	Match destination zone.
destination-address	Match destination address.
application	Choose default to select the application service from the application-ddos definition.
application-ddos	Specify the DDoS application.

Understanding Application-Level DDoS IP-Action

You configure ip-action to drop future sessions from identified bot client addresses for a specified time, or rate limit future connections.

Table 55 shows the parameters that can be set for ip-action.

Table 55: application-level DDoS IP-action Parameters

Parameter	Description
ip-block	Block-future connections of any session that matches the IP action.
ip-close	Closes future connections of any client address that matches ip-action by sending an RST packet to the client.
ip-connection-rate-limit	Rate limit future connections based on a connections per second limit that you set. This can be used to reduce the number of attacks from a client.
ip-notify	Does not take any action against matching future connections, but does log the event.

Understanding Application-Level DDoS Session Action

Session action determines what action should be performed on the identified bot client.

Table 56 shows the parameters that can be set for action.

Table 56: application-level DDoS Action Parameters