owasp-modsecurity/modsecurity
ModSecurity ist eine quelloffene, plattformübergreifende Web Application Firewall (WAF)-Engine für Apache, IIS und Nginx. Sie verfügt über eine robuste ereignisbasierte Programmiersprache, die Schutz vor einer Reihe von Angriffen auf Webanwendungen bietet und die Überwachung, Protokollierung und Echtzeitanalyse von HTTP-Datenverkehr ermöglicht.
Libmodsecurity ist eine Komponente des ModSecurity-v3-Projekts. Die Bibliothekscodebasis dient als Schnittstelle zu ModSecurity-Connectors, die Webverkehr entgegennehmen und die traditionelle ModSecurity-Verarbeitung anwenden. Im Allgemeinen bietet sie die Möglichkeit, Regeln zu laden/zu interpretieren, die im ModSecurity-SecRules-Format geschrieben sind, und sie auf HTTP-Inhalte anzuwenden, die Ihre Anwendung über Connectors bereitstellt.
Wenn Sie nach ModSecurity für Apache (auch bekannt als ModSecurity v2.x) suchen, wird dieses weiterhin gewartet und ist verfügbar: hier.
Libmodsecurity ist eine vollständige Neuimplementierung der ModSecurity-Plattform. Als das Projekt ursprünglich konzipiert wurde, startete ModSecurity lediglich als Apache-Modul. Im Laufe der Zeit wurde das Projekt aufgrund großer Nachfrage erweitert, um weitere Plattformen zu unterstützen, darunter (aber nicht beschränkt auf) Nginx und IIS. Um der wachsenden Nachfrage nach zusätzlicher Plattformunterstützung gerecht zu werden, wurde es notwendig, die diesem Projekt zugrunde liegenden Apache-Abhängigkeiten zu entfernen und es damit unabhängiger von der Plattform zu machen.
Als Ergebnis dieses Ziels haben wir Libmodsecurity neu architekturiert, sodass es nicht länger vom Apache-Webserver abhängig ist (sowohl bei der Kompilierung als auch zur Laufzeit). Ein Nebeneffekt davon ist, dass Benutzer auf allen Plattformen eine höhere Leistung erwarten können. Darüber hinaus haben wir diese Gelegenheit genutzt, um die Grundlagen für einige neue Funktionen zu schaffen, nach denen Benutzer seit langem suchen. Beispielsweise beabsichtigen wir, Auditlogs nativ im JSON-Format zu unterstützen, zusammen mit einer Reihe weiterer Funktionen in zukünftigen Versionen.
Der ModSecurity-Zweig enthält nicht länger die traditionelle Modullogik (für Nginx, Apache und IIS), die üblicherweise alles zusammen verpackt wurde. Stattdessen enthält dieser Zweig nur den Bibliotheksteil (libmodsecurity) dieses Projekts. Diese Bibliothek wird von sogenannten „Connectors“ konsumiert. Diese Connectors stellen die Schnittstelle zu Ihrem Webserver her und versorgen die Bibliothek mit einem gemeinsamen Format, das sie versteht. Jeder dieser Connectors wird als separates GitHub-Projekt gepflegt. Beispielsweise wird der Nginx-Connector vom Projekt ModSecurity-nginx bereitgestellt (https://github.com/owasp-modsecurity/ModSecurity-nginx).
Durch die getrennte Pflege dieser Connectors kann jedes Projekt eigene Release-Zyklen, Issues und Entwicklungszweige haben. Darüber hinaus bedeutet dies, dass Sie bei der Installation von ModSecurity v3 genau das erhalten, was Sie benötigen, ohne Extras, die Sie nicht nutzen werden.
Bevor Sie mit dem Kompilierungsprozess beginnen, stellen Sie sicher, dass alle erforderlichen Abhängigkeiten installiert sind.
Weitere Informationen finden Sie im Abschnitt Abhängigkeiten und Git-Submodule.
Stellen Sie nach der Kompilierung sicher, dass es keine Probleme mit Ihrem Build bzw. Ihrer Plattform gibt.
Wir empfehlen dringend, die Unit-Tests und Regressionstests auszuführen. Diese Testprogramme befinden sich im Unterordner tests/.
Als dynamische Bibliothek muss libmodsecurity an einem Ort installiert werden, an dem Ihr Betriebssystem dynamische Bibliotheken finden kann.
Auf Unix-ähnlichen Systemen verwendet das Projekt autotools für den Kompilierungsprozess.
Wenn Sie mit einem Git-Checkout arbeiten, stellen Sie sicher, dass Sie das Repository rekursiv klonen oder alle Submodule vor dem Build initialisieren.
Siehe auch den Abschnitt Git-Submodule.
git clone https://github.com/owasp-modsecurity/ModSecurity ModSecurity
cd ModSecurity
Dieses Repository verwendet Git-Submodule. Nach dem Klonen stellen Sie sicher, dass alle Submodule initialisiert und abgerufen werden:
git submodule update --init --recursive
Sie können überprüfen, ob alle Submodule ordnungsgemäß initialisiert sind, mit:
git submodule status
Korrekt initialisierte Submodule zeigen einen Commit-Hash.
Ein führendes - zeigt an, dass das Submodul nicht initialisiert wurde.
Anschließend können Sie den Build-Prozess starten:
./build.sh
./configure
make
sudo make install
Details zu distributionsspezifischen Builds finden Sie in unserem Wiki: Kompilierungsrezepte
Windows-Build-Informationen finden Sie hier.
Die Verarbeitung regulärer Ausdrücke in SecRules wird über das Dienstprogramm Regex (src/utils/regex.*) implementiert.
Standardmäßig verwendet ModSecurity PCRE2 für die Behandlung regulärer Ausdrücke.
Dies wird von Operatoren wie @rx, @rxGlobal und @verifyCC verwendet.
Verhalten zur Build-Zeit:
--with-pcre explizit angegeben wird (WITH_PCRE).Mit anderen Worten: Aktuelle Builds erwarten PCRE2, sofern nicht ausdrücklich anders konfiguriert.
Alle anderen Abhängigkeiten stehen im Zusammenhang mit Operatoren, die in SecRules oder Konfigurationsdirektiven angegeben sind, und sind für die Kompilierung möglicherweise nicht erforderlich.
libinjection wird für die Operatoren @detectXSS und @detectSQL benötigt.curl wird für die Direktive SecRemoteRules benötigt.Wenn diese Bibliotheken fehlen, wird ModSecurity ohne Unterstützung für die jeweiligen Operatoren bzw. Direktiven kompiliert.
Das Repository enthält die folgenden Submodule: