Sergey Nivens - Fotolia
Open-Source-WAF: Mit ModSecurity Webanwendungen schützen
ModSecurity ist eine quelloffene, plattformübergreifende Web Application Firewall Engine für Apache, IIS und Nginx. Wir zeigen, wie Sie Apache-Webserver damit absichern können.
ModSecurity ist ein Open-Source-WAF-Modul, das ursprünglich von Trustwave SpiderLabs entwickelt wurde und seit Februar 2024 von verschiedenen Organisationen weitergeführt wird, vor allem durch OWASP.
Die Web Application Firewall (WAF) dient hauptsächlich dem Schutz von Webanwendungen vor Angriffen durch die Erkennung und Blockierung potenziell schädlicher HTTP-Anfragen. ModSecurity bietet Funktionen wie Echtzeit-Überwachung, Logging und eine Vielzahl von Regeln zur Angriffserkennung, die kontinuierlich aktualisiert werden.
Die Webanwendungs-Firewall unterstützt verschiedene Plattformen und Webserver, einschließlich Apache, Nginx und IIS. Ein besonders bemerkenswertes Merkmal von ModSecurity ist die Fähigkeit zur Erkennung und Abwehr von SQL-Injections, Cross-Site Scripting (XSS) und weiteren häufigen Webangriffen. Dank der umfassenden und anpassbaren Regelsets, die auch das OWASP ModSecurity Core Rule Set (CRS) umfassen, bietet ModSecurity eine flexible und leistungsfähige Lösung für die Websicherheit.
ModSecurity auf Ubuntu installieren und Apache absichern
Um ModSecurity auf Ubuntu zu installieren, erfolgt die Aktualisierung der Paketquellen und danach die Installation der ModSecurity-Dateien:
sudo apt update && sudo apt upgrade
sudo apt install libapache2-mod-security2
Falls Apache noch nicht vorhanden sein, dann sollte der Webserver zuerst installiert und aktiviert werden. Das erfolgt mit:
sudo apt install apache2
sudo systemctl enable apache2
sudo systemctl start apache2
Nach der Eingabe der IP-Adresse des Servers in der Adressleiste des Browsers öffnet sich die Webseite von Apache. Üblicherweise erreichen sie die Webseite über den Aufruf von 127.0.0.1 oder localhost.
Damit ModSecurity funktioniert, muss noch die Konfigurationsdatei der Lösung aktiviert werden:
sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf
Im Anschluss erfolgt die Aktivierung des Moduls, inklusive eines Neustarts des Webservers, in diesem Beispiel von Apache:
sudo a2enmod security2
sudo systemctl restart apache2
Die Verwaltung von ModSecurity erfolgt über die Konfigurationsdatei modsecurity.conf. Die Bearbeitung kann zum Beispiel mit nano erfolgen:
sudo nano /etc/modsecurity/modsecurity.conf
Für die Aktivierung der WAF wird der Wert bei SecRuleEngine auf On gesetzt. Standardmäßig ist hier DetectionOnly aktiv. Bei diesem Wert prüft ModSecurity zwar nach Angriffen, führt aber keinerlei Aktionen aus. Erst mit On schützt die WAF den Webserver. Als Nächstes sollte der Wert bei SecAuditLogParts auf ABCEFHJKZ gesetzt werden. Hier steht oft ABDEFHIJZ. Dieser Wert ist aber nicht richtig für den Einsatz von ModSecurity mit Apache. Danach wird die Datei gespeichert und geschlossen.
Wichtig ist nun noch, die Datei /etc/apache2/mods-enabled/security2.conf zu überprüfen, zum Beispiel mit Nano:
sudo nano /etc/apache2/mods-enabled/security2.conf
Hier sollte die Zeile IncludeOptional /etc/modsecurity/*.conf zu finden sein. Das heißt, dass Apache alle *.conf-Dateien im Verzeichnis "/etc/modsecurity" ausführt.
Nach diesen Änderungen ist ein Neustart von Apache 2 notwendig:
sudo systemctl restart apache2
OWASP Core Rule Set ist die Basis für den Schutz von Apache mit ModSecurity
Sobald ModSecurity aktiv ist, sollte das OWASP Core Rule Set (CRS) installiert werden. Hier sind die notwendigen Regeln enthalten, mit denen die WAF den Webserver schützt. Das Standard-Regelwerk ist kostenlos und wird von der Community gepflegt und erweitert. Natürlich kann man jederzeit weitere Regelsätze integrieren, aber der Start mit OWASP CRS ist sicherlich ein optimaler Einstieg. CRS enthält Regeln, um häufige Angriffsvektoren zu stoppen, einschließlich SQL-Injection (SQLi), Cross-Site-Scripting (XSS), Bots, Scanner und viele andere. Die Installation erfolgt mit:
sudo apt install modsecurity-crs
Die Installation ist auch manuell möglich. Dazu laden Sie das aktuelle Archiv herunter. Danach erstellen Sie einen Symlink zur Aktivierung von CRS:
sudo ln -s /usr/share/modsecurity-crs /usr/share/modsecurity-crs/activated_rules
In produktiven Umgebungen sollten Sie immer den jeweils aktuelle Regelsatz verwenden. Die jeweils aktuelle Version ist auf der oben angegebenen GitHub-Seite des Projektes zu finden. Für die Integration wechseln Sie in das Verzeichnis /etc/apache2 und erstellen das neue Verzeichnis modsecurity-crs. In dieses Verzeichnis laden Sie den aktuellen Regelsatz herunter und extrahieren das Archiv:
cd /etc/apache2
sudo mkdir modsecurity-crs
cd modsecurity-crs
wget https://github.com/coreruleset/coreruleset/archive/v4.4.0.tar.gz
tar xvf v4.4.0.tar.gz
Danach befindet sich im Verzeichnis das Unterverzeichnis mit dem Regelsatz. Darin ist auch die Beispiel-Konfigurationsdatei für die enthaltenen Regeln. Diese lässt sich mit dem folgenden Befehl durch Umbenennung aktivieren:
sudo mv crs-setup.conf.example crs-setup.conf
Innerhalb des CRS-Verzeichnisses befindet sich das Verzeichnis rules. In diesem sind wiederum die verschiedenen Regeln zu finden. Diese Dateien lassen sich jetzt in Apache integrieren, um den Webserver zu schützen:
sudo nano /etc/apache2/mods-enabled/security2.conf
In der Datei ist die Zeile zu finden, in welcher die Regeln von CRS in Apache geladen werden:
IncludeOptional /usr/share/modsecurity-crs/*.load
Um jeweils die aktuellen Regeln zu laden, wird die Datei um folgende Zeilen erweitert. Bei der Version müssen Sie natürlich darauf achten, die heruntergeladene Version der Regeln zu verwenden:
IncludeOptional /etc/apache2/modsecurity-crs/coreruleset-4.4.0/crs-setup.conf
IncludeOptional /etc/apache2/modsecurity-crs/coreruleset-4.4.0/rules/*.conf
Nach der Änderung erfolgt die Speicherung der Datei. Die Konfiguration lässt sich danach mit dem folgenden Befehl testen. Es sollte dabei kein Fehler erscheinen:
sudo apachectl configtest
Hier sollte die Meldung Syntax OK im unteren Bereich erscheinen. Es kann immer mal wieder passieren, dass eine der Regeln nicht kompatibel ist. Der einfachste Weg dies zu beheben ist das Löschen der entsprechenden Regeldatei. Danach starten Sie Apache wieder mit dem folgenden Befehl neu:
sudo systemctl restart apache2
Nach der Aktivierung schützt ModSecurity den Server bereits. Die Aktionen sind in einer eigenen Protokolldatei zu finden. Durch eine Überprüfung der Datei lassen sich die Angriffe und False Positives erkennen. Das geht zum Beispiel mit:
sudo tail -f /var/log/apache2/modsec_audit.log
So funktioniert OWASP CRS: Optimierung der Umgebung
Um die Konfiguration von ModSecurity zu optimieren, sollte man sich die Konfigurationsdateien für die Regelsätze näher anschauen, zum Beispiel die Konfigurationsdatei von OWASP CRS. Diese befindet sich im Verzeichnis /etc/apache2/modsecurity-crs im jeweiligen Verzeichnis der Version für die eingesetzten Regeln.
Generell arbeitet CRS in zwei verschiedenen Modi. Im self-contained mode blockiert ModSecurity HTTP-Anfragen sofort wenn eine Regel zutrifft und beendet die weitere Evaluierung verbleibender Regeln. Dieser Modus war typisch für CRS v2.x. Im Gegensatz dazu prüft der anomaly scoring mode, der in CRS v3.x der Standardmodus ist, jede HTTP-Anfrage gegen alle Regeln und vergibt für jede Übereinstimmung eine Punktzahl. Wird ein bestimmter Schwellenwert erreicht, gilt die Anfrage als Angriff und wird blockiert. Der Standardwert für eingehende Anfragen liegt bei 5 Punkten, während für ausgehende Antworten ein Schwellenwert von 4 Punkten gilt.
Im Modus anomaly scoring mode lassen sich vier Stufen des Paranoia Levels definieren. Je höher die Stufe, um so restriktiver filtert ModSecurity die Zugriffe auf den Server. Das erhöht aber auch die Gefahr von fehlerhaften Erkennungen (False Positives). Die jeweiligen Aktionen sind in der oben verlinkten Protokolldatei zu finden. Zur Konfiguration des Paranoia Levels und des anomaly scoring modes für das OWASP Core Rule Set (CRS) in der aktuellen Version mit Apache, müssen Sie Anpassungen in der ModSecurity-Konfigurationsdatei vornehmen. Um den Paranoia Level zu konfigurieren, wird die SecAction verwendet, wobei der Wert tx.paranoia_level auf 1 bis 4 gesetzt werden kann. Für die Konfiguration des anomaly scoring modes wird die Überprüfung jeder Anfrage gegen alle Regeln aktiviert und für jede Übereinstimmung eine Punktzahl vergeben. Dies geschieht durch Setzen der SecDefaultAction auf phase:2,log,auditlog,pass und durch Definition von Schwellenwerten für eingehende und ausgehende Anfragen mittels SecAction mit den Werten tx.inbound_anomaly_score_threshold und tx.outbound_anomaly_score_threshold. Standardmäßig sind diese Schwellenwerte auf 5 Punkte für eingehende Anfragen und 4 Punkte für ausgehende Antworten eingestellt. Durch diese Konfiguration werden Anfragen, die die definierten Schwellenwerte überschreiten, als Angriffe erkannt und blockiert. Die einzelnen Schritte sind ausführlich in der Konfigurationsdatei bei den einzelnen Optionen zu finden.
