Lighttpd mit PHP-FPM

Die meisten Root- oder V-Server werden in der Standard-Konfiguration ganz ohne Webserver oder mit Apache2 ausgeliefert. Mein Tipp hier: Alternativen testen! Lighttpd oder Nginx sind in vielen Fällen schneller und benötigen weniger Ressourcen. Jeder Webserver hat seine Vor- und Nachteile, es kann also nicht schaden die Alternativen einmal zu testen. Ich persönlich verwende schon seit längerem Lighttpd und bin sehr zufrieden damit. Die Konfiguration der verschieden Webserver sollte Dank zahlreicher Tutorials die im Netz verfügbar sind kein Problem darstellen.
Desweiteren empfehle ich dringen statt des “üblichen” PHP-Moduls (mod_php) PHP-FPM zu verwenden. Zusammen mit Lighttpd oder Nginx schafft ein Server so nicht selten wesentlich mehr Requests/Sec abzuarbeiten. Darüber hinaus bietet PHP-FPM einige sehr nützliche Features wie z.b. das Anlegen verschiedener Pools. Damit ist es möglich verschiedenen PHP-Prozesse mit verschiedenen Benutzern zu starten. Das bringt Sicherheits-Vorteile mit sich und lässt Schreibrechte-Probleme der Vergangenheit angehören. Zum Thema Lighttpd und PHP-FPM habe ich hier auch schon andere Beiträge verfasst.

Opcode Caching mit XCache

Da PHP keinen eigenen Opcode-Cache mit sich bringt fehlt dieser häufig auf Webserver. Ein Opcode oder Bytecode-Cache sorgt dafür, dass PHP-Scripte nicht bei jedem Aufruf neu in Bytecode übersetzt werden müssen. Besonders bei vielen gleichzeitigen Anfragen an den Webserver kann ein solcher Cache die CPU-Last erheblich verringern. Neben dem Zend-Optimizer, eAccelerator und APC gibt es hier noch meinen persönlichen Favoriten XCache. Installation und Konfiguration sollten keine Probleme bereiten, da es für quasi jede Linux-Distribution bereits fertige Pakete gibt.
Hinweisen möchte ich jedoch noch auf das XCache-Admin Feature denn hier kann man gut sehen ob und wie gut der Opcode-Cache tatsächlich arbeitet. Die obere “Total” Zeile zeigt an wie viele der Requests aus dem Cache (hits) ausgeliefert werden konnten und wie viele nicht (misses). Ausserdem kann man sehen wie viel der zur Verfügung stehen Speichers aktuell benutzt wird. Sollte der Wert der Misses im Verhältnis zu den Hits sehr hoch sein, ist es ggf. sinnvoll XCache etwas mehr Speicher zu Verfügung zu stellen.

Requests begrenzen – mod_evasive und mod_status

Über Sinn oder Unsinn von Modulen wie mod_evasive kann man sich selbstverständlich streiten und mir ist klar, dass keines dieser Module einem richtigen DDoS Angriff entgegenwirken kann, das liegt in der Natur der Sachen. Dennoch halte ich den Einsatz für sinnvoll, denn vielen “Script-Kiddy”-, Spam-, Brutforce- und sonstigen Attacken kann man damit einen Riegel vorschieben. Mod_evasive mach im Prinzip nichts weiter als die Requets pro IP auf den Webserver zu limitieren. Eine gute Übersicht über die Requests die Lighttp aktuell verabeitet liefert das Modul mod_status.

Lasttest
Nachdem man nun alle (oder einen Teil) dieser Optimierungen vorgenommen hat. Sollte man seinen Webserver mit einem simplen Lasttest durchführen um zu sehen ob der Webserver wirklich durchhält wenn er ein paar parallele Requests abzuarbeiten hat. Tools für diese Aufgabe sind zum Beispiel Apache Benchmark oder LoadUI. Am besten startet man mit einigen wenigen Anfragen pro Sekunde und schaut auf der Konsole des Server wie sich da auf die Last auswirkt. Da man bei solchen Lasttests in der Regel nur von einer IP aus testet kann man hier auch direkt prüfen ob mod_evasive korrekt funktioniert. Ist das der Falls sollte man die Anfragen pro Sekunde im Lasttest-Tools quasi beliebig nach oben schrauben können ohne das die Serverlast merklich steigt. Wie viele Requests/Sec ein Server verträgt hängt natürlich start von der Hardware und dem aufgerufenen Script ab.
Neben den Requests pro Sekunde sollte man auch noch darauf achten ob alle Anfragen nach einer bestimmten Zeit wieder geschlossen werden. Hierzu kann an einen Blick auf die mod_status Weboberfläche werden. Normalerweise sollten allen Verbindungen nach einer kurzen Zeit wieder geschlossen werden. Wenn Verbindungen für eine sehr lange Zeit offen bleiben oder gar nicht geschlossen werden, sollten die entsprechenden Parameter in der Konfiguration noch einmal überprüft werden.

Ich hoffe ich konnte in diesem kurzen Anriss zum Thema Webserver-Konfiguration auf die häufigsten Performance-Bremsen eingehen und ein paar nützliche Tipps geben. Anregungen natürlich wie immer hin den Kommentaren.

Im zweiten Teil der “Performance-Reihe” wird es dann um Datenbank-Abfragen gehen, bzw. darum wie man hier optimieren kann.

Vorher:

$iv = mcrypt_create_iv(mcrypt_enc_get_iv_size($td), MCRYPT_DEV_RANDOM);

Nacher:

$iv = mcrypt_create_iv(mcrypt_enc_get_iv_size($td), MCRYPT_DEV_URANDOM);

Um zu prüfen ob ein Feld in einem Array existiert ohne dabei Fehlermeldungen zu erzeugen muss vor beiden Funktionen isset und is_array aufgerufen werden.

Beispiel:

1
2
3
4

if(isset($foo) && is_array($foo) && isset($foo['bar']))
{
	$check = true;
}

1
2
3
4

if(isset($foo) && is_array($foo) && array_key_exists('bar', $foo))
{
	$check = true;
}

Der Grund hierfür ist nicht immer direkt ersichtlich, deswegen hier die Erklärung:
isset erzeugt zwar keine Notices oder Warnings falls die Variable $foo nicht gesetzt ist, aber es gibt ein anderes Problem. Wenn die Variable $foo vom Typ String ist würde die Prüfung auf ein Array-Feld mit isset true liefern.

Beispiel:

1
2

$foo = 'bar';
var_dump(isset($foo['bar'])); // true

Dieses Verhalten erklärt die Notwendigkeit von is_array vor dem Prüfen mit isset. Das isset vor dem is_array ist schließlich notwendig weil is_array eine Notice erzeugt wenn die zu prüfende Variable nicht gesetzt ist.

Die Funktion array_key_exists erzeugt ein Warning falls das zu prüfende Array nicht existiert oder die übergebene Variable nicht vom Typ Array ist. Somit ist hier ebenfalls die Nutzung von is_array in Kombination mit isset zu empfehlen.

Mit obiger Syntax lässt sich nun eigentlich in beide Fällen prüfen ob ein Feld im einem Array existiert. Dabei ist jedoch eine Ausnahme zu beachten, und zwar der Wert null in einem Array.

Beispiel:

1
2
3

$foo['bar'] = null;
var_dump(isset($foo['bar'])); // false
var_dump(array_key_exists('bar', $foo)); // true

Damit sollte die Verwendung der beiden Funktionen geklärt sein (falls nicht bitte ich um einen kurzen Kommentar), aber es bleibt die Frage: Welche der beiden Varianten ist schneller, isset oder array_key_exists?
Hier das Ergebnis:

Klare Sache: isset ist wesentlich schneller als array_key_exists, 10000 Prüfungen dauert nur etwa halb so lange.
Zudem fallen zwei weitere Dinge auf: isset taucht nicht in den Xdebug Ergebnissen auf. Die Begründung ist relativ simpel. Da isset keine Funktion ist sondern lediglich ein Sprachkonstrukt, taucht dieses nicht in den Xdebug-Listings auf. Weiterhin fällt auf, dass is_array fast genauso viel Zeit in Anspruch nimmt wie array_key_exists. Hierfür habe ich leider keine Erklärung, denn ich hätte erwarten dass array_key_exists im Gegensatz zu is_array eine Array-Funktion und damit wesentlich langsamer ist. Falls jemand eine Erklärung hat: Immer her damit!

1
2
3
4

if(stripos($haystack, $needle) !== false)
{
	$found = true;
}

1
2
3
4

if(preg_match('/'.$needle.'/is', $haystack) == 1)
{
	$found = true;
}

Hierbei wird eine Sache schnell klar: Bei mehr als einem Suchsting wird das ganze etwas komplizierter. Man muss die strpos Variante für jeden Suchstring einmal laufen lassen, bzw. in der zweiten Variante die Suchstrings mit einem oder verknüpfen.
Die Frage ist nun: Welche der beiden Varianten ist schneller?

Ich habe ein kurzes Testscript gebastelt, und hier ist das Ergebnis:

Die preg_match Varinate ist um einiges schneller. Ausserdem fällt auf das bei 10000 Durchläufen des Testscript die Funktion stripos öfter als 10000 mal ausgeführt wird. Die liegt daran, dass die Funktion so oft aufgerufen werden muss, bis der erste Suchstring gefunden wurde (oder eben keiner der gesuchten Strings im Text vorkommt). Durch die oder-Verknüpfung der einzelnen Strings muss preg_match bei jedem Durchlauf nur einmal ausgeführt werden.
Klar wird also: Je mehr Suchstrings in einem Text gesucht werden sollen, desto langsamer wird die strpos Variante im Vergleich zu preg_match, obwohl natürlich auch der reguläre Ausdruck bei einem längeren Suchstring etwas langsamer wird.

Zum Schluss noch das Script mit dem ich dieses Verhalten getestet habe:
performance_preg_vs_strpos.php

Testumgebung
Für den Test habe ich Projekt genutzt welches sich derzeit noch in der Entwicklung befindet.
Das Projekt liegt lokal auf einem Thinkpad T42 (1,7Ghz und 2GB Ram) in einer XAMPP-Umgebung mit XDEBUG.

Installation / Integration
Zunächst müssen die PHPIDS-Dateien (es reicht das Verzeichnis “lib/IDS”) auf den Server geladen werden. Das Verzeichnis “IDS/tmp” benötigt Schreibrechte falls man dort Log- oder Cache-Files ablegen möchte. Anschließend müssen in der Datei Config.ini (IDS/Config) ein paar Einstellungen angepasst werden. Die Datei ist selbsterklärend, ich habe jedoch nur die Pfade angepasst da ich für meinen Test auf Logging oder Caching in einer Datenbank verzichtet habe.

Die Integration von PHPIDS in ein bestehendes Projekt hängt natürlich sehr stark vom Projekt selbst ab. In meinem Testfall werden sämtliche Anfragen per mod_rewrite auf die Datei index.php umgeleitet. Dort wird unter anderem eine Klasse security instanziert welche verschiedene Methoden zur Input-Validierung enthält. Eine dieser Methoden (validate_request) wird bei jedem Aufruf des Projektes ausgeführt und ist somit der ideale Ansatzpunkt für PHPIDS.
Das ist der hier relevante Teil der security-Klasse:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

// include-path auf den Ordner mit IDS setzen:
ini_set('include_path', '/path/to/libs');
// IDS einbinden:
require_once 'IDS/Init.php';
// Array mit möglichen User-Inputs bilden:
$request = array(
	'REQUEST' => $GLOBALS['_REQUEST'],
	'GET' => $GLOBALS['_GET'],
	'POST' => $GLOBALS['_POST'],
	'COOKIE' => $GLOBALS['_COOKIE']
);
// IDS initialisieren:
$init = IDS_Init::init('/path/to/libs/IDS/Config/Config.ini');
// Caching ausschalten:
$init->config['Caching']['caching'] = 'none';
// Request-Array analysieren:
$ids = new IDS_Monitor($request, $init);
$result = $ids->run();
// Impact abfragen und ggf. reagieren:
if($result->getImpact() > 1)
{
	die('Hacking attempt detected. IP logged.');
}
// include-path auf seinen ursprünglichen Wert zurücksetzten:
ini_restore('include_path');

Was hier passiert ist schnell erklärt:
Es wird ein Array gebildet welches alle Variablen enthält die vom Benutzer beeinflusst werden können, etwa durch Formulareingaben oder Ähnliches. Der Inhalt dieses Arrays wird nun von PHPIDS auf mögliche Angriffsversuche untersucht. Mögliche Angriffe wären z.B. XSS oder SQL-Injection Attacken. Erkannte Angriffe werden von PHPIDS bewertet. Je “gefährlicher” oder “bedrohlicher” ein Angriff ist, desto höher ist der Impact-Wert. Im obigen Beispiel wird das Script sofort beendet sobald der Wert größer als 1 ist.

Performance
Aufgrund vieler regulärer Ausdrücke u.Ä. ist PHPIDS sicherlich nicht extrem Performant, aber es ist auch nicht extrem langsam. In meinen Test gab es nur einen Angriff der PHPIDS quasi in die Knie gezwungen hat. (Genaueres weiter unten) Ob man dieses Tool nun auf einer High-Performance Webseite einsetzen kann ist schwer zu sagen. Hier kommt es sicherlich auf die Server, das Caching und viele andere Dinge an.
Hier jedoch ein kurzer Vergleich der Methode validate_request mit und ohne PHPIDS (eingebunden wie oben beschrieben). Es handelt sich um einen einfachen Aufruf der Seite ohne dass irgendwelche Angriffe versucht werden.

Bei Standard-XSS-Angriffsversuchen wie man sie z.B. hier findet gehen die Zeiten leicht nach oben, bleiben aber immer im Rahmen. Hier das Ergebnis bei einem GET-Parameter mit folgendem Imhalt:

1

<img SRC="javascript:alert('XSS');">

Einen Fall konnte ich jedoch finden, bei dem PHPIDS stark einbricht. Es handelt sich um einen SQL-Injection Angriff der kürzlich verwendet wurde um Javascript auf vielen Webseiten einzuschleusen. (Artikel bei heise.de)
Wird der String aus diesem Angriff per GET-Parameter übergeben steigt die Prozessorlast extrem an und das Script braucht lange für die Ausführung. Verantwortlich dafür sind 164 Aufrufe der Funktion preg_match die extrem lange brauchen. In meinem Test waren es über 4000ms.

Fazit
PHPIDS ist ein sehr nützliches Hilfsmittel um viele Angriffe auf Webprojekte zu erkennen. Die Installation ist kinderleicht und auch bei der Integration in ein bestehendes Projekt sollte es keine größeren Probleme geben.
Auf zwei Dinge möchte ich jedoch Hinweisen:
1. PHPIDS ist ein System zur Erkennung von Angriffen, es ist nicht dazu da sie zu verhindern oder zu blockieren. Diese Aufgabe muss ein Entwickler selbst übernehmen.
2. PHPIDS verwendet teilweise viele reguläre Ausdrücke welche resourcenhungrig sind. Bei High-Traffic Projekten sollte man deshalb ein Auge auf die Serverlast haben und sich das PHPIDS-Caching genauer anschauen.