How to mitigate DDoS attacks on your APIs

It’s frustrating that sometimes project deadlines are so tight that you neglect the quality of your application development. Thanks to weak security policies, it’s even worse when your security team can’t see the damage before it’s too late. To help you with that, I want to explore targeted DDoS API attacks and their impact on your application programming interfaces, also known as API endpoints.

I will explain what DDoS is and what problems it can cause. Then I’ll explain how to use Wireshark to check if you’re under attack. It is one of the most famous network analyzers on the market. Then I show how you can limit your environment’s DDoS API attack surface. After that, I will close with a summary of what we have analyzed.

So first, let’s understand what the DDoS API is and what it can do with your API endpoints.

What is a DDoS and how does it affect your API requests?

Let’s go through some concepts related to API and explore what a DDoS attack means.

DDoS stands for Distributed Denial of Service. It consists in filling your network connection with your services. These requirements, made at layer 7 of the OSI model, are said to be invalid. Layer 7 is also known as the application layer, which floods your server with ghost requests, which in turn creates what is known as a zombie network. So, there are cases where your computer attacks a target server without your consent. This is another reason to ensure your home computer’s security is more robust as well.

Now that we’ve looked at a DDoS API, let’s look at what an API request is. There are a few other types of attacks targeting API requests, as shown in this github repo.

DDoS API attacks not only target the server running your API, but also each endpoint of your API service. Your API service will be attacked in more advanced attacks both on the server and on the API service itself. In the event of a successful attack, this will have drastic consequences for the health of your API server.

Let’s see how you can use Wireshark, a network analyzer, to identify a compromised network.

Detect compromised network traffic with Wireshark

Wireshark is a handy tool for your network forensics. It’s also a versatile tool to have under your belt if you’re serious about digging into the nitty-gritty of your traffic. Let’s look at an example of a compromised network. Go here to go to the Wireshark log named sec-sickclient.pcapng.

Excerpt from Wireshark's Distributed Denial of Service logs.

Excerpt from Wireshark’s DDoS logs

The log confirms that the requests from the IP at the port 1047 cannot reach the server at the port 18067.

The first thing that catches your eye is the unusual port number. DDoS attacks usually target non-regular ports. The attacker’s goal is to flood the server with invalid requests made at the same time as valid requests.

Graphical user interface, automatically generated text description

Another tip when checking the validity of API calls is to verify that the checksum is correct. On the extract you can see that the checksum of an invalid request is incorrect – invalid requests like this will flood the server, which becomes unresponsive.

Now that you understand what a DDoS API attack is and how to detect it, let’s look at some approaches you can use to reduce your services’ attack surface. We start by reducing your attack surface by filtering your upstream traffic requests.

The filtered upstream requests approach

There are ways to filter your requests. I prefer the Content Delivery Network. The CDN hides your application’s source code while serving up the application layer data with its cached content. It acts as an upstream security defense option by filtering requests to your applications and helping your users with low-latency cached data. You may have third party tools that offer CDN solutions such as B. AWS CloudFront. Still, it’s good to have a minimal response plan in place before reaching out to your ISP provider. It can also be helpful for your user-facing services to access your web content such as videos and music in a secure cache.

This approach filters traffic before it reaches your network, making it easier to manage your servers. However, this approach requires something extra to protect you if your environment is discovered and compromised. This is where a honeypot can help.

The honeypot approach

I believe your environment is the best source of data for your mitigation plan. You have accurate data from your attacks with a malware honeypot that could mock both your front-end and back-end environments.

Your honeypot can act as a rat trap if you intentionally leave some vulnerabilities open for attackers to exploit. It’s a risky game as your honeypot needs to be identical to your production environment. Otherwise, you invited your attackers to explore your surroundings. But when used properly, it becomes a powerful tool to secure your domain.

Text description generated automatically

A good honeypot can also show how well your defense systems stop attacks. Another benefit is that it shows which data needs more security measures.

Even with an exposed honeypot, your network can suffer without excellent management of your API requests. To make sure you’re covered in this regard, you can limit your network resources.

Limiting your network resources

You can configure your network interface controller to handle the maximum amount of traffic per session. What is known as rate limiting can be done either by software or hardware. While the first manages the number of simultaneous calls, the second takes care of your switch and router configurations. Rate limiting your network resources gives you peace of mind that your application is in a healthy state, although some users experience higher latency from your services under attack.

A good response plan includes several layers of security. Now we will see how you can benefit from a content delivery network with a honeypot.

Hackers attack via DDoS

How a malware honeypot and CDN can boost your defenses

As mentioned earlier, the CDN will deliver your content at the application level and will only cover part of your security plan. You can benefit from having a honeypot as your first attack surface and it should be in a controlled environment where your application resides. Your security plan should use a mix of services focused on different application domains, and the security guiding principle reinforces the security of interconnected parts. So, combining your CDN and a malware honeypot can help your team apply the response plan in place and reduce the slowness and unavailability of your services. It then gives you enough time to more safely repeat your discounted benefits without opening up new threats.

Let’s look at the topics we covered today.


DDoS attacks make your environment unstable and the attacks do this by sending service calls to a target service with invalid requests. While there are many types of DDoS attacks, we often overlook those that focus on the health of your API services.

I suggest re-reading the OWASP API Security Advice. Depending on the data flow and the availability of your services, you can take additional measures. The idea is to narrow your attack surface. However, you don’t want to build a black box. The security and usability of your components must be balanced for the adoption of your service by your developers and users.

Traceable AI solutions for API security are an excellent choice for dynamically analyzing your API’s vulnerabilities. They deliver a mature infrastructure focused on observability of your ecosystem. You can see how Traceable AI works and reach out to team members to have their security team properly secure your digital assets.

This post was written by Daniel Paes. Daniel is a data-driven professional with an interest in AI for cognitive enhancement. He is an evangelist for security risk and privacy awareness.

The How to Mitigate DDoS Attacks on Your APIs post appeared first on Traceable App & API Security.

*** This is a Security Bloggers Network syndicated blog from Blog written by Daniel Paes. Read the original post at:

Comments are closed.