• Frequently Asked Questions about L7 DDOS profiles


  • Silverline WAF
  • Silverline DDoS
    • Proxy
  • Proxy/Proxies
  • L7 DDOS profile(s)




TPS-based protection

Q. I understand that TPS-based protection is client-side using Javascript. Does this mean that when in Transparent mode we are injecting Javascript? If we are injecting Javascript, how can I see what's injected?

A: Javascript can be injected while the L7 DDoS profile is in transparent mode, but the failure of the client to return the challenge-response will not cause that client to be denied access to the site.

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. 

Or, if bot defense is set to "always" the feature will attempt to determine is a bot or not by sending a Javascript/redirect challenge; more explanation for this feature is provided/answered below.


Q. Will we be able to use L7 DDoS profile on our native applications is Javascript injected?

A: If your native apps is unable to support Javascript, the 'Client-Side Integrity Defence' option should be avoided, but CAPTCHA challenge or Source Limiting feature can still be utilized. 


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.


Latency-based protection

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.


Q. Is latency-based protection less prone to false-positives and can it also involve javascript injection? How would the profile know which IP to block?

A: Javascript is still injected if the 'Client-Side Integrity Defence' mitigation option is selected.

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.


Heavy URLs

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.

See How to Configure New L7 DDoS Profiles


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

Q&A: How can I block traffic from country / countries for a specific proxy?


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. What does "Always" mean? Does this mean it always inject Javascript? 

A: Yes, the "always" setting will instruct the L7 DDoS profile to inject Javascript without looking at any of the other thresholds (from either Rate-based or Latency-Based protections)


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. 


Q. Where can we configure allowlisting of URL's that won't need Bot Defense, for example we have a URL that responds with a value that tells the application to open a WebView for login page instead of the native login page. This URL will be accessed by the native application hence there is no Javascript processing. After that request is made and it is instructed to open a Webview, then Javascript will be processed.

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?

A: After a successful response to a L7 DDoS challenge, such as a redirection challenge, Javascript challenge, or a captcha challenge, the L7 DDoS profile will assign a "TSPD_101*" cookie. This cookie signifies that the client was able to resolve the L7 DDoS challenge. 


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 [] uses [] and [] 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.
%DOSL7.captcha.image% %DOSL7.captcha.change%
<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. 


Related Content

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request