How to Configure New L7 DDoS Profiles

Description

Steps to create and configure a new L7 DDoS Profile.

• If you want to edit existing L7 DDoS Profiles --  see How to Edit / Manage L7 DDoS Profiles.
• If you already have L7 DDoS Profile created and need to add to proxy -- see Add L7 DDoS Profile to Proxy

 

Environment

• Silverline Portal
• L7 DDoS Profiles v3 (updated in Jan 2020)
• Proxy / Proxied customers

 

Procedure

1. Navigate to: Config > Proxy Configuration > L7 DDoS Profile Management

2. Click the blue Add button in the upper-right to add a new L7 DDoS Profile.

3. Under the General tab, choose a name for the new Layer 7 DDoS profile.

• Name used to identify L7 DDoS Profile (from a drop-down menu) later when adding to proxy.
• Best Practice: Choose a consistent naming convention to help stay organized as you create new profiles. 

 

4. Configure the following settings: Rate-based Anomaly, Stress-based Anomaly, and Bot defense. 

Note: What Mode is the Profile in? The Mode of the profile affects which options are available for Rate-based and Stress-based Anomalies. See the mode in the upper-right:   Mode Options: Transparent (Log Only) - traffic that violates thresholds is logged but still allowed to access application. Default mode for new L7 DDoS Profiles. Blocking - traffic that violates thresholds is logged and subject to mitigation actions.   How to switch Blocking Modes 1. Click the current mode name in the upper-right. 2. Select the desired mode. 3. The new mode appears in upper-right. Options will appear or disappear based on the newly-selected mode.   Advanced Settings In Blocking mode, enable more options with more control by selecting "View Advanced Settings."

 

5.  Save the new L7 DDoS Profile. Profile is now available to add to proxy.

6. Add L7 DDoS Profile to Proxy. See Add L7 DDoS Profile to Proxy for instructions.

 

Settings Details

Rate-based Anomaly

Description

• Configure thresholds for number of incoming HTTP(S) requests to determine if incoming traffic is coming from bot or legitimate client. Traffic over threshold is treated like a bot.
• Clients suspected as a bot have mitigation actions taken against them.
• Configure mitigation actions when profile is in Blocking mode. When profile is in Transparent mode, mitigation is only Real Browser Detection (because least intrusive to user).

 

Configuration

1. Select Rate-based Anomaly in left-hand menu.

• Defaults to ON. Left-hand menu is green when option is enabled.
• Switch blue toggle to OFF if want this option turned off.

 2. Set the TPS Thresholds under "Detection."

Sets a ceiling of the highest TPS (transactions per second) that the profile will tolerate before triggering mitigating actions.

Detection Levels

Thresholds can be set at the Site-wide, Source IP and/or the URL level. 

• Site-wide - Thresholds for the aggregated total of traffic hitting entire application.
  • If triggered, mitigation actions taken on all incoming traffic.
  • Please contact the SOC if you want to change these settings. 
• Source IP – Thresholds for traffic coming from a single IP address
  • If triggered, mitigation actions taken on all traffic from that IP address
  • Consult your server logs to determine what that rate might be for your specific site.
  • See The SOC needs to configure the TPS thresholds below
• URL – Thresholds for traffic coming to one of your URLs.
  • For URLs where you get consistently high traffic, so you can set a different threshold
  • Using your server logs, determine how often pages are served up on a per-URL level. Determine the peak rate for legitimate traffic and use this as a basis to mitigate when the traffic crosses what might be reasonably assumed to be an automated client.
  • See The SOC needs to configure the TPS thresholds below
    

     

Detection Thresholds

Mitigation actions occur when either of the following become true:

A. HTTP(S) requests per second (measured in TPS) reach or surpass the Absolute Threshold, the maximum allowed Transactions per Second (TPS).

B. HTTP(S) requests per second reach or surpass the minimum TPS Threshold ("after initially reaching: _____ TPS"), and the volume percentage increases by the Relative Threshold percentage.

 

Enable Heavy Url Protection (URL level only)

Heavy URLs: pages of your site that consume more server resources, usually because they perform intensive operations such as search.

Heavy URL Protection: If enabled, the Silverline system automatically detects which URLs are heavy and automatically sets a Heavy URL Latency Threshold for those pages.. When Rate-based or Stress-based thresholds are triggered, Silverline starts watching the Heavy URLs' latency. If the latency threshold is hit, mitigations are triggered on those URLs.

If you decide to use the basic (automatic) Heavy URL Protection, let it run for 1 week before enabling any Bot Defense techniques. This lets it gather enough data on your URLs.

Advanced: Heavy URL Latency Threshold

If in Blocking Mode and Advanced Settings, can configure Heavy URL latency Threshold (milliseconds.) Note this will overwrite the automatic Heavy URL Latency threshold above.

Above: This setting means any URL that takes more than 1 second (1000 milliseconds) to respond will be classified as "Heavy" and subject to mitigations.

 

Recommended: The SOC needs to configure the TPS thresholds. The SOC needs at least 7 to 14 days of data on proxy traffic to configure accurately. In order to build an accurate rate-based policy, you will need to be equipped with some baseline metrics of how your site performs (a) under normal operation and (b) at peak load.  The statistics you will need on a per-site level are: Base Threshold - Normal load for your site, in each Zone, in transactions per second (TPS).  These are HTTP or HTTPS connection attempts. Mitigation Threshold - The level at which it is reasonable to assume that the connection load in HTTP or HTTPS connection attempts is coming from nefarious sources, measured in transactions per second (TPS).  Silverline offers the ability to express this either in raw TPS numbers or as a percentage increase over normal load.  They can also be combined. We suggest tuning L7 DDos profiles during peak load (high traffic times), because we don’t want the profile to trigger during those times. A DDoS attack will be WAY bigger than even your highest peak times. How do I gather baseline metrics on my site? Baseline information can be gathered from the Web Traffic Statistics page in Portal.

 

3. Configure the Mitigating Actions under "Mitigation."

Mitigating actions are taken when the TPS reaches or surpasses the Thresholds configured in "Detection."

Mitigation Options by Mode

Options for Mitigating Actions depend on which Mode the profile is in and whether Advanced Settings are on (see Note: What Mode is the Profile in? above)

• Transparent (Log Only): Real Browser Detection only (because least intrusive to user).
  • Issues a JavaScript challenge to the browser
  • Note: In Transparent mode, browsers which fail to execute JavaScript are still allowed to access the website (until move into Blocking Mode).
• Blocking Mode: 3 configurable mitigations that occur in the following order:
  • Real Browser Detection,
  • CAPTCHA, and
  • Rate-Limiting
• Blocking Mode: Advanced Settings -- Enables additional control:
  
  • Can set different Mitigation options for Source IP and URL levels.
  • For Source IP > Rate Limiting: Additional option to block traffic from Source IP.
  • Heavy URL Protection (URL level only): Can configure Heavy URL latency Threshold (milliseconds.)

Mitigation Options in Blocking Mode
Option	Details
1. Real Browser Detection	Issues a JavaScript challenge to the browser. If it solves it, it's allowed to connect. This is the least intrusive for legitimate users. If the browser fails the challenge, it's blocked (or logged if in Transparent mode). If they attempt to access page again within the configured timeframe (i.e. 120 seconds in image above), they will receive the JS challenge again. If outside that timeframe, moves onto next mitigation (In this example, CAPTCHA).  Users with Javascript enabled typically sees a blank page for 1-2 seconds while the browser processes the JS challenge, then they are directed to the requested resource as normal. Note that this can interfere with non-browser clients
2. CAPTCHA	CAPTCHA presents a puzzle to the client. If they solve it, the client is permitted to connect. If the client fails the challenge, they are blocked (or logged if in Transparent mode). If they attempt to access page again within the configured timeframe (i.e. 120 seconds in image above), they will receive the Failure CAPTCHA challenge (see CAPTCHA Settings for details on Failure CAPTCHA). If outside that timeframe, moves onto next mitigation (In this example, rate-limiting.). Select "View CAPTCHA Settings" to configure CAPTCHA in pop-up. -- See L7 DDoS Profiles: CAPTCHA Settings for more details.
3. Rate-Limiting	If suspicious clients fail challenges, then they will be Rate-Limited. Seconds are the amount of time this mitigation is enacted. After time expires, if the attack is still ongoing, the initial mitigation is enacted. (In this example, Real Browser Detection). Recommendation: The default and recommended time is 2 hours, or 7200 seconds.

 

Stress-based Anomaly

Description

• Configure thresholds for back end server latency.  
• Silverline uses information gathered during the proxy deployment process to determine the expected latency between a request and your server response.
• Configure mitigation actions when profile is in Blocking mode. When profile is in Transparent mode, mitigation is only Real Browser Detection (because least intrusive to user). 

Configuration

1.  Select Stress-based Anomaly in left-hand menu.

• Defaults to ON. Left-hand menu is green when option is enabled.
• Switch blue toggle to OFF if want this option turned off.

 

Bot Defense

Bot Defense will be eventually retired. We recommend that you migrate to Silverline Shape Defense for bot protection.

Description

Bot defense allows the Silverline WAF to use behavioral analysis to automatically classify connections as being from a good (i.e. Google) or bad bot, in addition to the other defense mechanisms mentioned in this article.

 Bot Defense works by:

• Sending any new untrusted connection a JavaScript injection challenge.
• Waiting to see if the client responds correctly by responding to the challenge by sending back a reply with an embedded cookie.
• If successful, the connection is fingerprinted and marked as valid.

Configuration

This configuration page may be reached by selecting Bot Defense from the left hand menu and then switching the toggle to ON. 

Note: If Bot Defense is ON, the Javascript challenge will trigger even when the profile is in Transparent mode!

Note: The 'During Attack' mode of Bot Defense will be deprecated due to security concerns. We found customers impacted by several bots that stays below the 'Attack threshold' and continue to run malicious activities. Bot Defense has been defaulted to 'Always On' mode. 

Related Content

• What are Layer 7 DDoS Attacks and L7 DDoS Profiles?
• How to Edit / Manage L7 DDoS Profiles
• Add L7 DDoS Profile to Proxy
• L7 DDoS Profiles: CAPTCHA Settings
• Q&A: L7DDOS FAQ