Minecraft Server Monitoring: Angriffe in Echtzeit erkennen

Minecraft Server Monitoring: Angriffe in Echtzeit erkennen

Dein Minecraft-Server laeuft grossartig. Spieler bauen, PvP-Arenen brummen, alles stabil. Dann geht ploetzlich alles in die Knie. Spieler beschweren sich ueber Lag, die Konsole wird mit Fehlern ueberflutet, TPS faellt auf Null. Was ist passiert? Ohne Monitoring erfaehrst du es erst, wenn es zu spaet ist.

Monitoring ist kein Luxus fuer grosse Projekte. Es ist eine Grundvoraussetzung fuer jeden Server, der Spieler aus dem Internet akzeptiert. In diesem Artikel behandeln wir alles: von einfachen Terminal-Befehlen bis zum vollstaendigen Stack mit Prometheus und Grafana, Discord-Alerts und automatischen Reaktionsskripten.

Warum ueberhaupt ueberwachen

Einfache Antwort: frueherkennung = schnelle Reaktion. Ein DDoS-Angriff, den du nach 30 Sekunden bemerkst, ist eine Sache. Ein Angriff, von dem du erst 15 Minuten spaeter durch Discord-Beschwerden erfaehrst, ist eine voellig andere Situation.

Ohne Monitoring bist du blind. Du weisst nicht, ob die Serverlast normal oder anomal ist. Du kannst nicht zwischen Lag und einem Angriff unterscheiden. Du kannst deinem Hoster nicht beweisen, dass das Problem auf deren Seite liegt.

Monitoring gibt dir drei Dinge:

  1. Sichtbarkeit - du weisst, was gerade auf dem Server passiert
  2. Historie - du kannst nachschauen, was gestern, letzte Woche oder vor einem Monat war
  3. Automatisierung - das System reagiert auf Anomalien, waehrend du schlaefst

Wichtige Metriken

Nicht alle Metriken sind gleich wichtig. Hier sind die mit hoechster Prioritaet.

Netzwerk-Metriken

Connections per second (CPS) - die Anzahl neuer TCP-Verbindungen pro Sekunde. Normal fuer einen durchschnittlichen Server: 1-10 pro Sekunde. Bei 100+ stimmt etwas nicht. 1000+ ist fast sicher ein Angriff.

Bandwidth (Mbps) - Bandbreitenverbrauch. Minecraft braucht nicht viel Traffic. 50 Spieler erzeugen etwa 10-20 Mbps. Wenn du 500+ Mbps bei 50 Spielern siehst, sind es nicht die Spieler.

Packet rate (pps) - Pakete pro Sekunde. Wichtig fuer die Erkennung von Paketfluten, die zwar kein hohes Trafficvolumen erzeugen, aber die CPU mit Verarbeitung ueberlasten.

Server-Metriken

CPU - Prozessorlast. Minecraft ist in seiner Hauptschleife single-threaded, also achte auf die Last einzelner Kerne. Ein Kern bei 100%, waehrend andere frei sind, ist normales MC-Verhalten unter Last. Alle Kerne am Anschlag deutet auf ein Netzwerkproblem hin.

RAM - Speicherverbrauch. Beobachte nicht nur die Gesamtnutzung, sondern auch das GC-Verhalten (Garbage Collector). Haeufige GC-Pausen toeten die TPS.

Disk I/O - Lese-/Schreibaktivitaet. Minecraft erzeugt hohen I/O beim Speichern von Chunks und Spielerdaten. Hoher I/O-Wait bedeutet Lag unabhaengig von Angriffen.

Minecraft-spezifische Metriken

TPS (Ticks Per Second) - die primaere Gesundheitsmetrik eines MC-Servers. 20 TPS = perfekt. 18-19 = in Ordnung. Unter 15 = Spieler bemerken Lag. Unter 10 = unspielbar.

Spieleranzahl - ein ploetzlicher Sprung bei Verbindungen ohne organisches Wachstum ist ein Warnsignal. Bot-Angriffe sehen oft wie ein scharfer Anstieg der Online-Zahl aus.

Grundlegende Linux-Tools

Beginnen wir mit dem, was auf jedem Linux-Server verfuegbar ist. Keine Installation noetig.

htop: CPU und Speicher in Echtzeit

htop -p $(pgrep -d, java)

Zeigt nur Java-Prozesse (deinen MC-Server). Achte auf:

  • %CPU pro Kern
  • RES (tatsaechlicher RAM-Verbrauch)

iftop: Netzwerk-Traffic

sudo iftop -i eth0 -n -P

-n deaktiviert DNS-Aufloesung, -P zeigt Ports. Du siehst, wer Traffic sendet und wie viel.

nethogs: Traffic nach Prozess

sudo nethogs eth0

Zeigt, welcher Prozess Traffic verbraucht. Wenn java 500 Mbps frisst, waehrend es normal 20 Mbps sind, stimmt etwas nicht.

vnstat: Traffic-Historie

# Installation
sudo apt install vnstat

# Tagesstatistik
vnstat -d

# Echtzeit
vnstat -l -i eth0

vnstat sammelt Traffic-Statistiken und speichert sie. So kannst du Muster erkennen: "Wie viel Traffic gab es gestern um die gleiche Zeit?"

Verbindungsanalyse mit ss

Dein Hauptwerkzeug zur Diagnose von Netzwerkangriffen. ss ist schneller als netstat.

Verbindungsuebersicht

ss -s

Ausgabe sieht etwa so aus:

TCP:   1247 (estab 89, closed 1102, orphaned 3, timewait 1098)

Wenn closed oder timewait deutlich hoeher als estab ist, deutet das auf einen SYN-Flood oder Connection-Flood hin.

Verbindungen nach Status zaehlen

ss -tan | awk '{print $1}' | sort | uniq -c | sort -rn

Normal:

     89 ESTAB
     12 TIME-WAIT
      3 LISTEN

Nicht normal (Angriff):

    847 SYN-RECV
     89 ESTAB
    203 TIME-WAIT

847 Verbindungen im SYN-RECV-Zustand sind ein klassischer SYN-Flood.

Top-IPs nach Verbindungsanzahl

ss -tan | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

Wenn eine IP 200+ Verbindungen zu deinem Server hat, ist es entweder ein Proxy oder ein Angriff. Ein normaler Spieler hat 1-3 Verbindungen.

Prometheus + Grafana: Ernsthaftes Monitoring

Grundlegende Tools sind gut fuer manuelle Diagnose. Fuer kontinuierliches Monitoring mit Historie und Alerts brauchst du einen richtigen Stack.

Prometheus einrichten

wget https://github.com/prometheus/prometheus/releases/download/v2.51.0/prometheus-2.51.0.linux-amd64.tar.gz
tar xvf prometheus-2.51.0.linux-amd64.tar.gz
cd prometheus-2.51.0.linux-amd64

Konfiguration prometheus.yml:

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100']

  - job_name: 'minecraft'
    static_configs:
      - targets: ['localhost:9225']
    metrics_path: /metrics

Node Exporter fuer Systemmetriken

sudo tee /etc/systemd/system/node_exporter.service << EOF
[Unit]
Description=Node Exporter
After=network.target

[Service]
User=prometheus
ExecStart=/opt/node_exporter/node_exporter
Restart=always

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl enable --now node_exporter

Minecraft Exporter

Installiere das Plugin UnifiedMetrics oder PrometheusExporter auf deinem MC-Server. Danach sind Metriken auf dem konfigurierten Port verfuegbar (normalerweise 9225):

mc_tps 19.8
mc_players_online 47
mc_loaded_chunks 12847
mc_entities_total 8923

Nuetzliche Grafana-Abfragen

Neue TCP-Verbindungen pro Sekunde:

rate(node_netstat_Tcp_PassiveOpens[1m])

Bandbreitenverbrauch:

rate(node_network_receive_bytes_total{device="eth0"}[1m]) * 8

CPU-Auslastung pro Kern:

100 - (avg by(cpu) (rate(node_cpu_seconds_total{mode="idle"}[1m])) * 100)

Spark Profiler

Spark ist ein Profiler, der speziell fuer Minecraft entwickelt wurde. Er zeigt genau, was deinen Server verlangsamt.

/spark tps          - aktuelle TPS
/spark health       - allgemeine Server-Gesundheit
/spark profiler     - Profiling starten
/spark profiler --stop  - Stoppen und Bericht generieren
/spark gc           - Garbage-Collection-Info

Waehrend eines Angriffs faellt TPS normalerweise abrupt, nicht allmahlich. Das ist der entscheidende Unterschied zu Plugin-Problemen oder natuerlicher Last.

Log-Analyse

Minecraft-Server-Logs enthalten eine Fuelle diagnostischer Informationen.

Muster, die auf einen Angriff hindeuten

# "Can't keep up!" Meldungen
grep "Can't keep up" logs/latest.log | tail -20

# Schnelle Verbindungen/Trennungen (Bot-Angriff-Signatur)
grep -E "(logged in|lost connection)" logs/latest.log | tail -40

Wenn du Hunderte "logged in" gefolgt von sofortigem "lost connection" innerhalb derselben Sekunde siehst, ist das ein Bot-Angriff.

Alerts einrichten

Discord Webhook

#!/bin/bash
WEBHOOK_URL="https://discord.com/api/webhooks/DEINE_ID/DEIN_TOKEN"

send_alert() {
    curl -s -H "Content-Type: application/json" \
        -X POST "$WEBHOOK_URL" \
        -d "{
            \"embeds\": [{
                \"title\": \"Server Alert\",
                \"description\": \"$1\",
                \"color\": ${2:-16711680},
                \"timestamp\": \"$(date -u +%Y-%m-%dT%H:%M:%SZ)\"
            }]
        }"
}

send_alert "Hohe Verbindungsrate erkannt: 482 conn/s"

Grafana Alerts

Erstelle eine Alert Rule in Grafana:

Bedingung: WHEN avg() OF query(A) IS ABOVE 100
Query A: rate(node_netstat_Tcp_PassiveOpens[1m])
Dauer: 30s
Kanal: Discord Webhook

Dies loest einen Alert aus, wenn neue TCP-Verbindungen 100/s fuer 30 Sekunden ueberschreiten.

Angriff vs. legitimer Traffic-Anstieg

Nicht jeder Traffic-Anstieg ist ein Angriff. Wichtige Unterschiede:

Angriffszeichen:

  • Ploetzlicher Sprung (10 auf 500 Verbindungen in Sekunden)
  • Viele SYN_RECV ohne Uebergang zu ESTABLISHED
  • TPS faellt, obwohl die echte Spielerzahl gleich bleibt
  • Schnelle Verbindungs-/Trennungsmuster in Logs

Zeichen fuer legitimen Anstieg:

  • Allmaehliches Verbindungswachstum (Minuten, nicht Sekunden)
  • Alle Verbindungen erreichen den ESTABLISHED-Status
  • TPS faellt proportional zur Spieleranzahl
  • Faellt mit einem Event zusammen (YouTube-Video, Giveaway)
#!/bin/bash
# Schnelle Anomalie-Erkennung
syn_recv=$(ss -tan state syn-recv | grep -c ":25565")
established=$(ss -tan state established | grep -c ":25565")

if [ "$established" -eq 0 ]; then ratio=999
else ratio=$((syn_recv / established)); fi

if [ "$ratio" -gt 5 ]; then
    echo "ANGRIFF: SYN_RECV/ESTABLISHED Verhaeltnis ist $ratio"
else
    echo "NORMAL: $syn_recv SYN_RECV, $established ESTABLISHED"
fi

Automatische Reaktion

Einfaches Auto-Block-Skript

#!/bin/bash
MC_PORT=25565
CONN_LIMIT=50

ss -tan state established dst :$MC_PORT | \
    awk '{print $5}' | cut -d: -f1 | \
    sort | uniq -c | sort -rn | \
    while read count ip; do
        if [ "$count" -gt "$CONN_LIMIT" ] && [ "$ip" != "" ]; then
            echo "Blockiere $ip ($count Verbindungen)"
            iptables -A INPUT -s "$ip" -j DROP
            (sleep 3600 && iptables -D INPUT -s "$ip" -j DROP) &
        fi
    done

Praeventives Rate Limiting

# Neue Verbindungen auf MC-Port begrenzen
iptables -A INPUT -p tcp --dport 25565 \
    --syn -m connlimit --connlimit-above 3 \
    --connlimit-mask 32 -j DROP

# Rate-Limit fuer neue Verbindungen
iptables -A INPUT -p tcp --dport 25565 \
    --syn -m limit --limit 25/s --limit-burst 50 -j ACCEPT
iptables -A INPUT -p tcp --dport 25565 --syn -j DROP

Integration mit DDoS-Schutz

Wenn dein Server hinter einem DDoS-Schutz wie MineGuard steht, funktioniert Monitoring auf zwei Ebenen: auf der Schutzseite und auf deinem Server.

Das MineGuard-Dashboard zeigt Netzwerkmetriken in Echtzeit: eingehenden Traffic, Verbindungsanzahl, blockierte Pakete. Aber Monitoring auf deiner Seite ist trotzdem wichtig. Der Schutz filtert Netzwerkangriffe, sieht aber nicht, was innerhalb deines MC-Servers passiert: TPS, Chunk-Laden, Plugin-Zustand.

Das ideale Setup: DDoS-Schutz filtert Traffic am Eingang, dein Monitoring ueberwacht die Anwendungsgesundheit.

Einstieg: Minimaler Monitoring-Stack

Du musst nicht sofort Prometheus + Grafana einrichten. Fang klein an:

  1. Heute: Lerne ss -s und iftop. Fuehre sie bei Verdacht auf Probleme aus
  2. Diese Woche: Installiere vnstat fuer Traffic-Historie und Spark fuer TPS-Monitoring
  3. Diesen Monat: Richte ein Discord-Alert-Skript fuer automatische Benachrichtigungen ein
  4. Wenn du bereit bist: Setze Prometheus + Grafana fuer vollstaendiges Monitoring mit Historie auf

Wenn du wissen willst, was zu tun ist, wenn ein Angriff bereits laeuft, lies unseren separaten Artikel. Monitoring hilft dir, es zu bemerken, bevor Spieler anfangen, sich zu beschweren.


Schützen Sie Ihren Server vor DDoS-Angriffen

Kostenloser Schutz mit 5-Minuten-Einrichtung. 1 TB Traffic inklusive.

Kostenlos testen


Weitere Artikel