TechLibrary

Table of Contents

Guide That Contains This Content

[+] Expand All

[-] Collapse All

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 1 shows the parameters that can be set for application-ddos. See Junos OS CLI Reference .

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 1: 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. On SRX Series and J Series devices, for brute force and time-binding-related attacks, the logging is to be done only when the match count is equal to the threshold. That is, only one log is generated within the 60-second period in which the threshold is measured. This process prevents repetitive logs from being generated and ensures consistency with other IDP platforms, such as IDP-standalone. When no attack is seen within the 60-second period and the BFQ entry is flushed out, the match count starts over the new attack match shows up in the attack table, and the log is generated.

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 2 shows the parameters that can be set for application-ddos.

Table 2: 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 either to drop future sessions from identified bot client addresses for a specified time or to rate-limit future connections.

Table 3 shows the available parameters for configuring an application-level DDoS IP action.

Table 3: Application-Level DDoS IP-Action Parameters

Parameter	Description
ip-block	Blocks future connections of any session that matches the IP action.
ip-close	Closes future connections of any client address that matches the IP action by sending an RST packet to the client. If TCP is not used, the connection is dropped silently.
ip-connection-rate-limit	Rate-limits future connections based on a connections per second limit that you set. This parameter can be used to reduce the number of attacks from a client.
ip-notify	Takes no action against matching future connections, but logs the event.
log	Logs the information about the IP action against the traffic that matches a rule.
timeout	Specifies the number of seconds that you want the IP action to remain in effect after a traffic match.
log-create	Generates a log event on installing the ip-action filter.
refresh-timeout	Refreshes the timeout so that the ip-action filter does not expire if future traffic matches that ip-action entry, and when a timeout is configured with ip-action.

Understanding Application-Level DDoS Session Action

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

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

Table 4: application-level DDoS 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 generate logs for only some traffic.