How to protect a VPS from DDoS attacks

A distributed denial-of-service (DDoS) attack floods a server or its network connection with traffic until real visitors cannot get through. Some attacks are too large for the server itself to handle, so protection works best in layers: filtering at the network edge first, then firewall and application settings on the VPS. ONIE protects cloud servers in Ho Chi Minh City with DDoS Shield at the network edge at no extra charge, and you can deploy a VPS with DDoS protection in a few minutes.

Types of attacks

• Volumetric (layer 3 and 4): floods of packets that fill the network link, for example UDP floods.
• Protocol attacks: abuse of connection handling, such as SYN floods that fill the connection table.
• Application layer (layer 7): many valid-looking HTTP requests that exhaust the web server or database.

Each type needs a different defence. Volumetric traffic must be stopped before it reaches your server; application floods can be reduced on the server.

1. Filter at the network edge

Edge filtering drops bad traffic before it reaches your VPS, so the link is not saturated. With DDoS Shield, filtering runs at the network edge using XDP/eBPF, and the console shows traffic and attack events for each IP. Ask any provider you evaluate what is included, where filtering happens and whether it costs extra.

2. Close what you do not use

sudo ufw default deny incoming
sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable

Do not expose databases or admin panels to the internet. Bind them to 127.0.0.1 or a private network.

3. Tune the kernel for SYN floods

SYN cookies are on by default in most distributions. Check:

sysctl net.ipv4.tcp_syncookies

Keep other kernel changes small and test them, because wrong values can hurt normal traffic.

4. Rate-limit requests in Nginx

In the http block:

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

In the server or location block:

limit_req zone=perip burst=20 nodelay;
limit_conn connperip 20;

Reload with sudo nginx -t && sudo systemctl reload nginx. Serve static files from cache and use a caching plugin on WordPress to lower the cost of each request. See installing WordPress with Nginx.

5. Monitor traffic

ss -s
sudo ss -ntu state established | wc -l
sudo apt install -y nload && nload

A sudden jump in connections or bandwidth, or a server that becomes slow with low CPU use, can mean an attack. Set alerts so you notice early.

6. Incident checklist

1. Confirm in the console whether the traffic is an attack or a real spike.
2. Check the attack events and the attacked IP.
3. Block abusive source addresses or ranges you can identify.
4. Turn on stricter rate limits or a maintenance page.
5. Contact your provider's support with the time and the IP.
6. Afterwards, review logs and update this plan. Keep backups and snapshots current.