Why DDoS protection is UK only

Answer

Our free DDoS protection is included on our UK network only. That covers our London VPS range, which runs in our Maidenhead, Berkshire data centre. New York plans do not include in-line filtering. If you need mitigation in New York, place HTTP and HTTPS behind Cloudflare, use Spectrum for non‑HTTP protocols, or choose our UK VPS where Arbor filtering is already in front of the network.

Before you start

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

• Locations and naming: London is the product and network name. The servers are in our Maidenhead, Berkshire site. Both terms are correct.
• What is included where: our UK VPS includes in‑line Arbor DDoS filtering. Our New York VPS plans show “Free DDoS Protection (UK only)”. A paragraph further down the New York page mentions in‑line protection, but the plan bullets and our UK spec table are the authoritative detail. Treat New York as not bundled with filtering.
• SLA: our SLA excludes DDoS events from uptime credits. Do not plan around SLA credits for attack time in either location.
• Lockout risk when firewalling: if you enable UFW or firewalld on a remote server without allowing SSH first, you will cut yourself off. Add the SSH rule before enabling, then test in another session before closing your current one.
• Volumetric attacks need upstream mitigation: host‑based tools like UFW, firewalld or fail2ban help with noise and small brute‑force patterns. They cannot absorb a bandwidth‑saturating flood. Use an edge proxy like Cloudflare or host on our UK network where filtering sits in front of your VPS.
• Cloudflare scope: Cloudflare proxies only specific ports for HTTP and HTTPS. Other protocols need Cloudflare Spectrum. Leaving unproxied DNS records exposes your origin IP.
• Firewall backend: Ubuntu 24.04 and AlmaLinux 9 use nftables under the hood. That is normal if you see nftables when you list rules.

Step 1: Confirm what is protected on each network

Read the plan bullets, not the marketing paragraph. Our UK pages state “Free Arbor DDoS protection” and “Free DDoS Protection (UK only)”. The UK detailed spec table also says “DDoS protection … UK network only”. Our New York plans repeat “Free DDoS Protection (UK only)” in their bullets. That means:

• UK (London): in‑line Arbor filtering is included and sits in front of the network.
• New York: no bundled in‑line mitigation. Plan for your own edge protection if you choose this location.

If you need included filtering, choose our London VPS. If your workload must be in New York, read on for practical mitigation you can add yourself.

Step 2: Choose your mitigation route

Decide based on where users are and how sensitive you are to attack noise.

• If included filtering matters most: host in the UK on our London network. You still harden the OS firewall, but the heavy lifting is handled upstream.
• If you must be in New York: put all web traffic behind Cloudflare with proxying enabled. For non‑HTTP protocols use Cloudflare Spectrum. Lock down the origin with a firewall allowlist and Authenticated Origin Pulls so that direct hits cannot bypass the proxy.

Step 3: Put websites behind Cloudflare in New York

This reduces exposure by moving HTTP and HTTPS termination to Cloudflare’s edge. They provide unmetered mitigation for HTTP and HTTPS when proxying is on.

1. Onboard your domain to Cloudflare. You add the zone in Cloudflare, then change nameservers at your registrar to the nameservers Cloudflare gives you. Cloudflare’s onboarding flow explains the steps and applies managed DDoS rules by default.
2. Point web records at your New York VPS and enable proxying. In Cloudflare DNS, create A or AAAA records for your site that resolve to your VPS IP, then set the Proxy status to Proxied. This places Cloudflare in front of your origin.
3. Check port coverage. Cloudflare only proxies HTTP and HTTPS on specific ports. If your app listens on a non‑standard port, use a supported port or expect DNS‑only exposure. See Cloudflare’s port list in their documentation.

Do not leave alternative hostnames that resolve straight to the VPS with proxying off. Attackers scan for those and will target the real IP.

Step 4: Enable Authenticated Origin Pulls and lock down the origin

Authenticated Origin Pulls (AOP) makes Cloudflare present a client certificate when connecting to your server. You then configure your web server to require that certificate. This proves requests passed through Cloudflare, not direct from the internet. Combine AOP with a firewall allowlist of Cloudflare IP ranges so only Cloudflare can reach your web ports.

1. Enable AOP in Cloudflare. Turn on Authenticated Origin Pulls for the zone in the Cloudflare dashboard, then follow Cloudflare’s origin configuration guide for your web server. They provide step‑by‑step instructions for Nginx and Apache, including the certificate you need to trust.
2. Allowlist Cloudflare IP ranges at the origin. Fetch the current list of Cloudflare IPv4 and IPv6 networks from their documentation. Add firewall rules that allow ports 80 and 443 only from those ranges. Leave SSH accessible to you.

Risk: enabling AOP or allowlisting without testing can block all traffic. Enable AOP, add the allowlist rules, reload the firewall, then test from a browser with proxying on before removing any broad “allow http/https” rules.

Step 5: Configure the firewall on Ubuntu 24.04 safely

On Ubuntu we use UFW. The plan is to allow SSH, rate‑limit SSH, allow HTTP and HTTPS only from Cloudflare ranges, then enable the firewall with a default deny policy. Adjust the order if UFW is already active.

5.1 Allow and rate‑limit SSH

This allows SSH and rate‑limits repeated attempts. Run it before enabling UFW to avoid lockout.

sudo ufw limit OpenSSH

5.2 Allow HTTP and HTTPS from Cloudflare ranges

This creates allow rules for web traffic only from Cloudflare networks. Substitute each Cloudflare network for CLOUDFLARE_RANGE and repeat for all ranges in their list.

sudo ufw allow from CLOUDFLARE_RANGE to any port 80 proto tcp
sudo ufw allow from CLOUDFLARE_RANGE to any port 443 proto tcp

Repeat the two commands for every IPv4 and IPv6 range provided by Cloudflare.

5.3 Set a default deny policy

This sets the inbound policy to deny. Existing allow rules still take effect.

sudo ufw default deny incoming

5.4 Enable UFW

This turns UFW on using the rules you have prepared.

sudo ufw enable

5.5 Verify rules

This lists rules and their order so you can confirm that SSH and Cloudflare ranges are present.

sudo ufw status numbered

If you later want to restrict SSH to a fixed management IP, add a more specific rule. For example, to allow SSH only from 203.0.113.10:

sudo ufw delete limit OpenSSH
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp

Keep a second SSH session open while you test so you do not lose access.

Step 6: Configure the firewall on AlmaLinux 9 safely

On AlmaLinux we use firewalld, which manages nftables. The plan is the same: allow SSH with a rate limit, allow HTTP and HTTPS only from Cloudflare ranges, then remove broad http/https services.

6.1 Install and start firewalld if needed

This installs firewalld and ensures it is running at boot.

sudo dnf install -y firewalld
sudo systemctl enable --now firewalld

6.2 Ensure SSH is allowed

This adds the SSH service to the default zone so you do not lock yourself out.

sudo firewall-cmd --permanent --add-service=ssh

6.3 Rate‑limit SSH

This adds a rich rule that accepts SSH but limits the rate to reduce brute‑force noise.

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

6.4 Allow HTTP and HTTPS only from Cloudflare ranges

These rules allow ports 80 and 443 from each Cloudflare network. Replace CLOUDFLARE_RANGE with each range from Cloudflare’s list and repeat for IPv4 and IPv6.

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="CLOUDFLARE_RANGE" port port="80" protocol="tcp" accept'
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="CLOUDFLARE_RANGE" port port="443" protocol="tcp" accept'

Repeat the two commands for every IPv4 range, then add equivalent ipv6 rules for every IPv6 range:

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv6" source address="CLOUDFLARE_RANGE_V6" port port="80" protocol="tcp" accept'
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv6" source address="CLOUDFLARE_RANGE_V6" port port="443" protocol="tcp" accept'

6.5 Remove broad http/https services and reload

These commands remove the general allows for http and https so only Cloudflare can reach the web ports, then reload to apply changes.

sudo firewall-cmd --permanent --remove-service=http
sudo firewall-cmd --permanent --remove-service=https
sudo firewall-cmd --reload

Test in a browser with Cloudflare proxying enabled before you close your current SSH session.

Step 7: Verify Linux SYN cookie protection

SYN cookies help the kernel handle TCP SYN floods. They are enabled by default on modern Ubuntu and AlmaLinux, but it is worth checking.

7.1 Check current setting

This prints the current value. 1 means enabled.

sudo sysctl -n net.ipv4.tcp_syncookies

7.2 Enable if disabled

This enables SYN cookies immediately for the running kernel.

sudo sysctl -w net.ipv4.tcp_syncookies=1

This makes the change persistent across reboots.

echo 'net.ipv4.tcp_syncookies = 1' | sudo tee /etc/sysctl.d/99-syn-cookies.conf > /dev/null
sudo sysctl --system

Step 8: Audit DNS so the origin IP is not exposed

Cloudflare only protects records that are proxied. Leaving any A or AAAA records in DNS with proxying off can reveal your VPS IP. Attackers will use those to reach you directly.

1. Proxy all web hostnames. Ensure every hostname that serves your site is set to Proxied in Cloudflare DNS.
2. Understand mail exposure. MX records remain DNS‑only by design, and SMTP is not proxied by Cloudflare unless you use Spectrum. If mail runs on the same VPS, MX will reveal that IP.
3. Protect the origin with the firewall. Even if an IP leaks, your allowlist on ports 80 and 443 means direct web traffic will not reach the app. That is the point of combining AOP with allowlisting.

Step 9: Protect non‑HTTP and game services with Cloudflare Spectrum

If your workload in New York is not HTTP or HTTPS, Cloudflare Spectrum can act as a reverse proxy for TCP and UDP, provide L3 and L4 DDoS protection, and hide your origin. You create a Spectrum application for the hostname and port, point it at your VPS, and keep the DNS record proxied. Then allowlist Cloudflare ranges to the service port on your server firewall. Spectrum is separate from the standard HTTP proxy and is required for protocols like SSH, custom TCP services or many game servers.

Step 10: Good practice on the UK network too

On our UK network the Arbor filtering removes a large amount of attack traffic before it reaches your VPS. It is still worth keeping a tidy firewall, rate‑limiting SSH and checking SYN cookies as above. The same UFW and firewalld steps apply, except you do not need to allowlist Cloudflare unless you are using it for other reasons.

What next

• If you want included network‑level mitigation, see our London VPS. That range includes in‑line Arbor DDoS filtering on the UK network.
• For more server administration topics, browse our VPS guides.
• If you are unsure which route fits your workload or you need help applying firewall rules on a Hostworld VPS, open a support ticket and we will take a look with you.