Blog von Andreas Lehr

Nginx is (spoken: engine x) is a HTTP and reverse proxy server written by the russian developer Igor Sysoev. Nginx is also able to proxy mail server requests coming in via pop3 and imap.
Popular sites like FastMail.FM and Wordpress.com are usually using nginx as reverse proxy or HTTP Server.
According to Netcrafts Web Server Survey from December 2009 nginx gained 5,2% market share since December 2008 and will exceed the 7% barrier in january 2010. In addition to that 12,9 million websites started using nginx as webserver or loadbalancer as first contact instance in the year 2010. Nginx now clearly exceeds the former lightwight webserver king lighttpd (market share round 0.36% in December 2009).

In a first example we use nginx is together with the FastCGI Process Manager php-fpm in order to run a serendipity weblog.
PHP-fpm will be included in future versions of PHP 5.3 but isn't shipped with stable PHP 5.2 and therefore we have to built php and php-fpm the traditional way.

"Howto: nginx, php-fpm and serendipity weblog (s9y) with apache style rewriting" vollständig lesen

| Top Exits (187)

Seit geraumer Zeit ist bei uns das freie Wikisystem DokuWiki im Einsatz.
Um die Ergonomie und Verwaltung zu erleichtern, haben wir das wiki an unser ActiveDirectory angebunden.
Die Authentifizierung aus verschiedenen Netzen macht modldap:

Apache Vhost config:
# LDAP Authentication & Authorization is final; do not check other databases
AuthzLDAPAuthoritative off

# Do basic password authentication in the clear
AuthType Basic

# The name of the protected area or "realm"
AuthName "Use AD Account for authentification"

AuthBasicProvider ldap

# Active Directory requires an authenticating DN to access records
# This is the DN used to bind to the directory service
# This is an Active Directory user account
AuthLDAPBindDN "CN=USERNAME,OU=P-R,OU=P,OU=Organization,DC=intranet,DC=dmz"

# This is the password for the AuthLDAPBindDN user in Active Directory
AuthLDAPBindPassword "PASSWORD"

# The LDAP query URL
# Format: scheme://host:port/basedn?attribute?scope?filter
# The URL below will search for all objects recursively below the basedn
# and validate against the sAMAccountName attribute
# AuthLDAPURL "ldap://DOMAINCONTROLLER IP/HOST:389 OU=Organization,DC=intranet,DC=dmz?sAMAccountName?sub?(objectClass=*)"
AuthLDAPURL "ldaps://DOMAINCONTROLLER IP/HOST:636/OU=Organization,DC=intranet,DC=dmz?sAMAccountName?sub?(objectClass=*)"
AuthUserFile /dev/null

# Require authentication for this Location
Require valid-user

ModLDAP gibt die Credentials dann an Dokuwiki weiter, welches uns über das Plugin Auth:AD authentifiziert:

local.php
// configure your Active Directory data here
$conf['auth']['ad']['accountsuffix'] = '@intranet.dmz';
$conf['auth']['ad']['basedn'] = 'DC=intranetDC=dmz';
$conf['auth']['ad']['domaincontrollers'] = 'DOMAINCONTROLLER IP/HOST'; //multiple can be given
$conf['auth']['ad']['sso'] = 1;
$conf['auth']['ad']['adusername'] = 'USERNAME';
$conf['auth']['ad']['adpassword'] = 'password';
$conf['auth']['ad']['realprimarygroup'] = 1;
$conf['auth']['ad']['usessl'] = 1;
$conf['auth']['ad']['debug'] = 0;

Die Superuser Gruppe enthält alle User, die im Wiki Admin Rechte bekommen sollen:

$conf['superuser'] = '@grlokwikiadmin';

Zugriffe kann man dann ganz normal über das ACL plugin verteilen und in der acl.auth.php von DokuWiki konfiguriert werden. Aufpassen muss man allerdings bei Benutzergruppen die Sonderzeichen enthalten:

acl.auth.php
@gr%5flok%5falle 8

Die Gruppe "grlokallle" enthält uneingeschränkten Zugriff auf alle Wiki Seiten. Das Sonderzeichen "" muss mit "%5f" escaped werden.

acl.auth.php
production: @ALL 0
production:* @gr%5flok%5fbetrieb 8

Der Namespace "production" darf von niemandem gelesen werden, die Gruppe "grlok_betrieb" hat uneingeschränkten Zugriff.

| Top Exits (308)

Über Lücken und Schwachstellen in PHP liest man ja ständig. Die Entwickler sind beim fixen der Fehler leider auch nicht die schnellsten. Somit sollte man sich Gedanken über zusätzliche Absicherungen machen. Außerdem hat mich Martin unfreiwillig davon überzeugt, dass hier Handlungsbedarf besteht
Eine meiner Meinung nach gute Möglichkeit zur Absicherung stellt die Suhosin Erweiterung des Hardened PHP Projects dar.

Suhosin is an advanced protection system for PHP installations. It was designed to protect servers and users from known and unknown flaws in PHP applications and the PHP core.

Suhosin kommt in 2 Teilen - ein Teil ist ein Patch direkt für den PHP Core, der andere ist eine normale PHP Extension. Für optimalen Schutz sollte man beide einsetzen - muss aber nicht. Denn nicht jede Software ist 100% kompatibel zu den Einschränkungen, die Suhosin am PHP vornimmt.

Die Installation des Patches ist kinderleicht:
- Passende Version im Downloadbereich wählen.
- Patch das PHP Build verzeichnis entpacken
- in meinem Fall ein patch -p 1 -i suhosin-patch-5.2.3-0.9.6.2.patch ausführen
- PHP neu kompilieren und installieren
- nach einem Neustart sollte unter phpinfo nun ein "This server is protected with the Suhosin Patch 0.9.6.2" stehen.

Die Extension einzubauen ist ebenfalls kein Hexenwerk:
- Download der aktuellen Version vom Downloadbereich
- Entpacken und wechsel ins Source Verzeichnis
- phpize, configure & make
- Einbau in die PHP.ini mittels "extension="suhosin.so""
- nach dem Apache reload sollte sich die Zend Engine dann mit " with Suhosin v0.9.20, Copyright (c) 2002-2006, by Hardened-PHP Project" melden.

Danach solltet ihr noch eure Software testen, vor allem Fremdprodukte.
Natürlich hat das ganze auch den Nachteil, dass eure Applikationen ein wenig langsamer lauffen...wer aber eh Performance übrig hat, wird davon nicht viel merken. Nichtsdestotrotz gibts hier eine Benchmark Seite mit Vorher/Nachher Vergleichen. Außerdem gibts das Benchmark Skript auch zum Download


Bei uns funktioniert alles reibungslos, ob nun die Blogsoftware serendipity, das Webframework Symfony oder den PHP Accelerator eaccelerator, alles läuft bisher tadellos!

Viel Spaß beim ausprobieren.

| Top Exits (2882)