Schutzschild
Schützt den Proxy vor Minecraft-typischen Angriffen wie Verbindungs-, Ping- und Anmeldefluten, fest eingebaut in die Cloud.
Ein offener Minecraft-Port ist ein leichtes Ziel. Bot-Wellen, Ping-Fluten und fehlerhafte Pakete können einen Velocity-Proxy in die Knie zwingen, lange bevor die Spielserver dahinter überhaupt etwas merken, und mit ihm fliegt jeder Spieler im Netzwerk raus. Die meisten Netzwerke begegnen dem mit einem externen Schutzdienst oder einem selbst gebauten HAProxy-Aufbau vor dem Proxy, mit eigener Konfiguration, eigenem Dashboard und einer Sache mehr, die kaputtgehen kann.
MuteCloud bringt diesen Schutz fest eingebaut mit. Das Schutzschild sitzt vor jedem Proxy auf seiner Node, nimmt die Verbindungen entgegen, prüft sie in sieben Stufen und reicht nur saubere an Velocity weiter. Anfragen der Serverliste beantwortet es aus seinem eigenen Zwischenspeicher, so erreicht eine Ping-Flut den Proxy gar nicht erst.
Ein Schalter. shield on, dann den Proxy mit groups <Proxy> rollout neu starten. MuteCloud
verlegt Velocity auf einen internen Port, stellt es auf das PROXY-Protokoll um und übernimmt den
öffentlichen selbst.
Echte Spieler-IPs. Velocity und jedes Plugin dahinter sehen weiterhin die echte Adresse jedes Spielers, IP-Banns, Zweitaccount-Prüfungen und Statistiken funktionieren also weiter. Genau daran scheitern viele selbst gebaute Aufbauten.
Teil der Cloud, nicht angeflanscht. Abweisungen, Sperren und Angriffe tauchen in shield, im
Dashboard, als Metriken und als Warnungen über deinen Webhook auf. Die Grenzwerte lassen sich im
laufenden Betrieb ändern.
Ehrlich zu seinen Grenzen. Das Schutzschild stoppt die Angriffe, die auf Minecraft selbst zielen, und mit denen haben es kleine und mittlere Netzwerke meistens zu tun. Eine reine Bandbreitenflut, die die Leitung zu deinem Server füllt, kommt bei ihm gar nicht erst an, dagegen hilft nur eine Filterung bei deinem Anbieter.
So funktioniert es
Das Schutzschild ist in MuteCloud eingebaut und sitzt vor jedem Proxy auf seiner eigenen Node. Es nimmt die Verbindungen der Spieler an, prüft sie und reicht nur saubere an Velocity weiter. Anfragen der Serverliste beantwortet es selbst, so erreicht eine Ping-Flut den Proxy gar nicht erst.
shield
shield on
shield off
shield block 203.0.113.7 60
shield block 198.51.100.0/24
shield unblock 198.51.100.0/24
shield listaddon enable shield und addon disable shield tun dasselbe wie shield on und shield off,
addon führt es als eingebautes Addon neben den anderen auf.
Wogegen es schützt
Das Schutzschild arbeitet in Stufen, von der rohen Verbindung bis hinauf zum Spielernamen.
| Stufe | Was geprüft wird |
|---|---|
| Verbindung | höchstens per_ip_connections offene Verbindungen je Adresse, neue nur mit per_ip_rate pro Sekunde bei einer Spitze von per_ip_burst, insgesamt höchstens global_connections |
| Erstes Paket | kommt es nicht innerhalb von first_packet_ms an, wird die Verbindung geschlossen, so bleiben halboffene Verbindungen kurz |
| Handshake | Längenfelder, Paketnummer, Adresslänge und Folgezustand müssen gültig sein, sonst wird die Verbindung sofort geschlossen |
| Serverliste | höchstens status_per_second Pings je Adresse, die Antwort kommt aus dem Zwischenspeicher |
| Anmeldung | höchstens logins_per_minute je Adresse, der Name muss zu username_pattern passen |
| Punkte | jeder Verstoß kostet Punkte, ab score_threshold wird die Adresse für block_minutes Minuten gesperrt |
| Sperrliste | einzelne Adressen und Bereiche, mit oder ohne Ablauf, übersteht Neustarts |
Die Punkte sinken jede Minute um score_decay. Eine erfolgreiche Anmeldung zieht 20 ab, damit
normale Spieler nicht in eine Sperre rutschen. Fehlerhafte Pakete kosten 30, ein zu spät
eintreffendes erstes Paket 15, jede überschrittene Grenze 10, ein Ping über der Grenze 1 und ein
Versuch trotz Sperre 50. Eine Verbindung zu öffnen und wieder zu schließen, ohne ein einziges Byte
zu senden, wie bei einer Erreichbarkeitsprüfung, kostet nichts.
Nach der Anmeldung reicht das Schutzschild die Bytes unverändert durch. Die Verschlüsselung zwischen Spieler und Velocity bleibt unberührt, das Schutzschild sieht nur den Handshake und den Namen.
Wogegen es nicht schützt
Das Schutzschild läuft auf demselben Server wie der Proxy. Eine Flut, die einfach die Leitung füllt, also volumetrische Angriffe mit UDP, SYN oder Reflection im Gigabit-Bereich, kommt beim Schutzschild gar nicht erst an. Dagegen hilft nur eine Filterung vor dem Server, beim Hosting-Anbieter oder mit einem Dienst, der Minecraft-Verkehr schützt. Das Schutzschild ergänzt so einen Aufbau, es ersetzt ihn nicht.
Ebenso wenig erkennt es Bots, die sich wie echte Spieler anmelden, mit gültigem Namen und innerhalb der erlaubten Rate. Dafür gibt es Plugins auf dem Proxy, die im Spiel prüfen.
Einschalten
shield onDas schreibt enabled = true unter [shield] in die network.toml und legt eine Markierung
mutecloud-shield.toml in die Vorlage jeder Proxy-Gruppe. Damit ändert sich die Vorlage, und der
Proxy übernimmt das Schutzschild bei seinem nächsten Start. Standardmäßig warten Proxys auf
Freigabe, genau wie bei jeder anderen Änderung an ihrer Vorlage:
groups Proxy rolloutBis dahin nehmen die laufenden Proxys Spieler weiter direkt an wie bisher, und shield zeigt
„an, aktiv nach dem Neustart der Proxies“. Das Ausschalten geht denselben Weg zurück.
Startet ein Proxy mit der Markierung, passiert Folgendes:
- Das Schutzschild belegt die öffentliche Adresse, standardmäßig den Port des Proxys auf allen Adressen.
- Velocity bekommt einen freien Port zwischen 40000 und 40999 auf
127.0.0.1und ist von außen nicht mehr erreichbar. - Mit
proxy_protocol = truesetzt die Cloudhaproxy-protocol = trueunter[advanced]in dervelocity.tomldes Proxys. Das Schutzschild schickt jeder Verbindung einen Header nach PROXY-Protokoll Version 2 voraus, so sehen Velocity und jedes Plugin die echte Adresse des Spielers.
Ist die öffentliche Adresse schon belegt, startet der Proxy wie bisher ohne Schutzschild, und im
Log steht, warum. Ohne Markierung bleibt die velocity.toml so, wie die Vorlage sie vorgibt.
Einstellungen
Die Grenzwerte gelten sofort, ohne Neustart. Nur enabled, listen und proxy_protocol
brauchen einen, weil sie ändern, worauf Velocity lauscht.
[shield]
enabled = false
listen = ""
proxy_protocol = true
per_ip_connections = 4
per_ip_rate = 2
per_ip_burst = 8
global_connections = 2000
first_packet_ms = 2000
status_per_second = 1
logins_per_minute = 4
username_pattern = "^[a-zA-Z0-9_]{3,16}$"
score_threshold = 100
score_decay = 5
block_minutes = 30
status_cache_seconds = 5
alert_rejects_per_minute = 500
allow = []| Schlüssel | Bedeutung |
|---|---|
listen | leer heißt 0.0.0.0 auf dem Port des Proxys, eine reine IP behält den Port, IP:port setzt beides |
proxy_protocol | echte Spieleradressen an Velocity weitergeben, sollte eingeschaltet bleiben |
global_connections | zählt alle offenen Verbindungen, auch die von Spielern, die schon spielen, bei großen Netzwerken erhöhen |
status_cache_seconds | wie oft das Schutzschild die Serverliste beim Proxy abholt |
alert_rejects_per_minute | ab so vielen Abweisungen in einer Minute geht shield-attack raus, 0 schaltet das ab |
allow | Adressen und Bereiche, die nie gesperrt und nie begrenzt werden |
allow ist standardmäßig leer. Teilen sich viele Spieler eine Adresse, zum Beispiel auf einer
LAN-Party, gehört diese Adresse hier hinein, sonst greifen die Grenzen je Adresse. Dasselbe gilt
für deine eigenen Dienste, die sich oft anmelden oder pingen.
Das Schutzschild holt die Serverliste beim Proxy getrennt für jede Spielversion ab, die gerade anfragt, für höchstens sechzehn Versionen gleichzeitig. Bis eine neue Version zum ersten Mal abgeholt ist, bekommt der Client die allgemeine Antwort mit seiner eigenen Protokollversion, so wie Velocity es auch tun würde. Ist der Proxy nicht erreichbar, bleibt der Zwischenspeicher leer und die Anfrage geht durch.
Sperren
shield block 203.0.113.7 60 Spam
shield block 198.51.100.0/24
shield unblock 203.0.113.7
shield listOhne Minutenangabe ist eine Sperre dauerhaft. shield list zeigt jede Sperre mit Restzeit und
Herkunft, automatische Sperren erscheinen dort als automatisch mit ihren Punkten. Bestehende
Verbindungen laufen nach einer Sperre weiter, nur neue werden abgewiesen. Die Liste liegt in
shield/blocklist.json im Verzeichnis der Cloud und wird jede Minute und beim Herunterfahren
gespeichert.
Im Blick behalten
shield zeigt, vor welchen Proxys das Schutzschild sitzt, wie viele Verbindungen offen sind, was
abgewiesen wurde und warum, und die auffälligsten Adressen mit ihren Punkten. Das Dashboard zeigt
dasselbe im Bereich Netzwerk, wo sich Adressen auch direkt sperren lassen.
Zwei Ereignisse gehen über die Warnungen raus, jedes höchstens einmal
innerhalb von quiet Minuten:
| Ereignis | Wann |
|---|---|
shield-attack | mehr Abweisungen in einer Minute als alert_rejects_per_minute |
shield-block | das Schutzschild hat Adressen automatisch gesperrt, mit Anzahl und letzter Adresse |
/metrics liefert mutecloud_shield_connections_accepted_total,
mutecloud_shield_connections_rejected_total mit dem Grund als reason,
mutecloud_shield_connections_active, mutecloud_shield_front_connections je Proxy,
mutecloud_shield_blocked, mutecloud_shield_auto_blocks_total,
mutecloud_shield_status_total mit from auf cache oder proxy,
mutecloud_shield_logins_total und mutecloud_shield_bytes_total.
Im Verbund
Jede Node schützt nur die Proxys, die auf ihr laufen, und führt ihre eigene Sperrliste. Die
Markierung in der Vorlage kommt zusammen mit den Vorlagen vom Leiter, deshalb schalten
shield on und shield off den ganzen Verbund. Jede Node liest die Grenzwerte aus ihrer eigenen
network.toml, und shield zeigt den Zustand der Node, auf der es läuft.
Ausblick
Geplant sind eigene Edge-Nodes: eine Node auf einem anderen Server, die keine Spielserver betreibt, sondern nur das Schutzschild. Sie nimmt die Spieler an und reicht sie über das private Netzwerk an den am wenigsten ausgelasteten, gesunden Proxy im Verbund weiter. So bleibt die Adresse des Servers mit den Spielservern verborgen, und seine Proxys nehmen nur Verbindungen von den Edge-Nodes an.