Understanding Anti-DDoS protection and limiting the impact of an attack

A distributed denial-of-service (DDoS) attack tries to make a service unreachable by flooding it with traffic. Game servers, shops and community websites are frequent targets, sometimes for a few euros paid by a competitor or a banned player. This guide explains how the protection included with our services works, and what you can do on your side.

1. The three families of attacks

Volumetric attacks are the most spectacular, but also the easiest to recognise. Application attacks are more discreet: each request looks like one from an ordinary visitor.

2. How our protection works

Our Anti-DDoS protection relies on GCore's infrastructure, with a capacity of 200 Tbps, and works on three levels, active by default on every service:

• Volumetric absorption: attack traffic is absorbed and filtered on the network before it reaches your server.
• Protocol filtering: abnormal TCP and UDP sessions are dropped, SYN floods neutralised and amplification blocked upstream.
• Application inspection: for web traffic, suspicious requests go through checks that tell bots apart from real visitors.

Detection and filtering are automatic: there is nothing to enable, and legitimate traffic keeps flowing during the attack. No configuration is needed on your side to benefit from the network protection.

3. What network protection cannot do

Let us be clear about the limits, so you can compensate for them:

• It does not fix a slow application. If a page on your site takes two seconds to generate, a handful of requests, even legitimate ones, is enough to saturate the server. Caching is your best defence: see optimising PHP-FPM and the Nginx cache.
• It does not replace server security. A brute-force attack on SSH or on a login form is not a DDoS: that is the job of hardened SSH and Fail2ban.
• It only protects the address it covers. If your application depends on a service hosted elsewhere, such as an external database or API, that service remains vulnerable.

4. Limit abuse in Nginx

Against application-level abuse, limit the number of requests and connections per address. Declare the zones in the http block, for example in /etc/nginx/conf.d/limits.conf:

limit_req_zone  $binary_remote_addr zone=pages:10m rate=10r/s;
limit_req_zone  $binary_remote_addr zone=login:10m rate=5r/m;
limit_conn_zone $binary_remote_addr zone=conn:10m;
limit_req_status 429;

Then apply them in the site's server block:

limit_conn conn 20;
location / {
    limit_req zone=pages burst=20 nodelay;
    try_files $uri $uri/ /index.php?$args;
}
location = /wp-login.php {
    limit_req zone=login burst=3 nodelay;
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

Each address can make 10 requests per second with a burst of 20, and 5 login attempts per minute. Adjust these values to your real traffic: too strict, and they get in the way of visitors sharing one address, such as a company or school network. Excess requests are logged, and Fail2ban's nginx-limit-req jail can ban repeat offenders.

5. Do not expose the origin address

If your site goes through a proxy such as Cloudflare, the benefit disappears as soon as the server's real address is known: the attacker then targets the VPS directly. That address often leaks through an unprotected subdomain, the headers of emails sent by the server, or DNS history. See Cloudflare in front of a VPS. The network protection on our VPS covers the origin address in every case.

6. Game servers

Game servers mostly use UDP, which web proxies do not relay: the network protection does all the work. A few good practices make it more effective:

• Only open the ports the game actually uses, specifying the protocol: see configuring UFW.
• Restrict admin consoles (RCON, txAdmin) to your IP address or to a WireGuard VPN.
• Do not publish the server's raw IP address on your Discord if you can use a domain name.

For a turnkey game server, already protected and optimised, see our FiveM servers.

7. During an attack

If your service slows down or becomes unreachable, start by telling an attack apart from a resource problem:

uptime                              # CPU load
ss -s                               # number of open connections
ss -tn state established | awk 'NR>1 {sub(/:[0-9]+$/, "", $4); print $4}' | sort | uniq -c | sort -rn | head   # connections per remote address
tail -n 200 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head   # most active addresses

• A handful of addresses account for most requests: that is application abuse; block them or tighten the Nginx limits.
• The server is quiet but unreachable: the problem is upstream. Contact support with the start time, the affected service and the IP address concerned.
• CPU or memory is saturated with no abnormal traffic: it is not an attack; see monitoring your VPS.

Frequently asked questions