Yet another Web Blog

Da viele Webseiten auf per PHP generierten Sessiondateien basieren, die im in der php.ini angegebenen session.save_path abgespeichert werden, muss man sich Gedanken machen wie man diese wieder los werden möchte.

PHP erstellt Sessions, aber löscht diese nicht. Warum weiß niemand. Also muss ein Cronjob her der dies übernimmt:

# Öffnen der Zieldatei für unseren Cronjob
nano /etc/cron.d/php
# Einfügen einer Zeile dieser Art
09,39 *     * * *     root   for i in /home/www/*/phptmp; do find $i -type f -cmin +1440 -print0 | xargs -r -0 rm; done

Dieser Cronjob schaut in jedem Verzeichnis unter /home/www/ ob es in einem Unterverzeichnis einen Ordner namens “phptmp” gibt. Diesen verwende ich immer für die Sessions => php.ini session.save_path = /home/www/beispiel.de/phptmp

Dort werden alle Dateien die älter sind als 1440 Minuten = 1 Tag gesucht und anschließend gelöscht.

Wer dies nicht tut und gleichzeitig eine große Webapplikation im laufen hat, wird bald merken was es bedeutet dass die minimale Dateigröße in einem Linux Dateisysteme immer der bei der Partitionierung angegebenen Blockgröße entspricht (ext3 default = 1024 Byte).

Um den mod_security Engine dessen Installation ich hier beschrieben habe, für einen Vhost zu deaktivieren bzw. abzuschalten, legt man am besten eine .htaccess Datei im DocumentRoot des VirtualHosts mit feinem der folgenden Inhalte an:

mod_security (1) benutzt folgenden Befehl:

SecFilterEngine Off

Danach ist mod_security ab diesem Ordner aufwärts deaktiviert.

mod_security2 benutzt folgenden Befehl:

SecRuleEngine Off

// Nachtrag

Beide Varianten funktionieren auch direkt in der Apache Konfiguration und lassen sich auch im IfModule Syntax angeben:

Für mod_security Version 2:

<IfModule mod_security2.c>
SecRuleEngine Off
</IfModule>

Für mod_security Version 1:

<IfModule mod_security.c>
SecFilterEngine Off
</IfModule>

Um mod_security in der brandneuen Version 2.5 aus den Sources zu compilien, müssen zunächst diverse Libraries und Pakete nachinstalliert werden.

Nachfolgende Step-by-Step Anleitung geht von einem bereits installierten und funktionstüchtigen Apache2 Setup aus den Distributionspackages von Debian Etch aus.

1. Nachinstallieren der benötigten Pakete

apt-get update
apt-get install apache2.2-common flex libc6-dev gcc openssl libxml2 libxml2-dev lua5.1 \
libpcre3-dev libapr1 libapr1-dev libapreq2-dev aprsd libaprutil1 libaprutil1-dev g++ \
cpp cpp-4.1 libstdc++5 libstdc++6 libstdc++6-4.1-dev

2. Einbinden der von mod_security benötigten Apache2 Module

a2enmod unique_id
 
nano /etc/apache2/apache2.conf
 
Falls noch nicht vorhandenen folgende Zeile einfügen:
LoadFile /usr/lib/libxml2.so

Danach einmal den Webserver neustarten und wenn soweit alles geklappt hat, ist die Hälfte bereits geschafft.

3. Falls nicht schon vorhanden apxs (apxs2) installieren

Dieser Step kommt auf die Version eures Webservers an.

apache2 -V
 
Zeigt euch die Version an. Sollte dort stehen:
<strong>Server MPM:     Prefork</strong>
Dann mittels apt-get die richtige apxs Version installieren und mit Step 4 fortfahren:
apt-get install apache2-prefork-dev
 
Ansonsten solltet ihr das Debian threaded Modell haben:
apt-get install apache2-threaded-dev

4. Sources von mod_security 2.5 compilieren

cd /usr/src
wget http://www.modsecurity.org/download/modsecurity-apache_2.5.0.tar.gz
tar xfz modsecurity-apache_2.5.0.tar.gz
cd modsecurity-apache_2.5.0/apache2
./configure --with-apxs=/usr/bin/apxs2
make
make test

Sollte es zu Fehlern im unter Step-4 genannten Ablauf kommen, liegt dies vermutlich an fehlenden Libraries. Ihr seid gerne eingeladen mich zu kontaktieren

5. Installation von mod_security

make install
mv ../rules /etc/apache2/modsecurity
##
mkdir /etc/apache2/logs
oder den Pfad zur Logdatei anpassen in der Datei /etc/apache2/modsecurity/modsecurity_crs_10_config.conf
##
 
Einfügen von mod_security in die Datei /etc/apache2/apache2.conf:
 
LoadModule security2_module /usr/lib/apache2/modules/mod_security2.so
Include /etc/apache2/modsecurity/*.conf

6. Starten des Apachen mit mod_security

/etc/init.d/apache2 restart

Wenn nun der Apache2 startet hat alles geklappt und euer Webserver ist gegen Angriffe über PHP etc. schon ein ganzes Stück weiter geschützt.

Es ist jedem angeraten sowohl die Rules unter /etc/apache2/modsecurity anzuschauen als auch die Apache2 error_log oft zu kontrollieren, da hier alle abgewiesenen Zugriffe protokolliert werden.

Da es zu False Positive kommen wird, ist dies also vor allem in der Anfangszeit sehr wichtig.
Natürlich können die .conf Dateien unter /etc/apache2/modsecurity mittels einem Editor geprüft und editiert werden, sodass Regeln sehr einfach zu deaktivieren sind.

Ebenso das einfügen von Costum Rules z.B. dem Rulekit von Got Root?

Wie man solche Regeln erstellt und z.B. aus anderen Quellen wie Snort einbinden kann, werde ich in einem anderen Blogeintrag dokumentieren.