What DDoS protection covers, and what it does not

What DDoS protection covers, and what it does not

Hostworld’s UK VPS network includes always‑on, in‑line DDoS filtering on UK IP space. It automatically filters volumetric network floods before they reach your VPS. It does not stop application‑level request floods or performance problems caused by your own code. This guide explains what is covered, what is not, and what you should configure on the server.

This picks up from a server you can already reach over SSH.

Before you start

• Hostworld’s DDoS protection applies to UK IP space. It is always on and in‑line. If your VPS uses a UK IP, it benefits from this filtering. If it does not, it will not.
• Have console access ready. If you misconfigure the firewall and lose SSH, use the VNC console in Virtualizor from the Hostworld client area to recover.
• Plan firewall changes to avoid locking yourself out. Always allow SSH before enabling a firewall and confirm you can still connect from your current IP.
• Ubuntu 24.04 note: OpenSSH uses systemd socket activation by default. If you change the SSH port, you may also need to adjust or disable ssh.socket, not only sshd_config. If you skip that, SSH can look down even though the daemon is configured on the new port.
• AlmaLinux 9 note: the default firewall stack is firewalld with an nftables backend. Do not mix legacy iptables rules with firewalld. They can conflict and produce unexpected results.
• firewalld has runtime and permanent configs. A reload makes runtime equal to permanent. Runtime‑only changes are lost on reload unless you first persist them.
• Use rate‑limits with care. Over‑aggressive limits on SSH or web traffic can throttle legitimate users and look like intermittent outages.
• firewalld panic mode drops all traffic. Use it only if you have console or out‑of‑band access.
• UFW reset wipes rules and disables UFW. On a remote system that can expose services or cut access until rebuilt.

Step 1: Understand what our network‑level DDoS protection covers

Our UK network uses always‑on in‑line filtering to mitigate volumetric L3 and L4 attacks. These are floods intended to saturate bandwidth or overwhelm network stacks long before the application layer. Common examples are UDP amplification attacks that bounce tiny requests off open services on the internet to generate huge replies at your IP. Vectors include DNS, NTP, CLDAP, Memcached and SSDP. The in‑line filter is built for this type of attack and drops that junk before it reaches your VPS interface.

What this means in practice:

• Bandwidth saturation from large floods is filtered upstream on the UK range.
• SYN floods and other basic TCP floods are rate‑limited or scrubbed at the network edge.
• You do not have to toggle anything in your panel for this to work on UK IPs.

What it does not do:

• It does not fully stop application‑layer (L7) attacks that look like normal requests. Examples: HTTP GET floods and slow‑HTTP variants such as slowloris. These need application‑aware controls like web‑server rate‑limits or a WAF.
• It does not fix resource exhaustion that your own code causes. For example, an inefficient script that hammers your database will still run you out of connections. You might see “Too many connections” from MySQL or MariaDB. That is an application or database tuning problem, not a DDoS event.

Step 2: Enable a host firewall and rate‑limit SSH

The goal here is to control what reaches your services and to slow down brute‑force attempts on SSH. The upstream filter handles floods on the wire. Your firewall sets policy on the node itself.

On Ubuntu 24.04 using UFW

• Check UFW status. This reports whether UFW is active and which rules are loaded.

sudo ufw status verbose

• Set a default stance that denies new incoming connections and allows all outgoing. This creates a sensible baseline before you open specific ports.

sudo ufw default deny incoming
sudo ufw default allow outgoing

• Allow and rate‑limit SSH on port 22. The “limit” action allows connections but rate‑limits repeated attempts from the same source address.

sudo ufw limit 22/tcp

• Allow web traffic if you run a website on the VPS. These rules permit HTTP and HTTPS.

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

• Enable UFW. This activates the firewall with the rules you set.

sudo ufw enable

• Review the result. This confirms the rules, including the SSH rate‑limit.

sudo ufw status numbered

Always confirm you can still SSH in from a separate session before you log out of your current one.

On AlmaLinux 9 using firewalld

• Check whether firewalld is running. This tells you if the firewall service is active.

sudo firewall-cmd --state

• Add a rate‑limited rule for SSH. This rich rule accepts SSH with a cap of three new connections per minute from a source address. It is added to the permanent configuration.

sudo firewall-cmd --permanent --add-rich-rule='rule service name=ssh limit value=3/m accept'

• Allow web traffic if you host a site. These rules permit HTTP and HTTPS in the permanent configuration.

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https

• Reload firewalld so permanent rules are applied at runtime.

sudo firewall-cmd --reload

• List the active zone to confirm the rules and their permanence. This shows services and rich rules now in effect.

sudo firewall-cmd --list-all
sudo firewall-cmd --list-rich-rules

Notes for AlmaLinux 9:

• Do not add legacy iptables rules on a system managed by firewalld. The nftables backend and legacy tools can clash.
• Understand runtime versus permanent. If you test a rule without the --permanent flag, it will be lost on reload unless you persist it before reloading.
• Panic mode drops all traffic immediately. Only use it if you have console access through Virtualizor VNC, because SSH will be cut off.

Step 3: Harden the kernel networking behaviour

Basic kernel‑level hardening improves resilience to spoofing and connection floods. Two settings are worth enabling: TCP SYN cookies and reverse path filtering.

On Ubuntu 24.04

• Create a sysctl snippet that enables SYN cookies and rp_filter, then load it. This writes a small configuration file and applies it across the system.

sudo tee /etc/sysctl.d/60-hostworld-network.conf > /dev/null <<'EOF'
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
EOF
sudo sysctl --system

SYN cookies help the kernel handle bursts of connection attempts without exhausting the backlog. Reverse path filtering drops packets with spoofed source addresses. Tuning should avoid forcing SYN cookies under normal expected load.

On AlmaLinux 9

• Create the same sysctl snippet and load it. This persists the settings and applies them immediately.

sudo tee /etc/sysctl.d/60-hostworld-network.conf > /dev/null <<'EOF'
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
EOF
sudo sysctl --system

Step 4: Add application‑layer rate‑limits for web traffic (NGINX example)

Application‑layer floods are made of requests that look valid. They are not blocked by network‑layer filtering. Your web server should enforce its own limits so that a spike in requests does not consume all worker time or connections.

The example below adds per‑IP request and connection limits with modest defaults. Adjust them for your workload after testing. Aggressive values can throttle real users.

On Ubuntu 24.04 and AlmaLinux 9 (NGINX configuration)

• Define shared zones for limits. This sets a request rate per IP and a connection cap per IP.

# Add inside http { ... } in /etc/nginx/nginx.conf
limit_req_zone $binary_remote_addr zone=req_per_ip:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=conn_per_ip:10m;

• Apply the limits to your server block. This enforces a burst‑tolerant request limit and caps concurrent connections.

# Add inside your server { ... } block
location / {
    # Allow short bursts, then sustain 10 requests per second per IP
    limit_req zone=req_per_ip burst=20 nodelay;
    try_files $uri $uri/ =404;
}
# Cap concurrent connections per IP
limit_conn conn_per_ip 20;

• Test the configuration and reload NGINX. The test checks for syntax errors. The reload applies changes without dropping connections.

sudo nginx -t
sudo systemctl reload nginx

NGINX provides other controls that help in front of upstreams or applications, including timeouts and buffering. Start with conservative limits, monitor, then tune.

Step 5: Reduce brute‑force and noisy clients at the application level

Upstream filtering does not replace application hardening. Two common additions are worth knowing about:

• fail2ban: watches logs for repeated failures, then adds a temporary block. For example, it can ban repeated failed SSH logins. This complements SSH rate‑limits at the firewall. If you use fail2ban, enable the sshd filter and set thresholds that reflect your use. It should not replace strong authentication and keys.
• Database hygiene: floods of slow or inefficient queries can collapse your database under traffic. “Too many connections” is a resource signal, not a DDoS verdict. Raising max_connections without fixing queries will not help for long. Profile slow queries and fix the worst offenders first.

Step 6: Know when to ask for help

If you suspect an attack that you cannot stabilise with the steps above, or you think traffic is still saturating a UK IP, open a ticket so we can check from our side. Scrubbing happens upstream of your VPS, so we can see details you cannot from the guest OS.

You can open a support ticket. Include your VPS hostname, IP, recent changes and exact symptoms or timestamps.

What next

You now know what Hostworld’s DDoS protection handles for you on the UK range, and what you still need to configure on the VPS. If you want to explore more operational hardening and networking topics, browse our VPS guides. If you are planning a new deployment or want to place workloads on our UK network, see our Linux VPS plans.

If you are stuck at any point, or your VPS becomes unreachable during firewall work, use the Virtualizor VNC console from your client area to sign in and undo the last change. If you need us to look, please open a support ticket.