Erste Schritte mit der Einbruchserkennung PHPIDS

Das PHP-basierende, quelloffene PHPIDS erkennt Einbruchsversuche auf Web-Anwendungen und schlägt bei Gefahr Alarm. heise Security gibt praktische Tipps zur Installation.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 9 Min.
Von
  • Daniel Bachfeld
Inhaltsverzeichnis

Das in c't 10/09 vorgestellte PHPIDS soll auf PHP beruhende Anwendungen vor Cross-Site-Scripting-, SQL-Injection und anderen Angriffe schützen. Im einfachsten Einsatzszenario protokolliert man zunächst alle Angriffe mit, um einen Eindruck zu bekommen, ob die eigene Site überhaupt im Brennpunkt steht und weitere Schutzmaßnahmen notwendig sind. Die Installation und Konfiguration von PHPIDS ist in der Regel mit wenigen Handgriffen erledigt. Wir zeigen für erste Tests exemplarisch anhand einiger populärer Content-Management-Systeme und Blogs, wie man dabei vorgeht. Weitere Grundlagen zur Funktion und Hinweise zur Anpassung finden sich im c't-Artikel "Alarmanlage - Angriffe auf Webanwendungen mit PHPIDS erkennen" in c't 10/09 ab Seite 164.

Im Wesentlichen besteht die Installation und Konfiguration des IDS aus drei Schritten: den phpids-Tarball entpacken, die Pfade anpassen und das IDS in die vorhandene PHP-Anwendung einbinden. Insbesondere die Integration in die Anwendung unterscheidet sich von Produkt zu Produkt erheblich. Für das CMS Drupal steht jedoch ein angepasstes PHPIDS-Modul bereit, das zumindest die manuelle Einbindung sehr leicht macht.

Für die Praxisbeispiele haben wir der PHPIDS-Version 0.5.4 unter Ubuntu 8.10 mit Apache2 verwendet, wobei die jeweilige PHP-Anwendung unter /var/www/Name_der_Anwendung installiert war.

Zunächst entpackt man den phpids-Tarball, benennt das Verzeichnis php-0.5.4 in phpids um und verschiebt den Ordner in das Verzeichnis der Webanwendung. Wichtig ist noch, dem IDS respektive dem Webserver Schreibrechte für den Ordner phpids/lib/IDS/tmp zu gewähren, damit dieser dort die Filterregeln temporär ablegen und Attacken in der Log-Datei phpids_log.txt ablegen kann. Dazu ändert man am besten den Besitzer des Ordners via:

sudo chown www-data:www-data tmp

Für erste Tests eignet sich die Beispieldatei example.php im Unterverzeichnis docs/examples, die sich leicht anpassen lässt. Dazu entfernt man allen unnötigen Ballast und passt die dort angebenen Pfade so an, sodass nur folgendes übrig bleibt:

<?php

set_include_path(
get_include_path()
. PATH_SEPARATOR
. '/var/www/Name_der_Anwendung/phpids/lib/'
);

if (!session_id()) {
session_start();
}
require_once 'IDS/Init.php';
try {
$request = array(
'REQUEST' => $_REQUEST,
'GET' => $_GET,
'POST' => $_POST,
'COOKIE' => $_COOKIE
);
$init = IDS_Init::init(dirname(__FILE__) .
'/phpids/lib/IDS/Config/Config.ini');
$init->config['General']['base_path'] = dirname(__FILE__) .
'/phpids/lib/IDS/';
$init->config['General']['use_base_path'] = true;
$init->config['Caching']['caching'] = 'none';
$ids = new IDS_Monitor($request, $init);
$result = $ids->run();
if (!$result->isEmpty()) {
require_once 'IDS/Log/File.php';
require_once 'IDS/Log/Composite.php';
$compositeLog = new IDS_Log_Composite();
$compositeLog->addLogger(IDS_Log_File::getInstance($init));
$compositeLog->execute($result);
} else {
}
} catch (Exception $e) {
printf(
'An error occured: %s',
$e->getMessage()
);
}

Einige Admins stoßen sich vor allem bei sicherheitsrelevanten Anwendungen daran, dass alle Dateien über das Wurzelverzeichnis des Webservers erreichbar sind und Angreifer so Potenzial zum Rumspielen haben. PHPIDS lässt sich alternativ auch außerhalb des Webverzeichnisses installieren und betreiben. Dazu verlegt man den PHPIDS-Ordner beispielsweise nach /var/lib und kopiert die Datei example.php nach /var/lib/phpids. Der Eintrag

include ('/var/lib/phpids/example.php');

in der index.php der jeweiligen PHP-Anwendung bindet das IDS ein.

Darüber hinaus sind in example.php die Zeilen:

     . PATH_SEPARATOR
. '/var/lib/phpids/lib/'
...
$init = IDS_Init::init(dirname(__FILE__) . '/lib/IDS/Config/Config.ini');

...
$init->config['General']['base_path'] = dirname(__FILE__) . '/lib/IDS/';

anzupassen. Die Logdatei findet sich bei dieser Konfiguration in /var/lib/phpids/lib/IDS/tmp. Auch hier muss man dem Webserver via chown Schreibrechte einräumen.

Sofern auf dem System die PHP-Option open_basedir zur Beschränkung der möglichen Pfade für Zugriffe auf das Dateisystem bereits gesetzt ist, muss man den neuen Pfad (/var/lib/phpids) durch einen Doppelpunkt getrennt vom vorhandenen hinzufügen.

Die im folgenden aufgeführten Beispiele beziehen sich jedoch auf eine Installation von PHPIDS im Order der Webanwendung.

Die Datei example.php legt man im Wordpress-Verzeichnis ab und bindet sie in index.php hinter der Zeile

require('./wp-blog-header.php');

mit

include 'example.php';

ein.

Nun sollte ein Aufruf von http://localhost/wordpress im Browser die Startseite von Wordpress zutage fördern. Allerdings produzierte Wordpress in dieser Standardkonfiguration in unseren Tests bei jedem Aufruf einen Eintrag in der IDS-Logdatei – auch wenn es sich definitiv nicht einen Angriff handelte. Durch das Auskommentieren der Variable REQUEST und COOKIE im oben aufgeführten Request-Array traten diese False-Positives nicht mehr auf. Alternativ lassen sich auch Exception-Variablen definieren, mehr dazu im oben erwähnten c't-Artikel.

Hängt man für einen ersten Test der IDS-Funktion als simulierten SQL-Injection-Angriff ein

?test='%20OR%201=1--

an die URL seines Blogs an, so erscheint in der IDS-Datei ein dazugehöriger Eintrag mit einem Impact von 22. Ein typischerweise bei Cross-Site-Scripting-Tests eingesetzter Parameter wie

?test=">XXX

erzeugt einen Eintrag mit einem Impact 4.

Durch das Definieren eigener Aktionen im Rahmen von PHPIDS lässt sich ein Angriff so nicht nur erkennen, sondern auch abwehren, indem man etwa die IP-Adresse sperrt. Beispiele für weitere Aktionen finden sich in der Originaldatei von example.php im doc-Verzeichnis. Alternativ lassen sich Aktionen auch durch eigene Tools realisieren, die kontinuierlich die IDS-Logdatei auswerten.