A DDoS attack doesn't steal data: it tries to take your site down by flooding it with requests until the server can no longer answer real people. The good news is that in most cases you can get the site back up quickly, if you do the right things in the right order.
1. Don't switch everything off: look first
The first instinct is to restart the server. It rarely helps: the attack resumes as soon as the site is back. Take five minutes to understand what is happening, because the countermeasure depends on it.
Open the web server logs (on Nginx usually /var/log/nginx/access.log, on Apache /var/log/apache2/access.log) and look at the latest lines. If you have no access to the server, ask your hosting provider: they have the same data.
Look for these signs:
- many requests from the same IP addresses, or from different IPs all in the same country or on the same provider;
- always the same page: the login page, the site search, the cart, a heavy file;
- empty, identical or fake user agents (for example
python-requests,curl, or the same browser repeated thousands of times); - a sudden spike that doesn't match a campaign, a newsletter or a viral article.
A handy command to see who makes the most requests:
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
If the top of the list shows a few addresses with tens of thousands of requests, you already have something to block.
2. Tell an attack from a spike of real visitors
Not every spike is an attack. An article shared in a busy group or a mention on TV can bring thousands of visitors in minutes. The logs show the difference:
| Real visitors | Attack |
|---|---|
| Different pages, images and CSS loaded | Always the same page, no images or CSS |
| Many IPs, each with few requests | Few IPs with huge numbers of requests, or thousands with an identical pace |
| Various browsers and devices | Identical or missing user agents |
| Locations that match your audience | Countries where you have no customers |
If they are real visitors, the problem is not an attack but a site that can't handle the traffic: the fix is caching (see below), not blocking anyone.
3. Block what is obvious right away
If the attack comes from a few addresses, block them in the server firewall or in your hosting panel. On Linux with ufw:
sudo ufw deny from 203.0.113.45
If it comes from a country where you have no customers, blocking that country is often the fastest measure. Just be careful not to block yourself, your hosting provider or services you depend on (payments, shipping, backups).
This is an emergency measure: serious attacks keep changing IPs, and blocking them by hand becomes a race you lose.
4. Put the site behind a CDN with bot protection
This is where the real difference is made. As long as requests reach your server directly, it has to handle all of them. With a CDN in front, requests reach the network's nodes first:
- pages and files already cached are served by the nodes, without bothering your server;
- bots are recognised and stopped before they reach you;
- the largest network attacks are filtered by the nodes' data centres, which have their own anti-DDoS protection.
With 1PrimeCDN, activation means changing the domain's nameservers, or a single DNS record if you want to keep your DNS where it is. If your domain's record has a short lifetime (TTL), traffic moves within minutes; if it is long, it can take longer. That's why it pays to keep it low even in quiet times.
5. Turn on «under attack» mode
While the attack is running, caching alone may not be enough: many attacks deliberately hit pages that can't be cached, such as search or login.
1PrimeCDN's «under attack» mode sends every visitor through an automatic check: the browser solves a small calculation in about a second and then browses normally for hours. A person sees a waiting screen for a moment; a bot making thousands of requests per second doesn't get through. Verified Google and Bing crawlers still get in, so your search indexing is not affected.
Keep it on only during the attack: it also stops legitimate tools such as social media previews and monitoring services.
6. Close the back door: the server's IP
This step is often forgotten, and it's the one that undoes everything else. If your server's IP address is known, attackers can hit it directly and bypass the CDN.
Once the site goes through the CDN:
- in the server firewall, leave ports 80 and 443 open only to the node addresses;
- check you have no other names (mail, ftp, hosting panel) pointing to the same IP;
- if the attack keeps hitting the server directly, ask your hosting provider for a new IP address and don't publish it anywhere.
We cover this in detail in how to hide your origin server's IP.
7. Keep evidence and never pay a ransom
Save the logs with dates and times, screenshots of the graphs and any threatening emails. A DDoS attack is a crime and can be reported to your national police cybercrime unit.
If someone asks for money to stop the attack, don't pay: there's no guarantee it will stop, and anyone who has paid once becomes a repeat target.
After the attack: stop it happening again
Once things are back to normal, it's time to fix things calmly:
- keep the site behind the CDN permanently, not only in emergencies;
- cache everything you can, so a spike of requests never reaches the server;
- protect sensitive pages (login, search, cart) with request limits;
- keep the TTL of your DNS records low, so you can change route quickly;
- make sure the server only accepts connections from the CDN.
If you're not sure it's an attack, read how to tell if your site is under a DDoS attack. If you're in the middle of an emergency, the «Under attack?» page has a form that alerts our staff immediately.
Want a site that holds up even under attack?
1PrimeCDN puts your site behind 8 European nodes with caching, HTTPS and Shield against bots and attacks. Fixed monthly price from €9.90.