Rate Limiting fuer Minecraft Server | Verbindungsbegrenzung

Ein Bot-Angriff auf einen Minecraft-Server ist simpel: Hunderte Verbindungen pro Sekunde von verschiedenen IPs. Jeder Bot baut eine TCP-Verbindung auf, sendet einen Handshake, manchmal sogar einen kompletten Login. Der Server verbraucht Ressourcen fuer jede Verbindung und reagiert irgendwann nicht mehr auf echte Spieler.

Rate Limiting loest dieses Problem direkt: Wenn von einer IP mehr als N Verbindungen pro Sekunde kommen, werden die ueberschuessigen verworfen. Einfach, direkt, effektiv. Aber die Details sind entscheidend. Ein falsch konfigurierter Rate Limiter blockiert legitime Spieler. Einer, der zu locker eingestellt ist, stoppt nichts.

Dieser Artikel behandelt jede Ebene des Rate Limitings fuer Minecraft: von iptables bis zu Plugins. Mit konkreten Konfigurationen und Erklaerungen, warum bestimmte Werte funktionieren.

Was ist Rate Limiting

Rate Limiting ist ein Mechanismus zur Steuerung der Anfragenhaeufigkeit. Statt zu entscheiden, ob eine Anfrage gut oder schlecht ist (das ist die Aufgabe einer Firewall oder eines Antibots), zaehlt ein Rate Limiter einfach: Wie viele Anfragen kamen von dieser Quelle in einem bestimmten Zeitfenster? Schwellenwert ueberschritten? Abgelehnt.

Das funktioniert, weil ein normaler Spieler sich einmal verbindet. Vielleicht zweimal, wenn er abgestuerzt ist und sich neu eingeloggt hat. Zehnmal pro Minute ist verdaechtig. Hundertmal pro Sekunde ist definitiv ein Bot.

Rate Limiting operiert auf verschiedenen Ebenen:

Netzwerkebene (L3/L4): iptables, nftables. Zaehlt TCP-Verbindungen und Pakete. Am schnellsten, laeuft im Kernel.
Proxy-Ebene (L7): Velocity, BungeeCord, Waterfall. Zaehlt Minecraft-Verbindungen. Versteht das Protokoll, kann Handshake von Login unterscheiden.
Anwendungsebene: Plugins auf dem Spielserver selbst. Am flexibelsten, aber am ressourcenintensivsten.

Die beste Verteidigung kombiniert alle drei Ebenen. Jede faengt einen anderen Angriffstyp ab.

server.properties: der eingebaute Rate-Limit

In server.properties gibt es einen rate-limit-Parameter, den wenige kennen:

# server.properties
rate-limit=0

Standard ist 0 (deaktiviert). Wenn ein Wert gesetzt wird, trennt der Server Clients, die mehr als die angegebene Anzahl Pakete pro Sekunde senden.

# Vernuenftiger Wert fuer die meisten Server
rate-limit=500

500 Pakete pro Sekunde sind reichlich fuer einen normalen Spieler. Normales Spielen erzeugt 20-50 Pakete pro Sekunde. Selbst intensives PvP ueberschreitet selten 200. Aber Bots mit Paket-Spam erzeugen leicht Tausende.

Einschraenkungen

Dies funktioniert erst nach dem Verbindungsaufbau. Bots, die nur Verbindungen spammen, ohne Pakete zu senden, umgehen es komplett. Fuer Connection-Flood-Schutz braucht man andere Werkzeuge.

Auf Paper wird dieser Parameter durch den eingebauten Packet Limiter ersetzt:

# paper-global.yml
packet-limiter:
  kick-message: '<red><lang:disconnect.exceeded_packet_rate>'
  limits:
    all:
      interval: 7.0
      max-packet-rate: 500.0
    ServerboundCommandSuggestionPacket:
      interval: 1.0
      max-packet-rate: 15.0

Papers Implementierung ist flexibler: Du kannst Limits pro Pakettyp setzen. Tab-Complete-Spam? Begrenze ServerboundCommandSuggestionPacket auf 15 pro Sekunde.

iptables: Rate Limiting auf Kernelebene

iptables ist das maechtigste Rate-Limiting-Tool unter Linux. Es laeuft im Kernel, verbraucht keine Userspace-Ressourcen und verarbeitet Pakete, bevor sie den Java-Prozess erreichen.

Wenn du neu bei iptables bist, lies unseren Leitfaden zu iptables fuer Minecraft.

connlimit: gleichzeitige Verbindungen begrenzen

Das connlimit-Modul begrenzt die Anzahl gleichzeitiger TCP-Verbindungen von einer einzelnen IP.

# Max 3 gleichzeitige Verbindungen auf Port 25565 von einer IP
iptables -A INPUT -p tcp --dport 25565 \
  -m connlimit --connlimit-above 3 \
  -j DROP

Warum 3? Ein Spieler hat normalerweise eine aktive Verbindung. Zwei beim Neuverbinden (die alte ist noch nicht geschlossen). Drei sind Sicherheitspuffer. Ein Bot-Angriff von einer IP erzeugt Dutzende oder Hunderte Verbindungen, und connlimit schneidet alles ueber dem Schwellenwert ab.

Fuer BungeeCord/Velocity-Netzwerke, bei denen der Proxy sich mit Backend-Servern verbindet, muss die Proxy-IP auf die Whitelist:

# Proxy ohne Limits erlauben
iptables -A INPUT -p tcp --dport 25565 -s 10.0.0.1 -j ACCEPT

# Alle anderen begrenzen
iptables -A INPUT -p tcp --dport 25565 \
  -m connlimit --connlimit-above 3 \
  -j DROP

hashlimit: Verbindungsrate begrenzen

connlimit begrenzt gleichzeitige Verbindungen, aber nicht die Erstellungsrate. Ein Bot kann Verbindungen schneller erstellen und schliessen, als connlimit sie zaehlt. Dafuer gibt es hashlimit.

# Max 10 neue Verbindungen pro Sekunde von einer IP
iptables -A INPUT -p tcp --dport 25565 --syn \
  -m hashlimit \
  --hashlimit-name minecraft \
  --hashlimit-above 10/sec \
  --hashlimit-burst 20 \
  --hashlimit-mode srcip \
  --hashlimit-htable-expire 30000 \
  -j DROP

Parameter im Detail:

--syn: nur SYN-Pakete zaehlen (neue Verbindungsversuche)
--hashlimit-above 10/sec: Schwellenwert von 10 Verbindungen pro Sekunde
--hashlimit-burst 20: Spitzen bis 20 erlauben (fuer legitime Reconnects)
--hashlimit-mode srcip: separat pro IP zaehlen
--hashlimit-htable-expire 30000: Eintraege nach 30 Sekunden Inaktivitaet loeschen

10 Verbindungen pro Sekunde sind grosszuegig fuer einen Spieler. Selbst bei schlechter Verbindung mit staendigen Reconnects erreicht ein echter Spieler diesen Wert nicht. Aber ein Bot, der Hunderte Verbindungen erzeugt, wird sofort gestoppt.

Regeln kombinieren

In der Praxis kombiniert man mehrere Regeln:

# 1. Localhost und vertrauenswuerdige IPs erlauben
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p tcp --dport 25565 -s 10.0.0.1 -j ACCEPT

# 2. Bestehende Verbindungen erlauben
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# 3. Gleichzeitige Verbindungen begrenzen
iptables -A INPUT -p tcp --dport 25565 \
  -m connlimit --connlimit-above 3 -j DROP

# 4. Rate neuer Verbindungen begrenzen
iptables -A INPUT -p tcp --dport 25565 --syn \
  -m hashlimit \
  --hashlimit-name minecraft \
  --hashlimit-above 10/sec \
  --hashlimit-burst 20 \
  --hashlimit-mode srcip \
  -j DROP

# 5. Rest akzeptieren
iptables -A INPUT -p tcp --dport 25565 -j ACCEPT

Die Reihenfolge ist wichtig. Zuerst vertrauenswuerdigen Traffic durchlassen, dann nach Anzahl filtern, dann nach Rate. Jede Regel entfernt eine Schicht Muell.

Velocity: Connection Throttle

Wenn du Velocity als Proxy nutzt (und das solltest du fuer jedes Multi-Server-Netzwerk), hat es einen eingebauten Verbindungsbegrenzungsmechanismus.

# velocity.toml
[advanced]
connection-timeout = 5000
login-ratelimit = 3000

login-ratelimit ist die Mindestzeit (in Millisekunden) zwischen Verbindungsversuchen von einer IP. 3000 bedeutet: maximal eine Verbindung alle 3 Sekunden pro IP.

Fuer Server mit vielen Spielern hinter NAT (Schulen, Internetcafes) kann man den Wert auf 1000 senken (eine Verbindung pro Sekunde). Fuer kleinere Server sind 3000-5000 eine gute Balance.

BungeeCord connection_throttle

BungeeCord hat eine aequivalente Einstellung:

# config.yml (BungeeCord)
connection_throttle: 4000
connection_throttle_limit: 3

Waterfall

Waterfall (PaperMCs BungeeCord-Fork) verwendet dieselben Einstellungen mit einigen Erweiterungen:

# waterfall.yml
connection_throttle: 4000
throttle: 4000

Wenn du noch BungeeCord nutzt, ziehe einen Wechsel zu Velocity in Betracht. Es ist schneller, sicherer und handhabt Rate Limiting besser.

Token Bucket: der Algorithmus hinter allem

Die meisten Rate Limiter verwenden den Token-Bucket-Algorithmus. Die Idee ist einfach:

Jede IP hat einen "Eimer" gefuellt mit Tokens
Jede Anfrage verbraucht ein Token
Tokens werden mit fester Rate nachgefuellt (z.B. 10 pro Sekunde)
Der Eimer hat eine maximale Kapazitaet (z.B. 50 Tokens)
Wenn keine Tokens uebrig sind, wird die Anfrage abgelehnt

Warum ist das besser als ein einfacher Zaehler "N Anfragen pro Sekunde"? Weil Token Bucket Spitzen verarbeitet. Wenn ein Spieler sich 5 Sekunden lang nicht verbunden hat, ist sein Eimer voll (50 Tokens). Er kann sich schnell 10-mal hintereinander neu verbinden, und alle Verbindungen gehen durch. Ein Bot dagegen, der konstant Traffic erzeugt, leert seinen Eimer schnell.

Pseudocode-Beispiel:

bucket_size = 50        # max Tokens
refill_rate = 10        # Tokens pro Sekunde
tokens = bucket_size    # Start mit vollem Eimer

function handle_request(ip):
    bucket = get_bucket(ip)
    bucket.refill()     # Tokens fuer vergangene Zeit hinzufuegen

    if bucket.tokens > 0:
        bucket.tokens -= 1
        return ACCEPT
    else:
        return DROP

Das hashlimit-Modul in iptables funktioniert nach einem aehnlichen Prinzip. --hashlimit-burst ist die Eimergroesse, --hashlimit-above ist die Nachfuellrate (invertiert: der Schwellenwert, ab dem Blockierung beginnt).

Plugins fuer Rate Limiting

LimboFilter

LimboFilter ist ein Velocity-Plugin, das eine leichtgewichtige "Lobby" vor dem Hauptserver erstellt. Neue Verbindungen landen auf einem minimalen Limbo-Server, wo sie eine Pruefung durchlaufen (Captcha, Falling Check), bevor sie zum eigentlichen Spielserver weitergeleitet werden.

Rate Limiting operiert hier auf Minecraft-Protokollebene. LimboFilter zaehlt Verbindungen, verfolgt wiederholte Versuche und kann IPs blockieren, die zu haeufig versuchen, sich zu verbinden.

Mehr zum Captcha-Schutz in unserem Artikel ueber Captcha fuer Minecraft.

BotSentry

BotSentry ist ein BungeeCord/Velocity-Plugin, spezialisiert auf Bot-Abwehr. Es umfasst Rate Limiting als eine seiner Funktionen:

Verbindungen-pro-Sekunde-Limits (global und pro IP)
Automatische IP-Blockierung bei Schwellenwertueberschreitung
Integration externer Blocklisten
Konfigurierbare Aktionen (Kick, Tempban, Captcha)

Feintuning: eigene Spieler nicht aussperren

Rate Limiting ist ein Balanceakt. Zu streng und du sperrst echte Spieler aus. Zu locker und es stoppt nichts. Hier sind Situationen, die besondere Aufmerksamkeit brauchen.

Server-Eroeffnungen

Wenn du eine neue Server-Eroeffnung ankuendigst und 500 Spieler gleichzeitig auftauchen, koennte ein Standard-Rate-Limiter die Haelfte blockieren. Loesungen:

Limits temporaer erhoehen. Vor dem Start hashlimit-burst und hashlimit-above hochsetzen. Nach der Stabilisierung zuruecksetzen.
Eine Warteschlange verwenden. LimboFilter kann eine Queue erstellen, die Spieler schrittweise durchlaesst.
Gestaffelter Start. Erst per Einladung, dann fuer alle oeffnen.

NAT und geteilte IPs

In Schulen, Wohnheimen und Internetcafes teilen sich mehrere Spieler eine IP. Ein connlimit von 3 blockiert den vierten Spieler. Loesungen:

connlimit auf 10-15 fuer diese Szenarien erhoehen
Bekannte institutionelle IPs auf die Whitelist setzen
Staerker auf hashlimit (Rate) als auf connlimit (Anzahl) setzen

Mobile-Internet-Spieler

Mobile Verbindungen wechseln haeufig IPs, und ein Spieler kann auf einer IP landen, die kuerzlich von einem Bot genutzt wurde. Bei langen Sperren (30 Minuten oder mehr) kann ein mobiler Spieler "vererbt" gesperrt werden.

Loesung: Kurze TTLs fuer Sperren verwenden. 60-120 Sekunden genuegen, um einen aktiven Angriff zu stoppen, ohne einen unschuldigen mobilen Spieler einzusperren.

Whitelisting: vertrauenswuerdige IPs

Einige IPs sollten nie rate-limited werden:

# Proxy-Server
iptables -I INPUT -p tcp --dport 25565 -s 10.0.0.1 -j ACCEPT
iptables -I INPUT -p tcp --dport 25565 -s 10.0.0.2 -j ACCEPT

# Monitoring (Uptime-Checks)
iptables -I INPUT -p tcp --dport 25565 -s 1.2.3.4 -j ACCEPT

Regeln mit -I (Insert) kommen an den Anfang der Kette, werden vor Rate-Limiting-Regeln verarbeitet. Das ist kritisch: Wenn dein Proxy eine hashlimit-Regel trifft, verlieren alle Spieler ihre Verbindung.

Rate Limiting ueber Schichten

Die effektivste Strategie wendet Rate Limiting auf jeder Ebene mit unterschiedlicher Logik an:

Netzwerkebene (iptables): TCP-SYN-Pakete und gleichzeitige Verbindungen begrenzen. Ziel: rohe Connection Floods blockieren, bevor sie Java erreichen.

Proxy-Ebene (Velocity): Minecraft-Login-Versuche und wiederholte Verbindungen begrenzen. Ziel: Bots stoppen, die den TCP-Handshake geschafft haben, aber keine echten Spieler sind.

Anwendungsebene (Plugins): In-Game-Aktionen begrenzen (Befehle, Chat, Interaktionen). Ziel: Bots auffangen, die den Login geschafft haben, aber sich anomal verhalten.

Jede Ebene faengt ihren eigenen Bedrohungstyp. iptables stoppt SYN Floods. Velocity stoppt Connection Spam. Plugins stoppen Paket-Missbrauch.

Rate Limiting und DDoS-Schutz

Rate Limiting ist Teil des DDoS-Schutzes, aber nicht der gesamte Schutz. Gegen einen ernsthaften DDoS-Angriff (Dutzende Gigabit Traffic) ist Rate Limiting auf dem Server wirkungslos: Die Leitung ist voll, Pakete kommen nicht an.

Fuer ernsthaften Schutz braucht man Filterung auf Netzwerkebene vor dem Server. MineGuard filtert Traffic auf Netzwerkebene und verwirft Muell-Pakete, bevor sie den Server erreichen. Rate Limiting auf dem Server fungiert als zweite Verteidigungslinie: Es faengt das auf, was durch den Netzwerkfilter kommt.

Zusammen bilden sie gestaffelte Verteidigung:

DDoS-Filter (MineGuard): stoppt volumetrische Angriffe auf Netzwerkebene
iptables Rate Limiting: drosselt Verbindungsraten, die den Filter passiert haben
Proxy Rate Limiting: filtert auf Minecraft-Protokollebene
Plugin Rate Limiting: schuetzt vor In-Game-Missbrauch

Mehr zu Bot-Angriffen und Verteidigungsmethoden in unserem Artikel ueber Bot-Angriffe auf Minecraft.

Effektivitaet ueberwachen

Rate Limiting ist nutzlos, wenn du nicht weisst, ob es funktioniert. Hier ist, was du ueberwachen solltest:

iptables-Zaehler

# Regelzaehler anzeigen
iptables -L -n -v | grep hashlimit

Jede iptables-Regel hat einen Paket- und Byte-Zaehler. Wenn deine hashlimit-Regel Tausende Drops zeigt, funktioniert sie. Wenn Null, gibt es entweder keine Angriffe oder die Regel greift nicht (Regelreihenfolge pruefen).

Blockierten Traffic loggen

# Vor dem Drop loggen (Logging drosseln, um Festplatte nicht zu fuellen)
iptables -A INPUT -p tcp --dport 25565 --syn \
  -m hashlimit --hashlimit-above 10/sec \
  --hashlimit-burst 20 --hashlimit-name mc_syn \
  --hashlimit-mode srcip \
  -m limit --limit 5/min \
  -j LOG --log-prefix "MC_RATELIMIT: "

Beachte -m limit --limit 5/min bei der LOG-Regel. Ohne das erzeugen schwere Angriffe Tausende Log-Eintraege pro Sekunde, was Disk-I/O und CPU killt.

Velocity-Statistiken

Velocity loggt gedrosselte Verbindungen nach stdout:

[INFO] [ratelimiter] Connection from 1.2.3.4 throttled

Parse diese Logs fuer Monitoring. Massen-Throttling von verschiedenen IPs bedeutet Bot-Angriff. Von einer IP bedeutet ein hartneckiger Bot oder ein Spieler mit Verbindungsproblemen.

Kurzreferenz

Minimale Rate-Limiting-Einrichtung fuer einen Minecraft-Server:

iptables:

# Proxy whitelisten (falls vorhanden)
iptables -I INPUT -p tcp --dport 25565 -s DEINE_PROXY_IP -j ACCEPT

# Gleichzeitige Verbindungen begrenzen
iptables -A INPUT -p tcp --dport 25565 \
  -m connlimit --connlimit-above 5 -j DROP

# Rate neuer Verbindungen begrenzen
iptables -A INPUT -p tcp --dport 25565 --syn \
  -m hashlimit --hashlimit-name mc \
  --hashlimit-above 10/sec --hashlimit-burst 25 \
  --hashlimit-mode srcip -j DROP

Velocity:

[advanced]
login-ratelimit = 3000

Paper:

packet-limiter:
  limits:
    all:
      interval: 7.0
      max-packet-rate: 500.0

Das deckt die Grundlagen ab. Danach die Schwellenwerte an deine Last anpassen: Zaehler ueberwachen, Logs pruefen, Werte korrigieren.

Haeufige Fehler

connlimit zu niedrig. Ein connlimit von 1 blockiert Spieler, die sich neu verbinden (alte Verbindung ist noch in TIME_WAIT). Minimum sollte 3 sein.

Vergessene Whitelist. Proxy trifft das Rate Limit, alle Spieler verlieren die Verbindung. Immer den Proxy whitelisten.

Kein Burst. hashlimit ohne Burst blockiert jede kurze Spitze. Spieler kommt rein, stuerzt ab, kommt wieder: blockiert. Ein Burst von 15-25 behebt das.

Rate Limit auf ESTABLISHED. Rate Limiting nur auf neue Verbindungen anwenden (--syn), sonst drosselst du bereits verbundene Spieler.

Globales Limit ohne pro-IP. Ein globales Limit von "100 Verbindungen pro Sekunde gesamt" blockiert alle, wenn eine IP 100 Verbindungen erzeugt. Immer pro-IP-Limits verwenden.

Rate Limiting ist kein Allheilmittel. Es ist eine Schicht in einer mehrschichtigen Verteidigung. Aber ohne sie funktionieren die anderen Schichten schlechter. Richte die Grundlagen ein, ueberwache die Effektivitaet und passe bei Bedarf an.

Globales vs. pro-IP Rate Limiting

Ein wichtiger Unterschied, den viele uebersehen. Ein globaler Rate Limiter begrenzt die Gesamtzahl der Verbindungen zum gesamten Server. Ein pro-IP Rate Limiter zaehlt Verbindungen separat fuer jede Quell-IP.

Ein globales Limit dient als "Notbremse." Wenn dein Server fuer 200 Spieler ausgelegt ist, macht es keinen Sinn, 10.000 Verbindungen pro Sekunde zu akzeptieren. Ein globaler Grenzwert von 500-1.000 Verbindungen pro Sekunde schuetzt vor verteilten Angriffen, bei denen Tausende IPs jeweils 1-2 Verbindungen senden und pro-IP-Limits nie greifen.

Beispiel fuer ein globales Limit:

# Globales Limit: nicht mehr als 200 neue Verbindungen pro Sekunde insgesamt
iptables -A INPUT -p tcp --dport 25565 --syn \
  -m hashlimit \
  --hashlimit-name mc_global \
  --hashlimit-above 200/sec \
  --hashlimit-burst 300 \
  --hashlimit-mode dstip \
  -j DROP

Der entscheidende Unterschied: --hashlimit-mode dstip statt srcip. Jetzt zaehlt iptables alle Verbindungen zu unserer IP, nicht von jeder einzelnen Quelle.

Die Kombination beider Typen bietet maximalen Schutz:

Pro-IP-Limits fangen Bots, die von einer einzelnen Adresse spammen
Globale Limits fangen verteilte Angriffe von Tausenden IPs

Adaptives Rate Limiting

Statische Limits funktionieren, sind aber nicht ideal. Auf einem leeren Server nachts sind 10 Verbindungen pro Sekunde von einer IP eindeutig ein Bot. An einem belebten Samstagabend mit 300 Spielern online koennte sprunghafter Traffic normal sein.

Ein einfacher Ansatz fuer dynamisches Rate Limiting:

#!/bin/bash
# adaptive-ratelimit.sh
# Per Cron alle 5 Minuten ausfuehren

CURRENT_PLAYERS=$(mc-rcon list | grep -o '[0-9]* players' | cut -d' ' -f1)

if [ "$CURRENT_PLAYERS" -gt 200 ]; then
    RATE=20; BURST=40
elif [ "$CURRENT_PLAYERS" -gt 50 ]; then
    RATE=15; BURST=30
else
    RATE=8; BURST=15
fi

# Regeln aktualisieren (alte entfernen, neue hinzufuegen)
iptables -D INPUT -p tcp --dport 25565 --syn \
  -m hashlimit --hashlimit-name mc_adaptive \
  --hashlimit-above ${RATE}/sec --hashlimit-burst ${BURST} \
  --hashlimit-mode srcip -j DROP 2>/dev/null

iptables -A INPUT -p tcp --dport 25565 --syn \
  -m hashlimit --hashlimit-name mc_adaptive \
  --hashlimit-above ${RATE}/sec --hashlimit-burst ${BURST} \
  --hashlimit-mode srcip -j DROP

Dies ist ein einfaches Beispiel. Im Produktivbetrieb solltest du fail2ban oder einen eigenen Daemon verwenden, der Logs in Echtzeit analysiert und Regeln entsprechend anpasst.

GeoIP-basiertes Rate Limiting

Wenn 95% deiner Spieler aus einer Region stammen und Bot-Angriffe von IPs aus fernen Laendern kommen, kannst du strengeres Rate Limiting nach Geografie anwenden:

# GeoIP-Modul fuer iptables installieren
# Ubuntu/Debian: apt install xtables-addons-common

# Strenges Limit fuer nicht-lokale Laender
iptables -A INPUT -p tcp --dport 25565 --syn \
  -m geoip ! --src-cc DE,AT,CH \
  -m hashlimit --hashlimit-name mc_foreign \
  --hashlimit-above 3/sec --hashlimit-burst 5 \
  --hashlimit-mode srcip -j DROP

Vorsicht mit diesem Ansatz: GeoIP-Datenbanken sind nicht perfekt, und du koenntest Spieler blockieren, die VPNs fuer niedrigere Latenz nutzen. Verwende es als zusaetzlichen Filter, nicht als primaeren.

Rate Limiting fuer Minecraft: Schaedliche Verbindungen begrenzen