[ Contents] [ Prev] [ Next] [ Index] [ Report an Error]

Application-level Distributed Denial-of-Service (AppDDoS) Protection Overview

Understanding Application-level DDoS Module

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.

Understanding Application-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 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

Parameter	Description
service service-name	The application layer service to be monitored, such as DNS or HTTP.
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 time binding parameters are configured. If time binding 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 time binding 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 AppDDoS Rule

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

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 AppDDoS IP-action

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

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-notify	Does not take any action against matching future connections, but do log the event.

Understanding Session Action

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

Parameter	Description
close-server	Closes the connection and sends an RST packet to the server but not to the client.
drop-connection	Drops all packets associated with the connection, preventing traffic for the connection from reaching its destination. Use this action to drop connections for traffic that is not prone to spoofing.
drop-packet	Drops a matching packet before it can reach its destination but does not close the connection. Use this action to drop packets for attacks in traffic that is prone to spoofing, such as UDP traffic. Dropping a connection for such traffic could result in a denial of service that prevents you from receiving traffic from a legitimate source-IP address.
no-action	No action is taken. Use this action when you want to only generate logs for some traffic.