Minecraft RCON: Integrationen mit klaren Zugriffsgrenzen abnehmen

Bevor du eine Minecraft-Integration mit RCON abnimmst, verlange drei Nachweise: Nur der vorgesehene Dienst erreicht die Fernkonsole, das Zugangspasswort lässt sich austauschen und Nutzer können über die Integration keine beliebigen Konsolenbefehle abschicken. Ein erfolgreicher Befehl bestätigt die Verbindung. Ob die Zugriffsgrenzen stimmen, musst du zusätzlich prüfen.

Diese Anleitung richtet sich an Community-Betreiber, die eine Website, einen Bot oder ein Verwaltungswerkzeug für einen Java-/Paper-Server beauftragen. Sie beschreibt eine vorgeschlagene Abnahme in einer eigenen Testumgebung. Die Prüfungen wurden nicht auf deiner Infrastruktur ausgeführt; das Beispiel ist keine vollständige Deployment-Konfiguration.

Braucht die Funktion überhaupt Konsolenzugriff?

Paper beschreibt enable-rcon als Fernzugriff auf die Konsole. rcon.password und rcon.port legen Passwort und Port fest; der dokumentierte Standardport ist 25575. Siehe die Eigenschaftenreferenz von Paper. Behandle diesen Zugang bei der Angebotsprüfung als administrative Berechtigung.

Beginne mit der benötigten Funktion. Die Erreichbarkeit eines Servers anzuzeigen und Wartungsbefehle auszuführen sind unterschiedliche Anforderungen. Lass den Entwickler begründen, warum dafür Konsolenzugriff erforderlich ist und ob eine enger begrenzte Schnittstelle ausreicht. Ein Passwortfeld in einer Integrationsvorlage ist kein Grund, RCON vorsorglich einzuschalten.

Als Beispiel dient eine Event-Website: Berechtigte Teammitglieder sollen eine festgelegte Vorbereitungsnachricht senden können. Der Browser fordert diese benannte Aktion an. Ein vertrauenswürdiger Backend-Dienst prüft die Identität, wählt den vereinbarten Server und erzeugt den erlaubten Befehl. Das RCON-Passwort im Browser oder ein frei ausfüllbares Befehlsfeld würde dieser kleinen Funktion erheblich mehr Befugnisse geben als nötig.

Zeichne den tatsächlichen Verbindungsweg auf

Halte Ausgangsprozess, Zieladresse, Port und die dazwischenliegenden Netzregeln fest. Container und Adressübersetzungen gehören dazu. „Läuft auf derselben Maschine“ erklärt noch nicht, welche Prozesse welchen Dienst erreichen können.

Die folgenden Möglichkeiten dienen als Ausgangspunkt für die Prüfung durch den Infrastrukturverantwortlichen:

Standort der Integration	Zu vereinbarende Zugriffsgrenze
Im Minecraft-Container	Nicht allein für diese Verbindung einen Host-Port veröffentlichen
In einem anderen Container	Bewusst begrenztes Containernetz; jeden angeschlossenen Dienst prüfen
Als Prozess auf dem Docker-Host	Bei Bedarf eine nur vom Host erreichbare Portzuordnung erwägen
Auf einer anderen Maschine	Authentifizierten, verschlüsselten privaten Verbindungsweg mit begrenzten Quellen vorsehen

Das sind Architekturvorgaben, keine von RCON gelieferten Garantien. Ein erforderlicher verschlüsselter Verbindungsweg muss gesondert eingerichtet und betrieben werden. Dokumentiere, wer dafür zuständig ist und welchen Zustand die Anwendung bei einem Ausfall anzeigt.

Der Zugang für Spieler ist eine andere Schnittstelle. Für Velocity behandeln die Prüfungen zum direkten Backend-Zugriff diesen Weg. Ein dort bestandener Test belegt noch keine abgeschottete Fernkonsole.

Prüfe Docker-Portzuordnungen vor den Passwörtern

In einem üblichen Docker-Bridge-Netz veröffentlicht 25575:25575 den TCP-Port auf Host-Adressen. Docker dokumentiert die Bindung an localhost samt Ausnahme: Vor Version 28.0.0 konnten Rechner desselben Netzsegments solche Ports erreichen. Prüfe Version und Routing anhand der Docker-Dokumentation zur Portveröffentlichung.

Übernimm eine Portzuordnung nicht ungeprüft als allgemeine Lösung. Lass erklären, weshalb sie nötig ist, welche Adressfamilien erreichbar sind und welche Quellen ausgeschlossen werden. Auch eine bewusst auf den Host begrenzte Veröffentlichung beantwortet nicht, ob unerwünschte Dienste bereits im Containernetz hängen.

Bei itzg/minecraft-server gelten außerdem die Vorgaben des Images: RCON ist für Betriebsaufgaben standardmäßig aktiv, und RCON_PASSWORD_FILE wird unterstützt. Die Maintainer warnen vor einer externen RCON-Portfreigabe. Nutze die RCON-Konfiguration dieses Images, statt die Standardeinstellungen einer direkten Serverinstallation vorauszusetzen.

Das Passwort gehört nicht in die Produktoberfläche

Vereinbare Speicherort, lesenden Dienst und Zuständigkeit für einen Austausch. Das Passwort sollte weder in Browserdateien noch in Screenshots, Supporttickets oder normalen Anwendungslogs auftauchen. Prüfe auch Konfigurationssicherungen: Ein zur Laufzeit geschütztes Geheimnis hilft wenig, wenn es anschließend in einem herunterladbaren Archiv liegt.

Als Diagnoseclient für Betreiber unterstützt mcrcon Umgebungsvariablen, darunter MCRCON_PASS. Damit muss das Passwort nicht als ausgeschriebenes Befehlsargument erscheinen. Die Umgebung wird dadurch jedoch nicht zum sicheren Geheimnisspeicher. Zur Übergabe gehören das tatsächliche Verfahren zur Bereitstellung und seine Zugriffsregeln, nicht bloß ein Variablenname.

Probe den Passwortwechsel vor der Abnahme. Aktualisiere beide Seiten nach dem dokumentierten Deployment-Verfahren, verbinde dich erneut und prüfe, dass das alte Passwort keine neue Sitzung mehr eröffnet. Kläre gesondert, wie bestehende Sitzungen beendet werden. Ein Passwortwechsel darf nicht ohne Nachweis mit sofortigem Sitzungsabbruch gleichgesetzt werden. Halte erforderliche Neustarts oder Wartungsfenster fest.

Verlange eine überschaubare Abnahmematrix

Prüfe ausschließlich eigene Systeme und Adressen oder solche, für die du eine Erlaubnis hast. Vereinbare einen harmlosen Diagnosebefehl wie list. Notiere Testquelle, erwartetes Verhalten und beobachtetes Ergebnis, ohne das Passwort in die Nachweise aufzunehmen.

Prüfung	Gefordertes Ergebnis
Vorgesehener Dienst mit richtigem Passwort	Verbindung und erwartete Diagnoseantwort funktionieren
Vorgesehener Dienst mit falschem Passwort	Keine Authentifizierung und keine Befehlsausführung
Testrechner außerhalb des erlaubten Netzes	Kann keine RCON-Verbindung aufbauen
Unbeteiligter Dienst in der Nähe der Integration	Zugriff abgelehnt, sofern er nicht ausdrücklich zum Vertrauensbereich gehört
Neue Verbindung mit dem alten Passwort nach dem Austausch	Authentifizierung schlägt fehl
Website-Nutzer ohne erforderliche Teamrolle	Anwendung lehnt die Aktion vor dem Versand eines Konsolenbefehls ab

Wiederhole die Erreichbarkeitsprüfung für alle relevanten öffentlichen Adressen, gegebenenfalls einschließlich IPv6, und nach dem Neuerstellen der Container. Ein Firewall-Screenshot liefert weniger Belege als ein beobachtetes Ergebnis von einem unabhängigen Teststandort. Umgekehrt könnte eine fehlgeschlagene Verbindung lediglich einen ausgeschalteten Server anzeigen: Führe deshalb auch den erfolgreichen Test von der vorgesehenen Quelle aus.

Lege fest, wann eine Aktion abgeschlossen ist

Die Oberfläche sollte Verbindungsfehler, Authentifizierungsfehler und einen unbekannten Ausgang unterscheiden. Das RCON-Tutorial von mctools weist darauf hin, dass Befehlsantworten leer sein können. Eine leere Antwort allein eignet sich deshalb nicht als Abnahmekriterium für eine Produktfunktion.

Prüfe beim Nachrichtenbeispiel, ob der vereinbarte Text tatsächlich im Testserver erscheint. Bricht die Kommunikation nach dem Absenden ab, greift die vereinbarte Regel für Prüfung oder Wiederholung. Die Website darf nicht allein wegen versendeter Daten Erfolg melden. Protokolliere anforderndes Teammitglied, erlaubte Aktion, Ziel und Ergebnis, ohne Zugangsdaten aufzuzeichnen.

Nimm die Lieferung ab, wenn Zugriffsmatrix, Passwortwechsel und beobachtbare Aktion mit den vereinbarten Versionen funktionieren. Für individuelle Minecraft-Integrationen gehören diese Grenzen und Aktionen in die Projektbeschreibung. Kläre Deployment und Netzverantwortung im Umfang der betreuten Infrastruktur. Mineando kalkuliert bezahlte Projekte individuell; Wartung und Support werden separat vereinbart.