Sicherheitsdiskussion: Webinterface/ControlPanel für Gameserver

  • Thread starter Thread starter Deleted member 10028
  • Start date Start date
D

Deleted member 10028

Guest
Hallo Zusammen,

vorweg möchte ich erwähnen, dass ich mein eigenes ControlPanel für Gameserver entwickle und auch bestimmt einige Benutzer hier im Forum auf eigene Software vertrauen.

Das Thema "Sicherheit" wird bei vielen Webinterfaces/ControlPanels scheinbar ein wenig vernachlässigt und ich selbst bin keineswegs daran interessiert, dass meine Gameserverkunden unfug auf meinen Systemen anstellen können.

Da ich keine Spiele anpreise, die bei der ESL präsent sind, fällt für mich persönlich das Thema "Protected Mode" weg, aber wir können sehr gerne darüber diskutieren :)

Mein aktuelles Sicherheitskonzept sieht wie folgt aus:
- Jeder Server wird für die Installation von einem Imageserver herungtergeladen. (Lokal oder extern - Beides möglich - "tar" erspart Berechtigungsprobleme)
- Für jeden Server gibt es einen eigenen Shell-Benutzer - Das Passwort ist dem Kunden unbekannt und er kann es nicht ändern.
- Vor jedem Server(neu)start werden die auszuführenden Dateien des Gameservers ersetzt, außerdem wird jedes Mal das Passwort für den Shell-Benutzer geändert.(Fail2Ban )
- FTP-Zugänge werden über das MySQL-Modul von ProFTPd verwaltet.
- Wichtige Konfigurationsdateien, wie z.B. die server.cfg werden ausschließlich über das WI/CP konfiguriert und vor jedem (Neu)Start des Servers neu generiert. (chattr +i könnte zusätzlichen Schutz bieten - Doppelt hält besser.)

Diese Punkte lassen sich meiner Meinung nach ziemlich einfach realisieren.
EIne CHROOTED-Umgebung halte ich mit diesem Konzept für überflüssig, da der Kunde keinen bekannten Shell-Zugriff bekommt.

Ich bin auf eure Vorschläge sehr gespannt.


Gruß
Julian
 
Last edited by a moderator:
Wenn du dem Shell-Benutzer kein Passwort gibst, dann kann sich mit diesem Benutzer auch nie angemeldet werden.
 
Die jeweiligen Shell-Benutzer loggen sich von einem externen Server ein, also müssen diese ein Passwort haben.
Das WI liegt schließlich auf einem externen Server.
 
Vor jedem Server(neu)start werden die auszuführenden Dateien des Gameservers ersetzt,
Click to expand...

Da fallen mir pauschal so manche Spiele ein wo man langfrsitig Probleme damit bekommen wird, gerade bei autoupdate Spielen. Ich würde die Dateien viel eher von niemandem beschreiben lassen können ausser durch den ausführenden User. Der ausführende User ist natürlich keiner der per FTP daran kommt.
 
Wenn man die MD5 Hashes der auszuführenden Serverdateien speichert und dann bei jedem (Neu)Start des Servers vergleicht, gibt es ebenfalls das Problem, dass durch ein Update der Hash hinfällig wird.

Durch ein Serverupdate wäre chattr relativ sinnfrei, da die Dateien dann nicht ersetzt werden können.


Ich habe mich bisher noch nicht wirklich mit dem MySQL-Plugin von ProFTPd beschäftigt, weshalb sich mir folgende Frage stellt:
----------
Der Shell-Benutzer ist dem Kunden unbekannt und bevor er seine Daten "bruteforcen" kann, greift fail2ban ein.
Nun lege ich einen Benutzer mit ProFTPd an und weise ihm sein Verzeichnis zu.
Kann dieser Benutzer von ProFTPd dann die Dateien von seinem ihm zugewiesenen Verzeichnis bearbeiten/löschen?
Wenn ich mich richtig erinnere, ist der Benutzer von ProFTPd lediglich ein Synonym für den eigentlichen Benutzer, wobei man diesem Synonym extra Regeln/Sperren auftragen kann.
----------

Doch wie würde man bei den Serverupdates eingreifen können, sodass die Dateien nicht manipuliert werden?
 
Rechne mit dem Schlimmsten. Sobald ein Plugin geladen wird, dass eine Shell auf einem Port öffnet oder via rcon ganz normal vom Gameserver erreichbar ist, hast du verloren. Unter anderem können Plugins auch Dateien umbenennen & verschieben, neu erstellen, Berechtigungen ändern (u+x) und löschen. Das gleiche mit Verzeichnissen. Nun kommt es auf das Gameserver drauf an, was überhaupt für eine Pluginschnittstelle zur Verfügung steht, welche Möglichkeiten dort geboten werden usw.

Um mal ein krasses Beispiel zu nennen: srcds
Sogar laien können Plugins/Scripte mit Eventscripts/Python programmieren, die die oben genannten Sachen soweit ich weiß alle unterstützen. Das ist das eigentliche Problem beim srcds. Sollen es z.B. Gameserver sein, die keine Plugins laden können, hast du schonmal einen Sicherheitsgewinn.

Dann gilt nur noch Startscripte abchecken, Binaries überwachen und Server starten.

An deiner Stelle, würde ich mit Symlinks arbeiten. Spart Platz, macht die Installationen sehr schnell und man kann zentralisiert updaten. Wenn du willst kannst du sogar ein Tar-Archiv mit Symlinks bepacken. Dadurch hast du auch noch die Möglichkeit unveränderbare Serverdateien und Dateien des Kunden voneinander zu treffen (z.B. durch unterschiedliche User).

Das könnte dann so aussehen, dass die Masterdateien z.B. dem User serverfiles gehören und die Dateien des Kunden z.B dem User kdxxxxx gehören. Beide können in der gleichen Gruppe sein, wobei dann aber zu bachten ist, dass die UMASK richtig gesetzt ist. Sollte ein Updater wie Steam verwendet werden, sollte man nach jedem Update lieber nochmal ein Script drüberlaufen lassen, welches die Berechtigungen korrigiert. Soweit ich weiß schert sich der Steam-Installer einen Dreck um die gesetzte Umask. Wenn es Server ohne Updater sind (z.B. Quake3), würde dieser Check nur nötig sein, wenn du die Dateien manuell updatest.
 
Ganz einfache Sache die ein großer Anbieter aus Nürnberg so realisiert hat (oranges Logo mit 3 Kugeln, gibts allerdings nicht mehr) bei dem ich neben Support auch für das Einpflegen von Plugins zuständig war.

Die Kunden konnten per FTP nicht auf die Daten zugreifen sondern haben lediglich per WI Ihre Configs bearbeiten können. Auch nur darüber konnten Plugins installiert werden, simple Formulare, sowie deren Configs bearbeiten.

So kommen auch alle Plugins ganz einfach über einen internen Imageserver.

Andere Variante wäre, das einfach jeder Gameserver ein vServer ist. Das Bedarf dann in jedem Falle ein eigenes Backendsystem zur Verwaltung aber dann kann der Kunde im Grunde machen was er will, mehr als sich selbst kann er nicht schaden.
 
Bordey Bluenge said:
Die Kunden konnten per FTP nicht auf die Daten zugreifen sondern haben lediglich per WI Ihre Configs bearbeiten können. Auch nur darüber konnten Plugins installiert werden, simple Formulare, sowie deren Configs bearbeiten.
Click to expand...

Beim srcds unmöglich allen gerecht zu werden. Die Kunden werden reihenweise abhauen, wenn sie nicht flexiebel mit SM und Mani, ES, MM:S-Plugins und VSP.

Bei anderen aber durchaus Sinnvoll. Z.b. für COD4. Da gibt es nur ein paar Plugins. Diese laufen Teilweise sowieso als eigentständiges Programm, was der Provider dann einrichten muss. Wie gesagt, solange es kein srcds/hlds ist, ersparst du dir viel Arbeit.
 
Also bei dem Anbieter von dem ich spreche hat das verdammt gut funktioniert, und das sogar, obwohl jedes Plugin da ein par Cent extra gekostet hat. Was man glaubt was von der Business Seite funktioniert und was dann wirklich klappt ist oftmals erstaunlich. Man muss es nur verkaufen können ;)

Du kannst das sehr flexibel gestalten, es reicht vollkommen die am meisten gefragten Plugins / Erweiterungen anzubieten. Wenn die Qualität dabei stimmt, passt es. Die Kiddi-Kunden die sich jeden "Rotz" auf jede unmöglich erdenkliche Art einrichten, vor allem diesen Eventscript Schrott, würde ich, wäre ich Anbieter, eh nicht haben wollen.
 
Naaaaja. Ich find Eventscripts auch zum kotzen. Aber dennoch gibt es viele Sachen, was die Leute unbedingt haben wollen. Du schließt einen großen Kundenstamm schonmal aus (ja, auch viele Kinder). Auch das Warten und Aktualisieren von SourceMod-Plugins halte ich für Utopie. Bei einem unangekündigten Engine-Update bricht dann mal wieder Panik aus.

Da der OP geschrieben hat, dass er keine Spiele anpreist, die in der ESL präsent sind, denke ich mal, dass der srcds flach fällt.

Wenn er alte Spiele unterstützen will, die durchaus noch sehr oft vertreten sind, fällt damit auch der Verwaltungsaufwand. Da die meisten alten Server kaum noch aktualisiert werden und die Vielfalt der Plugins sicherlich auch überschaubar sein wird, denke ich mal, dass ein FTP-Zugriff eher nicht von Nöten ist.

Da er nicht schreibt, welche Spiele es sein sollen, kann man nur Vermutungen anstellen.
 
Zu meinen Spielen gehören bisher keine Steam-Games und haben keine Startparameter, welche die Slots, IP und/oder Port beinhalten.
Dies hat aber weniger mit dem Thema zu tun, da ich gerne über alle Spiele mit euch diskutieren möchte.

Anbieter müssten/sollten also am Besten eine Whitelist führen, in denen Plugins freigegeben werden und der Kunde keine anderen Plugins aktivieren/laden/instalieren kann - Soweit ok, bei CSS & Co. aber aufgrund der Masse an Plugins nicht wirklich realisierbar - Oder sehe ich das falsch?

Bei "GTA: San Andreas Multiplayer (SA:MP)" gibt es ungefähr 20 Plugins, welche man durchaus selbst pflegen und mit einer Whitelist betreiben könnte, gleiches gilt für "Multi Theft Auto (MTA)", einer weiteren Multiplayer-Modifikation für "GTA: San Andreas".

Sobald man also dem Kunden die Installation von Plugins überlässt, stellt dies ein relativ großes Sicherheitsrisiko dar - Deine Methode mit dem SSH-Tunnel habe ich gelesen, DeaD_EyE.

Für mich wäre dieses Plugin-Geschichte also relativ schnell "vom Tisch", doch das ist nicht der Sinn dieser Diskussion - Es geht hierbei nicht nur um mich, sondern um uns alle.
 
Blister said:
aber aufgrund der Masse an Plugins nicht wirklich realisierbar - Oder sehe ich das falsch?
Click to expand...

Wenn man es richtig macht, ist das problemlos machbar. Wie gesagt, ich war in dem Bereich einige Monate tätig. Einpflegen neuer Plugin-"Images" und Realisierung derer Konfiguration per Frontend.

Sobald man also dem Kunden die Installation von Plugins überlässt, stellt dies ein relativ großes Sicherheitsrisiko dar
Click to expand...

Jein, das hängt davon ab wie man seine Systeme konfiguriert und das Bereitstellen der Gameserver umsetzt. Es geht auch sicher ;)
 
Geht es so sicher, dass Systembefehle die der Server durch Plugins ausführt, geblockt werden? Ich sehe da nur ein minimales Chroot als annähernd sicher.

Mit Berechtigungen und Scripten die vor und nach dem Serverstart ausgeführt werden, kann man schon viel erreichen. Die Scripte können die Serverdateien vor Änderungen schützen. Wenn die Dateien einem anderen User gehören und keine Schreibrechte gesetzt sind, ist es unmöglich das auszuhebeln, es seiden es gibt mal wieder einen neuen local root exploit. Ein Restrisiko wird aber immer geben.

Am besten gleich alle Userprozesse eines Users nach dem Beenden des Servers killen. Damit stellt man sicher, dass nichts am Ende trotzdem im Hintergrund weiter läuft. Unter anderem sollte man Usercrontabs verbieten, damit man erst gar nicht dort ansetzen kann.

In wie weit Plugins anderer Server zu solchen Aktionen in der Lage sind, kann ich nicht sagen.
 
Dann ist mein aktuelles Konzept ja schon mal nicht soo schlecht.
Jeder Gameserver hat einen eigenen Shell-Benutzer und bei jedem (Neu)Start des Servers werden alle Prozesse von dem Shell-Benutzer gekillt.

Cronjobs könnten dann trotzdem durch Plugins "eingeschleust" werden, weshalb man auch hier wieder eine Whitelist der Plugins nutzen sollte - Also kommt man da wohl nicht drum herum.

Doch wie soll man dann mit "... die Rechte einem anderen User gehören" arbeiten?
Aktuell hat bei mir jeder Gameserver seinen eigenen Shell-Benutzer - Sollte dann jeder Gameserver 2 Shell-Benutzer haben, wobei einer von den beiden den Server startet und der andere Dateien verändern darf?
Soll das dann mit der Gruppenberechtigung arbeiten?
 
Das wäre zum Beispiel eine der möglichen Varianten. Um einen kundenübergreifenden Schutz zu bieten sollte man die Gameserver in jeweils eigenen vServern bereit stellen, das bietet auch weitere Möglichkeiten (z.B. Ressourcenlimitierung durch "Schrottplugins" etc.). Um den Gameserver im vServer selbst abzusichern bekommt der Kunde generell keinerlei Zugriffsmöglichkeit auf die Startdateien. Desweiteren wird der Gameserver auch unter einem anderen User gestartet als der FTP Zugriff gewährt wird.

So ist man schon sehr nahe dran. Einen endgültigen Schutz wird man durch die durch die Bank weg schlechte "Plugin" Realisierung vor allem z.B. bei Steam Spielen eh nie bekommen.
 
Das Problem bei vServern ist dann aber, dass man für jeden vServer eine eigene IP benötigt, was meiner Meinung nach übertrieben ist.
Lediglich die Ressourcenbegrenzung spricht für vServer - Alles Andere sollte man mit den 2 Shell-Benutzern hinbekommen.

Liege ich denn damit richtig, dass das MySQL-Plugin von ProFTPd lediglich aliase für einen Benutzer anlegt, welchen man dann Regeln/Sperren "auftragen" kann?
 
Interessanter Einwurf, doch vServer selbst benötigen ja auch wieder extra Ressourcen.
Dann müssen auf diesen vServern wieder mysql, ftp und der ganze Kram installiert werden.
Ob eine Automatisierung in diesen Fall sinnvoll ist, lasse ich Jedem frei - Mir wäre der Aufwand zu groß.
 
Overhead ist bei OpenVZ relativ gering, allerdings kannst du damit eps und 10k Hertz Server vergessen ;) Ja ich weiß 10k fps ist unreal aber die Leute sind so blöd und kaufen das.
 
You must log in or register to reply here.
Back
Top