SYN-Flood: Der häufigste DDoS-Angriff auf Minecraft Server

Jeder Minecraft-Serverbesitzer begegnet frueher oder spaeter DDoS-Angriffen. Und in den meisten Faellen ist das erste, was ankommt, ein SYN-Flood. Nicht weil es der ausgefeilteste Angriff ist. Ganz im Gegenteil, weil es die einfachste und immer noch wirksame Technik ist, die einen ungeschuetzten Server in Sekunden lahmlegen kann.

Um zu verstehen, wie SYN-Flood funktioniert, muss man verstehen, wie TCP-Verbindungen aufgebaut werden. Minecraft Java Edition laeuft auf TCP, daher durchlaeuft jede Spielerverbindung diesen Prozess.

Wie der TCP Three-Way Handshake funktioniert

Wenn sich ein Spieler mit deinem Server verbindet, findet ein "Drei-Wege-Handshake" statt. Drei Pakete, drei Schritte.

Schritt 1: SYN. Der Client sendet ein Paket mit dem SYN-Flag (synchronize). Dieses Paket sagt: "Hey, ich moechte eine Verbindung aufbauen. Hier ist meine initiale Sequenznummer."

Schritt 2: SYN-ACK. Der Server empfaengt das SYN, reserviert Ressourcen fuer die neue Verbindung (erstellt einen Eintrag im SYN-Backlog) und sendet ein SYN-ACK-Paket zurueck. Das bedeutet: "Ich habe dich gehoert, hier ist meine Sequenznummer, bitte bestaetige."

Schritt 3: ACK. Der Client sendet das abschliessende ACK. Verbindung hergestellt. Daten koennen fliessen, und Minecraft beginnt den Login-Prozess.

Der gesamte Vorgang dauert normalerweise weniger als 100 Millisekunden. Aber hier ist der kritische Punkt: Zwischen Schritt 2 und Schritt 3 haelt der Server die Verbindung in einem "halb-offenen" Zustand. Er hat bereits Ressourcen aufgewendet, aber noch keine Bestaetigung erhalten. Genau das nutzt der SYN-Flood aus.

Wie SYN-Flood deinen Server zerstoert

Die Idee ist denkbar einfach. Der Angreifer sendet Tausende (oder Millionen) SYN-Pakete an den Port deines Servers. Jedes Paket kommt mit einer gefaelschten IP-Adresse (IP-Spoofing). Der Server antwortet pflichtbewusst auf jedes SYN mit einem SYN-ACK und erstellt einen Backlog-Eintrag. Aber das SYN-ACK geht an eine gefaelschte Adresse, von der nie ein ACK zurueckkommen wird.

Das Ergebnis:

1. Der SYN-Backlog fuellt sich mit halb-offenen Verbindungen
2. Jede halb-offene Verbindung wartet im Speicher auf ein ACK (Standard 75 Sekunden unter Linux)
3. Wenn der Backlog voll ist, nimmt der Server keine neuen Verbindungen mehr an
4. Echte Spieler erhalten "Connection timed out" oder "Can't connect to server"

Die Standard-SYN-Backlog-Groesse in Linux betraegt 128 oder 256 Eintraege. Selbst mit einem erhoehten Backlog von 1024 ist bei einer Angriffsrate von 50.000 SYN-Paketen pro Sekunde der Backlog sofort voll. Und der Angriff kann von einem einzigen gemieteten Server generiert werden, kein Botnet noetig.

Warum Minecraft-Server besonders anfaellig sind

Minecraft-Server haben mehrere Eigenschaften, die sie zu idealen SYN-Flood-Zielen machen.

Ein einziger Port. Der gesamte Datenverkehr laeuft ueber einen TCP-Port (normalerweise 25565). Der Angreifer muss sich nicht verteilen, es reicht, diesen einen Port zu fluten.

TCP-Protokoll. Im Gegensatz zu UDP-basierten Spielen (Bedrock Edition, CS2, Valorant) verwendet Java Edition TCP. Jede Verbindung erfordert einen vollstaendigen Handshake, und jedes SYN-Paket verbraucht Serverressourcen.

Oeffentliche Adresse. Die meisten Minecraft-Server veroeffentlichen ihre IP in Serverlisten, Foren und auf Discord. Der Angreifer weiss immer, wohin er zielen muss.

Begrenzte Ressourcen. Ein typischer Minecraft-Server laeuft auf einem VPS oder Dedicated Server mit begrenzten Netzwerkressourcen. Selbst bei einer 1-Gbit/s-Anbindung erzeugt ein 500-Mbit/s-SYN-Flood ernsthafte Probleme.

Kein eingebauter Schutz. Weder Vanilla noch Paper noch Velocity haben eingebaute SYN-Flood-Schutzmechanismen. Das ist eine Aufgabe auf Betriebssystem- und Netzwerkebene.

Wie man einen SYN-Flood erkennt

Bevor du einen Angriff bekaempfst, musst du ihn diagnostizieren. Hier sind die konkreten Befehle.

Verbindungsstatus mit ss pruefen

ss -s

Zeigt die Gesamtstatistik der Sockets. Eine ungewoehnlich hohe synrecv-Anzahl bedeutet SYN-Flood.

ss -tnp state syn-recv | wc -l

Zeigt die Anzahl der Verbindungen im SYN_RECV-Zustand. Normalwert fuer einen Minecraft-Server mit 200 Spielern: 0-5. Wenn du Hunderte oder Tausende siehst, wirst du angegriffen.

Analyse mit netstat

netstat -n | awk '/^tcp/ {print $6}' | sort | uniq -c | sort -rn

Gruppiert TCP-Verbindungen nach Status. Bei einem SYN-Flood siehst du etwa:

  4891 SYN_RECV
    47 ESTABLISHED
    12 TIME_WAIT
     3 CLOSE_WAIT

Tausende SYN_RECV bei Dutzenden ESTABLISHED ist ein klares Zeichen fuer einen Angriff.

Live-Monitoring mit tcpdump

tcpdump -i eth0 -n 'tcp[tcpflags] & tcp-syn != 0' -c 100

Zeigt SYN-Pakete in Echtzeit. Beim SYN-Flood siehst du einen Strom von Paketen mit verschiedenen (gefaelschten) IP-Adressen. Achte auf die TTL-Werte: Wenn sie bei Paketen von verschiedenen "IPs" identisch sind, kommen die Pakete tatsaechlich aus einer einzigen Quelle.

SYN-Paketrate ueberwachen

watch -n 1 'ss -s | grep synrecv'

Echtzeit-Monitoring. Wenn SYN_RECV um Tausende pro Sekunde waechst, ist es ein aktiver Angriff.

Schutz auf Kernel-Ebene

Die erste Verteidigungslinie ist die richtige Kernel-Konfiguration. Das stoppt keinen ernsthaften Angriff, gibt aber Zeit zum Reagieren.

SYN Cookies

sysctl -w net.ipv4.tcp_syncookies=1

SYN Cookies eliminieren die Notwendigkeit, den Zustand halb-offener Verbindungen zu speichern. Stattdessen codiert der Server die Verbindungsinformationen direkt in die Sequenznummer des SYN-ACK-Pakets. Wenn das ACK ankommt, stellt der Server die Informationen aus der Sequenznummer wieder her.

Vorteile: Der Backlog fuellt sich nicht, der Server nimmt weiterhin Verbindungen an. Nachteile: Einige TCP-Optionen (Window Scaling, Timestamps) funktionieren nicht, was die Latenz erhoehen kann. Fuer Minecraft ist das normalerweise nicht kritisch.

SYN-Backlog vergroessern

sysctl -w net.ipv4.tcp_max_syn_backlog=65535
sysctl -w net.core.somaxconn=65535

Vergroessert die Warteschlange fuer halb-offene Verbindungen. Allein keine Loesung, aber mit aktivierten Syncookies gibt es zusaetzlichen Spielraum.

SYN-ACK-Wiederholungen reduzieren

sysctl -w net.ipv4.tcp_synack_retries=2

Standardmaessig sendet Linux SYN-ACK 5-mal erneut und wartet auf ein ACK. Jede Wiederholung verlaengert die Lebensdauer einer halb-offenen Verbindung. Bei Reduzierung auf 2 wird die Verbindung schneller verworfen.

Vollstaendige sysctl-Konfiguration

# /etc/sysctl.conf - SYN-Flood-Mitigation
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 65535
net.core.somaxconn = 65535
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1
net.core.netdev_max_backlog = 65535
net.ipv4.ip_local_port_range = 1024 65535

Anwenden mit:

sysctl -p

iptables SYN-Flood-Mitigation

Zweite Ebene: Filterung mit netfilter/iptables.

SYN-Rate-Limiting

iptables -A INPUT -p tcp --syn -m limit --limit 100/s --limit-burst 200 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

Akzeptiert maximal 100 SYN-Pakete pro Sekunde mit einem Burst von 200. Alles darueber wird verworfen. Fuer einen Minecraft-Server mit 200-300 Spielern reichen 100 SYN/s voellig aus, da sich Spieler nicht jede Sekunde verbinden.

Ungueltige TCP-Pakete blockieren

iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
iptables -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j DROP
iptables -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j DROP
iptables -A INPUT -p tcp --tcp-flags ACK,URG URG -j DROP

Diese Regeln blockieren Pakete mit ungueltigen TCP-Flag-Kombinationen. Ein normaler TCP-Stack erzeugt niemals ein Paket mit gleichzeitig gesetzten SYN- und FIN-Flags. Solche Pakete sind entweder ein Angriff oder ein Port-Scan.

Verbindungslimit pro IP

iptables -A INPUT -p tcp --dport 25565 --syn -m connlimit --connlimit-above 3 --connlimit-mask 32 -j DROP

Maximal 3 gleichzeitige neue Verbindungen pro IP. Ein normaler Spieler erstellt 1 Verbindung. Wenn 3+ SYNs gleichzeitig von derselben IP kommen, ist das verdaechtig.

SYNPROXY verwenden

iptables -t raw -A PREROUTING -p tcp --dport 25565 --syn -j CT --notrack
iptables -A INPUT -p tcp --dport 25565 -m conntrack --ctstate INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

SYNPROXY ist ein iptables-Target, das SYN-Proxy direkt im Kernel implementiert. Es beantwortet SYN-Pakete anstelle der Anwendung und erstellt erst nach Erhalt eines gueltigen ACK eine echte Verbindung zum Backend.

Warum Schutz auf Anwendungsebene nicht reicht

Manche Serverbesitzer installieren "Anti-DDoS"-Plugins auf Paper oder Velocity und halten sich fuer geschuetzt. Das ist ein gefaehrlicher Irrtum.

Ein Minecraft-Plugin arbeitet auf der Anwendungsebene (Layer 7). Wenn ein SYN-Paket ankommt, durchlaeuft es den Kernel-Netzwerk-Stack, den TCP/IP-Stack und die Accept-Queue, bevor Java es ueberhaupt sieht. SYN-Flood toetet den Server auf TCP-Stack-Ebene, bevor Java etwas verarbeitet.

Ein "Anti-Bot"-Plugin schuetzt vor Bots, die bereits eine TCP-Verbindung hergestellt haben und versuchen, sich in Minecraft einzuloggen. Das ist ein anderer Angriffstyp (Layer 7 Bot Flood). Gegen SYN-Flood ist das Plugin nutzlos, weil Verbindungen es nie erreichen.

Stell dir vor, du positionierst einen Waechter im Gebaeude, waehrend Angreifer die Eingangstuer von aussen verbarrikadiert haben. Der Waechter kann nichts tun, weil das Problem vor ihm liegt.

Wie professioneller DDoS-Schutz SYN-Floods bewaeltigt

Professionelle Loesungen wie MineGuard funktionieren grundlegend anders. Anstatt den Server zu schuetzen, verhindern sie, dass der Traffic ihn ueberhaupt erreicht.

XDP/eBPF-Filterung. XDP verarbeitet Pakete, bevor sie in den Kernel-TCP-Stack gelangen. Es ist die schnellste Filtermethode, die Pakete direkt auf Netzwerktreiber-Ebene verwirft. Bei einem 10-Gbit/s-SYN-Flood ist das die einzige Option, die die CPU nicht ueberfordert.

SYN-Proxy auf Filterebene. Der Filter nimmt das SYN vom Client an, antwortet mit einem SYN-ACK mit SYN-Cookie und wartet auf das ACK. Wenn ein gueltiges ACK ankommt und das Cookie korrekt ist, baut der Filter eine neue Verbindung zum Backend auf und verbindet beide. Der Backend-Server sieht nur abgeschlossene, validierte Verbindungen.

Musteranalyse. Professionelle Filter analysieren TTL, TCP-Window-Groesse, MSS und andere Parameter von SYN-Paketen. Echte Clients haben je nach Betriebssystem unterschiedliche Werte (Windows, macOS, Linux, Android). SYN-Flood-Tools (hping3, scapy) verwenden typischerweise Standard- oder anomale Werte, was sie leicht filterbar macht, noch bevor Cookies geprueft werden.

Unterschied zu anderen Flood-Typen

SYN-Flood wird oft mit anderen TCP-Angriffstypen verwechselt. Schauen wir uns die Unterschiede an.

UDP-Flood. UDP ist verbindungslos. UDP-Flood saettigt einfach die Bandbreite mit Muell-Paketen. Er nutzt keinen Handshake aus. Fuer Java Edition (TCP) ist UDP-Flood weniger gefaehrlich, da UDP-Pakete an einem TCP-Port einfach verworfen werden, obwohl sie trotzdem Bandbreite belegen.

ACK-Flood. ACK-Flood sendet Pakete mit dem ACK-Flag ohne vorheriges SYN. Stateful Firewalls koennen diese leicht erkennen und verwerfen, da kein passender Connection-Tracking-Eintrag existiert.

RST-Flood. RST-Pakete dienen zum erzwungenen Verbindungsabbruch. Wenn der Angreifer die Sequenznummer einer aktiven Verbindung erraten kann, kann er einen Spieler vom Server trennen. Gezielter und schwieriger ausfuehrbar als SYN-Flood.

TCP-Connection-Flood. Der Angreifer schliesst den Handshake ab (SYN, SYN-ACK, ACK) und erstellt echte Verbindungen. Das umgeht SYN-Cookies, erfordert aber echte IPs (kein Spoofing), was den Angreifer fuer IP-Blockierung anfaellig macht.

Reale Szenarien und Zahlen

Zum Verstaendnis des Ausmasses, einige reale Zahlen.

Ein typischer SYN-Flood auf einen Minecraft-Server liegt zwischen 100.000 und 5.000.000 Paketen pro Sekunde. Volumetrisch sind das 50-200 Mbit/s, was im Vergleich zu 100+ Gbit/s volumetrischen Angriffen nicht viel erscheint. Aber SYN-Flood dreht sich nicht um Volumen, sondern um Ressourcenerschoepfung.

Ein ungeschuetzter Server mit Standardeinstellungen (Backlog 128) faellt bei 1.000 SYN/s aus. Ein sysctl-optimierter Server (Backlog 65535, Syncookies) haelt 50.000-100.000 SYN/s aus, beginnt aber Pakete zu verlieren und die Latenz zu erhoehen. Nur Hardware- oder XDP-Filterung bewaeltigt Millionen SYN/s.

In der Praxis kombinieren Angreifer SYN-Flood oft mit anderen Techniken. Zuerst kommt SYN-Flood zur Ueberlastung des Netzwerkstacks, dann ein Layer-7-Bot-Angriff mit echten Verbindungen. Die erste Welle bindet Ressourcen, die zweite gibt den Rest. Ueber diese kombinierten Angriffe haben wir ausfuehrlich in unserem Artikel ueber DDoS-Trends fuer Minecraft 2026 geschrieben.

Schnell-Checkliste: Gerade unter Angriff

Wenn du gerade unter SYN-Flood stehst und schnell handeln musst:

1. Diagnose (30 Sekunden):

ss -s | grep synrecv
ss -tn state syn-recv | wc -l

2. Notfall-Syncookies:

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=65535
sysctl -w net.ipv4.tcp_synack_retries=1

3. iptables Rate-Limiting:

iptables -I INPUT -p tcp --dport 25565 --syn -m limit --limit 50/s --limit-burst 100 -j ACCEPT
iptables -A INPUT -p tcp --dport 25565 --syn -j DROP

4. Wenn der Angriff anhaelt, hole professionellen DDoS-Schutz. Wir haben einen detaillierten Aktionsplan in unserem Leitfaden "Minecraft-Server unter DDoS: Was tun" beschrieben.

SYN-Flood nicht mit anderen Problemen verwechseln

Nicht jeder Timeout ist DDoS. Manchmal laggt der Server aus anderen Gruenden, und es ist wichtig, sie zu unterscheiden.

Wenn ss -s eine normale SYN_RECV-Anzahl zeigt (unter 10), aber Spieler ueber Lag klagen, liegt das Problem wahrscheinlich am Server selbst: TPS-Drops, RAM-Mangel, ueberladene Chunks. Wir haben einen separaten Artikel ueber Lag-Diagnose: DDoS oder Serverprobleme.

Wenn SYN_RECV erhoeht, aber nicht kritisch ist (20-50), ist es vielleicht kein Angriff. Viele Spieler koennten sich gleichzeitig verbinden (nach einem Server-Neustart oder waehrend eines Server-Events). Pruefe, ob die IPs in SYN_RECV echten Spielern entsprechen.

Ein weiterer haeufiger Fall: Der Hosting-Anbieter aktiviert SYN-Flood-Schutz auf seiner Seite, der bei maessiger Last beginnt, legitime SYN-Pakete zu verwerfen. Die Symptome sehen aus wie DDoS, aber es ist tatsaechlich uebertrieben aggressive Filterung. Ueberpruefen laesst sich das durch Deaktivierung des Rate-Limitings auf Hosting-Seite.

Ergebnis

SYN-Flood nutzt einen fundamentalen TCP-Mechanismus aus, und diese Schwachstelle vollstaendig zu beseitigen ist ohne Aenderung des Protokolls selbst nicht moeglich. Aber man kann die Auswirkungen minimieren.

Fuer einen kleinen Server (unter 50 Spieler) reichen normalerweise eine richtige sysctl-Konfiguration plus grundlegende iptables-Regeln. Fuer groessere Server mit echtem Publikum ist professioneller DDoS-Schutz keine Luxus, sondern Notwendigkeit. Der Unterschied zwischen dem Verlust aller Spieler fuer 4 Stunden und der Filterung des Angriffs ohne einen einzigen Disconnect ist der Unterschied zwischen Hobby und funktionierendem Projekt.

Konfiguriere sysctl, fuege iptables-Regeln hinzu, halte Diagnosebefehle bereit. Und denke daran: SYN-Flood ist nur ein Angriffstyp. Guter Schutz deckt alle Vektoren gleichzeitig ab.