Seit dem letzten Artikel läuft auf dem Virtual-Server ein ressourcen-sparsames aber mächtiges Mailsystem. In diesem Beitrag geht es um die Einrichtung eines Webservers.

Dazu werden folgende Komponenten installiert:

• Cherokee: ein leichtgewichtiger Webserver


• PHP: die allseits verhasste Skriptsprache

Für Cherokee habe ich mich entschieden, da es für die weiter verbreiteten Webserver Apache httpd und lighttpd schon mehr als genug Anleitungen und Howtos gibt. Falls Bedarf besteht würde ich deren Installation (sowie die von nginx und eventuell LiteSpeed) ebenfalls beschreiben.

Die Installation von PHP dient lediglich zur Demonstration, wie dynamischer Content gehostet werden könnte. Für andere Skriptsprachen ist das Vorgehen ähnlich und wird imm Cherokee Cookbook für weitere Applikationen beschrieben.

PHP wird dabei über die FastCGI-Schnittstelle von Cherokee eingebunden. Einen generellen Überblick über die Vor- und Nachteile von PHP über diese Schnittstelle liefert z. B. dieser Artikel im RootForum.de Wiki. More »

Postfix supports a nifty feature named access policy delegation or short policy services. Some of the more well known policy servers include postgrey, SQLgrey and policyd-weight.

These policy servers usually cannot be used on systems running Plesk since qmail is currently the only supported MTA. Since many policy servers provide helpful anti-spam services, I wrote a little script named PolicyHQ (Policy Handler for qmail) which can be used to easily connect to one or more policy servers during mail delivery and process the messages according to their result.

In contrast to some other addons for qmail, no modifications on the qmail binaries is necessary for PolicyHQ. The policy servers can be queried on a per-user (recipient or sender), per-domain (recipient domain or sender domain) or global basis.

Detailed Setup instructions are included in the tarball.

Download policyhq-0.1.tar.bz2

WARNING: PolicyHQ is currently considered beta software and should not be used on mission critical systems. Install it at your own risk.

Dass das Akronym PHP ab und zu auch für "Pretty Hard to Protect" stehen kann, ist sicherlich nichts Neues. Eine Sprache die leicht zu erlernen ist und deren Laufzeitumgebung bei jedem Feld, Wald und Wiesenprovider installiert ist, zieht nun einmal auch Leute an, die normalerweise nicht programmieren würden (oder sollten) und sich über Sicherheit nicht den Kopf zerbrechen. Es gibt also jede Menge schlechter PHP-Skripte. Das ist sicherlich nicht die Schuld der PHP-Macher.

Aber manchmal frage ich mich ernsthaft, ob ein Abschied von PHP vielleicht sinnvoll wäre. Die letzten Tage ist mal wieder ein schon etwas älterer Bug von PHP an die Oberfläche des Interwebs gespült worden.

Beim Einsatz als Apache-Modul werden vor dem Aufruf des PHP-Interpreters nicht alle Dateideskriptoren aufgeräumt, die der Apache httpd geöffnet hat. Dadurch kann über ein normales PHP-Skript sowie ein unterstützendes Binary (oder ggf. Skript, wenn der Interpreter die entsprechenden Systemaufrufe unterstützt) der Apache-Prozess verdrängt bzw. ersetzt werden.

Ein bösartiges Skript kann dadurch an Stelle des Apache httpd Daten an Besucher ausliefern und so bspw. Malware verbreiten, Passwörter abgreifen usw.

Man erhält dadurch zwar keine Rootrechte (zumindest nicht trivial), aber die Möglichkeit den Webserver abzuschießen und durch einen eigenen Prozess zu ersetzen ist schlimm genug. Betroffen sind scheinbar alle Versionen von PHP.

Was das ganz noch viel schlimmer macht, ist die Tatsache, dass alle Wohnzimmerhoster (no offense ;), die Plesk und vergleichbare Pakete benutzen, die auf mod_php setzen, von der Problematik betroffen sind, es aber vermutlich nicht wissen und niemals erfahren werden. Irgendwann sind die Server einfach einmal gekapert und liefern munter Malware aus. Zumindest bei Plesk ist die Nutzung von PHP als Apache-Modul obligatorisch. Andere Modi werden nicht unterstützt.

Um das Problem zu umgehen, bieten sich neben den offensichtlichen Vorschlägen PHP zu deinstallieren oder den Apache httpd durch eine Alternative wie lighttpd oder nignx zu ersetzen, folgende Möglichkeiten an, die möglichst kombiniert werden sollten:

1) PHP über die CGI-Schnittstelle, SuPHP oder FastCGI mit SuExec einbinden.
2) Funktionen wie system, passthru usw. mit disable_functions verbieten.
3) open_basedir Restrictions korrekt setzen.
4) Die Partition mit den PHP-Skripten mit dem Parameter noexec mounten.

Verweise:
Bug #20302 Leaked Descriptors
Bug #38915 Apache: system() (and similar) don't cleanup opened handles of Apache
http://hackerdom.ru/~dimmo/phpexpl.c
Hijacking Apache https by mod_php
Apache mit mod_php übernehmen

via Fefe

Sebastian Bergmann hat in seinem Blog vor einer Weile einen Benchmark über die Performance von PHP 4.3.11, PHP 5.0.4 und der damaligen Entwicklerversion von PHP 5.1 veröffentlicht. Da PHP 5.1 mittlerweile schon in Version 5.1.2 vorliegt und es auch in der 4er Reihe in paar Updates gab, hab ich die Benchmarks erneut durchgeführt. Wie Sebastian habe ich das Skript aus dem CVS von php.net herangezogen.
Die reinen Zahlen sind sicherlich nicht sonderlich aussagekräftig, das Verhältnis der Ausführungsgeschwindigkeiten von PHP 5.1.2 gegenüber PHP 4.4.2 und PHP 5.0.5 ist jedoch beachtlich. Zwar werden die 400% Geschwindigkeitssteigerung aus Sebastians Benchmark nicht erreicht, allerdings war PHP 5.1.2 (egal mit welchem Execution Model) bei den durchgeführten Tests mehr als doppelt so schnell wie PHP 4.4.2 und 5.0.5.
Zwischen den verschiedenen Dispatch Methoden (CALL, GOTO und SWITCH) gibt es jedoch keine großartigen Unterschiede. Die paar Millisekunden Abweichung sind wohl auf Meßungenauigkeit zurückzuführen.

UPDATE: Und wie es der Zufall so will, hat Sebastian Bergmann seinen Benchmark heute aktualisiert. Der Schwerpunkt liegt allerdings im Unterschied verschiedener GCC Versionen (GCC 3.4.5, GCC 4.0.2 und GCC 4.1.0.) anstatt verschiedener PHP Versionen. More »