DDoS protection – Azure vs Cloudflare

In the Summer of 2021, Microsoft announced that they stopped one of the largest DDoS attacks ever recorded (Microsoft says it mitigated one of the largest DDoS attacks ever recorded – The Verge) saying they were able to mitigate a 2.4Tbps Distributed Denial-of-Service (DDoS) attack in August.

This attack was a UDP-based reflection attack, which was short-lived but for a business would certainly bring down any external services that they have which were targeted for this type of attack.

Microsoft also states that most attacks are short-lived, based upon statistics that they have collected most of the attacks are within the range of 5 – 30 minutes.

Now, fortunately, the customer was not that impacted by the attack since they were using the built-in DDoS protection mechanisms from Microsoft (sales pitch!). From a customer perspective if you wanted to be protected from these types of attacks in Azure you would need to upgrade to Azure DDoS standard which provides protection against these types of volume-based attacks.

By default, all services in Azure are running a service called DDoS protection basic which is focused on protecting Azure’s infrastructure and is just there to ensure the availability of the Azure region, it does not focus on protecting single applications or services in customer workloads. 

Azure DDoS protection standard only provides protection against attacks on layers 3 and 4.

The Standard feature provides protection against the common DDoS Attack types such as TCP SYN Flood, UDP Flood attacks.

It should be noted that this feature can also be used together with services hosted elsewhere, regardless of where the associated domain is registered or hosted, as long as the associated Public IP is hosted on Azure. 

It does not directly support PaaS services meaning that service running as PaaS needs to be protected behind another service and public IP traffic being served behind it, as the example below.

NOTE: All Azure PaaS services are also covered by Azure DDoS Basic (such as Azure DNS)

The DDoS service is also expensive, costs close to 2,500$ per month, and covers up to 100 Public IP addresses.

The Standard service also uses the Azure backbone to scrub traffic at the Azure network edge before it can impact the availability of services within a region. So, services that are routed through the backbone such as any services enabled by Front door or Global Load Balancer. 

Now, what about layer 7 attacks? This is where we have many bots/scripts mimicking regular end-users. The significant difference here compared to TCP SYN flood attacks is that 1: You can’t use spoofed IP addresses, and 2: It can be hard to differentiate between regular users and bots.

So, an example HTTP DDoS attack can be launching 100000x of HTTP GET commands against the service until it fails, or against multiple different URLs at the same time, or doing HTTP POST commands with a specified payload to overload the service as well.

There are different ways to stop these types of attacks, which will cover here

• URI restrictions – Is about just defining that end-user cannot access certain URIs on your website, in some cases attackers are going to a specific URI on your site when they are doing an attack, however, if they are going against your main page, it will be difficult since then you will also block out legitimate users as well.
• User-Agent blocking – In an automated attack, it will be in most cases triggered using a script on the botnet and therefore will not have a regular user-agent (as seen here) 
  You can also configure the blocking of certain user agents against your site, to make sure that non-legitimate user agents are not able to reach your backend web servers.
• IP address blocking – Is about just adding IP restrictions from the attackers, often this will not work properly since these attacks often come from many IP addresses so it will take time to update firewall rules with all the addresses (and also they might change)
• Geo-blocking – Most providers also can block IP ranges based on countries of origin, which should be done, either way, if your business only operates within a specific country, you should review your firewall log and block out countries that you do not do business with. However, when you are dealing with a DDoS attack in most cases, the botnet spans many different countries, making it difficult to maintain and not lock out countries where your legitimate users are.
• WAF features – Most WAF vendors provide support to block out based upon built-in signatures or custom rules. The built-in signatures are there to block against known attack patterns such as OWASP TOP 10. You can for instance read about the signature files that Microsoft have here –> CRS rule groups and rules – Azure Web Application Firewall | Microsoft Docs. Again, the problem is that this feature does not stop regular DDoS attacks on layer seven since it is a bit too simple since the attacks seem like regular user traffic. Therefore, it would be difficult to block the traffic from the attack without impacting the actual end-users.
• Rate limiting – This is the most common approach to reduce the impact of HTTP DDoS attacks, is to add rate limiting, this allows us to define a threshold on our website. Let’s say that someone send over 100x requests per second, then we will impose a QoS on their traffic or block it entirely. Many vendors have also implemented a JS challenge, which means that if they reach the threshold the service will send them a JS challenge (just a small JS script) that they need to run on the endpoint making the request. As mentioned, DDoS attacks are often triggered by scripts that are not able to parse the JS challenges and therefore fail the challenge and will then get blocked. Legitimate web users with a browser can run the JavaScript and therefore will not be blocked.

Now going back to the main topic, how do Cloudflare and Microsoft differentiate in protecting against these types of attacks?

• Microsoft has WAF features as part of the Azure Application Gateway feature which allows for blocking against common OWASP top ten and custom rules (such as geo-blocking) but does not provide rate limiting. 
• Rate limiting features from Microsoft are only available as part of Azure Front Door WAF feature. This rate limit feature is then applied to each client’s IP address trying to connect. Another issue is that Microsoft WAF only supports some main different actions, which are either LOG / BLOCK / ACCEPT, so unlike most vendors, you cannot define JS challenge or more advanced actions to be taken using Azure WAF, as seen here
• Cloudflare has rate limiting with different features depending on SKU level. (In addition to geo-blocking, OWASP, and custom rules. You also have more advanced actions available such as JS challenge and you can define custom actions such as redirecting users to a custom error page.
  
• Cloudflare like Front Door rules are triggered at the Edge (as close as the point of origin as possible) meaning that if you have a web service located in Amsterdam, but your users are coming from Australia, then the different rules are processed at one of the PoP’s in Australia before reaching the web service.
• Cloudflare DDoS protection for layer 3 – 5 is enabled by default and can be a lot cheaper depending on the size of your company. For smaller companies, it only costs about 200$ per month.

Summary

Both vendors provide DDoS protection mechanisms for layers four through seven and both are known to be able to handle large DDoS attacks based upon published articles.

However, if you want to provide the best performance and be able to have more customizable features not just for protecting against attacks but also for performance, Cloudflare is still the safe bet.

The only issue is that for large organizations it might be difficult to figure out what Cloudflare’s services are going to cost, while Microsoft has a much more transparent price model.