With the prolific growth in cybercrime, the number of infected devices under the control of criminal organizations has risen exponentially. As well as being used to execute file system encryption based ransomware attacks, these devices are now regularly being used to launch traditional Volumetric DDoS attacks and more recently Transaction Per Second DDoS attacks.

Traditional Volumetric DDoS Attacks

Traditionally the attacker was at a resource disadvantage when compared to the victim they were attempting to overwhelm. To ensure that attacks were economically feasible, attackers typically used amplification techniques. By sending fake requests supposedly from the victim’s IP address range would result in large unsolicited responses. UDP lends itself well to this type of technique so it was predominately used.

These unsolicited responses are very easy to reject, however just the process of directing high volumes of traffic towards the victim’s network can result in overwhelmed upstream links and routing infrastructure. Then the sheer volume of traffic rejection on the datacenter firewalls can also cause overload.

For these reasons, traditional DDoS attacks have been reported in Gbps or Tbps.

There are also a few traditional attacks that do use high rates of legitimate transactions to attempt to exhaust processing resources. Specifically TCP Flood (SYN Flood) to overwhelm the firewall session tables, TLS renegotiation targeting CPU exhaustion, and HTTP parser exhaustion (Slowloris & R.U.D.Y).

Bot driven Transaction Per Second DDoS Attacks

With the aforementioned growth in infected devices, attackers have turned the tables and now have substantially more compute resources than most targets. This has resulted in the following behavior:

1. Traditional amplification attacks targeting routing networks have grown exponentially in size. Regularly exceeding 1Tbps with the upper limits unknown.

2. Attacks using huge numbers of ‘normal’ transactions that the victim has to partially or fully process before detecting malicious intent are now commonplace.

This second type of attack is commonly achieved using botnets and is measured in Transactions Per Second (TPS).

The Anatomy of a Web Application DDoS Attack

Through observing attacks across multiple customers and jurisdictions we have observed a common approach taken by attackers in the more serious attacks. The process they follow cumulatively targets the following 4 resources. Attackers classically only add the additional techniques if those previous are not successful. They also only use adequate resources to cause the impact. This indicates a high degree of reconnaissance and then monitoring.

1st Target: Authoritative DNS
As the DNS is a critical resource in publishing an application, if this resource can be overwhelmed then an attack is successful. The technique predominantly used is to send a large number of queries for pseudo-random subdomains. When a subdomain exists it has likely been requested recently and hence cached by ISPs for fast response. With pseudo-random subdomains they are unlikely to be cached and hence are passed through to the authoritative resolver to answer. Queries per second can be in the millions, requiring substantial resolver capability to address.

Typical defenses:

1. Delegating your DNS to a large provider that can absorb these attacks for you

2. Building a substantial resolver capability to respond directly to high volume attacks

2nd Target: The serving Datacenter and upstream providers
With these attacks high volumes of UDP, SYN Flood and out of state TCP are commonly observed. They commonly target any IP range that a serving datacenter is publishing, so any unprotected ranges are likely to cause the entire data center problems. The traffic directed towards a datacentre is commonly upwards of 1 Tbps and can cause issues in the upstream internet in addition to any targeted victims ISP links and Datacentre network responders.

Typical defenses:

1. Using Border Gateway Protocol to force the traffic through a large scrubbing provider that can process and stop unwanted traffic. Clean traffic is then tunneled back to the web server

2. Use large cloud providers to host applications directly and purchasing their protection options

3rd Target: The classic DDoS volumetric protection mechanism
The classic DDoS volumetric protection mechanism is well known to attackers. When under attack network changes are commonly made to steer all inboard traffic to hyper scale scrubbing centers. To make this change without changing serving IP addresses the scrubbing center publishes the customer’s IPs addresses (using Border Gateway Protocol - BGP) and then tunnels the cleaned traffic back to the customer network (using Generic Routing Encapsulation - GRE) over a direct finite bandwidth point to point connection. Any response traffic back to the end customer goes directly to them, hence the request/response traffic path is asymmetric.

To disrupt this process attackers can target either of the following with volumetric attacks:

1. Shared intermediary routing infrastructure

2. Target the GRE tunnel directly

A further disruption may occur based on the asymmetry of request and response. To assist in stopping IP address spoofing, relied on for amplification attacks, some service providers implement BCP38 which explicitly blocks requests and responses coming from,going to different parts of the internet. Additionally stateful devices within the application stack may break an asymmetric session.

Typical defenses:

1. Using off internet mechanisms to get the traffic back to the datacenter.

4th Target: Application processing infrastructure
Once the target has successfully mitigated the previous methods, the attacker adds attacks on the application processing infrastructure. Previously these were targeted on protocol bottlenecks like TCP session tables, TLS key exchange and HTTP parsing, as mentioned above, now we observe a significant number of correctly formed HTTP requests. These requests are often from bots that may or may-not respond to challenges such as proof of work and Captcha, but regardless are consuming application publishing resources. These attacks can be in the millions of HTTP requests per second, hence requires substantial infrastructure to validate these transactions. Even a small percentage that gets through is likely to overwhelm the web server resources.

Typical defenses:

1. High capacity cloud infrastructure capable of processing large numbers of complete web transactions.

2. Auto scaling application processing infrastructure including bot and analomally countermeasures


Comparing RedShield to the Market 



CDN Web Application DDoS protection

Network DDoS protection


AWS, Neustar

Suppliers include:  AWS, Azure, Cloudflare, Akamai, Imperva, f5

Suppliers include: Arbor, Akamai, Cloudflare, Neustar, f5

Default configuration




Application specification optimization & operation




DNS DDoS Protection

Option A:
Cloud Hosted DNS Possible

Customers are free to choose any DNS provider as a independent buying decision eg AWS's route 53

DNS must be migrated to the protection provider


Option B:

Cloud Hosted DNS Not Possible

Customers can add RedShield’s RedLine DNS to their service, adding an additional ultra high capacity Name Server to customer managed zone files

Not supported


Datacentre Protection


Customers can add RedShield’s RedPipe to their service. Supports private links between RedShield DCs (Vodafone/IBM/AWS) and customer DCs off the internet

Relies on Network DDoS protection purchased separately

BGP/GRE scrubbing as either Always-Available (dynamic) or Always-On (static) 

Web Application Protection

Upstream links and network responders

Relies on AWS the world's largest hosting provider distributed across 100 datacenters

Relies on their own networks

Relies on their own networks


Uses a multi layered auto scaling architecture to use AWSs brawn when required, but also includes advanced bot and attacker detection to surgically address advanced attacks

Relies on their own processing equipment

Only supports TCP sessions. Attacks targeting high in the stack are not protected with this infrastructure

Application Specific Configuration and Incident Response Playbooks


There are a significant number of customizations that can be applied. These are application and even page specific that require expertise to optimize, iterate and may require dynamic situational changes.

A toolbox of varying depth that you configure and manage for your applications

A toolbox of varying depth that you configure and manage for your applications


Global and specific controls verification. Application specific playbooks can be developed and executed

Global controls verification

Global controls verification


Global and application specific communication

Global communication

Global communication

To get further information on RedShield’s architecture powered by AWS, see here


Learn more about RedShield's DDoS defence

Get in touch with RedShield's Solutions Architect team to discuss options for protection.


All Knowledge base

See how we can shield your web applications and APIs

Get a free trial or talk to one of our experts

Free trial
Talk to us