Frequently Asked Questions

Distributed Denial of Service (DDoS) attacks aim to disrupt the normal functioning of a website by overwhelming it with a flood of internet traffic. These attacks target various critical levels of a website’s infrastructure, exploiting vulnerabilities in different components to render the website inaccessible to legitimate users. Here’s how DDoS attacks target these critical levels: 

• Network Layer (Layer 3) – At the network layer, DDoS attacks, such as IP/ICMP floods, aim to consume the bandwidth available to the target network. By sending massive amounts of data packets to the network, attackers can saturate the bandwidth, causing legitimate requests to be dropped or significantly delayed. This level of attack can prevent access to websites hosted within the network. 

• Transport Layer (Layer 4) – DDoS attacks at the transport layer, such as SYN floods, exploit the TCP handshake process. Attackers send a flood of TCP/SYN requests with spoofed IP addresses to the server, which then allocates resources and waits for the acknowledgment that never comes. This can exhaust the server’s resources, making it unable to process legitimate requests. 

• Application Layer (Layer 7) – Application layer attacks, such as HTTP floods, directly target the web application itself. These attacks mimic legitimate requests but are sent in such high volumes that the web servers or application resources (such as CPU and memory) become overwhelmed. Since these attacks mimic normal traffic, they can be harder to detect and mitigate. They can target specific website features, such as search functions or login pages, to consume more server resources. 

• Infrastructure Components – DDoS attacks can also target specific infrastructure components critical to the website’s operation, including: 

Yes. RADAR testing checks production environments automatically against over 140 types of DDoS attack vectors, from layers 3 (network), 4 (transport), and 7 (Application) attacks. 

RADAR testing assists organizations in identifying and continually eliminating their DDoS vulnerability gap – bringing it down to as little as 2%. 

MazeBolt’s professional services include some of the top DDoS experts worldwide. Many of them joined MazeBolt with backgrounds working for other leading DDoS mitigation companies. MazeBolt’s professional services include – 

• High-touch customer support – MazeBolt’s professional services allow our customers to focus on their business, using our experience in DDoS mitigation to assist in liaising with DDoS mitigation vendors. We make closing vulnerabilities a painless process and are with you every step of the way. 

• Deep domain experience – Our DDoS experts come from leading DDoS mitigation companies and have worked with over 100 enterprise organizations consulting on vendor remediation, real-time attack analysis, and deep DDoS architecture planning and implementation. 

• The liaison with your DDoS mitigation company – Our team will guide your remediation efforts with your DDoS mitigation vendors. If required, our professional services can also help plan new architectural changes. 

• Customized attack simulation vectors – If your organization requires specific attack vectors for proprietary reasons, MazeBolt can design and implement your required attack vectors and add it to your RADAR™️ testing platform. 

MazeBolt RADAR testing can run from 50,000 to hundreds of thousands of DDoS attack simulations a year. It can do this comfortably because it is a patented technology that is non-disruptive to IT operations. Business continuity is maintained during RADAR’s DDoS attack simulations. 

MazeBolt provides remediation guidance & planning. Every DDoS vulnerability discovered by RADAR has all the data required to close the gap by fine-tuning relevant DDoS mitigation policies. For example, RADAR logs the volume of attack simulations sent and attack traffic received, together with other important reporting parameters. This information allows the DDoS mitigation vendor to implement an optimized policy change for each vulnerability discovered.  

RADAR outlines the steps of DDoS mitigation, including identification, response, and routing, to differentiate between legitimate high-volume traffic and attacks.  

Despite the deployment of sophisticated mitigation solutions, companies typically face a 48% DDoS vulnerability level. This is primarily because these solutions are reactive rather than proactive. RADAR provides continuous, non-disruptive testing across all OSI layers to identify and help remediate DDoS vulnerabilities before an attack occurs. RADAR simulation reports are used by security teams and mitigation partners to remediate DDoS vulnerabilities.  

Two types of reporting are available: continuous and on-demand. A DDoS Vulnerabilities (or DDoS Mitigation Gaps) report can be generated at any time. MazeBolt refers to this as a Vendor Report. Additionally, MazeBolt’s customers receive a quarterly, executive report with high-level risk quantification and reduction recommendations. 

RADAR Vendor Reports include a comprehensive picture of what took place during a particular DDoS attack simulation. For example, on a per attack simulation basis, the vendor can see: 

• Duration of DDoS attack simulation 

• Rate of DDoS attack simulation 

• Cumulative attack simulation traffic sent 

• Cumulative attack simulation traffic received 

• Target response monitoring during DDoS attack simulation 

• Graphical illustrations of charting during attack simulation 

• Knowledge base article on attack simulation with a Packet Capture (PCAP) example of an attack 

Yes. The RADAR testing platform user interface has a wealth of information on all DDoS attack simulations, for example: 

• Where there are 200,000 illegal packets of an IKE Phase 1 flood: 78% of the traffic that is sent, penetrates the Scrubbing Center 

• Where there are 5,673,562 kilobits of an URG-ACK-SYN flood: 83% of the traffic that is sent, penetrates the on-prem. DDoS mitigation devices 

• During a GoldenEye HTTPS attack: 24,000 connections are successfully created that penetrate the CDN 

• The RADAR testing cycles (for each IP address or FQDN) normally run between 4 and 8 hours daily. 

• RADAR testing automatically moves on to the next IP or FQDN address until a company’s entire DDoS attack surface has been tested against all currently known DDoS attack vectors. 

Generally speaking, DDoS attacks start at a default of 25 Mbps (for Layers 3 & 4) and work their way up to a maximal bandwidth of 500 Mbps. This may vary depending on the DDoS mitigation vendor SLA. 

RADAR testing reads the metadata generated from RADAR testing nodes. All other traffic is ignored. Customers receive a full security spec of metadata collection and other security standards in effect. 

No. RADAR testing does not read PII. 

This depends on the DDoS protections deployed: 

• If RADAR testing is validating CDN-based protections, yes, the RADAR detector will require the ability to read the X-Forward-for header (or similar). 

• For DDoS protections which do not traverse a CDN, no. For example, for the scrubbing center, ISP protections, and CPE, decryption is not required. 

MazeBolt identifies simulated attack traffic by looking for and filtering the traffic’s source IPs. In a default configuration, we only capture traffic originating from MazeBolt source IPs.  

For CDN-based traffic, this will turn the RADAR detector into a mode whereby we begin capturing all traffic, identifying the true source IP in the X-Forward-For header, and then using those statistics to send out. It is important to note that we only send out traffic statistics, and NO PII information or any other data other than TCP-related data, which is sent out via our secure API (which uses 2-factor authentication and only communicates with our data center). 

RADAR can test hybrid DDoS mitigation deployments simultaneously. 

• System users add the network to be validated by RADAR testing. These network IPs are then automatically and continuously verified for DDoS mitigation gaps. 

• FQDN names or specific IPs can also be added manually to the system. 

RADAR testing requires a TAP (Mirror) Port immediately downstream from each DDoS mitigation solution. 

• The ongoing concurrent traffic rate 

• Visibility of all traffic – toward the targets that are going to be tested

• AI is already used in attack crafting, such as evading detection systems.
• Attack patterns now adapt rapidly, behavior linked to automated, AI-based systems.
• Advanced botnet management tools with AI-like decision-making are emerging.
• AI is also used to probe DDoS defenses, identify misconfigurations, and suggest optimal vectors.
• One known project focuses on polymorphic DDoS traffic using AI.
• While some uses are speculative, AI’s role is increasingly evident.

You’re right – techniques like volumetric and application-layer attacks exist without AI.
What’s new is how AI enhances them:

• Automating discovery of vulnerable endpoints
• Real-time traffic analysis to adapt and evade
• Generating polymorphic attack payloads
  AI simulates network dynamics to find weaknesses. While widespread operational use is still emerging, signs point to growing adoption.

Yes – mostly in early-stage or experimental form:

• Reinforcement learning for adaptive attacks
• Generative adversarial networks (GANs) to simulate real user traffic
• AI-based probing and reconnaissance to identify entry points
  Many techniques are progressing toward active use.

Many organizations focus narrowly on specific DDoS layers or tools, not a unified architecture.
Example: A 4-layer defense (CDN, Scrubbing, On-prem, WAF) is vulnerable if one layer lacks proper L7 coverage.
Attackers can bypass the CDN and flood the WAF directly, overloading stateful components.
This highlights a key flaw: defense layers must be coordinated, or gaps will be exploited.

Very – these attacks are subtle, distributed, and diverse.

• They hit multiple services simultaneously
• Use varying attack types, often at low volumes
• Mimic normal user behavior to avoid detection
  MazeBolt RADAR simulates this by testing protection layers with stealthy, low-volume attack variants to validate resilience.

Yes – thanks to DDoS-for-hire services, attackers now target:

• SMBs
• Critical infrastructure
• Well-known brands
  The bar for launching effective attacks has dropped dramatically, leading to a broader range of affected entities

CDNs leverage the DNS protocol to direct traffic through the provider’s system. They are primarily used to enhance customer access to website content by caching certain and delivering content as close to the requesting user as possible.

CDNs specifically handle Layer 7 traffic while refraining from forwarding traffic at Layers 3 and 4 to the organization’s IT infrastructure. This approach shields the organization against volumetric attacks by design.

CDNs are designed to manage significant traffic surges, which can be expected during legitimate high-traffic events. However, attackers understand how to ensure their malicious requests go through the CDN servers and to the originating “origin” server responsible for providing the CDN its content. This then makes the server the CDN relies upon (the “origin”) server unavailable.

To prevent this, CDN DDoS protection policies need to be in place and configured correctly.

CPE appliances encompass a range of technologies designed to identify and block DDoS attacks. Positioned at the outer edge of an organization’s network infrastructure, the CPE resides after (downstream) the router but before (upstream) accessing the internal network infrastructure, including firewalls and load balancers.

These CPE devices offer in-depth traffic analysis, bandwidth monitoring, and performance reporting capabilities with secure SSL visibility (since the appliance is hosted by the organization itself). They facilitate better network traffic management and enable detailed analysis of DDoS attacks. Post- attack reports provide crucial insights and action items, aiding in refining systems for future attacks.

Intrusion Prevention Systems (IPSs) serve the critical role of monitoring suspicious activities within a network. These systems may function as part of firewalls or alone. An IPS meticulously inspects and scans packets, relying on pre-existing settings, signatures, protocol status, or anomaly detection to generate alerts and potentially block potential cyberattacks.

However, an IPS is primarily designed to block malware, web attacks, or other known exploitation attempts and is not designed to stop DDoS attacks. While they possess some capabilities across layers 3, 4, and 7, DDoS attacks often surpass the mitigation capacity of IPS systems. Resorting to an IPS to counter a DDoS attack typically suggests that the targeted organization is experiencing an exceptionally advanced DDoS attack campaign. This situation arises when CPEs and/or Scrubbing and/or CDN services fail to mitigate attacks effectively.

Web application firewalls (WAFs) are specialized firewalls that primarily inspect web-based traffic.

WAFs excel at analyzing application traffic, distinguishing between potential risks and legitimate usage, and controlling access to applications and services by applying rules to incoming HTTP traffic. Employing deep-packet inspection, they identify, categorize, reroute, or block packets containing specific data or code payloads; Legitimate user traffic is permitted, while suspicious traffic is either redirected for further scrutiny or blocked outright.

WAFs are effective against layer 7 attacks that directly impact applications. However, the inspection process can introduce latency and impact user experience, emphasizing the importance of efficiency.

WAFs can be implemented as cloud-based services offered by service providers. While firewalls can mitigate certain DDoS attacks, they are vulnerable targets that, when overwhelmed, can contribute to the disruption of online services. WAFs, due to their bot detection and DPI (deep packet inspection) capabilities, are integrated into the DDoS protection layers of many organizations for Layer 7, assuming volumetric attacks are taken care of upstream.

Load balancers serve as intermediaries, receiving traffic from multiple clients and evenly distributing it across various similar application servers. Clients connect to the load balancer, which then establishes a connection to an application server on the client’s behalf. Given their stateful nature, load balancers must monitor and manage the state of each connection, making them susceptible to saturation DDoS attacks like HTTP and SYN floods.

Stateful devices, including load balancers, often fall first during a DDoS attack. Stateful devices require high amounts of processing power and memory to function, which is not good in a DDoS scenario.

Load balancers play a role in mitigating DDoS attacks by dispersing malicious traffic among different application servers. However, in the absence of a suitable upstream DDoS mitigation component designed to filter out the majority of the attack traffic, will likely have no effect, relying solely on load balancers will not suffice to prevent service disruption under attack, in fact the load balancer itself has a high chance of failure.

Firewalls act as the gatekeepers of your internal network, controlling and filtering incoming packets or requests based on predefined rules. Configured with specific rulesets, the firewall scrutinizes and manages traffic based on allowed packet types and connection states. A firewall keeps a record of every connection opened between external clients and the internal servers and uses those records to filter out any out-of-state packets.

This qualifies the firewall as a stateful device, and like many other stateful devices, the firewall is vulnerable to saturation DDoS attacks such as HTTP attacks and SYN floods. While the firewall can sift through packets related to a DDoS attack, it’s generally not optimized to handle the sheer volume of incoming packets that accompany such attacks. This results in the firewall quickly becoming overwhelmed, leading it to “fail closed” state, which leads to downtime.