Apache mod_security2 auf Debian Lenny / Squeeze installieren.
Dies ist eine angepasste Version des Howtos von ITWelt.org, angepasst auf die Installation via backports.debian.org und entfernte Fehler aus der Anleitung. Ich übernehme keine Garnatie für die Richtigkeit.
Herunterladen der benötigten Pakete
Lenny: mod_security ist seid einiger Zeit wieder Inhalt von backports.debian org, das einspielen ist also recht leicht via apt-get zu erledigen. Hierzu die sources.list erweitern um:
deb http://backports.debian.org/debian-backports lenny-backports main
Nach dem hinzufügen einmal
apt-get update
aufrufen
Installation der Pakete
Die backports sind per Default deaktiviert, deshalb mit den folgenden Befehlen unter Debian Lenny installieren:
apt-get -t lenny-backports install libapache-mod-security
Unter Debian 6 (Squeeze) brauchen wir die Backports nicht, hier einfach wie üblich installieren.
modsecurity-Verzeichnis im Apache-Pfad anlegen
mkdir /etc/apache2/modsecurity2
chmod 600 -R /etc/apache2/modsecurity2
Regeln Herunterladen und Entpacken
Kann im tmp Verzeichniss oder auch in einem gewünschten anderen ausgeführt werden, ich verwende meist /tmp.
cd /tmp
Diese Regeln kommen direkt von modsecurity.com, und verhindern schon die meisten üblichen Angriffe:
wget http://www.modsecurity.org/download/modsecurity-core-rules_2.5-1.6.1.tar.gz
nun können wir die heruntergeladenen Regeln entpacken und in das vorher angelegte Verzeichnis verschieben:
tar fvx modsecurity-core-rules_2.5-1.6.1.tar.gz
mv *.conf /etc/apache2/modsecurity2/
Apache den Ordner mit den Regeln bekannt machen
vi /etc/apache2/conf.d/mod-security2.conf
…und in dem conf File folgendes einfügen:
<IfModule mod_security2.c>
Include /etc/apache2/modsecurity2/*.conf
</IfModule>
Symlink zum Apache-Logfile erstellen
Damit wird das Apache Log-Verzeichnis an Debian angepasst. Somit werden die Logfiles dann unter /var/log/apache2/modsec_<Regel>.log abgelegt.
ln -s /var/log/apache2 /etc/apache2/logs
Testen ob das Modul geladen wurde
Wenn ihr euch auf eurem Webserver eine „phpinfo.php“-Datei anlegt könnt ihr sehen, ob das mod_security Modul korrekt geladen wurde. Und zwar unter dem Punkt „Loaded Modules“.
Die phpinfo.php (kann natürlich auch anders heißen) muss folgenden Inhalt haben:
‹?php phpinfo(); ?›
Nur mitloggen, später blockieren
Zuerst soll mal nichts blockiert, sondern nur geloggt werden:
vi /etc/apache2/modsecurity2/modsecurity_crs_10_config.conf
Diese Zeile folgendermaßen anpassen:
SecRuleEngine DetectionOnly
So werden alle potenziellen Gefahren und Warnungen zwar geloggt, aber noch nichts geblockt. Man sollte also das Modul erstmal eine Weile so laufen lassen, damit nicht zuviel geblockt wird, was evtl. garnicht erwünscht ist.
Jetzt muss natürlich der Apache neu geladen werden: /etc/init.d/apache2 reload
In der Datei /var/log/apache2/modsec_debug.log kann man nun nachsehen, was alles geblockt werden würde. Hier ein Beispiel:
[31/Jan/2010:12:15:23 +0100] [www.itwelt.org/sid#3f1b6d0][rid#1125ac1][/test/index.php][1] Access denied with code 501 (phase 2). Pattern match „(?:b(?:.(?:ht(?:access|passwd|group)|www_?acl)|global.asa|httpd.conf|boot.ini)b|/etc/)“ at ARGS:text. [file „/etc/apache2/modsecurity2/modsecurity_crs_40_generic_attacks.conf“] [line „114“] [id „950005“] [msg „Remote File Access Attempt“] [data „/etc/“] [severity „CRITICAL“] [tag „WEB_ATTACK/FILE_INJECTION“]
Jede dieser Regeln hat eine ID, in diesem Fall ist das z.B. die „950005“. So ist es möglich, später Ausnahmen für mod_security festzulegen.
Ausnahmen hinzufügen
Mit der oben ausgelesenen ID ist es nun möglich, Ausnahmen für bestimmte Seiten festzulegen. Am einfachsten ist es, ein neues Config-File mit einer Whitelist anzulegen:
vi /etc/apache2/modsecurity2/modsecurity_crs_99_whitelist.conf
<LocationMatch /test/index.php>
SecRuleRemoveById 950005
SecRuleRemoveById 950006
SecRuleRemoveById 950907
</LocationMatch>
Man kann die Ausnahmen alternativ auch in den <VirtualHost…>-Bereich der entsprechenden Apache Konfigurations-Datei eintragen. (/etc/apache2/sites-available/…). Die Syntax ist dann die gleiche wie im obigen Beispiel.
mod_security „scharf“ schalten
Um unser Modul nun einzuschalten, und auch potenzielle Angriffe zu blockieren, muss die Konfiguration entsprechend angepasst werden:
vi /etc/apache2/modsecurity2/modsecurity_crs_10_config.conf
Ändern der Einstellung auf:
SecRuleEngine On
kannst du auch bitte beschreiben wie man die core rules updatet?
Es soll ja ein ziemlich üblem bug geben namens Apache Killer.
kind regards
Also der Apache bei mir auf dem das installiert ist hat bisher noch keine Probleme gehabt. Man muss halt an einigen Stellen für Scripte Ausnahmen definieren, insbesonder wenn Scripte mit URLs hantieren oder ähnlichen was ähnlich einem Angriff auf den Server aussieht. Aber dazu gibts ja die logs.
Wenn man es bis hierher geschafft hat sollte auch das Updaten der core rules klar sein 😉
die whitelist erkennt er dann auto beim apache reload?
und muss der pfad angepasst werden bei -> ?
Ja der Pfad muss dann entsprechend dem Script angepasst werden, sieht man ja im LOG File sollten dazu Einträge drin sein.
bei LocationMatch meinte ich oO