How DDoS protection works on your server

Every DediJet server includes always-on, network-level DDoS mitigation at no extra cost. There is nothing to install or switch on: attacks are detected automatically and filtered upstream, before the traffic reaches your server’s port. This page explains what the protection covers, what it does not, and how to make your own services harder to knock over.

How the mitigation works

Traffic entering our network is analyzed continuously. When an attack against one of your addresses is detected, its traffic is filtered upstream: packets that match attack patterns are dropped, and legitimate packets continue to your server. Mitigation starts automatically, without a ticket or any manual step.

We filter rather than null-route whenever possible. A null route, which drops all traffic to one IP address, remains a last resort.

What is filtered

The mitigation targets layer 3 and layer 4 attacks, which try to exhaust bandwidth or connection state and can be recognized from packet characteristics alone:

What it does not stop: HTTP floods

Application-layer (layer 7) attacks send requests that look valid: complete TCP connections and correct HTTP, often from many real infected devices. A network filter cannot tell them apart from your visitors, so protecting applications is your responsibility, and application-layer attacks are excluded from the SLA. What works:

• A reverse proxy, CDN or WAF in front of public websites. Once it is in place, accept HTTP and HTTPS only from the proxy’s address ranges, so attackers cannot bypass it by targeting your IP directly.
• Caching, so repeated requests never reach your application and database.
• Rate limits per client address, and short timeouts against slow-request attacks.

A starting point for nginx. Define the zones in the http context, for example in /etc/nginx/conf.d/limits.conf:

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=connperip:10m;
limit_req_status 429;
client_header_timeout 10s;
client_body_timeout 10s;

Then apply them where you need them:

location / {
    limit_req zone=perip burst=20 nodelay;
    limit_conn connperip 20;
    proxy_pass http://127.0.0.1:8080;
}

Tune rate and burst to your real traffic: a page that loads 40 assets needs a larger burst than an API endpoint. Behind a CDN, restore the visitor’s address first with the real IP module (set_real_ip_from, real_ip_header); otherwise every request seems to come from the proxy and the limits hit everyone at once.

What you may notice during an attack

Mitigation is automatic and needs nothing from you. When an attack starts, you may notice a brief increase in latency, or players on a game server a short lag spike, while filtering engages. Rebooting or reinstalling does not help: the traffic targets your IP address, not the operating system.

What to do if you suspect an attack

1. Do not reboot repeatedly. A reboot does not stop traffic aimed at your address; it disconnects your legitimate users and makes diagnosis harder. Check the status page for network-wide incidents.

2. Check the path from outside. Run mtr from your own computer towards the server, and from the server towards your computer:

   Shell

   mtr -rwzc 100 203.0.113.10

   Loss that starts at one hop and continues to the last hop is real. Loss shown only on an intermediate hop is usually ICMP rate limiting by that router. See network testing for details.

3. Check the server itself. A busy application can look like an attack. Compare load and connection counts with your usual values:

   Shell

   uptime
   ss -s
   ss -tn state syn-recv | wc -l

4. Open a ticket. If the server is unreachable, mark it critical: our first-response target for critical issues is 30 minutes. Include the affected IP addresses, start and end times with the time zone (UTC is easiest), what you observe (loss, latency, which ports or services), your mtr reports in both directions and, if you can, a short packet capture:

   Shell

   tcpdump -ni any -c 2000 -w /root/attack.pcap

Game servers and UDP

Most game servers speak UDP, which makes them frequent targets. UDP floods and amplification attacks are filtered at the network level before they reach your port; the rest depends on your configuration:

• Open only the game ports you use, and restrict admin ports (RCON, web panels, databases) to your own addresses.
• Keep the server software updated: recent versions of popular engines add challenge-response checks to query packets, so they cannot be used for reflection.
• Write down the time, server address and what players saw when you report lag: reports without timestamps are hard to trace.

More tips for hosting games are on Game servers.

Don’t become an amplifier yourself

Amplification attacks rely on misconfigured servers. Make sure yours is not one of them; our acceptable use policy forbids open DNS and NTP resolvers left exposed to the internet.

• List UDP listeners with ss -ulpn and close everything you do not serve on purpose.
• DNS: a recursive resolver must answer only your own networks (access-control in Unbound, allow-recursion in BIND).
• NTP: chrony serves time to other machines only with an allow directive; leave it out unless you need it.
• Memcached: bind it to 127.0.0.1 and keep UDP disabled (-U 0).
• SSDP and CLDAP: media servers with UPnP and Active Directory domain controllers should never answer on a public address.

Still stuck?

• Close the rest of the attack surface with Harden a new server.
• Read how our network is built on Network & DDoS protection.
• Under attack and unsure what you see? Open a ticket: DDoS mitigation is in scope for 24/7 support.