It’s frustrating how a project’s delivery dates are sometimes 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 catch the damage before it’s too late. To help you with that, I want to examine targeted DDoS API attacks and what they do to your application programming interfaces, also known as API endpoints.
I’ll explain what DDoS is and the problems it can cause. Then, I’ll explain how to check out whether you got attacked using Wireshark. It’s one of the best-known network analyzers on the market. I’ll then show how you can narrow your environment’s DDoS API attack surface. After that, I’ll end with a recap of what we analyzed.
So, let’s first understand what DDoS API is and what it can do to your API endpoints.
What Is a DDoS, and How Does It Affect Your API Requests?
Let’s go over some concepts related to API and explore what a DDoS attack means.
DDoS stands for distributed denial of service. It consists of stuffing your network connection to your services. These requests, made on layer 7 of the OSI model, are called non-valid. Layer 7 is also known as the application layer, which floods your server with ghost requests, which in turn creates what is called a zombie network. So there are cases where your machine hosts attack a targeted server without your consent. This is another reason to ensure that even your home computer’s security is more robust.
Now that we’ve reviewed a DDoS API, let’s go over what an API request is. There are some other types of attacks targeting API requests, as shown by this Github repo.
DDoS API attacks focus not only on the server where your API is running but also on each endpoint of your API service. Your API service is attacked on both the server and the API service itself in more advanced attacks. This yields drastic results for the health of your API server in the case of a successful attack.
With that said, let’s check how to identify a compromised network with Wireshark, a network analyzer.
Spotting Compromised Network Traffic With Wireshark
Wireshark is a handy tool for your network forensics. It’s also a versatile tool that you should have under your belt if you’re serious about getting into the detail 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.
Extract from Wireshark’s DDoS logs
The log confirms that the requests made by the IP 10.129.211.13 on port 1047 can’t reach the server 126.96.36.199 on port 18067.
The first thing to notice is the unusual port number. DDoS attacks usually target non-regular ports. The attacker’s goal is to flood the server with non-valid requests, which will be concurrent with valid ones.
Another tip while checking the validity of API calls is to verify whether the checksum is correct. On the extract, you can see that the checksum of an invalid request is incorrect—invalid requests like this one flood the server, which becomes unresponsive.
Now that you understand what a DDoS API attack is and how to track it down, let’s see some approaches that help mitigate your services’ attack surface. We’ll start by mitigating 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 the application layer data with its cached content. It works as a security upstream defense option by filtering requests on your applications and helping your users with low latency data cached. You can have third-party tools offering CDN solutions, such as AWS CloudFront. Still, it’s good to have a minimal response plan before reaching your ISP providers. Having your user-facing services accessing your web content, such as videos and music, on secured cached storage can also help.
This approach filters the traffic before it reaches your network, which smooths the management of your servers. But this approach still needs something extra to protect you if your environment is discovered and compromised. Here’s where a honeypot can help.
The Honeypot Approach
I find that your environment is the best data source for your mitigation plan. You’ll have accurate data from your attacks with a malware honeypot that could mock both your front-end and back-end environments.
Your honeypot can work as a rat trap if you deliberately leave some vulnerabilities open for attackers to exploit. It’s a risky game, as your honeypot must be identical to your production environment. Otherwise, you’ve invited your attackers to explore your environment. But when deployed correctly, it becomes a powerful tool to secure your domain.
A good honeypot can also show how well your defense systems are stopping attacks. Another perk is that it shows which data must have more security measures.
Even with an exposed honeypot, your network can suffer without the excellent management of your API requests. To make sure you’re covered in this respect, you can limit your network resources.
Limiting Your Network Resources
You can configure your network interface controller to handle maximum traffic per session. What’s known as rate limiting can be done by either software or hardware. While the first manages the number of concurrent calls, the latter will handle your switch and router configurations. Rate limiting your network resources grants you the certainty of having your application in a healthy state, despite some users experiencing higher latency from your attacked services.
A good response plan comes with multiple security layers. Now, we’ll see how you can benefit from a content delivery network with a honeypot.
How a Malware Honeypot and a CDN Can Improve Your Defenses
As mentioned before, the CDN will serve your application-layer content, covering only one part of your security plan. You can benefit by having a honeypot as a 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 guidance 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, mitigating the slowness and nonavailability of your services. It’ll then give you enough time to reiterate your degraded benefits more securely, without opening new threats.
Let’s review by checking the topics that we covered today.
DDoS attacks make your environment unstable, and the attacks do that by firing service calls to a targeted service with non-valid requests. Although there are many types of DDoS attacks, we often overlook the ones focusing on the health of your API services.
I suggest revisiting the OWASP API security hints. Depending on your services’ data flow and accessibility, you can adopt extra 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 your service’s adoption by your developers and users.
Traceable AI solutions for API security are an excellent choice for dynamic analysis of your API’s vulnerabilities. They deliver a mature infrastructure focused on the observability of your ecosystem. You can check out 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-focused professional with interest in AI for cognitive enhancement. He’s an evangelist on the awareness of security risks and data privacy.