Protecting APIs from DDoS Attacks

DDoS and APIs

In a world where digital security is critical, the future of business is at risk from a range of different threats. At the heart of many applications is a set of APIs. These APIs are used to communicate between consumers and the apps, and they're critical to business. If they go down, customers can't do anything with the app—and that means lost revenue.

How prevalent are these attacks?

While some report an overall drop in the area of RDDoS (ransom distributed denial-of-service), there was also a reported 164% increase in application layer (Layer 7) DDoS attacks. Japan, e.g., has encountered increased ransom DDoS attacks in 2022. “In the case of ransom DDoS, the proportion of L7 attacks using more advanced connections as well as DDoS attacks using traditional high-capacity traffic on L3 and L4 level is increasing.”

APIs can be internal, but any APIs exposed to the internet are open to attack by malicious users who want to prevent legitimate users from using them. What if someone tried to take them down by sending millions of requests per minute, far more than the system could handle? That would result in a distributed denial-of-service (DDoS) attack that floods the API with data requests so fast that it can't respond to any of them.

DDoS attacks are a common threat to networks and applications and are typically perpetrated by bots or botnets due to the increased need for computing power. These attacks can be launched from anywhere in the world, the results of which can range from inconvenient (slowed performance) to devastating (systems going offline).

Types of DDoS

A factor in defending APIs from DDoS attacks is understanding the types of attacks that are common:

1. TCP SYN floods,
2. HTTP Post floods, and
3. Volumetric attacks.

A TCP SYN flood occurs when an attacker sends numerous SYN packets but never completes the 3-way handshake. The server can’t process all these incomplete connections and resources being used.

An HTTP Post flood occurs when an attacker sends POST requests to a server with a large amount of data. Since many servers will only accept POST requests with small amounts of data, sending these excessive requests can cause them to become overloaded by processing requests without completing them before the next one arrives.

Volumetric attacks are attempts to cause so much traffic that it overwhelms resources and disrupts service for legitimate users. Some examples include DNS amplification, smurf, and NTP reflection/amplification attacks.

Protection

A good first step in protecting APIs from abuse, in general, is to know your endpoints. Inventory, inventory, inventory. If it’s public-facing, it’s a target that will be found and exploited.

One way is through web application firewalls (WAF). Using WAFs with attack profiling allows rules that detect certain types of traffic and block them before they reach your application server. For example, if you know that TCP SYN floods are usually caused by automated crawlers or bots trying to find vulnerabilities in your website, you could configure your WAF to reject any requests coming from those IP addresses or block them entirely until they send valid credentials first.

An important difference between normal web app IP blocking and API detection is contextualization. To properly protect APIs from IP abuse, the WAF technology needs to analyze traffic patterns over time and identify abnormal behavior such as repeated requests from different IP addresses.

Another part of the security layer is using a content delivery network (CDN) such as Cloudflare. A CDN will allow for the distribution of content across multiple servers around the world so that if one server goes down due to an attack, there will still be others available for users to access information from without any disruption in service.

An additional tactic is casting, where the WAF is configured to block certain types of traffic by casting them into a different port on your server.

When the WAF detects an attack, it can respond by blocking the attacking IP address or redirecting the user to a different page. This type of protection is referred to as blackhole filtering.

Other strategies include real-time packet analysis, rate limiting, and increased bandwidth to prevent these types of attacks.

Active defense

Another way to protect APIs from DDoS is authorized testing and following the company’s risk appetite. Important Note: never test any resource unless you have permission. There’s a fine line between testing and illegal activity! If the API being tested is cloud-hosted (e.g., Azure, AWS), read the agreement. There may be no DoS testing allowed, or it may be that it’s limited only to a certain range of Ips or resources.

Here are a couple of ways to test after authorization:

1. After enabling rate limiting, send numerous requests from Postman or Burp Suite against an API. The Response after hitting the threshold will show Blocked. If it doesn’t, then the requests were sent to the incorrect API, the threshold is not enabled on the right API, or the threshold is set incorrectly

   
   

2. Use Slowloris (python-based) to create the right number of requests for testing.

   
   

While more complicated to set up and run, it’s a good test because Slowloris is a common way to deploy a DDoS. These low-and-slow attacks are typical ways to abuse APIs because, “Traditional attacks, like SQL injections or cross-site scripting, still happen, but the successful API attacks don’t follow those kinds of “one-and-done” mechanisms that leverage known vulnerabilities.”

Why spend the resources?

One reason for a DDoS is to cause lost revenue, whether out of spite or revenge. Another could be to drive business to another site (NOTE: this is not to say that when X is down competitor Y did it – it’s just a possible reason).

Whatever the reason, an outage is an outage and is at minimum a security issue because it violates the A (Availability) of the CIA triad (the other two being Confidentiality and Integrity).

DDoS attacks are a serious threat to businesses. It's not just the cost of the DDoS attack itself, but also the damage to reputation and loss of revenue.

Whatever your role (formal or not) – developer, engineer, security, DevOps – do what you can to mitigate DDoS. Anything is progress!