Apache2 absichern mit mod_security

In der heutigen Zeit tummeln sich immer mehr Gefahren im Netz. Die Zahl der Hackerangriffe steigt stetig, daher ist es um so wichtiger, geeignete Maßnahmen zu ergreifen, um dem entgegenzuwirken. Wer einen eigenen Webserver betreibt kommt nicht umher, sich um eine vernünftige Absicherung zu kümmern. Diese Absicherung fängt schon auf Betriebssystemebene an, auf der durch sinnvolle Iptables Filter nur gewollte Dienste erreichbar sind, oder via Geoblocking mittels z.B. xtables Addon böse Buben aus gewissen Teil der Welt ausgesperrt werden. Für monetär betriebene Webpräsenzen kann ein zusätzlicher Schutz mithilfe einer vorgeschalteten Firewall-Appliance und IDS/IPS nötig sein. Ein absolut wichtiger Faktor ist ebenfalls, immer schnell die aktuellen Updates einzuspielen. Wer privat unterwegs ist, der kann, wenn er Ubuntu im Einsatz hat, auf die Ubuntu Pro Variante zurückgreifen. Diese ist für bis zu 5 PCs kostenlos und erhöht die Sicherheit auf Betriebssystemebene nochmals. Wie da zu bewerkstelligen ist habe ich in einem vorherigen Artikel bereits erläutert.

In diese Artikel zeige ich euch, wie ihr auf einer vorhanden Apache2 Installation mod_security installiert und aktiviert.

Mod_security ist eine sog. Web Application Firewall, welche sich zwischen dem anfragenden Client und dem Webserver schaltet und den Traffic auf bekannte Muster und Kommandos scannt. Wird etwas verdächtiges erkannt, dann wird die Anfrage komplett geblockt und der Client erhält lediglich eine 403 Meldung „Permission denied“. Unter Ubuntu 22.04 ist mod_security bereits als Paket im Repository vorhanden. Erkennt mod_security

Auf meinem Testsystem ist es bereits installiert. Falls es bei euch noch fehlt, dann könnt ihr mit folgendem Befehl die Installation durchführen.

apt install libapache2-mod-security2

Apache2 listet alle Module unter /etc/apache2/mods-available/ auf

Das Modul muss noch aktiviert werden. Dies erreichen wir mit nachfolgendem Befehl

a2enmod security2

In dieser Grundkonfiguration ist aber noch kein Schutz vorhanden. Als erstes muss noch die Konfigurationsdatei erstellt werden. Dazu kopiert man „/etc/modsecurity/modsecurity.conf-recommended“ nach „/etc/modsecurity/modsecurity.conf“

In der Grundeinstellung werden Anfragen auch nicht geblockt, sondern nur geloggt. Dies reicht für einen wirksamen Schutz natürlich nicht aus. Um dies zu ändern gehen wir in der „/etc/modsecurity/modsecurity.conf“ zum Abschnitt „SecRuleEngine“ und stellen den Wert auf „On“

Danach muss der Apache noch neu gestartet werden

systemctl restart apache2

Um zu sehen, welche Anfragen geblockt werden, könnt ihr folgenden Befehl nutzen.

grep ModSecurity /var/log/apache2/error.log | grep "\[id" | sed -E -e 's#^.*\[id "([0-9]*).*hostname "([a-z0-9\-\_\.]*)"].*uri "(.*?)".*"#\1 \2 \3#' | cut -d\" -f1 | sort -n | uniq -c | sort -n

Auf meinem Produktivsystem sieht das Ergebnis z.B so aus:

In der ersten Spalte steht die Häufigkeit, also wie oft ein spezifisches Event getriggert wurde. Die 2. Spalte zeigt euch die eindeutige ID und dahinter steht, was den Eintrag verursacht hat.

Nun kommt es immer wieder vor, das mod_security Falscherkennungen durchführt, sog. false/positives,also Blockierung, die legitimen Traffic aussperren. Die kommt leider immer wieder vor, daher ist es wichtig, dies zu erkennen und einen Weg zu finden, damit umzugehen.

Sofern wir geblockten Inhalt einer spezifischen ID zuordnen können, ist es ohne weiteres möglich, diese ID für zukünftige Scans zu sperren. Auf meinem System kam es leider in der Grundkonfiguration vor, dass gewisse Dinge bzw. Anfragen über das Backend blockiert wurden und ich somit nicht in der Lage war, gewisse administrative Aufgaben durchzuführen.

In der Datei „/etc/modsecurity/crs/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf“ lassen sich Ausnahmen definieren. Folgender Eintrag führt z.B. dazu, dass innerhalb einer ganzen Webpräsenz mehrere IDs ausgeschlossen werden.

<LocationMatch '^/'>
SecRuleRemoveById 941100,941160,942350,949110,980130
</LocationMatch>

Es lässt sich auch eine einzige IP Adresse whitelisten.

SecRule REMOTE_ADDR "@ipMatch 10.0.0.8" \
     "id:1000,\
     phase:1,\
     pass,\
     nolog,\
     ctl:ruleEngine=Off"

Im obigen Beispiel werden Anfragen von 10.0.0.8 gar nicht geblockt. Dies kann in bestimmten Szenarien sinnvoll sein. Man sollte aber vorsichtig mit solchen weitreichende Ausnahmen sein und besser dediziert filtern.

Es existieren natürlich noch zahlreiche weitere Möglichkeiten, mod_security granularer anzupassen bzw. zu konfigurieren. Auf Github findet man weitere Infos.

Abschließend möchte ich euch noch dafür sensibilisieren, bei ungewöhnlichen Fehlern auf der Webseite, die ihr entweder selbst merkt, oder die durch Besucher gemeldet werden, auch an mod_security als Verursacher zu denken. Häufig vergisst man im Eifer des Gefechts, dass bei WordPress oder ähnlichem nicht nur das z.B. Plugin ein Problem verursacht, sondern mod_security der „Übeltäter“ sein könnte.

Nun viel Erfolg bei der Umsetzung!