Since the moment I started building my website, I have always considered the possibility of it being targeted for destruction. There are various forms of attacks such as DDoS, spam, or attacks on certain security vulnerabilities… Do you think I have made any enemies that I should be worried about? Actually, no, I have never had any conflicts with anyone, but I can’t escape the “watchful eyes” of these malicious actors on the internet. This is not the first website I have built, so paying attention to these unfriendly behaviors is not new to me.
Recently, my blog has been experiencing a higher frequency of DDoS attacks. In its nearly 3 years of existence, I have lost count of the number of attacks. The lighter ones would cause the server to “freeze,” resulting in slow response times. The heavier ones would cause the server to completely crash, making it inaccessible. So far, there have been no significant damages, but it is always a hassle to deal with this mess. It’s not like we always have a computer and internet access nearby.
DDoS attacks are not new, but their destructive power is extremely high. Whatever the reason may be for an attacker to decide to DDoS a website, they must find great satisfaction in seeing the website crippled.
In the past, I hosted everything on DigitalOcean (DO) with a modest server configuration that was stable enough for the current user load. Occasionally, I would encounter a minor DDoS attack that would bring the server down. Initially, DO would issue warnings that the server was using more than 70% or even 90% of the CPU without knowing the cause. The UptimeRobot tool would send alerts that my website was inaccessible. Later, upon checking the access logs, I discovered that I was being DDoSed.
Most of the attack durations are very short, and during those times, I could only grit my teeth and wait until it ended, sometimes even occurring in the middle of the night. When I woke up the next morning and rebooted the server, everything would go back to normal.
People might think, why not take measures to protect against DDoS? My feeling about that would be :|, because I don’t know how to effectively defend against it. Everyone thinks the first step would be to set up rate limits, and let me tell you, I did that. Each IP address is limited to only 10 requests per second. So why not upgrade the server then? Where do I find the money to do that? $6 a month may not be much, but it serves as a financial safety net and covers the normal traffic if there are no malicious actors. Then, should I install more monitoring tools? Do you think I can install anything on a Shared CPU 1GB, 20SSD server?…
Actually, I’ve thought a lot about this issue, but I just can’t effectively block DDoS attacks. Remembering the OSI 7-layer model that most technology students are taught. We have Layer 7 – the topmost layer – the application layer. The rate limits that I applied were at Layer 7, and the software installed also operated at Layer 7… Layer 7 is the layer that directly interacts with your application or server. In simple terms, if an attacker can send an HTTP request to your server, they are attacking at Layer 7. And as you understand, your server will have to process their requests, whether it be simply rejecting the request, it still requires some CPU time to process. A single request might be simple, but what about thousands, hundreds of thousands of requests at once? As you can see, my blog crashes.
About 3 weeks ago, I wrote an article migrating from DO to Cloudflare. Everything was carefully planned, starting with migrating the frontend, then the API, and eventually everything to avoid maintaining a centralized server like DO. Perhaps this article “ticked off” some individuals and they decided to see if the “new home” could withstand DDoS attacks.
The answer is yes, but only partially. After discovering that the main blog was no longer SSR, attackers quickly realized that the API calls were still going to DO, and they continued attacking the API, with the consequence being the same – it crashed.
Finally, I couldn’t bear it anymore. Even with limited time, I had to perform a large migration to Cloudflare to put an end to these attacks.
Solution
Cloudflare (CF) – a name not unfamiliar to many. Years ago, many people knew it for its free proxy servers, free SSL, CDN, and caches… there were many interesting things there. In the beginning, I used Cloudflare but didn’t fully understand its functionalities, or even after setting up my website, I found that the access was slower or the caching features were quite annoying. However, recently Cloudflare seems to have transformed, with clearer operations, more documentation, and a stronger community.
Cloudflare stops Layer 3, 4 DDoS attacks. This means it can block suspicious requests before they reach Layer 7, your application. CF acts as a shield for you. All you need to do is configure it to block all suspicious queries.
To be honest, CF has many features that I haven’t fully understood. But first, let’s focus on defending against DDoS attacks, we can explore the other features later. The simplest way to defend against DDoS is by transferring your primary domain to Cloudflare, enabling the proxy and setting up rate limits.
Rate limiting is a way to limit the number of accesses within a specified period of time. This is one of the simple yet effective methods to counter DDoS attacks. Suddenly, an IP continuously sending requests to your address, whether with a motive to cause destruction or “unintentionally” using a certain “loop” command that they laugh about when asked, “Sorry, I accidentally triggered a bug”… Well, this is quite a “bug,” and if you can’t “fix” it, let me help.
You might find this intrusive, weren’t we talking about setting up rate limits on the server earlier, and it didn’t work? Well, remember that Cloudflare acts as an intermediary for all requests before they reach your actual server, meaning it operates at Layer 7, and according to them, CF has the technology or the capability to counter DDoS at layers 3 and 4. In summary, setting up rate limits at CF will block a considerable number of requests before they reach your actual server.
Now, I will guide readers on how to configure rate limits to minimize DDoS attacks through Cloudflare. Please note that this is one of the methods I have used, and there are many other methods, so if you have a better approach, please leave a comment below the article.
First, of course, you need to register a Cloudflare account and set up the domain you want to protect against DDoS. Don’t worry, Cloudflare will guide you through the process after successful registration.
Once the domain is activated, go to “Security” > “WAF” on the left navigation bar.
WAF, in simple terms, is Cloudflare’s firewall, which allows you to configure, block, modify… user requests before they reach your actual server. Look to the right side, to reach your server, a request will have to pass through all these security layers of CF.
Right there on the screen, switch to the “Rate limiting rules” tab and click the “Create rule” button at the bottom.
Here, give a name to the “Rule” and select the path for which Cloudflare will set the limit. For example, here I choose “/”, meaning that all paths of the main domain will be protected.
Next, set the limit by filling in the “Requests” and “Period” fields – the number of requests within a specified period, combining to form the rate limit. For example, here I choose 10 requests within 10 seconds for each IP address. If the limit is exceeded, users will receive an HTTP Status 429 error.
Finally, save the configuration and try spamming your website to test if it’s working properly.
If you’re wondering how to determine the number of requests, I suggest you “experiment”. Keep trying until you find the right number, as it depends on the number of requests your website receives. For example, if a page loads 20 requests in total, the limit should definitely be higher than 20. Not to mention 1 second, then 2 seconds… and then it continues to make “n” additional requests, or users continuously navigate your website, generating “m” requests within a certain period of time… In conclusion, this number depends heavily on your website, so try and find a reasonable number.
Finally, all the statistics about requests exceeding the limit will be displayed here. You can click on that “0” to view the details. Here, you can see that I haven’t had any requests exceeding the limit in the past 24 hours.
