- Frequently Asked Questions about L7 DDOS profiles
- Silverline WAF
- Silverline DDoS
- L7 DDOS profile(s)
- TPS-based protection
- Latency-based protection
- Heavy URLs
- Proactive Bot Defense
- CAPTCHA Response Settings
You can see it by inspecting the HTTP response when the thresholds are reached - though you might not see it in every response.
|Q. What do each option in the TPS Anomalies mean?|
A: TPS (Transactions per second) actually means HTTP request per second (req/s for short).
- The 'Minimum TPS threshold for Detection' is the value at which the system will start tracking the request rate.
- Then a threshold for starting to inject the challenge is reached by an absolute TPS value or a percentage increase.
- The checkboxes are the mitigation technique that would be used.
|Q. Is it possible for the TPS-based protection to trigger cause false-positives?|
A: Yes, this is a risk. The feature is designed to mitigate/rate-limit the number of requests when the profile detects the application is under a DDoS attack.
Q. Site-wide protection, what are the downsides?
It is not tied to a URL, so if a DDoS attack targets a particular URL and exceeds thresholds, all requests on the entire site will be challenged/rate limited.
|Q. For Latency-based protection, does the Silverline platform monitors the latency between our backend servers and the Silverline Platform. Currently, it's Off by default. Why?|
A: Yes, with latency-based protection, even with the threshold left as default, the system/L7 DDoS profile takes an average for the amount/length of time for the backend application to respond to a request over the last minute.
- The average is calculated/updated every second per L7 DDoS profile
The reason, it is off, because it is the default configuration of L7DDoS profiles. We can switch it on if required.
|Q. What each option in the Latency Anomalies means?|
A: There is a base level for detection, and then an absolute and percentage-based threshold for detected latency to the backend.
The setting will challenge IPs/URLs that are sending requests to the site while the thresholds are exceeded.
Essentially, the behavior toward the client is the same, but the detection method is different.
|Q. Site-wide protection, what are the downsides?|
A: It is not tied to a URL, so if a DDoS attack targets a particular URL and exceeds thresholds, all requests on the entire site will be challenged/rate limited.
|Q. How are heavy URLs configured? How can I add/remove a URL in the L7 DDoS profile(s)?|
A: You can configure Heavy URLs by using the Add button under 'Heavy URLs' on that tab.
|Q. How are heavy URLs "Automatic Detection" work, how the detection is determined?|
A: They are determined by those URLs incurring a backend latency exceeding the value stated in the 'Heavy URL Latency in Sec' box.
|Q. Heavy URL Latency in Sec - The default value is 1000. Does this mean 16.67 minutes ? Or is it actually milliseconds (1 second)|
A: It's actually milliseconds or 1 second
|Q. Is this just straight-forward IP2location based?|
A: The geolocation feature uses Silverline's internal DB (*not* whois). However, the geolocation feature on the L7 DDoS profile is only enabled when the profile detects an attack is occurring.
We recommend either using the WAF policy (if subscribed to WAF service) or an iRule to assist with enforcing geolocation blocking
Proactive Bot Defense
|Q. What does "During Attacks" mean? How is an "Attack" determined?|
A: An 'Attack' is determined when the configured "minimum threshold and increase by" or the "maximum thresholds" on the L7 DDoS profile has been reached.
Q. Does Proactive Bot Defense use also Heavy URLs or Latency-based protection?
A: Proactive Bot Defense can be used for Latency-based or Rate-based protections.
A: There is no feature specifically on the L7 DDoS that has the capabilities to allowlist per URLs, but as an alternative, we could leverage the proxy configuration settings to configure URLs where you want the L7 DDoS to be enabled or disabled.
If more advanced URL matching is required, an iRule may be used to assist with the deployment.
|Q. If the challenge succeeds, how to subsequent requests from the same client are considered legitimate? Is there a cookie we need to pass? Is it the TS cookie?|
|Q. Where do we configure Cross-Domain requests in order to allow these, do we need to configure them in all profiles of the participating proxies as they are separated. For example: Our web-application [app.google.com] uses [trade.google.com] and [instrumentsfe.google.com] in order to function. Do we need to configure all of these in all profiles since we have a profile per proxy as the use-cases, rates, URL, etc, are different.|
A: This would need to be configured in all L7DDoS profiles for which it is required, yes. However, "Allow all requests" is the default setting so may not be required.
CAPTCHA Response Settings
For full details, see L7 DDoS Profiles: CAPTCHA Settings
Q. I assume it's possible to customize the message with our own HTML. Where should assets come from (icons, images, css, etc)?
A: They would need to be externally hosted or base64-encoded and then used in the HTML so that the user can reference those resources - files cannot be stored on the Silverline systems.
Default CAPTCHA first response message
This question is for testing whether you are a human visitor and to prevent automated spam submission.
<b>What code is in the image?</b>
|Q. If multiple failures happen, is there a block or simply an "endless loop" of retries? Custom CAPTCHA challenges are supported only in a best-effort capacity. If errors are determined it will be required to revert to the default CAPTCHA challenge.|
A: It will present the CAPTCHA repeatedly to clients failing to solve it. There is no WAF-style blocking.
|Q. Can we allowlist specific URLs that won't trigger CAPTCHA?|
A: The Host/URI setting within each Proxy's configuration page can be leveraged to enable/disable an L7 DDoS profile. If you don't want URL to be challenged, then don't enable the L7 DDoS profile for that URI.
It may be possible for an iRule to disable/allowlist this behavior as well.
For more information on the L7 DDoS profile please review the following links below: