php_admin_value<\/pre>\n f\u00fcr die Include-Verzeichnisse gesetzt wird, der ein \u00dcberschreiben dieser Konfiguration durch PHP unm\u00f6glich macht. Die Generierung dieses Konfig-Eintrages zu patchen ist aber sinnlos, da es im n\u00e4chsten Update eh wieder \u00fcberschrieben wird. W\u00fcrde an dieser Stelle allein ein <\/p>\n
php_value<\/pre>\n stehen, w\u00fcrde das Script problemlos laufen. Aber gut, es gibt Schlimmeres!<\/p>\n
Zum Beispiel die Unterst\u00fctzung von SSL. Ich wei\u00df, 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\u00fcr den Apache auch als Modul verf\u00fcgbar ist. Und hier f\u00e4ngt es schon mal an: Damit GnuTLS funktioniert, muss man mod_ssl vollst\u00e4ndig 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\u00f6htem Arbeitsaufwand auch den Verlust dieser Funktion der Verwaltungsoberfl\u00e4che.<\/p>\n
Gehen wir zum n\u00e4chsten Punkt: Der Unterst\u00fctzung 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\u00f6tig \u00c4rger: Kunden an sich k\u00f6nnen dies nicht tun, da zus\u00e4tzliche Eintr\u00e4ge in der Apache-Konfiguration nur von einem Administrator vorgenommen werden k\u00f6nnen. Ein Kompromiss w\u00e4re maximal ein Konfigurationstemplate, was ein Reseller aktivieren\\deaktivieren kann – in diesem Fall fehlt aber jegliche Flexibilit\u00e4t des Ganzen.<\/p>\n
Setzen wir auf WebDAV doch einfach noch eine Anwendung drauf: ein SVN. SVN ist etwas sch\u00f6nes, 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\u00e4nkungen, 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\u00fcr das SVN an sich k\u00fcmmern (was daher der Einfachheit halber mit einem SVNParentDir geregelt werden sollte ;-)), sondern zus\u00e4tzlich auch jegliche Eintr\u00e4ge f\u00fcr die Benutzer-Verwaltung manuell anlegen, verwalten und \u00fcber die Repository-Konfiguration f\u00fcr Per-Directory-Schreibrechte einpflegen. Wer dies noch nicht gemacht hat, verzweifelt hier bereits beim Einrichten, wer sich diesen Stress bereits angetan hat, m\u00f6chte es so schnell nicht wieder.<\/p>\n
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\u00f6tig einfach macht, Prozesse auf dem Server auszuf\u00fchren, ohne dass der User sich dabei um Sicherheit k\u00fcmmern 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\u00f6glich ist, diese Funktionen gescheit in ihrer Funktionalit\u00e4t zu beschr\u00e4nken. Und was macht Confixx: Es bietet einem an, diese Funktionen zu deaktivieren, ruft aber fr\u00f6hlich 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) …<\/p>\n
Wie kann man bei solchen Patzern bitte seinen Server gegen Angriffe sch\u00fctzen, wenn schon die Verwaltungssoftware es einem praktisch unm\u00f6glich macht, diese Richtlinien sinnvoll durchzudr\u00fccken? Auch hier gilt es dank der Konfigurationssoftware: Selber Hand anlegen! Das Zauberwort hier Hardening Patch und Suhosin Extension f\u00fcr PHP, alles unn\u00f6tige abschalten und nur wo explizit n\u00f6tig wieder Whitelisten. Das behebt zwar nicht das Problem an sich, hilft aber zumindest die offensichtlichen L\u00fccken soweit zu stopfen, dass es Angreifern erschwert wird.<\/p>\n
Dass es eigentlich keine Software f\u00fcr PHP gibt, die mit einem auf diese Weise abgesicherten Server (out-of-the-box) l\u00e4uft, brauch ich glaube an dieser Stelle nicht weiter erw\u00e4hnen. Das zu Confixx mitgelieferte phpMyAdmin nervt auf seiner Startseite damit, dass es mit der Suhosin-Extension nicht l\u00e4uft – was ehrlichgesagt bei Hunderfach verschachtelten Arrays auch kein Wunder ist -, das phpBB-Forum nutzt eval f\u00fcr Templates – was nicht nur unperformant, sondern auch unsicher, ist -, und WordPress begr\u00fc\u00dft einen mit einer Meldung, dass es gern den \/e-Modifier zum Ausf\u00fchren von PHP-Code mit preg_replace nutzen m\u00f6chte, was schon seit Ewigkeiten sicherer und flexibler mit preg_replace_callback zu erreichen ist.<\/p>\n
Das einzige, wo einem die Konfigurationssoftware keine H\u00fcrden in den Weg legt, sind CGIs: in das zugeh\u00f6rige Verzeichnis legen und freuen, dass sie laufen – vorausgesetzt man steigt von libapache2_mod_suexec auf libapache_mod_suexec_custom um, damit die Berechtigungen stimmen.<\/p>\n
Vielen Dank, dass die Server-Software immer so reibungslos und DAU-sicher zu bedienen geht – viele Probleme k\u00f6nnten einem ja sonst erspart bleiben!<\/p>\n
![\"Flattr](\"http:\/\/blog.benny-baumann.de\/wp-content\/plugins\/flattr\/img\/flattr-badge-large.png\"){kind=icon}
<\/a><\/p>","protected":false},"excerpt":{"rendered":"