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

    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.

    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.

    The 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 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.

    On SRX 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.

    Modified: 2018-01-28