Do I need DDoS protection on a dedicated server?

What is DDoS protection, and which attacks does it stop?

DDoS protection is filtering placed upstream of your server: it drops attack traffic before that traffic reaches your network port. A distributed denial-of-service (DDoS) attack sends traffic from many machines at once to exhaust a link, a firewall or an application. Attacks fall into two groups:

• Network-layer attacks (layers 3 and 4). Floods of packets: SYN floods, ACK floods, UDP and ICMP floods, and reflection attacks such as DNS or memcached amplification. Volumetric floods try to fill the link itself, so only filtering before the link helps.
• Application-layer attacks (layer 7). Floods of real-looking HTTP requests, cache-busting requests, or slow connections such as Slowloris. They need little bandwidth. They exhaust CPU, web workers or the database instead.

Cloudflare's documentation lists these vectors under two managed rulesets: one for the network layer, one for HTTP. A server can fight off some layer 7 floods on its own, but never a flood larger than its uplink.

What is the difference between always-on and on-demand protection?

Always-on protection inspects your traffic all the time; on-demand protection reroutes your traffic to a scrubbing network only once an attack starts. Scrubbing means sending traffic through a filtering network that drops attack packets and forwards the clean rest to you.

• Always-on. No switch-over delay, but every packet takes the filter's path. A CDN or reverse proxy in front of a website works this way.
• On-demand. Traffic flows straight to you until an attack, then the provider announces your IP prefix from its own network. Cloudflare's Magic Transit on-demand mode turns that advertisement on during an attack and off afterwards. Until the switch, the attack reaches you.

For one rented server, always-on filtering in front of each public service is the practical choice.

Who needs DDoS protection on a dedicated server, and who doesn't?

You need it when strangers know your IP address and have a reason to knock the service offline. You can usually skip it when only you, and people you trust, connect to the machine.

Does Ironatoll protect my dedicated server against DDoS attacks?

Ironatoll sells bare metal, not a filtered network. The rule, word for word: Against DDoS attacks we promise nothing beyond the default handling of the datacenter network. We publish no mitigation capacity, no filtering scope and no response time, because we promise none.

That keeps plans cheap, and it makes a public UDP service your project to protect. For filtered game traffic, put a filtering service in front of the server. Or pick a host that sells mitigation with written numbers. Our ranking of offshore dedicated server providers compares hosts on the same criteria.

According to Ironatoll's check of 30 October 2026, a dedicated server comparable to Atoll 64 cost a median $337.49 at 14 hosts that accept crypto without ID; Ironatoll charges $72.62. That 78% gap leaves room for a CDN plan or a filtered proxy. Every plan is listed on how much an Ironatoll dedicated server costs.

How do I protect a website on a dedicated server from DDoS?

Put a reverse proxy or CDN in front of the website, then hide the server's real IP address. Cloudflare is one option. These points come from its documentation, read on 30 October 2026:

• DDoS protection comes with every Cloudflare plan, the free plan included. Cloudflare lists it as standard, unmetered protection for layers 3 to 7.
• Only proxied records are protected. Proxying works on A, AAAA and CNAME records and covers HTTP and HTTPS traffic. A DNS-only record shows your origin IP to anyone who queries it.
• Proxied web traffic uses fixed ports. HTTP: 80, 8080, 8880, 2052, 2082, 2086 and 2095. HTTPS: 443, 2053, 2083, 2087, 2096 and 8443.
• Accept web traffic from Cloudflare only. Cloudflare publishes its ranges at cloudflare.com/ips and advises blocking everything else at the origin. An attacker who finds the real IP, in old DNS records or mail settings, can hit the server directly.
• Other protocols need Spectrum. SSH, game ports and other TCP or UDP services are not covered by a proxied record. Spectrum for every TCP and UDP port is on the Enterprise plan only.

Each Ironatoll server has one IPv4 address, so a DNS-only record pointing at it, such as a mail record, reveals the origin.

How do I rate-limit connections with nftables?

nftables can cap new connections per source address, which blunts small floods and brute-force attempts, but it cannot stop a flood that fills your link. By the time nftables sees a packet, the packet has already used your bandwidth.

The nftables wiki keeps one rate limiter per source IP in a dynamic set. Each entry expires after 60 seconds without traffic. The ruleset below applies that idea to SSH, accepts web traffic and drops the rest. Behind Cloudflare, accept ports 80 and 443 from a set of its published ranges only. Load it with nft -f /etc/nftables.conf, keep a second SSH session open, then run systemctl enable nftables. The SSH limit covers IPv4; add an ipv6_addr set with ip6 saddr for IPv6.

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  set ssh_meter {
    type ipv4_addr
    timeout 60s
    flags dynamic
  }

  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    meta l4proto ipv6-icmp accept
    icmp type echo-request limit rate 10/second accept
    tcp dport 22 ct state new update @ssh_meter { ip saddr limit rate 10/minute } accept
    tcp dport { 80, 443 } accept
  }
}

# http block
limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;

server {
    location / {
        limit_req zone=perip burst=20 nodelay;
    }
}

What else lowers the risk without buying anything?

Give attackers less to see:

• Close every port you do not serve. A Proxmox web interface, a database or an LLM API belongs behind an SSH tunnel.
• Keep private services off the machine that runs public ones. A flood against a game server takes down everything sharing its link.
• Never publish the origin IP of a proxied website, in DNS history or in mail headers.

Our dedicated server or VPS comparison explains when bare metal is worth it for a public service.