The AppDDoS IDP module uses application-level metrics to differentiate between normal and malicious application requests. It will then identify the offending source addresses and can drop or deny these requests. Based on user configured application thresholds, when the client application transactions exceeds the defined thresholds, session and ip-actions will be applied on traffic from the offending client address. This feature will protect servers against DNS and HTTP application DDoS attacks.
In order to identify malicious bot clients, you create a policy with rulebase-ddos to monitor specific traffic, define AppDDoS 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 multi-stage analysis from connection monitoring, protocol analysis, to bot client classification, and maintains the state for each protected server. You can configure connection-rate-threshold in the AppDDoS application definition to monitor connection rate. When connection rate are exceeded, IDP transitions to protocol analysis for deep content inspection and maintains statistical data on application transactions. The AppDDoS 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 non-existing 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 above 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 a 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 AppDDoS processing. This is helpful for requests for well known resources that may 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 10,000 hits limit in a 60 seconds interval.
IDP also uses hysteresis for state transitions to avoid thrashing between the states. A default of 20% 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 10000 hits in 60 seconds for identical context values, and falls behind in state only when such hits are smaller than 8000 in 60 seconds.
It is recommended to configure time-binding thresholds in the application-ddos definition, since it is critical to enumerate benign client versus a malicious bot client. However, if you chose to not define time-binding thresholds, IDP does 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 AppDDoS state for the current policy only. For more information, see the policy aging reference in Multiple IDP Detector Support. Traffic from sessions using older policy will not be inspected for AppDDoS. If a new policy is loaded, AppDDoS state for each protected server will be relearned.
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 and/or to-zone to protect two or more servers with same desired applicaiton-ddos thresholds. Table Table 101 shows the parameters that can be set for application-ddos.
![]() |
Note: Application-level denial-of-service (AppDDoS) detection will not work if two rules with different AppDDoS applications hit traffic going to a single destination application server. When setting up AppDDoS 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 hit more than one rule. Essentially, for each protected application server, you have to configure AppDDoS rules so traffic destined for one protected server only hits one AppDDoS rule. AppDDoS rules are terminal, which means that once traffic is processed by one rule, it will not be processed by other rules. |
For more details on the following commands, see the JUNOS Software CLI Reference guide.
Table 101: Application DDoS Parameters
You configure one or more AppDDoS rules to define the traffic that should be monitored in order to protect your servers. Table Table 102 shows the parameters that can be set for application-ddos.
Table 102: AppDDoS Rule Parameters
You configure ip-action to drop future sessions from identified bot client addresses for a specified time. Table Table 103 shows the parameters that can be set for ip-action.
Table 103: AppDDoS IP-action Parameters
Configure the action to perform on the identified bot client.
Table Table 104 shows the parameters that can be set for action.
Table 104: AppDDoS Action Parameters