TCP vs UDP Angriffe auf Minecraft Server: Unterschiede erklaert

Jedes Mal, wenn ein Spieler sich mit einem Minecraft-Server verbindet, werden Daten ueber eines von zwei Transportprotokollen uebertragen: TCP oder UDP. Java Edition verwendet TCP. Bedrock Edition verwendet UDP. Das ist nicht nur ein technisches Detail. Es bestimmt, welche Angriffe moeglich sind, wie gefaehrlich sie sind und wie man sich dagegen schuetzt.

Dieser Artikel analysiert beide Protokolle aus der DDoS-Angriffsperspektive. Keine abstrakte Theorie. Echte Zahlen und konkrete Empfehlungen.

TCP und UDP: die Grundlagen in 2 Minuten

Wenn du den Unterschied zwischen TCP und UDP bereits kennst, ueberspringe diesen Abschnitt. Fuer alle anderen hier die Kurzfassung.

TCP (Transmission Control Protocol) stellt eine Verbindung her, bevor Daten gesendet werden. Drei-Wege-Handshake: Client sendet SYN, Server antwortet mit SYN-ACK, Client bestaetigt mit ACK. Erst dann beginnt der Datenaustausch. Jedes Paket wird nummeriert, die Zustellung wird garantiert, verlorene Pakete werden erneut gesendet.

UDP (User Datagram Protocol) stellt keine Verbindungen her. Pakete werden ohne Bestaetigung, ohne Nummerierung, ohne Zustellungsgarantie gesendet. Abschicken und vergessen. Das macht UDP schneller (weniger Overhead), aber weniger zuverlaessig.

TCP (Minecraft Java):
Client  ──SYN──>     Server
Client  <─SYN-ACK──  Server
Client  ──ACK──>     Server
Client  <──DATA──>   Server   ← Verbindung hergestellt

UDP (Minecraft Bedrock):
Client  ──PKT──>  Server     ← einfach senden
Client  ──PKT──>  Server     ← keine Bestaetigung
Client  ──PKT──>  Server     ← kein Zustand

Minecraft Java Edition hoert auf TCP-Port 25565. Minecraft Bedrock Edition hoert auf UDP-Port 19132. Einige Server aktivieren das Query-Protokoll, das auf UDP-Port 25565 laeuft. Merke dir das. Es wird spaeter wichtig.

TCP-Angriffe: Klassiker mit vorhersehbarem Muster

TCP-Angriffe auf Minecraft-Server sind gut erforscht und werden generell gut gefiltert. Aber "gut gefiltert" bedeutet nicht "harmlos." Hier sind die wichtigsten Typen.

SYN Flood

Der haeufigste TCP-Angriff. Der Angreifer sendet eine massive Anzahl von SYN-Paketen (der erste Schritt des Handshakes) mit gefaelschten Quell-IPs. Der Server reserviert fuer jede halboffene Verbindung Speicher und sendet SYN-ACK. Die Antwort geht an die gefaelschte IP, ACK kommt nie an. Die Tabelle der halboffenen Verbindungen fuellt sich, neue legitime Clients koennen sich nicht verbinden.

Fuer Minecraft-Server ist SYN Flood besonders gefaehrlich, weil Java-Server typischerweise einen begrenzten Backlog haben. Standard net.core.somaxconn unter Linux ist 4096. Bei 100.000 SYN/s fuellt sich diese Warteschlange in Bruchteilen einer Sekunde.

Typische Volumen: 1 bis 50 Gbps. Wir haben Angriffe auf Minecraft-Server mit Spitzen von 30 Gbps reinem SYN Flood gesehen. Mehr Details zu SYN Flood Angriffen in unserem separaten Artikel.

ACK Flood

Der Angreifer sendet massenhaft TCP-Pakete mit gesetztem ACK-Flag. Der Server erhaelt ACKs fuer Verbindungen, die nicht existieren, und verbraucht Ressourcen bei der Suche in der Verbindungstabelle. Wenn der Server conntrack verwendet (und das tut er fast sicher), loest jedes Paket einen Hash-Table-Lookup aus.

ACK Flood ist weniger effektiv als SYN Flood, weil Pakete ohne passende Verbindung schnell verworfen werden. Aber bei ausreichendem Volumen (10+ Gbps) wird die Paketverarbeitungslast zum Problem.

RST Flood

Ein Strom von TCP-Paketen mit RST-Flag (Reset). Ziel: bestehende Spielerverbindungen trennen. Wenn der Angreifer die Sequenznummer einer aktiven Verbindung erratet, kann er sie zwangsweise beenden. In der Praxis ist das Erraten der Sequenznummer schwierig, daher funktioniert RST Flood meist als volumetrischer Angriff.

Slowloris

Ein eleganter Angriff, der kein hohes Verkehrsvolumen erfordert. Der Angreifer oeffnet viele TCP-Verbindungen und sendet die initialen Handshake-Bytes sehr langsam, ein Byte alle 10-30 Sekunden. Der Server haelt diese Verbindungen offen und erschoepft schliesslich das Limit gleichzeitiger Verbindungen.

Fuer Minecraft-Server sieht Slowloris so aus: Hunderte Verbindungen starten den Handshake, beenden ihn aber nie. Jede blockiert einen Slot. Wenn die Slots aufgebraucht sind, koennen echte Spieler nicht beitreten.

Warum TCP-Angriffe leichter zu filtern sind

TCP-Angriffe sind vorhersehbar, weil TCP von Natur aus zustandsbehaftet ist. Jede Verbindung hat einen klaren Lebenszyklus: SYN, SYN-ACK, ACK, DATA, FIN. Eine Firewall kann diesen Zustand verfolgen und Pakete verwerfen, die nicht in die erwartete Sequenz passen.

SYN Cookies loesen das SYN-Flood-Problem fast vollstaendig. Statt Speicher pro SYN zu reservieren, kodiert der Server Verbindungsinformationen in der SYN-ACK-Sequenznummer. Speicher wird erst reserviert, wenn ein gueltiges ACK mit der richtigen Sequenznummer eintrifft.

Conntrack (Connection Tracking) verfolgt den Zustand jeder TCP-Verbindung. ACK fuer eine nicht existierende Verbindung? Verwerfen. RST mit falscher Sequenznummer? Verwerfen. Guenstig und effektiv.

UDP-Angriffe: ein anderes Tier

UDP-Angriffe auf Minecraft-Server funktionieren grundlegend anders. Kein Zustand, kein Handshake, keine Paketreihenfolge. Das schafft enorme Probleme fuer die Verteidigung.

UDP Flood

Der einfachste Angriff: Senden massiver Mengen von UDP-Paketen an den Zielport. Da UDP keinen Verbindungsaufbau erfordert, kann der Angreifer Pakete mit gefaelschten IPs ohne Einschraenkungen senden. Der Server muss jedes Paket annehmen und pruefen, ob eine Anwendung auf diesem Port lauscht.

Fuer Bedrock-Server ist das kritisch: Jedes eingehende UDP-Paket auf Port 19132 trifft auf RakNet (Bedrocks Netzwerkbibliothek), die Ressourcen fuer den Parsing-Versuch aufwendet.

Die Volumen von UDP Flood koennen enorm sein. Da Pakete ohne Warten auf Antwort generiert werden, kann ein einzelner Angriffsserver Gigabits an Muellverkehr pro Sekunde senden. Ein Botnet mit einigen Tausend Knoten generiert leicht 100+ Gbps reinen UDP Flood. Und jedes Paket muss mindestens minimal verarbeitet werden, bevor klar ist, dass es Muell ist.

Ein separates Problem: UDP Flood auf zufaellige Ports. Wenn der Angreifer Pakete nicht an 19132, sondern an zufaellige Ports sendet, generiert der Server fuer jedes Paket eine ICMP Port Unreachable-Nachricht. Das erzeugt zusaetzliche CPU-Last und kann den ausgehenden Kanal mit ICMP-Antworten fuellen.

Amplification-Angriffe: wo 1 Byte zu 50 wird

Hier wird UDP wirklich gefaehrlich. Amplification nutzt legitime Internetdienste als Verkehrsverstaerker. Das Prinzip ist einfach:

1. Angreifer sendet eine kleine Anfrage an einen offenen Dienst (DNS, NTP, Memcached)
2. Quell-IP wird auf die IP des Opfers gefaelscht (Spoofing)
3. Der Dienst antwortet mit einer viel groesseren Antwort an die IP des Opfers
4. Das Opfer erhaelt Traffic, der 10 bis 1000+ Mal groesser ist als das, was der Angreifer gesendet hat

Amplification-Faktoren nach Protokoll:

Protokoll	Amplification-Faktor	Typisches Angriffsvolumen
DNS	28-54x	10-100 Gbps
NTP (monlist)	556x	50-400 Gbps
Memcached	10.000-51.000x	100-1.700 Gbps
SSDP	30x	5-50 Gbps
CLDAP	56-70x	10-100 Gbps

Ja, du hast richtig gelesen. Memcached kann den Traffic um das 51.000-fache verstaerken. Der Angreifer sendet 1 MB Daten, das Opfer erhaelt 51 GB. Im Minecraft-Kontext: Ein ungeschuetzter Bedrock-Server kann mit 100+ Gbps via NTP Amplification getroffen werden. Die Bandbreite jedes Hosters ist sofort voll.

Query Flood: Angriff ueber eine eingebaute Funktion

Das Minecraft Query-Protokoll laeuft ueber UDP, typischerweise auf Port 25565. Es gibt Serverinformationen zurueck: Spielerzahl, MOTD, Plugin-Liste, Version. Eine Query-Anfrage ist etwa 9 Bytes gross. Die Antwort reicht von 200 bis 2000+ Bytes, abhaengig von Plugins und Spielern.

Das ergibt einen Amplification-Faktor von 20x bis 200x. Mit Minecraft selbst, ohne externe Dienste.

Schlimmer noch: Viele Server aktivieren Full Query, das vollstaendige Plugin- und Spielerlisten zurueckgibt. Auf einem Server mit 50 Plugins und 100 Spielern kann eine Full-Query-Antwort 3-4 KB gross sein. Amplification-Faktor: 400x+.

Loesung: Deaktiviere Query, wenn du es nicht brauchst.

# server.properties
enable-query=false

Warum UDP schwerer zu filtern ist

Bei TCP kann eine Firewall fragen: "Gehoert dieses Paket zu einer bestehenden Verbindung?" Wenn nicht, verwerfen. Bei UDP kann man diese Frage nicht stellen, weil Verbindungen nicht existieren. Jedes Paket ist unabhaengig. Ein legitimes Bedrock-Spielerpaket sieht genau so aus wie ein Angriffspaket. Beide sind einfach UDP-Datagramme an Port 19132.

Was bleibt:

• Rate Limiting pro IP: Pakete pro Sekunde von einer einzelnen IP begrenzen. Funktioniert gegen Angriffe von echten IPs, nutzlos gegen gefaelschte IPs.
• Payload Inspection (DPI): UDP-Paketinhalte analysieren. Legitime RakNet-Pakete haben eine bestimmte Struktur. Angriffspakete sind oft zufaellige Bytes. Aber das ist teuer.
• GeoIP-Filterung: Pakete aus Regionen ohne Spieler verwerfen. Grob, aber effektiv.
• Verhaltensanalyse: Verkehrsmuster analysieren. 10.000 UDP-Pakete pro Sekunde von einer IP auf einen Port ist kein Spieler.

Die Zahlen im Vergleich

Parameter	TCP-Angriffe	UDP-Angriffe
Minecraft Edition	Java (Port 25565)	Bedrock (Port 19132)
Typisches Volumen	5-50 Gbps	50-500+ Gbps
Maximum aufgezeichnet	~300 Gbps	~3,5 Tbps
Amplification	Nicht moeglich	Bis zu 51.000x
IP-Spoofing	Schwer (braucht ACK)	Trivial
Stateful Filtering	Effektiv	Nicht moeglich
Angriffskosten	$$$	$
Verteidigungskosten	$	$$$

Beachte die Kostenasymmetrie. Ein TCP-Angriff erfordert echte Ressourcen: Server, die Handshakes abschliessen oder hohe Paketraten generieren. Ein UDP-Amplification-Angriff kostet fast nichts: ein paar Skripte, eine Liste offener Resolver, fertig.

Laut den DDoS-Trends 2026 machen UDP-Angriffe auf Minecraft-Server etwa 70% aller DDoS-Vorfaelle aus. TCP-Angriffe bleiben relevant, verschieben sich aber in Richtung Application-Level: gefaelschte Minecraft-Handshakes, Login-Floods, Bot-Joins.

Reales Szenario: Hybridangriff

Schauen wir uns ein typisches Angriffsszenario auf einen Server an, der sowohl Java als auch Bedrock unterstuetzt. Der Angreifer geht in mehreren Phasen vor.

Phase 1: Aufklaerung. Der Angreifer scannt die Ports des Servers. Findet TCP 25565 (Java), UDP 19132 (Bedrock), UDP 25565 (Query aktiviert). Ueber Query erhaelt er die Plugin-Liste und Serverversion.

Phase 2: UDP Amplification. DNS Amplification wird auf die Server-IP gestartet. 5 Gbps ausgehender Traffic werden zu 150 Gbps eingehendem. Die Bandbreite des Servers ist voll. Alle Spieler, Java und Bedrock, werden getrennt.

Phase 3: SYN Flood. Parallel zum UDP-Angriff wird SYN Flood auf Port 25565 gestartet. Selbst wenn der Upstream-Provider einen Teil der UDP Amplification filtert, belastet der SYN Flood Conntrack und Backlog. Der Server kann keine neuen TCP-Verbindungen annehmen.

Phase 4: Bot Join. Nach dem Abschwaechen der ersten beiden Wellen sendet der Angreifer Bots, die den TCP-Handshake abschliessen, einen gueltigen Minecraft-Login senden und den Server betreten. Slots werden mit Bots gefuellt, echte Spieler landen in der Warteschlange.

Das ist keine Theorie. Solche mehrstufigen Angriffe sind seit 2025 zum Standard geworden. Der Schutz muss auf allen Ebenen gleichzeitig funktionieren.

Verschiedene Protokolle, verschiedene Verteidigungsstrategien

Der Schutz eines Java-Servers (TCP) und eines Bedrock-Servers (UDP) erfordert unterschiedliche Ansaetze. Man kann nicht dieselbe Logik auf beide anwenden.

Schutz fuer Java Edition (TCP)

Fuer TCP existieren maechtige Werkzeuge auf OS-Kernel-Ebene:

1. SYN Cookies - loesen SYN Flood ohne zusaetzliche Software
2. Connection Tracking - zustandsbasierte Paketfilterung
3. Handshake-Verifikation - Abschluss pruefen bevor Zugang gewaehrt wird
4. Application-Level-Pruefungen - Minecraft-Protokoll nach TCP-Verbindung validieren

Schutz fuer Bedrock Edition (UDP)

Fuer UDP verlieren wir zustandsbasierte Tools. Keine SYN Cookies, kein Conntrack. Andere Methoden sind noetig:

1. XDP-Level Rate Limiting - Pakete verwerfen bevor sie den Kernel erreichen
2. RakNet Payload Validation - Bedrock-Paketstruktur ueberpruefen
3. Cookie-basierte Verifikation - eigenes Challenge-Response ueber UDP
4. GeoIP-Filterung - geografische Einschraenkungen
5. Upstream-Filterung - BGP Flowspec auf Provider-Ebene

Fuer Serverbetreiber, die beide Editionen betreiben (Java und Bedrock), ist es entscheidend zu verstehen, dass keine einzelne Loesung beide Protokolle abdeckt. Ein Schutzdienst muss separate Module fuer TCP- und UDP-Traffic haben. MineGuard zum Beispiel verarbeitet Java- und Bedrock-Traffic durch verschiedene Pipelines, jede mit eigenem Regelsatz und Algorithmen.

Minecraft Query: die versteckte Bedrohung

Query laeuft ueber UDP auf demselben Port wie Java Edition (25565 standardmaessig). Es ist in vielen Hosting-Konfigurationen standardmaessig aktiviert. Selbst wenn du nur Java Edition betreibst und denkst, dass UDP dich nicht betrifft, erzeugt Query eine UDP-Angriffsflaeche.

Drei Probleme mit Query:

1. Amplification - kleine Anfrage, grosse Antwort. Dein Server kann als Verstaerker fuer Angriffe auf andere missbraucht werden.
2. Informationspreisgabe - Query gibt Serverversion, Plugin-Liste (mit Versionen), Spieler-IPs bei Full Query zurueck. Aufklaerung vor dem echten Angriff.
3. Ressourcenverbrauch - jede Query-Anfrage wird vom Haupt-Thread des Servers verarbeitet. Eine Flut von Query-Anfragen kann TPS-Einbrueche verursachen.

# Query in server.properties deaktivieren
enable-query=false

Praktische Empfehlungen: was du jetzt tun solltest

Fuer alle Server

• Query deaktivieren (enable-query=false)
• Alle ungenutzten Ports schliessen (besonders UDP)
• Firewall mit Port-Whitelist aktivieren
• RCON nicht ins Internet exponieren
• Echte Server-IP hinter DDoS-Schutz verstecken

Fuer Java Edition (TCP)

# SYN Cookies
sysctl -w net.ipv4.tcp_syncookies=1

# Backlog erhoehen
sysctl -w net.core.somaxconn=65535
sysctl -w net.ipv4.tcp_max_syn_backlog=65535

# SYN-ACK Retries begrenzen
sysctl -w net.ipv4.tcp_synack_retries=2

Fuer Bedrock Edition (UDP)

# UDP-Empfangspuffer erhoehen
sysctl -w net.core.rmem_max=26214400

# Rate Limiting via iptables
iptables -A INPUT -p udp --dport 19132 \
  -m hashlimit \
  --hashlimit-above 50/sec \
  --hashlimit-burst 100 \
  --hashlimit-mode srcip \
  --hashlimit-name bedrock \
  -j DROP

# UDP-Port 25565 schliessen wenn Query deaktiviert
iptables -A INPUT -p udp --dport 25565 -j DROP

Haeufige Fehler von Administratoren

Einige typische Fehler, die Minecraft-Server-Administratoren machen und die einen kleinen Angriff in vollstaendige Ausfallzeit verwandeln.

Fehler 1: Offene Ports. Auf dem Server ist alles offen: 25565 TCP und UDP, 19132, RCON auf 25575, SSH auf Standard-22. Jeder offene Port ist ein Angriffsvektor. Schliesse alles, was nicht gebraucht wird.

Fehler 2: Query aktiviert. Es lohnt sich zu wiederholen: Query ist in vielen Builds standardmaessig aktiviert. Es wird fuer den Serverbetrieb nicht benoetigt. Es wird nur fuer Monitoring gebraucht, und selbst dafuer gibt es bessere Alternativen.

Fehler 3: Echte Server-IP im DNS. Wenn die IP deines Servers dem Angreifer bekannt ist, kann er direkt angreifen und jeden Cloud-Schutz umgehen. Verwende DDoS-Schutz mit Proxying und zeige nie die echte IP.

Fehler 4: Kein Rate Limiting. Ohne Geschwindigkeitsbegrenzung kann eine einzelne IP Tausende Anfragen pro Sekunde senden. Selbst einfaches hashlimit in iptables reduziert die Effektivitaet von Angriffen erheblich.

Fehler 5: sysctl ignorieren. Standard-Linux-Parameter sind nicht fuer Betrieb unter Last ausgelegt. SYN Cookies deaktiviert, Backlog klein, UDP-Puffer minimal. Fuenf Minuten sysctl-Konfiguration koennen eine Stunde Ausfallzeit verhindern.

Fazit

TCP- und UDP-Angriffe auf Minecraft-Server sind zwei verschiedene Welten. TCP-Angriffe (SYN Flood, ACK Flood, Slowloris) sind gefaehrlich, aber gut erforscht und effektiv filterbar durch SYN Cookies, Conntrack und Stateful Inspection. UDP-Angriffe (Flood, Amplification, Query-Missbrauch) sind schwieriger und gefaehrlicher: hoehere Volumen, einfacheres Spoofing, schwierigere Filterung.

Wenn du Java Edition betreibst, stelle sicher, dass SYN Cookies aktiviert und Query deaktiviert ist. Wenn Bedrock, investiere in Rate Limiting und Upstream-Filterung. Wenn beides, nutze einen Schutz, der den Unterschied zwischen den Protokollen versteht und jedes mit eigenem Regelsatz filtert.

Es gibt keinen universellen "Vor allem schuetzen"-Knopf. Aber zu verstehen, wie Angriffe auf jedes Protokoll funktionieren, ist der erste Schritt zum Aufbau einer echten Verteidigung.