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 Codebasis der Bibliothek dient als Schnittstelle zu ModSecurity-Connectors, die Web-Traffic entgegennehmen und die traditionelle ModSecurity-Verarbeitung anwenden. Im Allgemeinen bietet sie die Möglichkeit, Regeln im ModSecurity-SecRules-Format zu laden und zu interpretieren und sie auf HTTP-Inhalte anzuwenden, die von Ihrer Anwendung über Connectors bereitgestellt werden.
Wenn Sie ModSecurity für Apache suchen (auch bekannt als ModSecurity v2.x), wird es weiterhin gepflegt und ist verfügbar: hier.
Libmodsecurity ist eine vollständige Neuimplementierung der ModSecurity-Plattform. Als das ModSecurity-Projekt ursprünglich konzipiert wurde, begann es als reines Apache-Modul. Im Laufe der Zeit wurde das Projekt aufgrund der großen Nachfrage erweitert, um andere 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 Apache-Abhängigkeiten, auf denen dieses Projekt basiert, zu entfernen und es dadurch plattformunabhängiger zu machen.
Als Ergebnis dieses Ziels haben wir Libmodsecurity so neu architektiert, dass es nicht mehr vom Apache-Webserver abhängig ist (weder bei der Kompilierung noch zur Laufzeit). Ein Nebeneffekt davon ist, dass Benutzer auf allen Plattformen eine erhöhte Leistung erwarten können. Darüber hinaus haben wir diese Gelegenheit genutzt, um die Grundlage für einige neue Funktionen zu schaffen, die Benutzer schon lange gefordert haben. Beispielsweise streben wir die native Unterstützung von Auditlogs im JSON-Format an, zusammen mit einer Reihe weiterer Funktionalitäten in zukünftigen Versionen.
Der Branch 'ModSecurity' enthält nicht mehr die traditionelle Modullogik (für Nginx, Apache und IIS), die üblicherweise alles zusammen gepackt wurde. Stattdessen enthält dieser Branch nur den Bibliotheksteil (libmodsecurity) für dieses Projekt. Diese Bibliothek wird von dem konsumiert, was wir 'Connectors' nennen; diese Connectors kommunizieren mit Ihrem Webserver und stellen der Bibliothek ein gemeinsames Format bereit, das sie versteht. Jeder dieser Connectors wird als separates GitHub-Projekt gepflegt. Beispielsweise wird der Nginx-Connector vom ModSecurity-nginx-Projekt bereitgestellt (https://github.com/owasp-modsecurity/ModSecurity-nginx).
Die Trennung dieser Connectors ermöglicht es jedem Projekt, unterschiedliche Release-Zyklen, Issues und Entwicklungszweige zu haben. Darüber hinaus bedeutet es, dass Sie bei der Installation von ModSecurity v3 nur genau das erhalten, was Sie benötigen, ohne Extras, die Sie nicht verwenden werden.
Bevor Sie mit dem Kompilierungsprozess beginnen, stellen Sie sicher, dass alle erforderlichen Abhängigkeiten installiert sind.
Weitere Informationen finden Sie in den Abschnitten Abhängigkeiten und Git-Submodule.
Stellen Sie nach der Kompilierung sicher, dass in Ihrem Build/Ihrer Plattform keine Probleme auftreten.
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. Stellen Sie nach dem Klonen sicher, dass alle Submodule initialisiert und abgerufen werden:
git submodule update --init --recursive
Sie können überprüfen, ob alle Submodule ordnungsgemäß initialisiert wurden, mit:
git submodule status
Korrekt initialisierte Submodule zeigen einen Commit-Hash an.
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 sich in unserem Wiki: Compilation Recipes
Informationen zum Windows-Build finden sich hier.
Regex (src/utils/regex.*) implementiert.@rx, @rxGlobal und @verifyCC genutzt.