Nach einem DDoS-Angriff: Minecraft Server wiederherstellen und Wiederholung verhindern

Der DDoS-Angriff ist vorbei. Dein Server liegt entweder flach oder reagiert kaum noch. Die Konsole ist voller Fehler, Spieler fragen im Discord "Wann wird es repariert?", und du weisst nicht, wo du anfangen sollst. Kommt dir bekannt vor?

Dieser Artikel ist fuer alle, die bereits von einem DDoS getroffen wurden und jetzt die Scherben aufsammeln. Wir werden nicht besprechen, was DDoS ist oder wie es funktioniert. Stattdessen konzentrieren wir uns auf konkrete Schritte: was jetzt sofort zu tun ist, wie du deinen Server ueberpruefst, wie du wiederherstellst und wie du sicherstellst, dass es nicht noch einmal passiert.

Ich habe den Prozess in 12 Schritte aufgeteilt. Du kannst sie der Reihe nach durchgehen oder direkt zum benoetigten Abschnitt springen. Aber wenn du die Zeit hast, geh alle Schritte durch. Jeder einzelne ist wichtig.

Schritt 1: Aktuellen Zustand bewerten

Bevor du irgendetwas reparierst, musst du das Ausmass des Schadens verstehen. Oeffne deinen Server nicht sofort fuer Spieler nach einem Angriff. Pruefe zuerst alles in Ruhe. Das ist entscheidend: Wenn du den Server mit beschaedigten Daten oeffnest, fangen die Spieler an zu spielen, und die Beschaedigung wird beim naechsten Speichern zementiert.

Laeuft der Server ueberhaupt?

Per SSH verbinden und die Grundlagen pruefen:

# Pruefe ob der Java-Prozess lebt
ps aux | grep java

# Systemlast pruefen
top -bn1 | head -20

# Festplattenspeicher pruefen
df -h

# Netzwerkverbindungen pruefen
ss -tulnp | grep 25565

Wenn der Java-Prozess abgestuerzt ist, starte ihn nicht sofort neu. Pruefe zuerst die Logs. Wenn der Server haengt, aber der Prozess noch lebt, erstelle einen Thread-Dump (kill -3 <PID>) bevor du den Prozess beendest. Das kann zeigen, was genau eingefroren ist.

Achte auf die CPU-Zeit des Prozesses (TIME-Spalte in top). Wenn Java seit laengerer Zeit 100% CPU verbraucht, steckt es wahrscheinlich in einer Endlosschleife oder einem GC-Sturm. Ein Thread-Dump ist in diesem Fall besonders nuetzlich.

Netzwerk pruefen

Ein DDoS-Angriff kann die Netzwerkschnittstelle ueberlastet haben, und Restprobleme koennen nach dem Angriff bestehen bleiben:

# Netzwerkschnittstelle pruefen
ip -s link show eth0

# Nach Fehlern und Drops suchen
ifconfig eth0 | grep -i "error\|drop"

# Conntrack-Tabelle pruefen
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

Wenn Conntrack voll ist, werden neue Verbindungen abgelehnt. Lass alte Eintraege von selbst ablaufen oder mache einen sauberen Neustart, anstatt die Tabelle auf einem laufenden System zu flushen.

Pruefe auch, ob dein Hoster eine automatische Null-Route angewendet hat. Einige Anbieter blockieren deine IP auf Netzwerkebene fuer mehrere Stunden, wenn sie DDoS erkennen. In diesem Fall ist dein Server auch nach Ende des Angriffs aus dem Internet nicht erreichbar. Pruefe das Hoster-Panel oder kontaktiere den Support.

Zeitlinie festhalten

Notiere die genauen Start- und Endzeiten des Angriffs. Du brauchst das fuer:

• Bestimmung des Wiederherstellungspunkts aus dem Backup
• Log-Analyse
• Post-Mortem-Erstellung
• Eine eventuelle Anzeige bei der Polizei

Wenn du die genaue Startzeit nicht kennst, suche in den Server-Logs nach dem Moment der massenhaften Spieler-Disconnects oder dem ersten Anstieg der Fehlermeldungen.

Schritt 2: Datenintegritaet pruefen

Das ist der wichtigste Schritt. Ein DDoS-Angriff selbst aendert keine Dateien auf deinem Server. Aber wenn der Server unsauber abgestuerzt ist (kill -9, OOM, Freeze), kann Datenbeschaedigung auftreten. Minecraft speichert die Welt periodisch, und wenn der Prozess mitten beim Schreiben unterbrochen wurde, koennen Dateien in einem ungueltigen Zustand landen.

Weltdateien

Weltbeschaedigung ist das schmerzhafteste Problem. Warnzeichen:

• Server stuerzt beim Laden bestimmter Chunks ab
• Chunks sind auf eine aeltere Version zurueckgefallen
• Leere Chunks ("Loecher") in der Welt
• Beschaedigte level.dat-Datei
• Fehlermeldungen beim Lesen von Region-Dateien in den Logs

Pruefung:

# Weltdateigroessen - ploetzliches Schrumpfen ist verdaechtig
ls -la world/region/
ls -la world/level.dat

# Nach Null-Byte-Regionsdateien suchen
find world/region/ -size 0

Wenn level.dat beschaedigt ist, versuche level.dat_old. Minecraft speichert automatisch ein Backup der vorherigen Version. Die level.dat-Datei enthaelt kritische Informationen: Weltzeit, Spawn-Position, Welt-Generator, Spielregeln. Ohne sie startet der Server nicht.

Region-Dateien (.mca) speichern Chunk-Blockdaten. Jede Datei deckt einen 32x32-Chunk-Bereich ab. Wenn eine bestimmte Region-Datei beschaedigt ist, verlierst du nur diesen Bereich, nicht die gesamte Welt. MCASelector ermoeglicht es dir, beschaedigte Chunks visuell zu finden und zu loeschen, woraufhin Minecraft sie beim Laden regeneriert.

Spielerdaten

# Playerdata-Dateien pruefen
ls -la world/playerdata/

# Null-Byte-Dateien finden (verlorene Spielerdaten)
find world/playerdata/ -size 0

# Advancements pruefen
find world/advancements/ -size 0

# Stats pruefen
find world/stats/ -size 0

Null-Byte-Playerdata-Dateien bedeuten, dass die Daten des Spielers weg sind. Inventar, Position, Erfolge, Gesundheit, Erfahrungslevel, alles. Wiederherstellung ist nur aus einem Backup moeglich.

Wenn nur einige Spieler ihre Daten verloren haben, aber nicht alle, bedeutet das normalerweise, dass der Server genau waehrend des Speicherzyklus fuer diese bestimmten Spieler abgestuerzt ist. Das passiert, wenn der OOM Killer oder der Kernel den Prozess mitten im Auto-Save beendet.

Pruefe auch separat die Wirtschaftsdaten. Wenn du Plugins wie Vault, EssentialsX oder CMI mit dateibasierter Speicherung verwendest, pruefe auch deren Datendateien. Der Verlust des Kontostands eines Spielers ist ein ernstes Problem, das zu Community-Konflikten fuehren kann.

Konfigurationen

Configs ueberleben einen DDoS normalerweise problemlos. Pruefe trotzdem:

# Pruefe ob Configs nach dem letzten bekannten guten Zustand geaendert wurden
find . -name "*.yml" -newer /tmp/last_known_good -type f

# ops.json auf verdaechtige Aenderungen pruefen
cat ops.json

Achte besonders auf server.properties, spigot.yml, paper.yml und Plugin-Configs. Wenn du vermutest, dass jemand waehrend des Angriffs Zugang erhalten hat (unwahrscheinlich bei reinem DDoS, aber moeglich bei kombinierten Angriffen), pruefe ops.json, whitelist.json und banned-players.json.

Ein kombinierter Angriff bedeutet, dass DDoS als Ablenkung verwendet wird. Waehrend du mit dem DDoS beschaeftigt bist, versucht der Angreifer, Plugin-Schwachstellen auszunutzen oder RCON- bzw. SSH-Passwoerter zu bruteforcen. Klingt paranoid, kommt aber vor.

Datenbank

Wenn du MySQL/MariaDB fuer Plugins verwendest (LuckPerms, ShopGUI+ usw.), pruefe die Tabellenintegritaet:

-- MySQL
CHECK TABLE luckperms_user_permissions;
CHECK TABLE luckperms_group_permissions;

Datenbanken sind dank Transaktionsprotokollierung (WAL/InnoDB-Log) im Allgemeinen widerstandsfaehig gegen ploetzliche Unterbrechungen. Aber eine Pruefung schadet nicht.

Schritt 3: Logs analysieren

Logs erzaehlen dir, was passiert ist. Ueberspringe diesen Schritt nicht, auch wenn du alles schnell wieder online bringen willst. Das Verstaendnis der Angriffsart hilft dir, den richtigen Schutz einzurichten.

Server-Logs

# Letzte Eintraege vor dem Absturz
tail -200 logs/latest.log

# Nach Angriffsmustern suchen
grep -i "connection\|disconnect\|timeout\|overflow" logs/latest.log | tail -50

# Verbindungsanzahl ueber die Zeit
grep "logged in with entity" logs/latest.log | awk '{print $1, $2}' | uniq -c | sort -rn | head -20

Achte auf:

• Ploetzlicher Anstieg der Verbindungen in kurzer Zeit. Wenn sich 500 "Spieler" innerhalb einer Minute verbunden haben, ist das ein Bot-Angriff
• Massenhafte Disconnects mit identischer Fehlermeldung
• Lese-/Schreib-Timeouts ("Read timed out", "Connection reset")
• OutOfMemoryError oder aehnliche kritische Fehler
• Ungewoehnliche IPs, die sich wiederholt verbinden
• "Can't keep up! Is the server overloaded?"-Meldungen

Wenn du Paper oder seine Forks verwendest, koennten in der logs/-Ordner Dateien mit Datum sein. Pruefe die Logs der Angriffstage. Schau dir auch Timings-Berichte an (falls aktiviert); sie zeigen, welche Serverkomponenten am staerksten belastet waren.

System-Logs

# dmesg auf Netzwerk- oder Speicherprobleme pruefen
dmesg | tail -100

# OOM Killer?
dmesg | grep -i "oom\|killed"

# Netzwerkprobleme
dmesg | grep -i "eth0\|network\|link"

# Syslog auf Conntrack-Probleme pruefen
grep -i "conntrack\|nf_conntrack" /var/log/syslog | tail -20

Wenn der Kernel deinen Prozess ueber den OOM Killer beendet hat, siehst du den entsprechenden Eintrag. Das bedeutet, der Angriff hat den gesamten verfuegbaren Speicher erschoepft. Erwaege eine Erhoehung der Speicherlimits oder die Einrichtung von Swap.

Der Eintrag nf_conntrack: table full, dropping packet im Syslog bedeutet, dass die Verbindungsverfolgungstabelle uebergelaufen ist. Das ist ein klassisches Zeichen eines DDoS-Angriffs mit hoher Verbindungsanzahl.

Hosting-Panel

Wenn du auf einem VPS bist, pruefe das Panel deines Hosters. Viele Anbieter protokollieren Netzwerkanomalien und stellen Traffic-Grafiken bereit. Einige schalten automatisch Null-Route ein, wenn sie DDoS erkennen. Das bedeutet, deine IP wurde moeglicherweise auf Provider-Ebene blockiert. Klaere das mit dem Support.

Bitte deinen Hoster um Netflow-Daten oder zumindest eine Traffic-Grafik fuer den Angriffszeitraum. Das hilft dir, das Angriffsvolumen (Gbps/Mpps) zu verstehen und ein entsprechendes Schutzniveau zu waehlen.

Angriffstyp identifizieren

Aus den Logs kannst du die Art des Angriffs bestimmen:

• Volumetrisch (UDP/ICMP Flood): Server war nicht erreichbar, wenig in den Logs, Hoster meldete einen eingehenden Traffic-Spike. Dein Server war nicht schuld; die Leitung wurde einfach mit Muell geflutet.
• TCP SYN Flood: Viele halboffene Verbindungen, Conntrack uebergelaufen, Server lief, aber neue Spieler konnten sich nicht verbinden.
• Application-Layer (Bot-Angriff): Massenverbindungen in den Server-Logs, Server laggete wegen CPU-Last, TPS sank.
• Kombiniert: Anzeichen mehrerer Typen gleichzeitig. Das schlimmste Szenario.

Der Angriffstyp bestimmt, welchen Schutz du brauchst. Gegen volumetrische Angriffe hilft nur ein externer Filter. Gegen Application-Layer koennen Plugins und Firewall-Regeln helfen.

Schritt 4: Pruefen ob die IP geleakt wurde

Einer der Hauptgruende fuer wiederholte Angriffe: der Angreifer kennt deine IP und kann jederzeit wieder zuschlagen. Solange deine IP bekannt ist, bist du gefaehrdet.

Wie deine IP geleakt sein koennte:

• DNS-A-Record zeigt direkt auf deinen Server. Jeder kann einen nslookup deiner Domain machen
• Ein Spieler mit einem Client-Mod, der Server-IPs protokolliert
• Deine IP wurde auf einer Server-Listing-Seite veroeffentlicht (mc-monitoring, minecraft-server-list usw.)
• Ein Admin hat die IP in einem Chat oder Forum geteilt
• Der Angreifer hat sie ueber DNS-History-Abfragen gefunden (SecurityTrails, DNSHistory)
• Ein SRV-DNS-Record, der zu einem A-Record mit der echten IP aufloest
• Eines deiner Plugins hat externe Anfragen gemacht und die Server-IP offengelegt

Wenn der Angriff direkt auf deine IP zielte (nicht auf eine Domain), ist diese IP kompromittiert und muss geaendert werden. Du kannst die DNS-History auf SecurityTrails pruefen. Wenn deine echte IP jemals in einem DNS-Record war, ist sie bereits bekannt.

Detaillierter Guide zum Verstecken deiner IP: So versteckst du die IP deines Minecraft Servers.

Schritt 5: Aus Backups wiederherstellen

Wenn Daten beschaedigt sind, musst du aus einem Backup wiederherstellen. Wenn du keine Backups hast, ist das eine schmerzhafte Lektion. Richte nach der Wiederherstellung sofort automatische Backups ein. Backups sind die Sache, die man nie braucht, bis man sie dringend braucht.

Korrekter Wiederherstellungsprozess

1. Server komplett stoppen. Stelle niemals Dateien auf einem laufenden Server wieder her. Der Java-Prozess kann Dateien offen halten, und deine Aenderungen werden beim naechsten Speichern ueberschrieben.

2. Wiederherstellungspunkt identifizieren. Finde das letzte Backup, das vor Beginn des Angriffs erstellt wurde. Verwende kein Backup, das waehrend des Angriffs erstellt wurde; es kann beschaedigte Daten enthalten. Wenn Auto-Backups alle 6 Stunden laufen und der Angriff um 15:00 begann, verwende das Backup von 12:00.

3. Aktuellen Zustand sichern vor der Wiederherstellung. Auch wenn er beschaedigt ist. Fuer den Fall, dass etwas schiefgeht, oder wenn sich spaeter herausstellt, dass die beschaedigten Daten etwas Nuetzliches enthalten.

# Beschaedigten Zustand sichern
tar czf /backup/damaged_$(date +%Y%m%d_%H%M%S).tar.gz ./

4. Daten wiederherstellen:

# Nur die Welt wiederherstellen, wenn das das einzige Problem ist
tar xzf /backup/world_backup_clean.tar.gz -C ./

# Oder vollstaendige Wiederherstellung
tar xzf /backup/full_backup_clean.tar.gz -C ./

5. Pruefen und starten im Testmodus, ohne fuer Spieler zu oeffnen. Logge dich selbst ein, besuche die wichtigsten Orte, pruefe ob die Welt korrekt laedt.

Wiederherstellung ohne Backups

Wenn du keine Backups hast und die Welt beschaedigt ist, versuche Wiederherstellungstools:

• MCASelector - ein visuelles Tool zur Arbeit mit Region-Dateien. Ermoeglicht das Finden und Loeschen beschaedigter Chunks. Minecraft regeneriert sie beim Laden.
• NBTExplorer - zum manuellen Bearbeiten von level.dat und anderen NBT-Dateien.
• Region Fixer - ein Python-Skript zur automatischen Pruefung und Reparatur von Region-Dateien.

Keine Garantie, aber besser als von Null anzufangen. Wenn nur wenige Chunks beschaedigt sind, schafft es MCASelector. Wenn level.dat beschaedigt ist, kann NBTExplorer helfen, es manuell zu reparieren.

Mehr ueber Backup-Strategien: Backup-Strategie fuer Minecraft Server.

Schritt 6: Server haerten

Wiederherstellen allein reicht nicht. Du musst sicherstellen, dass der naechste Angriff nicht den gleichen Schaden verursacht. Betrachte es als Aufruestung deiner Verteidigung nach einer Belagerung.

IP-Adresse aendern

Wenn der Angreifer deine IP kennt, kommt er zurueck. Die IP zu aendern ist das Erste, was du tun solltest. Solange du auf derselben IP bist, bist du jederzeit fuer einen erneuten Angriff anfaellig.

• Auf VPS: Neue IP beim Hoster anfordern oder auf einen anderen Server migrieren. Die meisten Hoster bieten IP-Wechsel kostenlos oder gegen eine geringe Gebuehr an
• Auf Dedicated: IP-Wechsel beim Provider beantragen. Normalerweise kostenlos, kann aber dauern
• Auf Home-Server: Router neu starten (bei dynamischer IP) oder Wechsel beim Internetanbieter beantragen
• Nach dem Wechsel: DNS-Records aktualisieren, aber die neue IP nicht oeffentlich machen

Wichtig: Die neue IP sollte vom ersten Tag an hinter einem Proxy oder DDoS-Schutz versteckt sein. Sonst wird sie ueber DNS oder Server-Listing-Seiten wieder gefunden.

Firewall-Regeln

Grundlegende iptables-Regeln, die jeder Minecraft-Server haben sollte:

# Verbindungen auf Port 25565 begrenzen
iptables -A INPUT -p tcp --dport 25565 -m connlimit --connlimit-above 3 -j DROP

# Rate Limiting fuer neue Verbindungen
iptables -A INPUT -p tcp --dport 25565 -m state --state NEW -m recent --set
iptables -A INPUT -p tcp --dport 25565 -m state --state NEW -m recent --update --seconds 60 --hitcount 10 -j DROP

# Alle Ports schliessen ausser den benoetigten
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 25565 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -j DROP

Das stoppt keinen ernsthaften DDoS, filtert aber kleine Angriffe und Port-Scans. Erwaege auch, den SSH-Zugang per IP einzuschraenken, wenn du dich von einer festen Adresse verbindest. Das eliminiert Brute-Force-Versuche.

Mehr Details zu iptables fuer Minecraft: Was tun bei DDoS auf den Minecraft Server.

Kernel-Netzwerk-Tuning

Fuer Linux-Server ist es nuetzlich, sysctl-Parameter zu optimieren:

# Conntrack-Tabelle vergroessern
net.netfilter.nf_conntrack_max = 262144

# Conntrack-Timeouts beschleunigen
net.netfilter.nf_conntrack_tcp_timeout_established = 600
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 30

# SYN-Flood-Schutz
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 4096

# Schnellere Socket-Wiederverwendung
net.ipv4.tcp_tw_reuse = 1

Diese Parameter helfen dem Server, Verbindungsspitzen besser zu bewaeltigen und Ressourcen von abgeschlossenen Verbindungen schneller freizugeben.

Server-Einstellungen

In server.properties:

max-players=100
rate-limit=10
network-compression-threshold=256

Der Parameter rate-limit begrenzt Pakete pro Sekunde von einem einzelnen Client. Wenn ein Client das Limit ueberschreitet, wird die Verbindung getrennt. Ein Wert von 10 ist eine gute Balance zwischen Schutz und Benutzerfreundlichkeit.

In spigot.yml:

settings:
  connection-throttle: 4000

connection-throttle ist das Mindestintervall in Millisekunden zwischen Verbindungen von derselben IP. Ein Wert von 4000 (4 Sekunden) stoert normale Spieler nicht, bremst aber Bots.

Anti-Bot-Plugins

• EpicGuard - kostenloses Anti-Bot mit CAPTCHA-Verifizierung, VPN-Blockierung und Geo-Filterung
• AntiBot - Verbindungslimits, Client-Verifizierung, Geo-Filterung
• BotSentry - erweiterter Bot-Schutz mit Machine Learning

Plugins helfen gegen einfache Bot-Angriffe. Gegen volumetrischen DDoS sind sie machtlos. Fuer echten Schutz brauchst du einen externen Dienst. Ein Plugin kann Traffic nicht filtern, der den Java-Prozess nie erreicht, weil die Leitung bereits geflutet ist.

Schritt 7: DDoS-Schutz einrichten

Wenn du bis hierhin gelesen hast, warst du bereits durch einen DDoS und verstehst, dass das kein Spass ist. Plugins und iptables bieten eine Grundlage. Gegen einen ernsthaften Angriff brauchst du einen externen DDoS-Filter, der den Traffic verarbeitet, bevor er deinen Server erreicht.

Was ein guter Filter koennen sollte:

• Traffic filtern, bevor er deinen Server erreicht. Traffic sollte ueber einen Filterknoten laufen, nicht direkt ankommen
• Die echte IP deines Servers verstecken. Spieler verbinden sich mit der IP des Filters, nicht mit deiner
• Sowohl TCP- als auch UDP-Protokolle verarbeiten (Bedrock nutzt UDP)
• Minimale Latenz hinzufuegen (< 5 ms zusaetzlich)
• Angriffe automatisch erkennen und mitigieren, ohne manuellen Eingriff
• Legitime Spieler auch waehrend eines Angriffs durchlassen

MineGuard bietet genau diesen Schutz: Der gesamte Traffic laeuft ueber einen filternden Proxy, die echte IP ist versteckt, und Angriffe werden automatisch mitigiert. Die Einrichtung dauert 5 Minuten und erfordert keine Aenderungen an deiner Server-Software.

Warum nicht CloudFlare oder normales "Anti-DDoS"-Hosting?

CloudFlare ist ein grossartiger Dienst fuer Websites, aber es proxied TCP/UDP-Traffic fuer Minecraft nicht im kostenlosen Plan. CloudFlare Spectrum kann das, startet aber bei 5$/Monat fuer 5 Gbps und hat keine Minecraft-spezifische Filterung.

Hoster werben oft mit "DDoS-Schutz inklusive", aber in der Praxis bedeutet das Null-Routing bei Erkennung (deine IP wird fuer 24 Stunden blockiert) oder grundlegende L3/L4-Filterung, die gegen Application-Layer-Angriffe nicht hilft.

Schritt 8: Auto-Backups einrichten

Wenn du vor dem Angriff keine Backups hattest, richte sie jetzt sofort ein. Verschiebe es nicht. Der naechste Vorfall kann morgen passieren.

Die 3-2-1-Strategie

Die klassische Backup-Strategie:

• 3 Kopien deiner Daten
• Auf 2 verschiedenen Medientypen
• 1 Kopie an einem entfernten Ort

Fuer einen Minecraft-Server koennte das so aussehen:

• Lokales Backup auf demselben Server (fuer schnelle Wiederherstellung)
• Backup auf einem separaten VPS oder NAS
• Cloud-Backup (S3, Google Cloud Storage, Backblaze B2)

Zeitplan

• Alle 30 Minuten: Welt-Auto-Save (eingebauter save-all-Befehl)
• Alle 4-6 Stunden: Vollstaendiges Backup von Welt und Spielerdaten
• Taeglich: Vollstaendiges Backup inklusive Configs und Plugins
• Woechentlich: Vollstaendiges Server-Backup inklusive Datenbanken

Automatisierung

Ein einfaches Cron-Backup-Skript:

#!/bin/bash
# /opt/backup-minecraft.sh
BACKUP_DIR="/backup/minecraft"
SERVER_DIR="/opt/minecraft"
DATE=$(date +%Y%m%d_%H%M%S)

# save-all ueber screen/tmux senden
screen -S minecraft -p 0 -X stuff "save-all\n"
sleep 5
screen -S minecraft -p 0 -X stuff "save-off\n"
sleep 2

# Backup erstellen
tar czf "$BACKUP_DIR/world_$DATE.tar.gz" -C "$SERVER_DIR" world world_nether world_the_end

# Auto-Save wieder aktivieren
screen -S minecraft -p 0 -X stuff "save-on\n"

# Backups aelter als 7 Tage loeschen
find "$BACKUP_DIR" -name "world_*.tar.gz" -mtime +7 -delete

In Crontab eintragen: 0 */4 * * * /opt/backup-minecraft.sh

Mehr ueber Backup-Strategien: Backup-Strategie fuer Minecraft Server.

Schritt 9: Kommunikation mit Spielern

Ignoriere deine Community nicht. Spieler haben bemerkt, dass der Server offline war, und wollen wissen, was passiert ist. Transparenz ist wichtiger als cool zu wirken. Spieler, die die Situation verstehen, sind loyaler als Spieler, die im Dunkeln gelassen werden.

Was du mitteilen solltest

• Der Server wurde von einem DDoS-Angriff getroffen (keine Schande, passiert den Besten. Hypixel, 2b2t, MineHeroes haben das alles durchgemacht)
• Welche Daten betroffen sein koennten (Welt-Rollback, verlorener Fortschritt)
• Was du zur Wiederherstellung getan hast
• Welche Massnahmen du ergriffen hast, um es zu verhindern
• Wie Spieler Probleme melden koennen (fehlende Items, falsche Position)

Was du NICHT sagen solltest

• Beschuldige keine bestimmten Personen ohne Beweise. Auch wenn du jemanden verdaechtigst, koennen oeffentliche Anschuldigungen zu Community-Toxizitaet fuehren
• Teile keine technischen Angriffsdetails (Typ, Volumen, Quellen). Das sind Informationen fuer den Angreifer darueber, was funktioniert hat
• Versprich nicht "Das wird nie wieder passieren." Versprich "Wir haben Massnahmen ergriffen, um es zu verhindern"
• Keine Panik, kein Drama. "Wir wurden von Hackern gehackt!!!" klingt unprofessionell

Beispiel Discord-Nachricht

Hey Leute. Gestern zwischen 14:00 und 18:00 Uhr war der Server
wegen eines DDoS-Angriffs nicht erreichbar. Wir haben den Betrieb
wiederhergestellt, aber die Welt wurde etwa 2 Stunden
zurueckgesetzt (auf den letzten Auto-Save vor dem Angriff).

Was wir getan haben:
- Welt aus Backup wiederhergestellt
- Server-IP geaendert
- DDoS-Schutz eingerichtet

Wenn euch fehlende Items oder andere Probleme auffallen, erstellt
bitte ein Ticket in #support. Wir helfen so gut wir koennen.

Sorry fuer die Unannehmlichkeiten.

Kurz, ehrlich, keine Panik. Spieler schaetzen das. Wenn der Angriff zu erheblichem Datenverlust gefuehrt hat, erwaege eine Entschaedigung fuer betroffene Spieler. Das koennen Item-Wiederherstellungen, Boni oder Spielwaehrung sein. Nicht zwingend, aber es baut guten Willen auf.

Nachrichten-Timing

• Waehrend des Angriffs: Kurze Nachricht "Server ist voruebergehend nicht erreichbar, wir arbeiten daran"
• Direkt nach der Wiederherstellung: Detaillierte Nachricht mit Situationsbeschreibung
• 24-48 Stunden spaeter: Update ueber ergriffene Schutzmassnahmen, falls es grössere Aenderungen gab

Schritt 10: Rechtliche Aspekte

Kann man einen DDoS-Angriff bei der Polizei anzeigen? Technisch ja. Praktisch ist es kompliziert, aber es gibt Situationen, in denen es notwendig ist.

DDoS-Angriffe sind in praktisch jeder Rechtsordnung illegal. In Deutschland fallen sie unter StGB Paragraph 303b (Computersabotage). In Oesterreich gilt Paragraph 126b StGB (Stoerung der Funktionsfaehigkeit eines Computersystems). In der Schweiz Art. 144bis StGB. Die Herausforderung ist die grenzueberschreitende Ermittlung, besonders wenn der Angreifer ein Botnet aus verschiedenen Laendern nutzt.

Was du fuer eine Anzeige brauchst

• Server-Logs mit Zeitstempeln
• Traffic-Daten vom Hosting-Provider (Netflow, Grafiken)
• Jegliche Kommunikation mit dem Angreifer (Drohungen, Loesegeldforderungen)
• Informationen ueber finanzielle Schaeden (entgangene Spenden, Serverkosten)

Praktischer Rat

Bewahre alle Logs und Beweise auf, auch wenn du jetzt keine Anzeige erstatten willst. Wenn die Angriffe weitergehen oder zu Erpressung eskalieren ("Zahle 500 Euro oder wir ddosen dich jeden Tag"), steigt die Chance, dass die Strafverfolgung aktiv wird, deutlich. Verjaehrungsfristen fuer Cyberverbrechen liegen in den meisten Rechtsordnungen zwischen 2 und 6 Jahren, Beweise koennen also spaeter noch nuetzlich sein.

Was du aufbewahren solltest:

• Vollstaendige Server-Logs vom Angriffszeitraum
• Screenshots von Traffic-Grafiken deines Hosters
• Jegliche Kommunikation mit dem Angreifer
• Aufzeichnungen ueber Ausfallzeiten und finanzielle Verluste
• IP-Adressen aus den Logs (auch wenn sie meist gefaelscht sind oder zu einem Botnet gehoeren)

Schritt 11: Incident Response Plan

Warte nicht auf den naechsten Angriff, um darueber nachzudenken, was zu tun ist. Bereite einen Plan im Voraus vor. Wenn ein DDoS tobt, wirst du nervoes sein und offensichtliche Dinge vergessen. Ein fertiger Plan spart Zeit und Nerven.

Was der Plan enthalten sollte

1. Kontakte: Wer verwaltet den Server, wie erreicht man den Hoster/Schutzanbieter, Kontaktdaten der Co-Admins
2. Prioritaeten: Was ist wichtiger, Wiederherstellungsgeschwindigkeit oder Datenintegritaet. Fuer einen PvP-Server mit Rankings ist jede Minute Ausfallzeit kritisch. Fuer einen RPG-Server ist die Erhaltung des Spielerfortschritts wichtiger
3. Verfahren: Schritt-fuer-Schritt-Anleitungen fuer jeden Vorfalltyp. Schreibe sie so, dass auch ein nicht-technischer Moderator die ersten Schritte ausfuehren kann
4. Backups: Wo gespeichert, wie wiederherstellen, wer hat Zugang. Bewahre diese Informationen an mehreren Orten auf
5. Kommunikation: Nachrichtenvorlagen fuer Spieler, Benachrichtigungskanaele (Discord, Twitter, Foren)
6. Eskalation: Wann den Hoster anrufen, wann zusaetzlichen Schutz aktivieren, wann es Zeit ist die IP zu wechseln
7. Post-Mortem: Was nach der Wiederherstellung zu tun ist (Vorlage ausfuellen, Plan aktualisieren)

Schnellreaktions-Checkliste

Drucke diese Checkliste aus oder speichere sie als Lesezeichen. Wenn ein Angriff beginnt, wirst du dir selbst danken:

[ ] Angriff erkannt, Zeit notiert
[ ] Team benachrichtigt (Discord/Telegram)
[ ] Bewertung: Server laeuft oder liegt?
[ ] Falls DDoS-Schutz vorhanden: Filterstatus pruefen
[ ] Falls kein Schutz: Hoster kontaktieren
[ ] Spieler benachrichtigt (kurz, keine Panik)
[ ] Logs gesichert (Kopie an separatem Ort)
[ ] Angriff beendet: Serverzustand pruefen
[ ] Datenintegritaet ueberpruefen (Welt, Playerdata, Configs)
[ ] Bei Bedarf aus Backup wiederherstellen
[ ] Server im Testmodus starten
[ ] Fuer Spieler oeffnen
[ ] Post-Mortem: aufschreiben was passiert ist und was verbessert werden muss

Schritt 12: Post-Mortem-Vorlage

Nach jedem Vorfall solltest du aufschreiben, was passiert ist. Das hilft dir (und deinem Team), aus Fehlern zu lernen und beim naechsten Mal schneller zu reagieren. Hier ist eine einfache Vorlage:

# Post-Mortem: [Datum des Vorfalls]

## Zeitablauf
- [HH:MM] Problem erkannt (wer hat es erkannt, wie)
- [HH:MM] Als DDoS identifiziert
- [HH:MM] Massnahmen ergriffen
- [HH:MM] Server wiederhergestellt
- [HH:MM] Fuer Spieler geoeffnet
- [HH:MM] Post-Mortem ausgefuellt

## Auswirkungen
- Ausfallzeit: X Stunden Y Minuten
- Betroffene Daten: (Welt N Stunden zurueckgesetzt / Daten verloren / kein Verlust)
- Betroffene Spieler: ~N
- Finanzielle Verluste: (entgangene Spenden, Wiederherstellungskosten)

## Ursache
- Angriffstyp: (TCP SYN Flood / UDP Flood / Bot-Angriff / unbekannt)
- Volumen: (falls vom Hoster bekannt, in Gbps oder Mpps)
- Dauer: (von ersten Anzeichen bis vollstaendigem Ende)
- Vermutetes Motiv: (Konkurrent / veraeRGerter Spieler / Erpressung / unbekannt)

## Was funktioniert hat
- (was bei der Wiederherstellung geholfen hat)
- (welche Vorbereitungsmassnahmen sich bewaehrt haben)

## Was nicht funktioniert hat
- (was verbessert werden muss)
- (welche Verfahren gefehlt haben)

## Massnahmen zur Verbesserung
- [ ] (konkrete Massnahme 1, Verantwortlicher, Deadline)
- [ ] (konkrete Massnahme 2, Verantwortlicher, Deadline)
- [ ] (konkrete Massnahme 3, Verantwortlicher, Deadline)

Fuenf bis zehn Minuten zum Ausfuellen dieser Vorlage nach einem Vorfall sparen dir Stunden beim naechsten Mal. Bewahre Post-Mortems an einem Ort auf (Google Docs, Notion, ein einfacher Dateiordner) und lies sie vor dem Aktualisieren deines Reaktionsplans noch einmal durch.

Zusammenfassung: Minimaler Aktionsplan

Wenn du dich gerade von einem DDoS erholst, hier der komprimierte Plan auf einer Seite:

1. Starte den Server nicht sofort. Pruefe seinen Zustand per SSH.
2. Ueberpreufe Weltdateien (level.dat, Region-Dateien), Spielerdaten und Configs.
3. Lies die Logs. Verstehe Art und Ausmass des Angriffs.
4. Stelle aus Backup wieder her, wenn Daten beschaedigt sind.
5. Aendere deine IP-Adresse. Die alte ist kompromittiert.
6. Richte Firewall-Regeln, sysctl-Tuning und Server-Limits ein.
7. Aktiviere DDoS-Schutz, bevor du wieder oeffnest.
8. Richte automatische Backups ein, falls noch nicht geschehen.
9. Sag deinen Spielern, was passiert ist. Ehrlich und ohne Panik.
10. Schreibe ein Post-Mortem, solange die Details frisch im Gedaechtnis sind.

Ein DDoS-Angriff ist nicht das Ende. Es ist ein Vorfall, den du bewaeltigen kannst und solltest. Server, die einen DDoS durchleben und die richtigen Schlussfolgerungen ziehen, werden widerstandsfaehiger. Viele der groessten Minecraft-Netzwerke haben Dutzende von Angriffen ueberstanden und sind staerker daraus hervorgegangen. Der Schluessel ist, das Problem nicht zu ignorieren und nicht zu hoffen, dass "es vielleicht nicht wieder passiert." Es wird passieren. Die einzige Frage ist, ob du bereit sein wirst.