Brauche ich DDoS-Schutz auf einem dedizierten Server?

Was ist DDoS-Schutz, und welche Angriffe stoppt er?

DDoS-Schutz ist Filterung, die vorgelagert vor Ihrem Server sitzt: Sie verwirft Angriffsverkehr, bevor dieser Verkehr Ihren Netzwerk-Port erreicht. Ein Distributed-Denial-of-Service-Angriff (DDoS) sendet Verkehr von vielen Maschinen gleichzeitig, um eine Leitung, eine Firewall oder eine Anwendung zu überlasten. Angriffe fallen in zwei Gruppen:

• Angriffe auf der Netzwerkschicht (Layer 3 und 4). Paketfluten: SYN-Floods, ACK-Floods, UDP- und ICMP-Floods sowie Reflection-Angriffe wie DNS- oder memcached-Amplification. Volumetrische Floods versuchen, die Leitung selbst zu füllen, daher hilft nur Filterung vor der Leitung.
• Angriffe auf der Anwendungsschicht (Layer 7). Fluten von echt aussehenden HTTP-Anfragen, Cache-Busting-Anfragen oder langsame Verbindungen wie Slowloris. Sie brauchen wenig Bandbreite. Stattdessen überlasten sie CPU, Web-Worker oder die Datenbank.

Die Dokumentation von Cloudflare listet diese Vektoren unter zwei verwalteten Regelsätzen auf: einen für die Netzwerkschicht, einen für HTTP. Ein Server kann manche Layer-7-Floods allein abwehren, aber niemals eine Flut, die größer ist als seine Uplink-Anbindung.

Was ist der Unterschied zwischen Always-on- und On-Demand-Schutz?

Always-on-Schutz prüft Ihren Verkehr die ganze Zeit; On-Demand-Schutz leitet Ihren Verkehr erst dann in ein Scrubbing-Netzwerk um, wenn ein Angriff beginnt. Scrubbing bedeutet, Verkehr durch ein Filter-Netzwerk zu schicken, das Angriffspakete verwirft und den sauberen Rest an Sie weiterleitet.

• Always-on. Keine Umschaltverzögerung, aber jedes Paket nimmt den Weg durch den Filter. Ein CDN oder Reverse-Proxy vor einer Webseite funktioniert so.
• On-Demand. Verkehr fließt direkt zu Ihnen, bis ein Angriff kommt; dann kündigt der Anbieter Ihr IP-Präfix aus seinem eigenen Netzwerk an. Der On-Demand-Modus von Cloudflare Magic Transit schaltet diese Ankündigung während eines Angriffs ein und danach wieder aus. Bis zum Umschalten erreicht der Angriff Sie.

Für einen einzelnen gemieteten Server ist Always-on-Filterung vor jedem öffentlichen Dienst die praktische Wahl.

Wer braucht DDoS-Schutz auf einem dedizierten Server, und wer nicht?

Sie brauchen ihn, wenn Fremde Ihre IP-Adresse kennen und einen Grund haben, den Dienst offline zu bringen. Sie können ihn in der Regel überspringen, wenn nur Sie und Personen, denen Sie vertrauen, sich mit der Maschine verbinden.

Schützt Ironatoll meinen Dedicated Server vor DDoS-Angriffen?

Ironatoll verkauft Bare Metal, kein gefiltertes Netzwerk. Die Regel, wörtlich: Gegen DDoS-Angriffe versprechen wir nichts über die Standardbehandlung des Rechenzentrumsnetzwerks hinaus. Wir veröffentlichen keine Mitigation-Kapazität, keinen Filterumfang und keine Reaktionszeit, weil wir nichts davon zusagen.

Das hält die Tarife günstig, und es macht einen öffentlichen UDP-Dienst zu Ihrem eigenen Schutzprojekt. Für gefilterten Spielverkehr setzen Sie einen Filterdienst vor den Server. Oder wählen Sie einen Hoster, der Mitigation mit schriftlichen Zahlen verkauft. Unser Ranking der Offshore-Dedicated-Server-Anbieter vergleicht Hoster nach denselben Kriterien.

Laut der Prüfung von Ironatoll zu 30 October 2026 kostete ein Dedicated Server, vergleichbar mit Atoll 64, einen Median von $337.49 bei 14 Hosts, die Krypto ohne Ausweis akzeptieren; Ironatoll verlangt $72.62. Diese Differenz von 78% lässt Spielraum für einen CDN-Tarif oder einen gefilterten Proxy. Alle Tarife stehen unter wie viel ein Dedicated Server von Ironatoll kostet.

Wie schütze ich eine Webseite auf einem Dedicated Server vor DDoS?

Setzen Sie einen Reverse Proxy oder ein CDN vor die Webseite und verbergen Sie dann die echte IP-Adresse des Servers. Cloudflare ist eine Option. Diese Punkte stammen aus der Dokumentation, gelesen am 30. Oktober 2026:

• DDoS-Schutz ist in jedem Cloudflare-Tarif enthalten, auch im kostenlosen Tarif. Cloudflare führt ihn als standardmäßigen, unbegrenzten Schutz für die Layer 3 bis 7.
• Nur proxied Records sind geschützt. Das Proxying funktioniert bei A-, AAAA- und CNAME-Records und deckt HTTP- und HTTPS-Verkehr ab. Ein DNS-only Record zeigt Ihre Origin-IP jedem, der danach fragt.
• Proxied Web-Verkehr nutzt feste Ports. HTTP: 80, 8080, 8880, 2052, 2082, 2086 und 2095. HTTPS: 443, 2053, 2083, 2087, 2096 und 8443.
• Akzeptieren Sie Web-Verkehr nur von Cloudflare. Cloudflare veröffentlicht seine Ranges unter cloudflare.com/ips und rät, am Origin alles andere zu blockieren. Ein Angreifer, der die echte IP in alten DNS-Records oder Mail-Einstellungen findet, kann den Server direkt treffen.
• Andere Protokolle brauchen Spectrum. SSH, Spielports und andere TCP- oder UDP-Dienste sind nicht durch einen proxied Record abgedeckt. Spectrum für jeden TCP- und UDP-Port gibt es nur im Enterprise-Tarif.

Jeder Ironatoll-Server hat eine IPv4-Adresse, daher verrät ein DNS-only Record, der darauf zeigt, etwa ein Mail-Record, den Origin.

Wie begrenze ich Verbindungen mit nftables per Rate Limit?

nftables kann neue Verbindungen pro Quelladresse begrenzen, was kleine Floods und Brute-Force-Versuche abmildert, aber einen Flood, der Ihre Leitung füllt, kann es nicht stoppen. Wenn nftables ein Paket sieht, hat das Paket Ihre Bandbreite bereits verbraucht.

Das nftables-Wiki führt einen Rate Limiter pro Quell-IP in einem dynamischen Set. Jeder Eintrag läuft nach 60 Sekunden ohne Verkehr ab. Das unten stehende Ruleset wendet diese Idee auf SSH an, akzeptiert Web-Verkehr und verwirft den Rest. Hinter Cloudflare akzeptieren Sie die Ports 80 und 443 nur aus einem Set der veröffentlichten Ranges. Laden Sie es mit nft -f /etc/nftables.conf, halten Sie eine zweite SSH-Sitzung offen und führen Sie dann systemctl enable nftables aus. Das SSH-Limit deckt IPv4 ab; fügen Sie ein ipv6_addr-Set mit ip6 saddr für IPv6 hinzu.

#!/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;
    }
}

Was senkt das Risiko sonst noch, ohne dass ich etwas kaufen muss?

Geben Sie Angreifern weniger zu sehen:

• Schließen Sie jeden Port, den Sie nicht bedienen. Eine Proxmox-Weboberfläche, eine Datenbank oder eine LLM-API gehört hinter einen SSH-Tunnel.
• Halten Sie private Dienste fern von der Maschine, die öffentliche Dienste ausführt. Ein Flood gegen einen Spielserver reißt alles mit, was sich seine Leitung teilt.
• Veröffentlichen Sie nie die Origin-IP einer proxied Webseite, weder in der DNS-Historie noch in Mail-Headern.

Unser Vergleich Dedicated Server oder VPS erklärt, wann sich Bare Metal für einen öffentlichen Dienst lohnt.