Comparing the RedShield-AWS DDoS Solution to Market Alternatives

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 

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