Frequently Asked Questions
MazeBolt RADAR™ Testing
No. RADAR™ testing is based on a revolutionary patented non-disruptive DDoS testing technology that has ZERO impact on ongoing operations. It is an automated solution that runs on live production environments at pre-scheduled time periods.
Yes. RADAR testing checks production environments
automatically against over 140 different types of DDoS attack vectors, from
layers 3 (network), 4 (transport) & 7 (Application) attacks.
RADAR testing assists organizations in identifying, and continually eliminating their DDoS vulnerability gap to as little as under 2%.
MazeBolt’s professional services include some of the top experts worldwide in the DDoS. Many of them originally come from 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 mitigation company – Our team will guide your remediation efforts with your DDoS mitigation vendors. If required, our professional service 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 during these DDoS attack simulations.
Every vulnerability discovered by RADAR has all the data required to fine-tune the DDoS mitigation policy. For example, RADAR logs the volume of attack simulation sent and attack traffic received, together with other important reporting parameters. This information allows the DDoS mitigation vendor and MazeBolt to coordinate an optimized policy change for each vulnerability discovered. Because RADAR is non-disruptive, revalidating can be done in real-time to fine-tune the updated security policies. Each customer has different requirements, and a mutually agreed-upon schedule for simulations and vulnerability reporting, and remediation intervals are mutually agreed.
The increasing vulnerability of enterprises to DDoS attacks is due to their reliance on web and IP-based applications. RADAR outlines the steps of DDoS mitigation, including identification, response, and routing, to differentiate between legitimate high-volume traffic and attacks. Despite sophisticated mitigation solutions, companies face a 48% DDoS vulnerability level, primarily because these solutions are reactive rather than proactive. RADAR provides continuous, non-disruptive testing across all OSI layers to identify and help remediate vulnerabilities before an attack occurs. RADAR simulation reports are used by security teams and mitigation partners remediate DDoS vulnerabilities making it a critical tool for organizations to anticipate and counter DDoS threats proactively and effectively.
Continuously & On-demand.
A DDoS Vulnerabilities (DDoS Mitigation Gaps) report can be generated at any time (we refer to this as a Vendor report). Additionally, customers receive a quarterly executive report for high-level risk quantification and reduction recommendations.
RADAR™ testing vendor reports include a comprehensive and complete story of what took place during that 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 PCAP example of an attack
MazeBolt’s SOC team generates an executive summary once a quarter.
Yes. The MazeBolt RADAR testing platform UI has a wealth of information on all DDoS attack simulations.
- 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 the 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 (Personally identifiable information).
This depends on the DDoS protections deployed.
Yes – If RADAR testing is validating CDN-based protections the RADAR detector will require the ability to read the X-Forward-for header (or similar).
No – For DDoS protections which do not traverse a CDN E.g. scrubbing center, ISP protections, CPE, the decryption is not required.
We identify our attack traffic by looking for and filtering our attack traffic’s source IPs only. In a default configuration, we only capture traffic originating from MazeBolt source IPs. However, there is an exception to this rule, and that is 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).
If such a feature is deployed, it will first require a new contractual agreement with the customer.
- We take many considerations into account for compliance. Our Data Center is well segmented, and no unnecessary data is stored. MazeBolt is also ISO 27001 compliant and certified (since 2015). Upon request, this documentation can be provided.
- MazeBolt undertakes pen testing on a regular basis through 3rd party contractors.
The RADAR testing can test hybrid DDoS mitigation solutions simultaneously.
Which targets in the customer network are tested against for DDoS Mitigation Gaps?
- System users will 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.
- System users will 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 TAP port needs to be downstream from the DDoS mitigation.
- The ongoing concurrent traffic rate.
- Seeing all traffic toward the targets planned to be tested.
Red Team DDoS Testing
Yes, we do, but only for RADAR testing customers. We do not offer standalone Red Team DDoS testing.
A DDoS Test runs a very high rate of DDoS attack traffic against your website or network (online services). This type of testing usually has a lot of disruption to online services, so requires a maintenance window. The test is run with your participation, and will check your response team’s readiness and the procedures you have in place to deal with a successful DDoS attack. This type of testing is done mainly for post-attack handling when the damage has already occurred, to recommend how your team should start recovering from the DDoS attack.
DDoS Testing has three basic stages:
- Planning & Scheduling – a professional services team works with you to understand your needs and tailor the DDoS Tests accordingly (i.e. number of tests, type of tests, bandwidth, geo-distribution and more).
- Testing – a professional services team runs the tests in real-time via the User Interface. The emergency button allows you to stop the tests at any time.
- Reporting – Once testing is completed, a DDoS Test Report is created that highlights points of strengths and weaknesses of your DDoS attack handling, and recommendations for further action.
Yes.
Not only do many Fortune 500 and large organizations regularly use DDoS Testing, but in some countries, DDoS Test has become a recommended regulation for validating the organization’s human response and procedural handling to DDoS attacks. However, because traditional DDoS testing is disruptive nature and can’t identify DDoS vulnerabilities across an organization’s entire attack surface, many organizations are now switching to automated testing, that provides full, accurate, and non-disruptive DDoS testing.
Normally between 1 and 3 hours.
MazeBolt’s DDoS Test is customized to the size and complexity of each organization’s IT network, and includes multiple tests for ongoing and iterative improvements.
Can you test a cloud-based DDoS Mitigation scrubbing service as well?
Yes, we can. However, once you have RADAR testing running in your cloud environment, most customers will not opt for such a disruptive Red Team DDoS test (there is also little to no need for one). Additionally, unlike RADAR testing, a manual DDoS testing requires approval from your cloud provider.
Yes, we can. However, once you have RADAR testing running in your cloud environment, most customers will not opt-in for such a disruptive Red team DDoS test (There is also little to no need for one). Additionally, unlike RADAR testing, a normal DDoS test will require a more complex approval from your cloud provider.
MazeBolt is completely vendor-agnostic.
We do not align ourselves with any vendor and commit to providing customers with 100% objective testing results.
DDoS General
A distributed denial-of-service (DDoS) attack refers to a malicious player that disturbs the regular flow of traffic to a specific server, service, or network. This disruption is caused by inundating the target or its connected infrastructure with excessive Internet traffic. DDoS attacks are harnessed by utilizing numerous compromised computer systems as sources of the attacking traffic. These compromised systems can encompass traditional computers and other interconnected resources like Internet of Things (IoT) devices.
At a conceptual level, a DDoS attack bears resemblance to an unanticipated traffic congestion that congests a highway, impeding the regular progression of traffic towards its intended destination.
One of the primary challenges in identifying a DDoS attack lies in the familiarity of its symptoms. Many of these indicators closely resemble the experiences of regular technology users, such as sluggish upload or download speeds, websites becoming temporarily unavailable, intermittent internet connectivity, unusual content or media, or an upsurge in spam. Additionally, the duration and intensity of a DDoS attack can vary significantly, ranging from a few hours to several weeks – this is what is referred to as downtime.
DDoS attacks are executed through networks comprising interconnected Internet-enabled machines. These networks encompass computers and various devices (including Internet of Things devices) that have been compromised by malware, enabling remote control by an attacker. These individual compromised devices are termed “bots” or “zombies,” while a collection of such bots forms a “botnet.” Once a botnet is established, the attacker can orchestrate an assault by issuing remote commands to each bot within the network.
Upon targeting a victim’s server or network, each bot within the botnet sends requests to the target’s specific IP address. This onslaught of requests has the potential to overwhelm the server or network, resulting in a denial of service for legitimate traffic. The intricacy arises from the fact that each bot in the botnet is a genuine internet-connected device. Thus, distinguishing between the malicious attack traffic and the normal traffic becomes a complex task.
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:
DNS Services: By targeting DNS services with a flood of requests, attackers can prevent the resolution of domain names into IP addresses, making the website inaccessible even if the web servers are operational.
Load Balancers: Overwhelming load balancers can prevent them from distributing traffic efficiently, causing service degradation or total failure.
Data Centers and ISP Connectivity: Attacking the infrastructure hosting the website or its connectivity to the Internet can isolate the website from its users.
