Sicherheitsdiskussion: Webinterface/ControlPanel für Gameserver

  • Thread starter Thread starter Deleted member 10028
  • Start date Start date
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.


Entweder:
Code:
chmod go-rwx /var/spool/cron/crontabs/
#würde generell den Zugriff druch den Befehl crontab untersagen

Wobei ich diese Lösung viel eleganter finde:
http://www.pantz.org/software/cron/croninfo.html
/etc/cron.deny
oder /etc/cron.allow


Doch wie soll man dann mit "... die Rechte einem anderen User gehören" arbeiten?
Überhaupt nicht, solange es keinen lokalen exploit gibt, der zum Erlangen der Root-Rechte ausgenutzt werden könnte. Das könnte ein alter Kernel sein oder die Version, die du gerade nutzt. Man ist sozusagen vor nichts sicher. Sobald aber eine Lücke bekannt ist, wird diese sehr schnell gefixt.

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?
[/QUOTE]

Jain. Ich persönlich würde es z.B. vorziehen, dass du einen User hast, dem die Serverdateien gehören. Dies kann zentral ein User sein.

Allen Dateien bekommen die Berechtigungen 640, Verzeichnisse und ausführbare Dateien 750.

Nennen wir den User masterserver. Den packst du in die Gruppe server mit rein.

Alle User, mit denen deine Server gestartet werden, sind auch in der Gruppe server. Die Dateien des Masterservers kannst du symbolisch Verlinken (cp -sr) wobei Verzeichnisse erstellt werden und alle Serverdateien verlinkt werden. Dateien die beschreibbar sein müssen, müssen vorher als Template in einem anderen Verzeichnis vorbereitet vorliegen. Diese kannst du dann bei der Erstinstallation als erstes kopieren (mit dem Shellacount des Users). Danach mit cp -sr die Masterdateien drüberjauchen und zum Schluss vielleicht noch irgendwelche Plugindateien.

Bei den FTP-Zugängen arbeitest du am besten mit Virtuellen Benutzern. Das mit den Shell-Accounts ist der letzte Mist. Es hat auch noch den Vorteil, dass du das Chroot des Virtuellen FTP-Users in ein anderes Verzeichnis packen kannst, als das Homeverzeichnis.

Das ist das grobe Prinzip der zentralisierten Verwaltung durch Symlinks.


Ein weitere Prinzip wäre z.B. das, was 4netplayers einsetzt. Die Idee dahinter ist, dass der User keinen Zugriff auf die Serverdateien hat, da er in einem ganz anderen Verzeichnis als FTP-User eingeloggt wird. Das schöne an der Sache ist, dass erst nach dem Serverneustart die Dateien aus dem FTP-Verzeichnis in das Serververzeichnis kopiert werden. Dabei kann man prima mit Shell-Scripts arbeiten und recht simpel Dateien filtern, die nicht kopiert werden sollen. Der Haken an der Sache ist, dass der Kunde die vom Server erstellten Dateien nicht sieht. Darunter zählen z.B. Demos, die durch den Server aufgenommen worden sind oder SourceMod-Configs, die erst durch Plugins erstellt werden.

Da es schon spät ist, werd ich mal hier Schluss machen.
 
Die Symlinks sind eine echt gute Idee und gefällt mir sehr, aber ich sehe da ein kleines Problem.
Nicht alle Kunden möchten ihren Server sofort aktualisiert haben, da die meisten Plugins erst wieder an die neue Version angepasst werden müssen.
Wie könnte man dies "umgehen"? - Mit mehrere "zentralen Dateipfaden"?
 
Back
Top