When faced with a CC attack, many users panic, but it's crucial to remember not to panic or rush to find out who did it. The most important thing is to restore the website to normal operation first. The golden time to handle an attack is often only a few minutes; the longer you delay, the greater the business losses and the more users will leave.
The first step is to confirm whether it is indeed a CC attack.
Sometimes website slowdowns aren't necessarily due to an attack; it could be a program bug or a genuine surge in traffic. How do you distinguish between them? A few characteristics can help you quickly determine the cause. First, check CPU usage. Normally, CPU usage increases linearly with traffic, but a CC attack is characterized by CPU overload even with minimal traffic changes. Next, check the access logs. If you find a large number of requests concentrated on the same URL (such as login or search interfaces), and the source IPs are widely distributed, then it's likely being targeted.
The following command can help you quickly identify frequently accessing IPs:
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20If an IP requests the same URL more than 100 times in a short period, or if a large number of IPs access the same path with high consistency, it's a strong indication that an attack has occurred.
The second step is emergency containment—giving the website a breather.
After confirming an attack, the first thing to do is not to find the source of the attack, but to block malicious requests. Several methods can be effective quickly.
If you are using Nginx, you can directly add a rate-limiting configuration. Adding this to the `server` block will limit each IP to a maximum of 5 requests per second; requests exceeding this limit will return a 503 error:
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=5r/s;
location /api/ {
limit_req zone=api_limit burst=10 nodelay;
error_page 503 = @fallback;
}If you're using a WAF (Web Application Firewall), this is the time to put it to work. Enable CC protection in the WAF console, select "IP rate limiting" mode, and set the frequency threshold low, for example, blocking requests exceeding 50 within 30 seconds.
Another more direct method is to temporarily disable non-core functions. For example, switch computationally intensive interfaces like product reviews and user profile queries to static caching or disable them altogether, reserving resources for core business functions like payment and login.
The third step is traffic diversion—don't let the server handle the load.
If the attack traffic has already saturated the bandwidth, the server simply cannot handle the load. At this point, you have two options.
One is to enable CDN or DDoS protection. If you previously connected to Cloudflare, Alibaba Cloud, or Tencent Cloud's DDoS protected CDN, simply enable "Under Attack Mode" in the console, or switch traffic to the DDoS protected IP. The scrubbing center will automatically identify malicious traffic and allow legitimate requests to pass.
The other method is to temporarily change your IP. If your server has an elastic public IP, simply unbind the old one in the console and bind a new one. Then, go to the DNS settings and change the A record to the new IP, setting the TTL to 60 seconds for faster effect.
In the cloud console: Unbind the original IP and bind the new IP.
Then, go to the domain name resolution settings and modify the A record.
Fourth step: After the attack is over, don't rush to sleep.
The attack stopping doesn't mean it's over. Next, you need to do a few things to prevent it from happening again.
First, extract the logs from the attack period to see which API the attacker targeted. Then, optimize that API—add caching, add indexes, and add rate limiting. If a particular API is found to be frequently called, consider adding token verification or slider verification at the business layer to raise the barrier to attack.
The database and code also need to be checked. Restore data from the most recent backup to confirm that nothing has been tampered with. If possible, roll back the database to a point before the attack.
Finally, "protect" your server. It's recommended to at least do the following: connect to a WAF (this is a must; a few hundred yuan a year can block most attacks), enable basic DDoS protection from your cloud service provider (many are free), and keep Nginx rate limiting configured continuously; don't wait until you're attacked to enable it.
Frankly speaking, you know how painful a CC attack is once you've experienced it. But on the other hand, it's also an opportunity that forces you to build a robust protection system. The more effort you put into it beforehand, the more prepared you will be when something goes wrong.
Finally, here's a "check-up" command you can run anytime to see if your server is functioning correctly:
# View connection count and CPU usage in real time
watch -n 1 'netstat -an | grep ESTABLISHED | wc -l; top -bn1 | grep "Cpu(s)"'Hopefully, this experience will help you. Next time you encounter something like this, you'll know where to start.
