BenBE's humble thoughts Thoughts the world doesn't need yet …

Also so ein vServer kann etwas Schönes sein – wenn man ihn nicht administrieren muss. Gut, man hat vollen Zugriff auf alles, außer die Dinge, wo einem die Verwaltungssoftware ins Handwerk pfuscht. Und das ist leider an vielen Stellen etwas zu viel des Guten – fangen wir dazu doch einfach einmal bei ganz simplen Dingen an:

Auf meinem Server läuft die neue Website des GeSHi-Projektes. Jedes Mal, wenn ich die Verwaltungssoftware – in meinem Falle Confixx – aktualisiere, darf ich einmal in die Apache-Konfiguration rennen, die mir Confixx dabei neu erzeugt, da dort für den gesamten Server ein

php_admin_value

für die Include-Verzeichnisse gesetzt wird, der ein Überschreiben dieser Konfiguration durch PHP unmöglich macht. Die Generierung dieses Konfig-Eintrages zu patchen ist aber sinnlos, da es im nächsten Update eh wieder überschrieben wird. Würde an dieser Stelle allein ein

php_value

stehen, würde das Script problemlos laufen. Aber gut, es gibt Schlimmeres!

Zum Beispiel die Unterstützung von SSL. Ich weiß, da ist der Apache auch ein wenig mit dran schuld, da mod_ssl IP-basiert die Zertifikate verteilt, aber es gibt ja Alternativen wie GnuTLS, was für den Apache auch als Modul verfügbar ist. Und hier fängt es schon mal an: Damit GnuTLS funktioniert, muss man mod_ssl vollständig lahmlegen – dadurch bedingt, darf man absofort jeglichen SSL-Support per Hand konfigurieren, das geht zwar nahezu analog zu mod_ssl auch mit mod_gnutls, bedeutet aber neben erhöhtem Arbeitsaufwand auch den Verlust dieser Funktion der Verwaltungsoberfläche.

Gehen wir zum nächsten Punkt: Der Unterstützung von WebDAV. Diese Funktion ist in Confixx nicht enthalten, was auch gut nachvollziehbar ist, wenn man aber versucht, WebDAV auf eine bestehende, mit Confixx-konfigurierte Domain zu legen, macht man sich nur unnötig Ärger: Kunden an sich können dies nicht tun, da zusätzliche Einträge in der Apache-Konfiguration nur von einem Administrator vorgenommen werden können. Ein Kompromiss wäre maximal ein Konfigurationstemplate, was ein Reseller aktivieren\deaktivieren kann – in diesem Fall fehlt aber jegliche Flexibilität des Ganzen.

Setzen wir auf WebDAV doch einfach noch eine Anwendung drauf: ein SVN. SVN ist etwas schönes, gerade zum managen dieses Blogs. Aber eh ich mir den Trubel antue, das SVN mit auf dem Server aufzusetzen, lasse ich es. Analog zu den Einschränkungen, die ich bereits bei WebDAV-Verzeichnissen gesagt habe, kommt bei SVN noch erschwerend hinzu, dass die normalerweise recht gut gelungene Benutzer-Verwaltung und der daraus resultierende Passwort-Schutz komplett wegfallen. Somit darf man sich nicht nur um das Schreiben der Konfigurationsdateien für das SVN an sich kümmern (was daher der Einfachheit halber mit einem SVNParentDir geregelt werden sollte ;-)), sondern zusätzlich auch jegliche Einträge für die Benutzer-Verwaltung manuell anlegen, verwalten und über die Repository-Konfiguration für Per-Directory-Schreibrechte einpflegen. Wer dies noch nicht gemacht hat, verzweifelt hier bereits beim Einrichten, wer sich diesen Stress bereits angetan hat, möchte es so schnell nicht wieder.

Bliebe das Thema Sicherheit. PHP ist nicht sicher. Das wissen wir auch nicht erst, seit Stefan Esser beim PHP Security Team ausgestiegen ist, sondern schon allein daraus, dass PHP es dem User unnötig einfach macht, Prozesse auf dem Server auszuführen, ohne dass der User sich dabei um Sicherheit kümmern muss. Versteht mich jetzt nicht falsch, ich habe nichts dagegen, dass es Funktionen wie eval, exec und popen gibt – jedoch dagegen, dass es mit einer Standard-Implementation von PHP unmöglich ist, diese Funktionen gescheit in ihrer Funktionalität zu beschränken. Und was macht Confixx: Es bietet einem an, diese Funktionen zu deaktivieren, ruft aber fröhlich selbst allerhand Funktionen dieses Kalibers auf – unter anderem, um ein Directory Listing zu erstellen (geht ohne Exec auch einfach mit opendir, readdir und closedir), Dateiberechtigungen zu setzen (geht mit chmod und chown auch mit PHP selber) …

Wie kann man bei solchen Patzern bitte seinen Server gegen Angriffe schützen, wenn schon die Verwaltungssoftware es einem praktisch unmöglich macht, diese Richtlinien sinnvoll durchzudrücken? Auch hier gilt es dank der Konfigurationssoftware: Selber Hand anlegen! Das Zauberwort hier Hardening Patch und Suhosin Extension für PHP, alles unnötige abschalten und nur wo explizit nötig wieder Whitelisten. Das behebt zwar nicht das Problem an sich, hilft aber zumindest die offensichtlichen Lücken soweit zu stopfen, dass es Angreifern erschwert wird.

Dass es eigentlich keine Software für PHP gibt, die mit einem auf diese Weise abgesicherten Server (out-of-the-box) läuft, brauch ich glaube an dieser Stelle nicht weiter erwähnen. Das zu Confixx mitgelieferte phpMyAdmin nervt auf seiner Startseite damit, dass es mit der Suhosin-Extension nicht läuft – was ehrlichgesagt bei Hunderfach verschachtelten Arrays auch kein Wunder ist -, das phpBB-Forum nutzt eval für Templates – was nicht nur unperformant, sondern auch unsicher, ist -, und WordPress begrüßt einen mit einer Meldung, dass es gern den /e-Modifier zum Ausführen von PHP-Code mit preg_replace nutzen möchte, was schon seit Ewigkeiten sicherer und flexibler mit preg_replace_callback zu erreichen ist.

Das einzige, wo einem die Konfigurationssoftware keine Hürden in den Weg legt, sind CGIs: in das zugehörige Verzeichnis legen und freuen, dass sie laufen – vorausgesetzt man steigt von libapache2_mod_suexec auf libapache_mod_suexec_custom um, damit die Berechtigungen stimmen.

Vielen Dank, dass die Server-Software immer so reibungslos und DAU-sicher zu bedienen geht – viele Probleme könnten einem ja sonst erspart bleiben!