CDN Debug Information, or in short “Debug Info” is a technique used and supported by CDNs in order to debug the CDN behavior.
The debug info allows a client to gain information from the CDN such as:
| Debug Type | Debug Info |
|---|---|
| Caching | Information about the caching status of the resource: was the resource received from the cache or form origin, caching status, and caching reason. |
| Origin Server | Details about the origin server such as IP or domain. |
| POP Details | The CDN server known as POP (Point-of-Presence) details such as IP, country, and location. |
Each vendor implements the debug info differently, but typically debug info is enabled by adding special HTTP headers to the request, and receiving the info in special HTTP headers in the response.
What is used for?
Like any other system you may have, it is important to have tools to debug and understand what the CDN is doing with the traffic. Organizations strive to accelerate traffic as much as possible, and therefore to cache as much as possible content. Therefore using the caching info they can see the caching status and take action to improve it.
The next section will describe two DDoS concerns when using CDN and how the debug info can be used to reduce those concerns.
DDoS-related concerns with debug info
Caching for the purpose of security and DDoS mitigation
In the previous section, it was mentioned that organization use caching in order to accelerate their website, however, caching is not only used for acceleration but also for security. Caching is a type of “reducing the attack surface”. Take an example of an attacker sending an SQLInjection. If the injection hits the CDN which returns the response from its cache then nothing bad can happen.
Caching is also important for DDoS since under a DDoS attack if all or most of the attacking requests hits the CDN and are served from the cache then the server can remain safe, while the CDN itself typically has no issues responding to all the attacking requests.
It is important to know that sophisticated attackers have techniques to bypass the CDN by requesting only dynamic data so that they know it will not be cached. Nevertheless, the bottom line, is that proper caching is a very important DDoS mitigation line of defense. Caching itself will block any type of application attack, and even if the attacker will find a method to bypass the cache using a dynamic request, proper caching will ensure that the non-cached attack is confined to something that can address by other lines of defense.
In order to improve caching, the debug info is used in the following method:
- Validating which pages are cached and which are not and then attempting to cache more pages.
- Examine ways to bypass the cache, for example, by adding random parameters to the URL and inspecting if they cause a cache miss. If so, in some cases you can make ensure that this will not happen.
Removing or hiding debug info
The debug info that CDN vendors provide can be a security issue by itself. In some CDNs, the debug info is enabled by default allowing not only you but also the attacker, to use it. An attacker can use this to learn critical information that you definitely want to prevent from disclosing. This information can be used by the attacker not only for DDoS but for many other types of attacks.
Specifically for DDoS, we need to disable the debug info to make sure the attacker does not get:
- Origin server info
If the attacker finds it he can launch DDoS attacks directly and bypass the CDN entirely. - Pages that are not cached
When the attacker identifies pages that are not cached he will choose to attack them in order to ensure that each DDoS request he sends goes to the origin server, and is not stopped by the CDN.
Recommendations
- Improve caching
Understand how to use the debug info in order to debug your caching and then use it to increase your caching. - Restrict debug info
Validate that only you can use the debug info. Work with your CDN provider in order to ensure that.