Schwerer DDoS-Angriff: was jetzt zu tun ist

Ein Angriff, der nach zehn Minuten vorbei ist, ist ärgerlich. Einer, der seit Tagen jeden Abend zur selben Zeit wiederkommt, ist etwas anderes: Dann ist Ihr Server kein Zufallsziel mehr. Dieser Beitrag zeigt, was jetzt zu tun ist, was Sie ohne Zusatzkosten selbst absichern können und wo diese Maßnahmen enden.

Alle Befehle beziehen sich auf Debian 12, Debian 13, Ubuntu 22.04 LTS und Ubuntu 24.04 LTS und sind für root geschrieben, als normaler Benutzer stellen Sie sudo voran. Was ein DDoS-Angriff technisch ist, erklärt der Beitrag Was ist ein DDoS-Angriff?.

Solange der Angriff läuft: nicht neu starten und nicht die halbe Konfiguration umbauen. Ein Neustart löscht genau die Zähler, die Sie für die Meldung an Ihren Anbieter brauchen, und der Angriff kommt danach unverändert zurück.

Warum ausgerechnet Ihr Server so hartnäckig angegriffen wird

Server, die über Wochen beschossen werden, haben fast immer dieselben drei Eigenschaften. Erstens veröffentlichen sie ihre Adresse selbst: in einer Serverliste, in einem Discord, über einen DNS-Eintrag. Zweitens ist ihre Nutzung an feste Zeiten gebunden, ein Ausfall um 20 Uhr ist also maximal sichtbar. Drittens gibt es jemanden, dem dieser Ausfall etwas wert ist: ein konkurrierendes Projekt, einen gebannten Spieler, einen verärgerten Kunden.

Technisch kommt hinzu, dass viele der betroffenen Dienste über UDP laufen. UDP kennt keinen Verbindungsaufbau, den man verlangen könnte, und Absenderadressen lassen sich fälschen. Ein Angreifer muss Ihren Dienst also weder betreten noch korrekt ansprechen, um Last zu erzeugen. Bei TCP-Diensten belegen stattdessen halb geöffnete Verbindungen Ressourcen, ohne je abgeschlossen zu werden.

Die Ports, um die es tatsächlich geht

Ein Angriff trifft nicht "den Server", sondern einen Port. Die folgende Übersicht nennt die Standardports der am häufigsten beschossenen Dienste und ist zugleich Ihre Prüfliste: Alles, was hier nicht vorkommt und trotzdem offen ist, gehört geschlossen.

Eine zweite Gruppe taucht nicht als Ziel auf, sondern als Quelle: 53 (DNS), 123 (NTP), 389 (CLDAP), 1900 (SSDP), 11211 (memcached) und ebenfalls 27015. Überwiegen diese Quellports, ist es ein Reflexions- und Verstärkungsangriff. Die Absender sind dann unbeteiligte, schlecht konfigurierte Server, weshalb das Sperren einzelner Adressen ins Leere läuft.

Was Sie selbst tun können, bevor Sie Geld ausgeben

Dieser Abschnitt ist der längste, und das mit Absicht: Ein sauber konfigurierter Server hält kleine und mittlere Angriffe aus eigener Kraft aus und liefert im Ernstfall die Messwerte für die nächste Stufe.

1. Die ersten Minuten: messen statt schrauben

Bevor Sie etwas ändern, halten Sie fest, was gerade passiert. Vier Werte genügen: eingehende Paketrate, Zustandsverteilung der Verbindungen, Kernelmeldungen und die Frage, ob der Dienst lokal noch antwortet.

IF=$(ip -o route get 1.1.1.1 | awk '{print $5}')
A=$(cat /sys/class/net/$IF/statistics/rx_packets) || exit 1; sleep 1; B=$(cat /sys/class/net/$IF/statistics/rx_packets); echo "$((B-A)) Pakete/s eingehend auf $IF"
ss -Htan | awk '{print $1}' | sort | uniq -c | sort -rn
dmesg -T | tail -50
curl -o /dev/null -s -w '%{time_total}\n' http://127.0.0.1/

Der Schnittstellenname kommt aus der Standardroute, weil eth0 auf vielen KVM-Servern gar nicht existiert (dort heißt sie ens3 oder enp1s0) und ein falsch eingetragener Name seelenruhig null Pakete meldet. Ein großer Block in SYN-RECV ist das Muster eines SYN-Floods. Antwortet der Dienst über 127.0.0.1 schnell, während er von außen ausfällt, sitzt das Problem im Netz. Und: Im Server messen Sie nur, was durchgekommen ist, hinter einer Filterung sehen Sie nur einen Bruchteil des Volumens. Die Systematik dazu steht in DDoS-Angriff erkennen.

Kommen Sie per SSH nicht mehr durch, ist das kein Grund für einen Neustart, sondern die Folge einer gesättigten Leitung. Der Zugang läuft dann über die VNC-Konsole im Kundenbereich, die unabhängig von der Netzwerkanbindung funktioniert.

2. Bestandsaufnahme: was lauscht nach außen?

ss -lntup
nmap -Pn -p- --min-rate 1000 IHRE.SERVER.IP.ADRESSE

Der erste Befehl zeigt die eigene Sicht, der zweite von einem anderen Rechner aus die des Angreifers. Entscheidend ist die lokale Adresse: 0.0.0.0:3306 heißt "aus dem ganzen Internet erreichbar", 127.0.0.1:3306 heißt "nur lokal" und braucht keine Firewall-Regel. Dabei tauchen regelmäßig vergessene Dienste auf: eine Testinstanz, ein Verwaltungspanel, eine Datenbank ohne lokale Bindung.

3. Nur offen lassen, was der Dienst wirklich braucht

Die Reihenfolge ist wichtig, sonst sperren Sie sich selbst aus: erst die Freigaben, dann die Standardrichtlinie, dann einschalten.

ufw allow 22/tcp comment 'SSH'
ufw allow 80,443/tcp comment 'Web'
ufw allow 25565/tcp comment 'Spielport'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Prüfen Sie danach mit einer zweiten, frisch aufgebauten Sitzung, ob Sie noch hereinkommen: Bestehende Verbindungen überleben das Einschalten auch dann, wenn die passende Regel fehlt. Die Anleitung samt Rettungsweg steht in UFW-Firewall einrichten, ohne sich selbst auszusperren.

Die Datenbank gehört nicht ins offene Netz, in /etc/mysql/mariadb.conf.d/50-server.cnf muss bind-address = 127.0.0.1 stehen. Verwaltungsoberflächen ebenso wenig: Ohne feste IP-Adresse für eine gezielte Freigabe lassen Sie den Port geschlossen und erreichen ihn über einen SSH-Tunnel.

ssh -N -L 8443:127.0.0.1:8443 root@IHRE.SERVER.IP.ADRESSE

Veröffentlichte Container-Ports laufen an den UFW-Ketten vorbei. Binden Sie sie lokal, also -p 127.0.0.1:8080:80 statt -p 8080:80, und führen Sie den Zugriff über einen Reverse Proxy.

4. Den Abfrageport absichern, ohne ihn zu schließen

Viele Dienste haben neben dem eigentlichen Port einen zweiten, der Statusinformationen ausliefert: bei Steam-basierten Spielen 27015 UDP, bei Minecraft den Query-Port, bei TeamSpeak die ServerQuery-Schnittstelle auf 10011 TCP. Sie antworten ohne Anmeldung, und die Antwort ist größer als die Anfrage, taugt also zur Verstärkung gegen Dritte. Schließen ist meist keine Option, weil Ihr Server dann aus der Serverliste verschwindet. Begrenzen Sie stattdessen je Quelladresse:

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP

Zehn Abfragen pro Sekunde je Adresse reichen für echte Spieler und für Ihr Monitoring, verwerfen aber eine Quelle mit tausenden Anfragen pro Sekunde. Bei Minecraft schaltet enable-query=false in der server.properties den Query-Port ganz ab, ohne dass der Server aus der Liste verschwindet. enable-status=false unterdrückt zusätzlich die Antwort auf den Listen-Ping, dann erscheint Ihr Server allerdings als offline. Die ServerQuery-Schnittstelle von TeamSpeak binden Sie an 127.0.0.1.

5. Verbindungs- und Paketraten begrenzen

iptables -I INPUT -p tcp --dport 443 --syn -m connlimit --connlimit-above 40 --connlimit-mask 32 -j DROP
iptables -I INPUT -p udp --dport 7777 -m hashlimit --hashlimit-name game_udp --hashlimit-mode srcip --hashlimit-above 600/sec --hashlimit-burst 900 -j DROP

Die erste Regel verwirft neue TCP-Verbindungen, sobald eine Adresse mehr als vierzig gleichzeitig offen hat, die zweite UDP-Pakete ab dauerhaft mehr als 600 Paketen pro Sekunde aus derselben Quelle. Beide Werte sind Startwerte, keine Wahrheiten: Wer zu eng einstellt, wirft eigene Nutzer heraus. Prüfen Sie mit iptables -L INPUT -n -v, ob die Trefferzähler steigen. Bleiben sie bei null, wird die Regel gar nicht erreicht.

Reine iptables-Regeln sind nach einem Neustart weg, gesichert werden sie mit apt-get install -y iptables-persistent und netfilter-persistent save. Unter UFW gehören sie in /etc/ufw/before.rules, sonst verschwinden sie beim nächsten ufw reload. Und die grundsätzliche Grenze: Limits je Quelladresse wirken nur, solange es auffällige Quellen gibt. Schickt jede der 200.000 beteiligten Adressen genau ein Paket, fällt keine davon auf.

6. Den Kernel auf viele kleine Pakete vorbereiten

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=4096
sysctl -w net.core.somaxconn=4096
sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

SYN-Cookies beantworten den Verbindungsaufbau, ohne Speicher zu belegen, und sind ab Werk aktiv. Die beiden Warteschlangen laufen bei vielen gleichzeitigen Verbindungsversuchen als Erste über. Dauerhaft gehören solche Werte in eine Datei unter /etc/sysctl.d/ und werden mit sysctl --system übernommen. Die letzte Zeile zeigt die Verbindungsverfolgung, die es nur bei aktiver Firewall gibt: Läuft ihre Tabelle voll, verwirft der Server auch legitime Pakete und meldet nf_conntrack: table full, dropping packet.

7. Anwendungsebene: Rate-Limits, Whitelist, Plugins und Anti-Cheat

Angriffe, die nicht die Leitung, sondern die Anwendung überlasten, sehen anders aus: wenige Pakete, aber teure. Ein HTTP-Flood auf die Suchfunktion eines Shops braucht kein Gigabit. Beim Webserver ist eine Begrenzung je Adresse deshalb die wirksamste Maßnahme, in nginx im http-Block und danach im server- oder location-Block:

limit_req_zone $binary_remote_addr zone=web:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=webconn:10m;

limit_req zone=web burst=20 nodelay;
limit_conn webconn 20;

Gegen wiederkehrende Anmeldeversuche ergänzt Fail2ban das sinnvoll, die Einrichtung steht in Fail2ban einrichten. Bei Gameservern wirken drei Dinge gegen alles, was den regulären Beitrittsweg nutzt: eine Whitelist (bei Minecraft whitelist=true mit enforce-whitelist=true), eine realistische Obergrenze für gleichzeitige Spieler und serverseitig geprüfte Netzwerkereignisse.

Was Plugins und Anti-Cheat-Systeme nicht können, gehört ebenso klar gesagt: Beide laufen im selben Prozess wie das Spiel und prüfen erst, wenn ein Paket bereits verarbeitet wird. Steht der Prozess, steht die Schutzlogik mit ihm. Für die Whitelist gilt dasselbe, denn wer Ihren Server flutet, will gar nicht beitreten.

8. Serverliste, DNS und die eigene IP-Adresse

Hier lohnt Ehrlichkeit statt Wunschdenken: Ihre IP-Adresse lässt sich nicht geheim halten. Jeder, der einmal verbunden war, kennt sie, und ein Listeneintrag veröffentlicht sie ohnehin. Zwei Gewohnheiten helfen trotzdem: die rohe Adresse nirgends selbst veröffentlichen, auch nicht im Discord-Kanal oder über einen Status-Bot, und die Nutzer über einen Hostnamen verbinden, damit ein Adresswechsel nicht alle Verweise bricht.

Beim Wechsel selbst sind alte DNS-Einträge der Klassiker: ein vergessener A-Eintrag, eine Subdomain aus einer Statusseite, ein MX-Eintrag auf denselben Server. Und selbst dann bleibt ein Adresswechsel Zeitgewinn statt Lösung.

9. Protokollieren, solange der Vorfall läuft

Ohne Vergleichswert können Sie hinterher nicht sagen, ob 40.000 Pakete pro Sekunde viel waren oder einfach Dienstagabend. Mit apt-get install -y vnstat sysstat läuft die Messung dauerhaft mit. Während des Vorfalls sammeln Sie:

mkdir -p /root/vorfall && cd /root/vorfall
date -u > 01-zeit.txt
ss -s > 02-sockets.txt
ip -s link > 03-interfaces.txt
sar -n DEV 1 10 > 04-paketrate.txt
dmesg -T | tail -100 > 05-kernel.txt
tcpdump -ni "$IF" -s 96 -c 500 -q > 06-stichprobe.txt

tcpdump immer mit -c begrenzen, ein unbegrenzter Mitschnitt auf voller Leitung belastet den Server zusätzlich. Ins Ticket gehören danach Zeitpunkt mit Zeitzone, betroffene IP-Adresse samt Port, gemessene Paketrate mit Richtungsangabe, Protokollverteilung und die auffälligen Quellports. Mit diesen Angaben wird eine Meldung sofort bearbeitet, mit "Server war langsam" folgen Rückfragen.

Wo diese Maßnahmen aufhören

Jetzt der Teil, den keine Konfigurationsdatei löst. Alle bisherigen Maßnahmen laufen am Ende der Leitung. Eine Firewall-Regel entscheidet über ein Paket, das bereits über das Kabel gelaufen ist: Sie können es verwerfen, aber nicht ungesendet machen.

Rechnen Sie einmal mit. Eine Anbindung mit 1 Gbit/s trägt 125 Megabyte pro Sekunde und ist voll, sobald jemand mehr schickt. Bei kleinstmöglichen Paketen entspricht das rund 1,49 Millionen Paketen pro Sekunde, bei 10 Gbit/s rund 14,9 Millionen. Ein Serverkernel verarbeitet je nach CPU und Netzwerkkarte einige hunderttausend davon, bevor er zu verwerfen beginnt. Ein Angriff, der Ihre Leitung nicht einmal zu einem Drittel füllt, legt Sie also trotzdem lahm, weil die Rechenzeit ins Verwerfen geht.

Zur Einordnung der realen Größenordnungen: Auf KernelHost-Servern wurden unter anderem ein Angriff mit über 473,4 Gbit/s bei über 41,5 Millionen Paketen pro Sekunde auf einen Voice-Server (9987 UDP) und ein UDP-Flood mit über 112,2 Gbit/s auf einen Gameserver (7777 UDP) in Echtzeit gefiltert. Der erste Fall ist rund das 473-fache dessen, was eine Leitung mit 1 Gbit/s überhaupt transportieren kann. Volumetrische Angriffe müssen im Netz vor dem Server enden, sonst enden sie in Ihrer Leitung.

Was KernelHost dagegen stellt

Der Dauerschutz, der auf jedem Server enthalten ist

Der DDoS-Schutz von KernelHost ist zweistufig aufgebaut und permanent aktiv, ohne dass Sie etwas bestellen, einschalten oder konfigurieren müssen:

• Stufe 1: 17 Tbps Mitigationskapazität im globalen Scrubbing-Netzwerk. Volumetrische Angriffe werden nah an ihrer Quelle bereinigt, bevor sie das Rechenzentrum erreichen.
• Stufe 2: Arbor-Echtzeitfilterung mit 3,2 Tbps vor Ort in Frankfurt am Main. Direkt vor dem Server werden protokollspezifische Muster erkannt und verworfen, Paket für Paket.

Zwei Eigenschaften sind im Ernstfall entscheidend. Der Schutz läuft dauerhaft und muss nicht erst auf einen Angriff reagieren, es gibt also keine Minuten am Anfang, in denen der Server weg ist. Und es wird kein Nullrouting eingesetzt: Ihre IP-Adresse bleibt im Netz, verworfen werden nur die schädlichen Pakete. Nimmt ein Anbieter die angegriffene Adresse dagegen aus dem Netz, ist das Ergebnis für Sie identisch mit einem erfolgreichen Angriff. Rechenzentrum ist maincubes in Frankfurt am Main, Deutschland, Betreiber ist die KernelHost GmbH mit Sitz in Wien, Österreich. Der Schutz ist in jedem Serverpaket ohne Aufpreis enthalten, vom KVM-Rootserver bis zum Dedicated Server.

Advanced DDoS Protection für dauerhaft beschossene Projekte

Manche Projekte werden nicht gelegentlich getroffen, sondern gezielt und über Wochen. Dafür gibt es die Advanced DDoS Protection ab 50,00 EUR im Monat, PrePaid und ohne Mindestlaufzeit. Der Unterschied liegt nicht in mehr Kapazität, sondern in der Kontrolle:

• Dedizierte Schutz-IP aus dem Frankfurter Kern, auf die Ihr Server im eigenen Netz umgestellt wird. Auf Ihrer Seite ist kein Umbau nötig.
• Selbst verwaltbare Schutzregeln je Port und Protokoll im Kundenbereich, ohne Ticket: Der Spielport bekommt andere Regeln als der Abfrageport.
• Änderungen greifen in Echtzeit, Sie können also mitten im laufenden Angriff nachjustieren.
• Schutzprofil passend zum jeweiligen Spiel, dazu Profile für eigene und modifizierte Anwendungen auf beliebigen TCP- oder UDP-Ports.

Die beiden Stufen im Vergleich

Für die meisten Projekte reicht der inkludierte Dauerschutz zusammen mit einer sauberen Serverkonfiguration. Die Advanced DDoS Protection ist die Antwort darauf, dass jemand es persönlich nimmt.

Häufige Fehler und Lösungen

"Ich habe den Server neu gestartet, danach lief es kurz wieder": Das war der Angriff in Wellen, nicht der Neustart. Neustarts löschen die Zähler, die Sie für die Meldung gebraucht hätten.

"Ich habe die IP-Adresse gewechselt und war zwei Stunden später wieder offline": Die neue Adresse kam aus derselben Quelle wie die alte, meist einem Listeneintrag, einem Status-Bot oder einem alten DNS-Eintrag.

"Ich sperre die auffälligen Adressen, es kommen immer neue": Bei einem verteilten Angriff sind es Zehntausende, bei Reflexionsangriffen sperren Sie ohnehin nur unbeteiligte Dritte.

"Meine Firewall-Regeln greifen nicht": Drei Ursachen sind häufig: Die Regeln stehen hinter den UFW-Ketten, sie waren nach dem letzten Neustart weg, oder der Angriff ist volumetrisch und die Regel arbeitet korrekt an einer Leitung, die schon voll ist.

"Die Auslastung war niedrig, trotzdem war der Dienst weg": Ein typischer Angriff über die Paketrate. Die Bandbreite sieht harmlos aus, die Anzahl der Pakete nicht. Messen Sie Pakete pro Sekunde, nicht Megabit.

"Im tcpdump sehe ich nichts Auffälliges": Wird der Verkehr im Netz davor gefiltert, kommt auf dem Server erwartungsgemäß nichts an. Ist die Leitung dagegen gesättigt, erreicht Sie unter Umständen nicht einmal mehr die SSH-Sitzung. Nutzen Sie dann die VNC-Konsole im Kundenbereich.

Kurz zusammengefasst

Messen Sie zuerst, bauen Sie erst danach um. Schließen Sie alles, was der Dienst nicht braucht, begrenzen Sie Abfrageport, Verbindungen und Paketraten je Quelladresse und sammeln Sie Messwerte, solange der Vorfall läuft. Damit sind Sie gegen alles gewappnet, was ohne nennenswerte Bandbreite auskommt. Darüber hinaus entscheidet ausschließlich das Netz vor dem Server.

Läuft Ihr Projekt bereits bei KernelHost, ist die Filterung aktiv, ohne dass Sie etwas tun müssen. Bemerken Sie trotzdem Auffälligkeiten, eröffnen Sie ein Support-Ticket, damit die Filterregeln für Ihre IP-Adresse nachjustiert werden. Bei einem laufenden Angriff erreichen Sie uns zusätzlich über den WhatsApp-Notfallchat unter +43 650 8209883.