Browsergame-Hosting Teil 2: Konfiguration grundlegender Dienste

Browsergame-Betreiber haben es schwer. Es ist noch lange nicht damit getan, ein gutes Spiel zu programmieren. Neben der eigentlichen Entwicklungsarbeit muß das Spiel auch immer irgendwie zum Spieler gelangen. Die kostengünstigste und wohl auch beliebteste Variante der Bereitstellung ist hier wohl ein eigener Server. Aber Achtung: Die Anschaffung eines eigenen Servers will wohl überlegt sein. Der zweite Teil dieser dreiteiligen Artikelserie beschäftigt sich mit der Einrichtung der wichtigsten Dienste wie Webserver, Datenbank und Mailserver.

Im letzten Artikel Vorüberlegungen & Betriebssystem haben wir unseren Server mit einem frisch installierten Betriebssystem auf einer Festplatte mit einem schöneren Partitionsschema als dem des Hosters ausgestattet. Der einzige Dienst der bisher produktiv läuft ist SSH. Dies soll sich nun ändern, allerdings sind vorher der Sicherheit zuliebe noch einige andere Schritte nötig.

Anlegen eines eigenen Benutzerkontos

Da momentan als root gearbeitet wird, sollte man unbedingt ein Benutzerkonto anzulegen, mit dem sämtliche Arbeiten ausgeführt werden die keine root-Rechte benötigen. Denn man sollte aus sicherheitstechnischen Gründen weder dauerhaft als root arbeiten, noch root den Login via SSH erlauben. Letztere Möglichkeit deaktiviert man deshalb am besten in der Konfiguration des SSH-Servers. Desweiteren bieten sich zwei einfache Maßnahmen an, SSH bedeutend sicherer gegen Angriffe zu machen. Erstens ist es günstig den Port, auf dem der SSH-Server hört vom Standardport 22 auf irgendeinen exotischen, aber dennoch leicht einprägsamen Port (z.B. Port 774, welcher auf einer Handytastatur die Buchstaben ssh darstellt) zu verschieben. Denn die meisten automatisierten Angriffe prüfen nur Port 22. Somit ist der Server allein dadurch schon aus dem Schußfeld vieler Hackversuche. Zweitens ist es sinnvoll statt einem Login mit Passwort nur schlüsselbasierte Logins zuzulassen. Dies führt dazu, dass ein Angreifer sich nicht mit einem erratenen Passwort via SSH auf dem Server einloggen kann, sondern den privaten Schlüssel braucht, den der Administrator des Servers zuhause auf seinem Rechner hat. Anleitungen hierfür finden sich ebenfalls im Internet.

Selbst ist der Admin


Nachdem die SSH-Konfiguration nun erstmal soweit abgeschlossen ist, folgt die Installation weiterer Dienste. Der Bequemlichkeit halber würde es sich nun anbieten ein Tool zu Konfiguration des Servers zu installieren, über das sich sämtliche relevanten Einstellungen vornehmen lassen. Allerdings haben solche Tools alle eine Gemeinsamkeit: schwerwiegende Sicherheitslücken. Das betrifft sowohl kommerzielle Systeme wie Confixx und Plesk, als auch OpenSource-Systeme wie VHCS oder DTC. Besonders vor letzterem sei besonders gewarnt. Wer halbwegs versiert in PHP ist und einiges ertragen kann, kann ja mal in den Sourcecode reinschauen. Da solche Serverkonfigurationstools meist sehr tiefgreifende Aufgaben erledigen sind auch ihre Sicherheitslücken dementsprechend tiefgreifend. Außerdem bietet ein konfigurieren per Hand den Vorteil, dass man mit keinerlei Einschränkungen leben muss. Deshalb wird im folgenden auch kein Tool zur Konfiguration verwendet, sondern alles per Hand konfiguriert.

Einrichtung des Webservers


Nach der Entscheidung gegen ein Tool zur Serverkonfiguration wenden wir uns nun der Einrichtung des eigentlichen Webservers zu, über den später das Spiel, Forum, etc. erreichbar sind. Da nur ein Rootserver zur Verfügung steht, muss man dafür sorgen, dass der Webserver auch bei vielen Anfragen schnell und ressourcensparend arbeitet. Der wohl am häufigsten verwendetet Webserver - Apache - bietet sich dafür nicht an. Er bietet zwar Unmengen von Möglichkeiten bei der Konfiguration und unzählige Module, ist aber dafür auch verhältnismäßig langsam.

Für ein einfaches Browsergame reicht auch der bedeutend flinkere lighttpd. Dieser hat zwar bei weitem nicht so viele Features wie Apache, aber sämtliche grundlegenden Möglichkeiten die Apache bietet sind ebenfalls vorhanden.

Da es Module wie mod_php nicht für lighttpd gibt, müssen die Interpreter der Programmiersprache unserer Wahl auf eine andere Art und Weise angesprochen werden. Dafür bietet sich fastcgi an. Dies funktioniert mit fast jeder Programmiersprache und hat unter anderem den Vorteil, dass man mit ein klein wenig Vorarbeit für jede Subdomain eine extra php.ini und unterschiedliche Benutzer einrichten kann [1]. Dies bietet große Vorteile bei der Sicherheit des Servers.

Hackt zum Beispiel jemand das Forum aufgrund einer Sicherheitslücke in der Forensoftware, hat er immer noch keinen Zugriff auf die Daten des Spiels, wenn das Forum beispielsweise unter dem Benutzer alf und das Spiel unter dem Benutzer otto läuft. Dies funktioniert natürlich nur wenn man die Dateirechte auch restriktiv genug setzt. Gewährt man der Kategorie "Andere" die Möglichkeit Dateien zu lesen, so bringt natürlich obige Benutzertrennung nichts. Deshalb sollte man "Andere" keinerlei Schreib- oder Leserechten an Dateien einräumen. Als Gruppe sollten sämtliche Dateien den Benutzer von lighttpd haben, damit lighttpd statische Inhalte wie Bilder oder einfache HTML-Dateien lesen kann. Dieser Benutzer ist im Normalfall www-data.

Kurzgesagt: Sämtliche Dateien, die etwas mit Inhalten des Webservers zu tun haben, sollten die Rechte 750 haben, als Benutzer einen Benutzer nach Wahl und als Gruppe www-data.

Doch nicht nur bei den vom Webserver verwalteten Dateien sollte man ein Auge auf die Dateirechte werfen. Dies gilt ebenso für sämtliche anderen Dateien. Je restriktiver die Dateirechte gesetzt sind, desto besser. Gerade Konfigurationsdateien die Passwörter enthalten kann man so gut vor allzu neugierigen Blicken schützen.
Das Prinzip von htaccess wie unter Apache gibt es bei lighttpd nicht. Zwar bietet lighttpd auch fast alle Möglichkeiten von htaccess, zum Beispiel das Schützen einzelner Ordner mit Passwörtern, allerdings muss dies in einer zentralen Konfigurationsdatei angegeben werden. Da man ja aber als Besitzer des Rootservers Zugriff auf diese Konfigurationsdatei hat sollte dies keine Einschränkung darstellen.

Jede Subdomain braucht ein eigenes Verzeichnis. Zu diesem Verzeichnis gibt es neben obengenannten Dateirechten noch etwas zu sagen. Idealerweise liegt das Verzeichnis, in dem die Daten einer Subdomain gespeichert werden können, nicht direkt im document-root des Webservers, sondern nur ein Verzeichnis unterhalb dieses Verzeichnisses. So hat der Webserver beispielsweise keinen Zugriff auf /var/www/virtual/forum/, sondern nur auf /var/www/virtual/forum/htdocs/. Dies bietet sich an, um brisante Dateien, zum Beispiel Konfigurationsdateien mit Passwörtern, außerhalb des document-root speichern zu können. Auch sollte man das auflisten von Verzeichnisinhalten, das sogenannte directory listing, deaktivieren, da sonst unter Umständen ersichtlich ist welche Dateien im document-root liegen und Angreifer somit eine Liste von Dateien erhalten bei denen sie gezielt nach Sicherheitslücken suchen können.

Einbindung von Scriptsprachen und Programmen

Wie durch weiter oben verlinkte Anleitung ersichtlich, ist es nicht weiter schwer Interpreter für PHP und beliebige andere Sprachen via fastcgi in lighttpd einzubinden. Die meisten hobbymäßigen Browsergameentwickler verwenden für ihre Browsergames PHP, deshalb sei nun auf ein paar Sicherheitsaspekte bei PHP eingegangen. So sollte man unbedingt den suhosin-Patch installieren, der neben vielen Verbesserungen der Sicherheit von PHP auch einige essentielle Features wie zum Beispiel Hashing nach SHA1 nachrüstet. Hat man PHP nach obiger Anleitung eingebunden, ergibt sich die Möglichkeit pro Subdomain eine eigene php.ini zu verwenden. Dies sollte man auch unbedingt tun, da damit eine viel feinkörnigere Konfiguration verwendet werden kann als mit einer zentralen php.ini. Dies führt sowohl zu mehr Sicherheit als auch zu mehr Performance, da für jede Subdomain nur die benötigten PHP-Module geladen werden müssen.
Eine Option, die PHP momentan bietet, um vor allem bei Shared-Hosting eine gewisse Sicherheit zu erlangen, ist der sogenannte Safe-Mode. Dieser sollte nicht verwendet werden, denn er bietet nur trügerische Sicherheit und nichts was man nicht auch auf andere Art und Weise konfigurieren könnte. Desweiteren wird es den Safe-Mode ab PHP 6 sowieso nicht mehr geben, insofern wäre es sinnlos jetzt beim einrichten eines Servers ein Feature zu verwenden, welches nicht "aufwärtskompatibel" ist.

Was bei einer möglichst sicheren php.ini zu beachten ist, sind vor allem die Restriktiven open_basedir, register_globals und disable_functions. open_basedir grenzt die Verzeichnisse ein auf die PHP zugreifen darf. Als Wert bietet sich da natürlich das Wurzelverzeichnis der aktuellen Subdomain an (zum Beispiel /var/www/virtual/forum/). register_globals sollte grundsätzlich deaktiviert sein und gehört ebenfalls zu den "Features" die es ab PHP6 nicht mehr geben wird. Mit disable_functions besteht die Möglichkeit einzelne PHP-Funktionen gezielt zu deaktivieren. Welche da im Einzelfall sinnvoll sind, ist je nach Anwendungszweck unterschiedlich. Allerdings sollte man nach Möglichkeit alles deaktivieren, wodurch PHP der Zugriff auf eine Shell und externe Skripte möglich ist. Desweiteren sollte man mit den passenden Restriktiven die Ausgabe von Fehlermeldung auf Nutzerseite abschalten und Fehlermeldungen stattdessen in eine Logdatei schreiben lassen. Dies führt einerseits dazu das Nutzer nicht von kryptischen PHP-Fehlermeldungen irritiert werden und andererseits muss man auf diese Art und Weise keine Details offenbaren die diese Fehlermeldungen zwangsläufig enthalten. Zum Beispiel wie der absolute Pfad zur gerade ausgeführten Datei aussieht.

Doch genug zu Sicherheitsaspekten von PHP. Nun stellt sich die Frage, ob man PHP neben der ohnehin schnellen Ausführung via fastcgi nicht noch weiter beschleunigen kann. Die Antwort lautet: ja. Dafür bietet sich ein sogenannter Opcode-Cache an, welcher bestehende Skripte einmal in Opcode umwandelt und cached, sodass diese Umwandlung bei weiteren Anfragen entfällt. Beispiele für solche Opcode-Caches wären APC, eAccelerator und IonCube.

Installation der Datenbank


Nachdem der Webserver mit PHP-Interpreter nun läuft, ist die Einrichtung einer Datenbank sinnvoll, in der verschiedenste Dienste ihre Daten speichern können. Als Beispiel verwenden wir MySQL, da dies die Datenbank ist die wahrscheinlich auch die meisten von euch verwenden werden. Nach der Installation von MySQL ist nicht viel zu konfigurieren. Man sollte lediglich darauf achten ein root-Passwort für MySQL zu setzen, da dies zumindest bei Debian direkt nach der Installation nicht der Fall ist. Um die Datenbank nicht die ganze Zeit via Kommandozeile bedienen zu müssen, bietet sich die Installation eines Tools wie phpmyadmin an, welches eine bequeme Weboberfläche zur Verwaltung bereitstellt. Außer dem root-Nutzer wird es später sicher noch verschiedene andere Benutzer für die Datenbanken geben. Dabei sollte man darauf achten, den Nutzern nur so wenig Rechte wie möglich einzuräumen. Denn auch hier trifft wieder obiges Beispiel zu: Verfügen Spiel und Forum über unterschiedliche Zugänge zur Datenbank und dürfen nicht auf die jeweils anderen Daten zugreifen, so hat ein Hacker nach dem hacken des Forums nur die Daten des Forums und nicht die des Spieles.

Mail- und FTP-Server


Als nächstes kommen Mail- und FTP-Server an die Reihe. Diese sollen eine Gemeinsamkeit haben: virtuelle Nutzer. Das heißt, dass ihre Nutzer unabhängig von den Systemnutzern des Servers sind. So können ohne großen Aufwand E-Mail-Konten und FTP-Accounts erstellt werden, was auch sehr viel flexibler bei der Art der Speicherung dieser Accountdaten ist. Es bietet sich an diese Nutzer in einer Datenbank zu speichern. In diesem Fall natürlich sinnvollerweise in der schon eingerichteten MySQL-Datenbank. So lassen sich Änderungen an Nutzerkonten sehr einfach vornehmen.

Welche Kombination aus Mailserver und Mail Transfer Agent man verwendet, ist relativ egal und hängt von eigenen Vorlieben ab. Für normale Aufgaben eignen sich aber sämtliche Kombinationen. So ist eine Verwaltung der Accountdaten via MySQL beispielsweise bei der Kombination Courier + Postfix ohner größere Probleme möglich [2]. Zur generellen Konfiguration des SMTP-Servers sei noch gesagt, dass man unbedingt darauf achten sollte, dass nur authentifizierte Nutzer E-Mails verschicken dürfen. Denn darf dies jeder Internetnutzer so wird der Server früher oder später zum Spamversand genutzt werden, was dazu führt, dass der Server auf Blacklists landet und somit auch keine gewünschten E-Mails mehr beim Empfänger ankommen.

Für die Nutzung von POP3 und IMAP sollte man Verschlüsselung zwingend vorschreiben. Deren Einrichtung stellt kein großes Hindernis dar und schützt vor dem mitsniffen von Passwörtern oder ganzen E-Mails, was grade in offenen WLANs ein nicht zu unterschätzendes Problem darstellt.

Gegen ankommenden Spam gibt es mehrere Möglichkeiten. So lässt sich beispielsweise mit Spamassassin und Amavis ein Spamfilter einrichten. Allerdings sollte man beachten, dass die Interpretation was Spam ist, teilweise eine reine Interpretationssache ist und für verschiedene Nutzer unterschiedlich sein kann. Somit sollte man jedem Nutzer die Möglichkeit geben einen eigenen Spamfilter trainieren zu können. Dazu habe ich bisher allerdings noch keine zufriedenstellende Möglichkeit gefunden. Allerdings gibt es eine andere Möglichkeit einen Großteil des Spams auszusortieren ohne das man anhand des Inhalts der E-Mails filtert. Diese Möglichkeit heißt greylisting. Dabei wird jede ankommende E-Mail erstmal abgewiesen und erst beim zweiten Zustellversuch angenommen. Da Spam meist keinen zweiten Zustellversuch unternimmt bleibt somit der meiste Spam außen vor. Einziger Nachteil dieser Lösung ist, dass sich die Mailzustellung in Einzelfällen um mehrere Stunden verzögern kann. Für Postfix eignet sich für greylisting beispielsweise das Tool postgrey, welches mit einer Whitelist die Möglichkeit bietet bei bekannten Providern ebengenanntes Problem zu umgehen.
Oft passiert es, dass bei einem neu eingerichteten Mailserver ausgehende E-Mails bei anderen Providern in den Spamordnern der Kunden landen oder vom entsprechenden Provider gar nicht erst angenommen werden. Woran dies liegt kann verschiedene Ursachen haben, aber meist bieten die Provider umfangreiche Informationen was man in einem solchen Fall tun sollte. Beispielsweise sollte die RDNS-Auflösung auch auf den richtigen Domainnamen auflösen.

Ein unrühmliches Beispiel beim Thema Spambehandlung stellt Hotmail dar. Hotmail nimmt grundsätzlich alle E-Mails an und filtert diese erst nach Annahme auf Spam, während die meisten anderen Provider eine grundsätzliche Überprüfung einiger Merkmale schon vor der Annahme der E-Mails durchführen. Dadurch kann es passieren das Hotmail E-Mails intern als Spam klassifiziert und aber nicht an den Empfänger ausliefert. Somit erscheint die E-Mail nicht einmal im Spamordner des Empfängers, sondern verschwindet irgendwo im Hotmail-internen Mailsystem. Um dieses Problem zu erkennen und zu beheben bietet Hotmail kaum Informationen an. Sollte man in die beschriebene Lage kommen helfen nur längere Diskussionen mit dem E-Mail-Support von Hotmail, da der eigene Webserver auf irgendeiner internen Blacklist gelandet ist.

m Nutzern von E-Mail-Adressen Zugriff auf ihre E-Mails unabhängig von POP3 und IMAP zu bieten und ihnen ein ändern ihres Passwortes zu ermöglichen sollte man einen Webmailclient installieren. Natürlich idealerweise einen der eine entsprechende Funktionalität zum ändern des Passwortes enthält. Dies ist beispielsweise bei squirrelmail der Fall. Dort lassen sich viele Funktionen durch zusätzliche Module nachrüsten, wie zum Beispiel besagtes ändern des Passwortes.


Als Software für den FTP-Server bietet sich proftpd an. Zwar gibt es mit vsftpd ein performanteres und potenziell sichereres Programm, allerdings unterstützt vsftpd nicht das wechseln der uid und gid für einzelne FTP-Sitzungen, was bei der Nutzung von virtuellen FTP-Nutzern aus Sicherheitsgründen sehr empfehlenswert ist. Wer keine virtuellen FTP-Nutzer benötigt ist mit vsftpd besser bedient als mit proftpd. Auch bei FTP sollte man Verschlüsselung verwenden, da sonst sämtliche Daten im Klartext übertragen werden. Zur eigentlichen Einrichtung von proftpd ist nicht allzuviel zu sagen. Entsprechende Tutorials, proftpd mit MySQL aufzusetzen, finden sich wieder im Internet [3].



Somit laufen nun auf dem Rootserver ein Webserver mit PHP, eine MySQL-Datenbank, ein Mailserver und ein FTP-Server. Dies ist die Software die für einen grundsätzlichen Betrieb eines Browsergames meist benötigt wird. Ein paar weitere Hilfsprogramme und -dienste werden im folgenden vorgestellt, wobei man natürlich je nach Spiel auch noch andere Programme benötigen kann. Wenn man sich bei der Wahl und der Konfiguration dieser Programme ein paar Gedanken zum Thema Sicherheit macht, steht einem sicheren Server nichts mehr im Wege.

Im dritten und letzte Teil dieser Artikelserie stellen wir eine Reihe nützlicher Tools und Programme vor, die euch bei der Administration eures Server gute Dienste leisten werden. Der letzte Teil erscheint Ende Oktober 2007.

[1] http://trac.lighttpd.net/trac/wiki/HowToSetupFastCgiInd...
[2] http://www.howtoforge.com/virtual_users_and_domains...

[3] http://www.howtoforge.com/proftpd_mysql_virtual_hosting...