Contents
Preface
When I opened my eyes early in the morning, I saw a bunch of emails from cloudflare:
From the emails, we can see that there are 5 attack notification emails in total. In the order of the 5 emails, the contents are as follows:
1,
2,
3.
4.
5.
This was my first time being attacked, and I was mostly filled with curiosity and surprise, but I was also a little speechless because I had used up my free quota of 100,000 gets for workers today. Let's not think about that for now, and review the process of this attack.
WAF log analysis
Let’s take a look at the time when the warning email was first received:
At 2:16 AM, let’s first check if there are any anomalies in the WAF log around that time period:
Click on the 86.4k number to enter:
Although 5 rules were triggered, I took a look and found that there was not much difference in the content of these packets. It was just a post request to access the homepage of my blog, but it was accessed from all over the world within 15 minutes. So below, I will take the first and second types of attacks as examples to see the general content.
1. The top attack type comes from the third email
The rule ID is: "6e3ccc23900c428e8ec0fb8a3a679c52", and the rule description is: "Requests coming from known bad sources".
Click on any of the detailed information:
Actually, there is nothing unusual in the red box. The UserAgent is written very carefully, similar to the UA of a normal browser, unlike some crawlers which write it very simply or even leave it empty.
2. The second most common attack type comes from the fifth email
The rule id is: "0a07c24f3cd44a57a5c19b73d2f294d7", and the rule description is: "HTTP requests trying to impersonate browsers".
Click on any of the detailed information:
The content is similar to the first type of attack, and the content of the remaining three types of attacks is also the same. It is estimated that they can be divided into five types based on Cloudflare's own feature library and its own analysis algorithm. In our eyes, they should all be the same.
Because the statistics of the free version are too rough, I can't see the specific time when the attack started. There is no option to go directly to the last page of the WAF attack log. I can only click it myself. There are 25 items on a page, hundreds of millions of items, it will kill me? ? So I can only see the attack duration from the time of the earliest email notification received at 2:16 and the time of the last request filtered by the rule ID in the log. The following 4 are the first 4 attack notification emails, all started at 2:16:
It can be seen that these four attacks all started at 2:16 and ended in the interval between 2:28 and 2:31 respectively.
The fifth attack notification email was received at 2:29 and also stopped at 2:30. This duration was the shortest:
From the above start and end times, it can be seen that although there are 5 categories, they all end at around 2:30 and should be uniformly controlled (the start time is difficult to control uniformly, but the end time is easy to control, so as the saying goes: We don’t ask to be born on the same day, but we ask to die on the same day?).
Analysis and logging section
Web traffic:
threaten:
workers:
Site-wide rate limit
I have set a site-wide rate limit to see if it works.
However, these only initiate a large number of requests to the same IP, and must access the URI specified in the settings to be effective. There are also a large number of attacks in which only one IP sends one request, so this is not effective for this type of attack.
Changting WAF data
I don't understand Changting's statistics. The request counts of the two pages are a bit different. But it's a free community version, so I don't have much to say.
In general, Changting did not intercept any incoming requests, but this is reasonable, because we have seen before that from a single request, there is no problem with these requests. Moreover, although Changting has also configured high-frequency access interception:
I wrongly accused Changting. It was my own fault. I set the IP of the device where the cloudflare tunnel was deployed to the whitelist.
Summarize
Although I don't know who is so bored as to launch a distributed DDOS attack on my small website, it doesn't prevent me from using this as a case study for a simple analysis.
If you still use Tencent Cloud CDN deployment method, according to my usual setting strategy:
This situation will trigger one of these two instant usages, and according to my settings:
Once 5 minutes are up, the CDN service will be shut down and a 404 error will be returned. Therefore, the traffic consumed and the number of requests for https resource packages will definitely not reach the final cloudflare capacity of 35G and 11 million SSL requests. However, the result is that the website will be inaccessible before the 60-minute unblocking time.
So the final conclusion is: if I had not relied on Cloudflare's global IP anycast structure to deal with this distributed DDOS attack, but still used Tencent Cloud CDN, there would have been an hour of network disconnection. This is because the attack only lasted 15 minutes and only occurred once. If this attack occurred once an hour, my website would be inaccessible (Cloudflare is awesome).
However, this also exposed that my current home data center still lacks a solution for traffic tracing. I need to think about this carefully, otherwise next time a problem occurs, there will still be no way to trace it locally. Does Kelai have a solution?
Another point of view: From a technical point of view, Cloudflare's globally deployed IP anycast structure is too easy to deal with this kind of distributed DDOS attack launched on a global scale, and the traffic allocated to each edge node is pitifully small.
Another 2: If I manually turn on the "Under Attack" button during the attack:
Wouldn't that mean my workers' free quota wouldn't be consumed? The attack started at 2am, they must have waited until I fell asleep, so insidious...
It seems that the method of using the worker's free quota of 100,000 requests per day to optimize blog access is still a bit fragile, and we need to explore new ways to optimize access.
Aren't home data centers usually deployed on the intranet? For such important services, I usually either don't map them to the public network or access them through VPN. I feel uneasy about directly throwing them to the public network.
Generally speaking, "home data centers" mentioned on the Internet are just euphemistic names. For example, a NAS with public network port mapping or intranet penetration can also be called a "home data center". Strictly speaking, these can only be regarded as "pseudo-home data centers" in a broad sense. From a professional perspective, data centers are divided into internal services (for example, only internal employees of the unit can access) or public services (for example, the financial industry and tax industry are open to the public) according to the usage scenario. And what I mean by "home data center" is professional. It is a complete set of solutions including security and caching: from domain name resolution-DDoS attack mitigation-web security filtering-optimized access speed-intranet penetration-web application firewall secondary filtering-load balancing (application hot standby), it also includes multiple WordPress site data synchronization and one-click activation of the same-city disaster recovery of the cloud server mirror site after a power outage at home. These together are what I mean by "real home data center", not what you said, which is just the concept of mapping it on the public network or directly throwing it on the public network. In other words, the purpose of my home data center solution is to talk about how to put the home applications safely and openly on the public network (Ng Mang-tat said in Kung Fu Soccer: I am not just a cripple~). You know, the performance of any idle device at home is much better than the 1-core or 2-core cloud server with 1G2G memory, and the cost is just a little more electricity bill every month.
If the performance is good enough, after all, the limit of human technology is here, and the power consumption can never be lowered. A device with a power of 15W and an annual electricity bill of 60 yuan will have performance similar to those cloud services that cost 98 yuan a year. The only difference is that the memory and hard disk can be larger. However, considering the cost of the hardware itself and the cost of future upgrades (for idle hardware, it can be sold second-hand to recover part of the cost). Within a certain range of usage intensity, self-built hardware may not be as cost-effective as using some cloud services.
Well, technically it is true, but when you buy a cloud server, you have to register it domestically, and the access speed from abroad may not be fast. The advantage of using your own equipment is that the deployment is simple, flexible, and highly controllable. As long as the problem of slow access from domestically can be solved, people with a certain level of hands-on ability will still be eager to try it.