So richten Sie ModSecurity mit Nginx unter Debian/Ubuntu ein

Dieses Tutorial zeigt Ihnen, wie Sie ModSecurity installieren und verwenden mit Nginx auf Debian/Ubuntu-Servern. ModSecurity ist die bekannteste Open-Source-Firewall für Webanwendungen (WAF) und bietet umfassenden Schutz für Ihre Webanwendungen (wie WordPress, Nextcloud, Ghost usw.) vor einer Vielzahl von Layer-7-Angriffen (HTTP), wie SQL-Injection, Cross-Site-Scripting und lokale Dateieinbindung.

Hinweis :Dieses Tutorial funktioniert auf allen aktuellen Debian- und Ubuntu-Versionen, einschließlich Debian 10, Ubuntu 18.04, Ubuntu 20.04 und Ubuntu 20.10.

Webanwendungen sind von Natur aus unsicher. Wenn Sie ein WordPress-Administrator sind, werden Sie wahrscheinlich von Zeit zu Zeit Nachrichten über Hacker hören, die Schwachstellen in WordPress-Plugins und -Designs ausnutzen. Es ist wichtig, dass Sie eine WAF auf Ihrem Webserver bereitstellen, insbesondere wenn Sie alte Anwendungen haben, die keine Updates erhalten. ModSecurity wurde ursprünglich 2002 von Ivan Ristić entwickelt und wird derzeit von Trustwave SpiderLabs verwaltet. Es ist die weltweit am weitesten verbreitete WAF, die von über einer Million Websites verwendet wird. cPanel, das am weitesten verbreitete Hosting-Control-Panel, enthält ModSecurity als WAF.

Sie haben vielleicht schon von anderen hostbasierten Firewalls wie iptables, UFW und Firewalld usw. gehört. Der Unterschied besteht darin, dass sie auf Layer 3 und 4 des OSI-Modells arbeiten und Aktionen basierend auf IP-Adresse und Portnummer ausführen. ModSecurity, oder Webanwendungs-Firewalls im Allgemeinen, ist darauf spezialisiert, sich auf HTTP-Verkehr (Schicht 7 des OSI-Modells) zu konzentrieren und Maßnahmen basierend auf dem Inhalt von HTTP-Anfragen und -Antworten zu ergreifen.

ModSecurity 3

ModSecurity wurde ursprünglich für den Apache-Webserver entwickelt. Es konnte mit Nginx vor Version 3.0 funktionieren, litt aber unter schlechter Leistung. ModSecurity 3.0 (auch bekannt als libmodsecurity ) wurde 2017 veröffentlicht. Es ist ein Meilenstein, insbesondere für Nginx-Benutzer, da es die erste Version ist, die nativ mit Nginx funktioniert. Der Vorbehalt von ModSecurity 3 ist, dass es noch nicht alle Funktionen wie in der vorherigen Version (2.9) hat, obwohl jede neue Version einige der fehlenden Funktionen hinzufügen wird.

Schritt 1:Installieren Sie die neueste Version von Nginx auf Debian/Ubuntu

ModSecurity lässt sich als dynamisches Modul in Nginx integrieren, wodurch Sie den Quellcode einzelner Module kompilieren können, ohne Nginx selbst zu kompilieren.

Die Nginx-Binärdatei muss mit --with-compat kompiliert werden -Argument, das dynamische Module mit Ihrer vorhandenen Nginx-Binärdatei binärkompatibel macht. Allerdings wird nicht jede Nginx-Binärdatei, die aus dem standardmäßigen Debian/Ubuntu-Repository geliefert wird, mit --with-compat kompiliert Streit. Zur Vereinfachung können wir die neueste Version von Nginx von der ondrej/nginx-mainline installieren PPA, das von einem Debian-Entwickler gepflegt wird.

Hinweis :Das nginx.org-Repository enthält auch die neueste Version von Nginx. Allerdings ist die ondrej/nginx-mainline PPA bietet zusätzliche dynamische Module, die Sie möglicherweise nützlich finden, wie z. B. das Brotli-Modul.

Ubuntu

Wenn Sie Ubuntu 16.04, 18.04, 20.04 oder 20.10 verwenden, führen Sie die folgenden Befehle aus, um die neueste Version von Nginx zu installieren.

sudo add-apt-repository ppa:ondrej/nginx-mainline -ysudo apt updatesudo apt install nginx-core nginx-common nginx nginx-full

Während des Installationsvorgangs kann es Ihnen mitteilen, dass der Paketverteiler eine aktualisierte Version der Hauptkonfigurationsdatei geliefert hat. Es wird empfohlen, n zu drücken um Ihre aktuelle Version zu behalten. Sie können den Unterschied später immer noch überprüfen.

Standardmäßig ist nur das Binär-Repository aktiviert. Wir müssen auch das Quellcode-Repository aktivieren, um den Nginx-Quellcode herunterzuladen. Bearbeiten Sie die Nginx-Mainline-Repository-Datei.

sudo nano /etc/apt/sources.list.d/ondrej-ubuntu-nginx-mainline-*.list

Suchen Sie die Zeile, die mit # deb-src beginnt .

# deb-src http://ppa.launchpad.net/ondrej/nginx-mainline/ubuntu/focal main

Entfernen Sie das # Zeichen, um dieses Quellcode-Repository zu aktivieren.

deb-src http://ppa.launchpad.net/ondrej/nginx-mainline/ubuntu/focal main

Speichern und schließen Sie die Datei. Aktualisieren Sie dann den Repository-Index.

sudo-apt-Update

Debian

Wenn Sie Debian 10 oder Debian 11 verwenden, führen Sie die folgenden Befehle aus, um die neueste Version von Nginx zu installieren.

curl -sSL https://packages.sury.org/nginx-mainline/README.txt | sudo bash -xsudo apt update sudo apt install nginx-core nginx-common nginx nginx-full

Während des Installationsvorgangs kann es Ihnen mitteilen, dass der Paketverteiler eine aktualisierte Version der Hauptkonfigurationsdatei geliefert hat. Es wird empfohlen, n zu drücken um Ihre aktuelle Version zu behalten. Sie können den Unterschied später immer noch überprüfen.

Standardmäßig ist nur das Binär-Repository aktiviert. Wir müssen auch das Quellcode-Repository aktivieren, um den Nginx-Quellcode herunterzuladen. Bearbeiten Sie die Nginx-Mainline-Repository-Datei.

sudo nano /etc/apt/sources.list.d/nginx-mainline.list

Sie sollten eine einzelne Zeile finden, die das binäre Nginx-Repository aktiviert. Fügen Sie die folgende Zeile hinzu, um das Nginx-Quellcode-Repository auf Debian 10 zu aktivieren.

deb-src https://packages.sury.org/nginx-mainline/ buster main

Wenn Sie Debian 11 verwenden, fügen Sie stattdessen die folgende Zeile hinzu.

deb-src https://packages.sury.org/nginx-mainline/ bullseye main

Speichern und schließen Sie die Datei. Aktualisieren Sie dann den Repository-Index.

sudo-apt-Update

Überprüfen der Nginx-Konfigurationsargumente

Überprüfen Sie nun die Konfigurationsargumente von Nginx mit dem folgenden Befehl:

sudo nginx -V

Alle Nginx-Binärdateien im PPA werden mit dem --with-compat kompiliert Argument.

Schritt 2:Nginx-Quellpaket herunterladen

Obwohl wir Nginx selbst nicht kompilieren müssen, benötigen wir das Nginx-Quellcodepaket, um das dynamische ModSecurity-Modul zu kompilieren. Führen Sie den folgenden Befehl aus, um ein nginx zu erstellen Verzeichnis unter /usr/local/src/ zum Speichern des Nginx-Quellcodepakets. Ersetzen Sie username mit Ihrem echten Benutzernamen.

sudo chown Benutzername:Benutzername /usr/local/src/ -R mkdir -p /usr/local/src/nginx

cd in das Nginx-Quellverzeichnis.

cd /usr/local/src/nginx/

Laden Sie das Nginx-Quellpaket mit den folgenden Befehlen herunter:

sudo apt install dpkg-devapt source nginx

Wenn Sie die folgende Warnmeldung sehen, können Sie sie ignorieren.

W:Der Download wird ohne Sandbox als Root ausgeführt, da auf die Datei „nginx_1.19.5.orig.tar.gz“ durch den Benutzer „_apt“ nicht zugegriffen werden konnte. - pkgAcquire::Run (13:Zugriff verweigert)

Sehen Sie sich die heruntergeladenen Quellcodedateien an.

ls

Beispielausgabe:

nginx-1.19.5nginx_1.19.5-3+ubuntu20.04.1+deb.sury.org+1.debian.tar.xznginx_1.19.5-3+ubuntu20.04.1+deb.sury.org+1.dscnginx_1.19.5 .orig.tar.gz

Stellen Sie sicher, dass die Quellcodeversion mit Ihrer Nginx-Binärversion übereinstimmt (sudo nginx -v ).

Schritt 3:Installieren Sie libmodsecurity3

libmodsecurrity ist die ModSecurity-Bibliothek, die tatsächlich die HTTP-Filterung für Ihre Webanwendungen durchführt. Unter Debian 10 und Ubuntu 20.04, 20.10 können Sie es mit sudo apt install libmodsecurity3 installieren , aber ich empfehle Ihnen, es aus den Quellen zu kompilieren.

Um libmodsecurity zu kompilieren , klonen Sie zuerst den Quellcode von Github.

sudo apt install gitgit clone --depth 1 -b v3/master --single-branch https://github.com/SpiderLabs/ModSecurity /usr/local/src/ModSecurity/cd /usr/local/src/ ModSecurity/

Build-Abhängigkeiten installieren.

sudo apt install gcc make build-essential autoconf automake libtool libcurl4-openssl-dev liblua5.3-dev libfuzzy-dev ssdeep gettext pkg-config libpcre3 libpcre3-dev libxml2 libxml2-dev libcurl4 libgeoip-dev libyajl-dev doxygen 

 Erforderliche Submodule installieren.
 
git submodule initgit submodule update
 

 Konfigurieren Sie die Build-Umgebung.
 
./build.sh ./configure
 

 Wenn Sie den folgenden Fehler sehen, können Sie ihn ignorieren.
 
fatal:Keine Namen gefunden, kann nichts beschreiben.
 

 Kompilieren Sie den Quellcode mit dem folgenden Befehl. Standardmäßig make verwendet nur einen CPU-Kern. Ich habe 4 CPU-Kerne auf meinem Server, also gebe ich 4 Jobs an (-j4 ) für make um den Kompilierungsprozess zu beschleunigen. Ändern Sie 4 auf Ihre eigene Anzahl von CPU-Kernen.
 
make -j4
 

 Nach dem make Befehl ohne Fehler beendet, installiere die Binärdatei.
 
sudo make install
 

 Es wird unter /usr/local/modsecurity/ installiert Verzeichnis.
 
Fehlerbehebung bei Kompilierungsfehlern
 
Fehler Nr. 1
 

 Wenn Sie beim Ausführen von make den folgenden Fehler sehen Befehl, liegt es wahrscheinlich daran, dass Ihr Server keinen RAM mehr hat.
 
g++:interner Compiler-Fehler:Killed (Programm cc1plus)
 

 Die folgenden Zeilen in /var/log/syslog Datei zeigt an, dass dem Server nicht genügend Arbeitsspeicher zur Verfügung steht, erwägen Sie daher ein Upgrade der Serverspezifikationen.
 

 
 

 Alternativ können Sie Auslagerungsspeicher erstellen, um Probleme mit unzureichendem Arbeitsspeicher zu lösen. Es sollte jedoch nur als vorübergehende Maßnahme verwendet werden. Die Verwendung von Auslagerungsspeicher auf SSD-Servern kann sich nachteilig auf die Systemleistung auswirken.
 
Fehler Nr. 2
 

 Wenn Sie beim Kompilieren von ModSecurity den folgenden Fehler sehen,
 
utils/geo_lookup.cc:In Memberfunktion 'bool modsecurity::Utils::GeoLookup::lookup(const string&, modsecurity::Transaction*, std::function&)>) const':utils/geo_lookup.cc:124:32:Fehler:Ungültige Konvertierung von 'const MMDB_s*' nach 'MMDB_s*' [-fpermissive]r =MMDB_lookup_string(&mmdb, target.c_str( ), &gai_error, &mmdb_error);
 

 Wahrscheinlich liegt es daran, dass Sie eine veraltete Version von libmaxminddb-dev installiert haben . Sie können dieses Paket entfernen.
 
sudo apt entfernen libmaxminddb-dev
 

 Und installieren Sie libgeoip-dev , das eine Alternative zu libmaxminddb-dev ist .
 
sudo apt install libgeoip-dev
 

 Dann ModSecurity neu kompilieren.
 
sauber machen./configuremake -j4
 

 Installieren Sie die Binärdatei.
 
sudo make install
 
Schritt 4:ModSecurity v3 Nginx Connector-Quellcode herunterladen und kompilieren
 

 Der ModSecurity Nginx Connector verlinkt libmodsecurity zum Nginx-Webserver. Klonen Sie das ModSecurity v3 Nginx Connector Git-Repository.
 
git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git /usr/local/src/ModSecurity-nginx/
 

 Stellen Sie sicher, dass Sie sich im Nginx-Quellverzeichnis befinden.
 
cd /usr/local/src/nginx/nginx-1.19.5/
 

 Build-Abhängigkeiten für Nginx installieren.
 
sudo apt build-dep nginxsudo apt install uuid-dev
 

 Als nächstes konfigurieren Sie die Umgebung mit dem folgenden Befehl. Wir werden Nginx nicht selbst kompilieren, sondern den ModSecurity Nginx Connector kompilieren nur Modul. Der --with-compat -Flag macht das Modul binärkompatibel mit Ihrer vorhandenen Nginx-Binärdatei.
 
./configure --with-compat --add-dynamic-module=/usr/local/src/ModSecurity-nginx
 

 Erstellen Sie den ModSecurity Nginx Connector Modul.
 
Module erstellen
 

 Das Modul wird als objs/ngx_http_modsecurity_module.so gespeichert . Kopieren Sie es nach /usr/share/nginx/modules/ Verzeichnis.
 
sudo cp objs/ngx_http_modsecurity_module.so /usr/share/nginx/modules/
 
Schritt 5:Laden Sie das ModSecurity v3 Nginx Connector-Modul
 

 Bearbeiten Sie die Hauptkonfigurationsdatei von Nginx.
 
sudo nano /etc/nginx/nginx.conf
 

 Fügen Sie die folgende Zeile am Anfang der Datei hinzu.
 
load_module modules/ngx_http_modsecurity_module.so;
 

 Fügen Sie außerdem die folgenden zwei Zeilen in http {...} hinzu Abschnitt, sodass ModSecurity für alle virtuellen Nginx-Hosts aktiviert wird.
 
modsecurity on;modsecurity_rules_file /etc/nginx/modsec/main.conf;
 

 
 

 Speichern und schließen Sie die Datei. Als nächstes erstellen Sie /etc/nginx/modsec/ Verzeichnis zum Speichern der ModSecurity-Konfiguration
 
sudo mkdir /etc/nginx/modsec/
 

 Kopieren Sie dann die ModSecurity-Konfigurationsdatei.
 
sudo cp /usr/local/src/ModSecurity/modsecurity.conf-recommended /etc/nginx/modsec/modsecurity.conf
 

 Bearbeiten Sie die Datei.
 
sudo nano /etc/nginx/modsec/modsecurity.conf
 

 Suchen Sie die folgende Zeile.
 
SecRuleEngine DetectionOnly
 

 Diese Konfiguration weist ModSecurity an, HTTP-Transaktionen zu protokollieren, ergreift jedoch keine Maßnahmen, wenn ein Angriff erkannt wird. Ändern Sie es wie folgt, damit ModSecurity Webangriffe erkennt und blockiert.
 
SecRuleEngine ein
 

 Suchen Sie dann die folgende Zeile (Zeile 224), die ModSecurity mitteilt, welche Informationen in das Prüfprotokoll aufgenommen werden sollen.
 
SecAuditLogParts ABIJDEFHZ
 

 Die Standardeinstellung ist jedoch falsch. Sie werden später wissen, warum, wenn ich erkläre, wie man ModSecurity-Protokolle versteht. Die Einstellung sollte wie folgt geändert werden.
 
SecAuditLogParts ABCEFHJKZ
 

 Wenn Sie eine Programmier-Website haben, sollten Sie die Response-Body-Inspection deaktivieren, andernfalls erhalten Sie möglicherweise 403 verbotene Fehler, nur wenn Sie eine Webseite mit viel Code-Inhalt laden.
 
SecResponseBodyAccess aus
 

 Speichern und schließen Sie die Datei. Als nächstes erstellen Sie die /etc/nginx/modsec/main.conf Datei.
 
sudo nano /etc/nginx/modsec/main.conf
 

 Fügen Sie die folgende Zeile hinzu, um /etc/nginx/modsec/modsecurity.conf einzuschließen Datei.
 
Schließen Sie /etc/nginx/modsec/modsecurity.conf ein
 

 Speichern und schließen Sie die Datei. Wir müssen auch die Unicode-Mapping-Datei kopieren.
 
sudo cp /usr/local/src/ModSecurity/unicode.mapping /etc/nginx/modsec/
 

 Testen Sie dann die Nginx-Konfiguration.
 
sudo nginx -t
 

 Wenn der Test erfolgreich ist, starten Sie Nginx neu.
 
sudo systemctl restart nginx
 
Schritt 6:OWASP Core Rule Set aktivieren
 

 Damit ModSecurity Ihre Webanwendungen schützt, müssen Sie Regeln definieren, um böswillige Akteure zu erkennen und zu blockieren. Für Anfänger ist es eine gute Idee, vorhandene Regelsätze zu installieren, damit Sie schnell loslegen und später das Wesentliche lernen können. Es gibt mehrere kostenlose Regelsätze für ModSecurity. Das OWASP Core Rule Set (CRS) ist der Standardregelsatz, der mit ModSecurity verwendet wird.
 
 
Es ist kostenlos, wird von der Community gepflegt und ist der am weitesten verbreitete Regelsatz, der eine verkaufte Standardkonfiguration für ModSecurity bereitstellt.
 
Es enthält Regeln zum Stoppen gängiger Angriffsvektoren, darunter SQL-Injection (SQLi), Cross-Site-Scripting (XSS) und viele andere.
 
Es kann in Project Honeypot integriert werden.
 
Es enthält auch Regeln zur Erkennung von Bots und Scannern.
 
Es wurde durch breite Belichtung so eingestellt, dass es nur sehr wenige Fehlalarme gibt.
 
 

 Laden Sie das neueste OWASP CRS von GitHub herunter.
 
wget https://github.com/coreruset/coreruset/archive/v3.3.0.tar.gz
 

 Extrahieren Sie die Datei.
 
tar xvf v3.3.0.tar.gz
 

 Verschieben Sie das Verzeichnis nach /etc/nginx/modsec/ .
 
sudo mv coreruleset-3.3.0/ /etc/nginx/modsec/
 

 Benennen Sie crs-setup.conf.example um Datei.
 
sudo mv /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf.example /etc/nginx/modsec/coreruset-3.3.0/crs-setup.conf
 

 Bearbeiten Sie dann die Hauptkonfigurationsdatei.
 
sudo nano /etc/nginx/modsec/main.conf
 

 Fügen Sie die folgenden zwei Zeilen hinzu, wodurch Nginx die CRS-Konfigurationsdatei und einzelne Regeln enthält.
 
Schließen Sie /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf einSchließen Sie /etc/nginx/modsec/coreruleset-3.3.0/rules/*.conf ein
 

 
 

 Speichern und schließen Sie die Datei. Testen Sie dann die Nginx-Konfiguration.
 
sudo nginx -t
 

 Wenn der Test erfolgreich ist, starten Sie Nginx neu.
 
sudo systemctl restart nginx
 
Schritt 7:Erfahren Sie, wie OWASP CRS funktioniert
 

 Werfen wir einen Blick auf die CRS-Konfigurationsdatei, die Ihnen eine gute Dokumentation zur Funktionsweise von CRS bietet.
 
sudo nano /etc/nginx/modsec/coreruset-3.3.0/crs-setup.conf
 

 Sie sehen, dass OWASP CRS in zwei Modi laufen kann:
 
 
Eigenständiger Modus . Dies ist der traditionelle Modus, der in CRS v2.x verwendet wird. Wenn eine HTTP-Anfrage mit einer Regel übereinstimmt, blockiert ModSecurity die HTTP-Anfrage sofort und stoppt die Auswertung der verbleibenden Regeln.
 
Anomalie-Bewertungsmodus . Dies ist der in CRS v3.x verwendete Standardmodus. ModSecurity überprüft eine HTTP-Anforderung anhand aller Regeln und fügt jeder übereinstimmenden Regel eine Punktzahl hinzu. Wenn ein Schwellenwert erreicht wird, wird die HTTP-Anforderung als Angriff betrachtet und blockiert. Die Standardpunktzahl für eingehende Anfragen beträgt 5 und für ausgehende Antworten 4.
 
 

 
 

 Beim Laufen im Anomalie-Scoring-Modus gibt es 4 Paranoia-Stufen.
 
 
Paranoiastufe 1 (Standardeinstellung)
 
Paranoia Stufe 2
 
Paranoia Stufe 3
 
Paranoiastufe 4
 
 

 Mit jeder Erhöhung des Paranoia-Levels aktiviert das CRS zusätzliche Regeln, die Ihnen ein höheres Maß an Sicherheit bieten. Ein höheres Maß an Paranoia erhöht jedoch auch die Wahrscheinlichkeit, dass legitimer Datenverkehr aufgrund von Fehlalarmen blockiert wird.
 

 
 

 Dies sind die beiden grundlegenden Konzepte, die Sie verstehen müssen, bevor Sie das CRS verwenden. Jetzt können wir die Datei schließen. Die einzelnen CRS-Regeln sind in /etc/nginx/modsec/coreruleset-3.3.0/rules/ gespeichert Verzeichnis. Jede übereinstimmende Regel erhöht den Anomaliewert.
 
Schritt 8:Testen
 

 Um zu überprüfen, ob ModSecurity funktioniert, können Sie einen einfachen SQL-Injection-Angriff auf Ihre eigene Website starten. (Bitte beachten Sie, dass es illegal ist, ohne Genehmigung Sicherheitstests auf den Websites anderer Personen durchzuführen.) Geben Sie die folgende URL in Ihren Webbrowser ein.
 
https://ihredomain.com/?id=3 oder 'a'='a'
 

 Wenn ModSecurity ordnungsgemäß funktioniert, sollte Ihr Nginx-Webserver eine 403-Fehlermeldung zurückgeben.
 

 
 

 Der Firefox-Browser zeigt möglicherweise die 403-Fehlermeldung nicht an. Sie können Ctrl+Shift+I drücken , um das Entwicklertools-Fenster zu öffnen und das network auszuwählen Tab. Drücken Sie dann F5 um die Webseite neu zu laden. Sie sollten jetzt den 403-Fehlercode in Firefox sehen.
 

 Wenn ModSecurity in DetectionOnly läuft Modus wird dieser SQL-Injection-Angriff nicht blockiert.
 
Schritt 9:Verstehen der ModSecurity-Protokolle
 

 Es ist wichtig, die ModSecurity-Protokolle zu analysieren, damit Sie wissen, welche Art von Angriffen auf Ihre Webanwendungen gerichtet sind, und bessere Maßnahmen ergreifen können, um sich gegen Bedrohungsakteure zu verteidigen. Es gibt hauptsächlich zwei Arten von Protokollen in ModSecurity:
 
 
Debug-Protokoll:standardmäßig deaktiviert.
 
Prüfprotokoll:/var/log/modsec_audit.log 
 
 

 Um die Audit-Logs von ModSecurity zu verstehen, müssen Sie die 5 Verarbeitungsphasen in ModSecurity kennen:
 
 
Phase 1:Anforderungsheader prüfen
 
Phase 2:Anforderungstext prüfen
 
Phase 3:Antwortheader prüfen
 
Phase 4:Inspizieren des Reaktionskörpers
 
Phase 5:Aktion (Protokollieren/Blockieren schädlicher Anfragen)
 
 

 Sie sind auch zwei Arten von Protokolldateien.
 
 
Seriennummer :eine Datei für alle Protokolle. Dies ist die Voreinstellung.
 
Gleichzeitig :mehrere Dateien für die Protokollierung. Dies kann eine bessere Schreibleistung bereitstellen. Wenn Sie feststellen, dass Ihre Webseiten nach der Aktivierung von ModSecurity langsamer werden, können Sie den gleichzeitigen Protokollierungstyp verwenden.
 
 

 Ereignisse im Protokoll sind in mehrere Abschnitte unterteilt.
 
 
Abschnitt A:Audit-Log-Header
 
Abschnitt B:Anforderungsheader
 
Abschnitt C:Anfragetext
 
Abschnitt D:reserviert
 
Abschnitt E:zwischengeschaltete Antwortstelle
 
Abschnitt F:endgültige Antwortheader
 
Abschnitt G:reserviert
 
Abschnitt H:Audit-Log-Trailer
 
Abschnitt I:Alternative zum kompakten Anfragetext, die Dateien ausschließt
 
Abschnitt J:Informationen zu hochgeladenen Dateien
 
Abschnitt K:jede Regel, auf die ein Ereignis zutrifft, in der Reihenfolge der Übereinstimmung
 
Abschnitt Z:endgültige Grenze
 
 

 Wenn Sie eine stark frequentierte Website betreiben, kann das ModSecurity-Überwachungsprotokoll sehr schnell zu groß werden, daher müssen wir die Protokollrotation für das ModSecurity-Überwachungsprotokoll konfigurieren. Erstellen Sie eine Logrotate-Konfigurationsdatei für ModSecurity.
 
sudo nano /etc/logrotate.d/modsecurity
 

 Fügen Sie dieser Datei die folgenden Zeilen hinzu.
 
/var/log/modsec_audit.log{ 14 mal täglich rotieren missingok compress delaycompress notifempty}
 

 Dadurch wird die Protokolldatei jeden Tag rotiert (täglich ), Komprimieren alter Versionen (compress ). Die vorherigen 14 Protokolldateien werden beibehalten (rotate 14 ), und es findet keine Rotation statt, wenn die Datei leer ist (notifempty ). Speichern und schließen Sie die Datei.
 

 Wenn Ihr ModSecurity-Protokoll leer ist, müssen Sie Nginx möglicherweise neu starten.
 
sudo systemctl restart nginx
 
Schritt 10:Umgang mit falsch positiven Ergebnissen
 

 ModSecurity ist eine generische Webanwendungs-Firewall und nicht für eine bestimmte Webanwendung konzipiert. Der OWASP-Kernregelsatz ist auch ein generischer Regelsatz ohne bestimmte Anwendung, daher ist es wahrscheinlich, dass Sie nach der Aktivierung von ModSecurity und OWASP CRS falsch positive Ergebnisse sehen. Wenn Sie den Paranoia-Level im CRS erhöhen, werden mehr Fehlalarme angezeigt.
 

 Beispielsweise verbietet das CRS standardmäßig das Einschleusen von Unix-Befehlen wie die Eingabe von sudo auf einer Webseite, was in meinem Blog eher üblich ist. Um Fehlalarme zu eliminieren, müssen Sie dem CRS Regelausschlüsse hinzufügen.
 
Anwendungsspezifische Regelausschlüsse 
 

 Es gibt einige vorgefertigte, anwendungsspezifische Ausnahmen, die mit OWASP CRS geliefert werden. Bearbeiten Sie die crs-setup.conf Datei.
 
sudo nano /etc/nginx/modsec/coreruset-3.3.0/crs-setup.conf
 

 Gehen Sie zu den Anwendungsspezifischen Regelausschlüssen Abschnitt und finden Sie die folgenden Zeilen.
 
#SecAction \# "id:900130,\# phase:1,\# nolog,\# pass,\# t:none,\# setvar:tx.crs_exclusions_cpanel=1,\# setvar:tx.crs_exclusions_drupal=1,\# setvar:tx.crs_exclusions_dokuwiki=1,\# setvar:tx.crs_exclusions_nextcloud=1,\# setvar:tx.crs_exclusions_wordpress=1,\# setvar:tx.crs_exclusions_xenforo=1"
 

 Wenn ich beispielsweise WordPress-Ausschlüsse aktivieren möchte, sollten die obigen Zeilen wie folgt geändert werden. Bitte achten Sie auf die Syntax. Zwischen t:none,\ sollten keine Kommentare stehen und setvar:tx.crs_exclusions_wordpress=1" . (Der Backslash \ Zeichen am Ende zeigt an, dass die nächste Zeile eine Fortsetzung der aktuellen Zeile ist.)
 
SecAction \ "id:900130,\ phase:1,\ nolog,\ pass,\ t:none,\ setvar:tx.crs_exclusions_wordpress=1"# setvar:tx.crs_exclusions_cpanel=1,\# setvar:tx. crs_exclusions_drupal=1,\# setvar:tx.crs_exclusions_dokuwiki=1,\# setvar:tx.crs_exclusions_nextcloud=1,\# setvar:tx.crs_exclusions_xenforo=1"
 

 Speichern und schließen Sie die Datei. Testen Sie dann die Nginx-Konfigurationen.
 
sudo nginx -t
 

 Wenn der Test erfolgreich ist, laden Sie Nginx neu, damit die Änderung wirksam wird.
 
sudo systemctl reload nginx
 

 Beachten Sie, dass, wenn Sie mehrere Anwendungen wie (WordPress, Nextcloud, Drupal usw.) auf demselben Server installiert haben, die oben genannten Regelausschlüsse auf alle Anwendungen angewendet werden. Um die Sicherheitsrisiken zu minimieren, sollten Sie einen Regelausschluss nur für eine Anwendung aktivieren. Gehen Sie dazu zu /etc/nginx/modsec/coreruleset-3.3.0/rules/ Verzeichnis.
 
cd /etc/nginx/modsec/coreruset-3.3.0/rules
 

 Benennen Sie REQUEST-900-EXCLUSION-RULES-BEFORE-CRS um Datei.
 
sudo mv REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
 

 Bearbeiten Sie dann diese Datei.
 
sudo nano REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
 

 Fügen Sie am Ende dieser Datei die folgende Zeile hinzu. Wenn Ihr WordPress den blog.yourdomain.com verwendet Subdomain enthält und der vom Browser des Besuchers gesendete Anfrageheader diese Subdomain enthält, dann wendet ModSecurity die Regelausschlüsse für WordPress an.
 
SecRule REQUEST_HEADERS:Host "@streq blog.yourdomain.com" "id:1000,phase:1,setvar:tx.crs_exclusions_wordpress=1"
 

 Wenn Sie Nextcloud auf demselben Server installiert haben, können Sie dieser Datei auch die folgende Zeile hinzufügen. Wenn also ein Besucher auf Ihre Nextcloud-Subdomain zugreift, wendet ModSecurity die Nextcloud-Regelausschlüsse an.
 
SecRule REQUEST_HEADERS:Host "@streq nextcloud.yourdomain.com" "id:1001,phase:1,setvar:tx.crs_exclusions_nextcloud=1"
 

 Speichern und schließen Sie diese Datei. Testen Sie dann die Nginx-Konfigurationen.
 
sudo nginx -t
 

 Wenn der Test erfolgreich ist, laden Sie Nginx neu, damit die Änderung wirksam wird.
 
sudo systemctl reload nginx
 
Ausschlüsse von benutzerdefinierten Regeln
 

 Das Aktivieren der vordefinierten anwendungsspezifischen Regelausschlüsse beseitigt möglicherweise nicht alle Fehlalarme. Wenn dies der Fall ist, müssen Sie das Audit-Protokoll von ModSecurity untersuchen (/var/log/modsec_audit.log ), überprüfen Sie, welche Regel das Fehlalarm verursacht hat, und fügen Sie Ihre benutzerdefinierten Regelausschlüsse in REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf hinzu Datei.
 

 Abschnitt H im Überwachungsprotokoll zeigt Ihnen, welche Regel zutrifft. Wenn ich zum Beispiel versuche, <code>...</code> zu verwenden HTML im Kommentarformular, ModSecurity blockiert meinen Kommentar. Das folgende Protokoll sagt mir, dass die HTTP-Anfrage mit einer Regel in REQUEST-941-APPLICATION-ATTACK-XSS.conf übereinstimmt (Zeile 527). Die Regel-ID ist 941310. Der Anfrage-URI ist /wp-comments-post.php .
 

 
 

 Es wird als XSS-Filterangriff mit fehlerhafter Codierung erkannt. Ich möchte jedoch, dass Benutzer den <code>...</code> verwenden können und <pre>...</pre> HTML-Tag im Kommentarformular, daher habe ich einen Regelausschluss erstellt. Fügen Sie die folgende Zeile am Ende der REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf hinzu Datei.
 
SecRule REQUEST_URI "@streq /wp-comments-post.php" "id:1002,phase:1,ctl:ruleRemoveById=941310"
 

 Diese Zeile teilt ModSecurity mit, dass der Anforderungs-URI /wp-comments-post.php ist , dann Regel-ID 941310 nicht anwenden. Speichern und schließen Sie die Datei. Testen Sie dann die Nginx-Konfiguration.
 
sudo nginx -t
 

 Wenn der Test erfolgreich ist, laden Sie Nginx neu.
 
sudo systemctl reload nginx
 

 Wenn ein Fehlalarm mit mehreren Regel-IDs übereinstimmt, können Sie Regelausschlüsse wie folgt in einer Zeile hinzufügen:
 
SecRule REQUEST_URI "@streq /wp-admin/post.php" "id:1003,phase:1,ctl:ruleRemoveById=941160 ,ctl:ruleRemoveById=941310 ,ctl:ruleRemoveById=942100 "
 

 Hinweis :Es wird nicht empfohlen, zu viele Regeln der Stufe 1 im OWASP CRS zu deaktivieren, da Ihre Website dadurch viel leichter gehackt werden kann. Deaktivieren Sie Regeln nur, wenn Sie wissen, was Sie tun.
 
IP-Whitelisting
 

 Wenn Sie ModSecurity für Ihre eigene IP-Adresse deaktivieren, aber für alle anderen IP-Adressen aktiviert lassen möchten, fügen Sie die folgende benutzerdefinierte Regel in der REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf hinzu Datei. Ersetzen Sie 12.34.56.78 mit Ihrer echten IP-Adresse.
 
SecRule REMOTE_ADDR "^12\.34\.56\.78" "id:1004,phase:1,allow,ctl:ruleEngine=off"
 

 Um ein Subnetz auf die Whitelist zu setzen, verwenden Sie die folgende Syntax, die 10.10.10.0/24 auf die Whitelist setzt Netzwerk.
 
SecRule REMOTE_ADDR "^10\.10\.10.*" "id:1005,phase:1,allow,ctl:ruleEngine=off"
 

 Speichern und schließen Sie die Datei. Testen Sie dann die Nginx-Konfigurationen.
 
sudo nginx -t
 

 Wenn der Test erfolgreich ist, starten Sie Nginx neu, damit die Änderung wirksam wird.
 
sudo systemctl restart nginx
 
Verkettungsregeln
 

 Wenn Ihr Nginx über mehrere virtuelle Hosts verfügt, möchten Sie möglicherweise Ihre IP-Adresse für einen bestimmten virtuellen Host auf die Whitelist setzen. Sie müssen zwei Regeln wie folgt verketten:
 
SecRule REMOTE_ADDR "^12\.34\.56\.78" "id:1004,phase:1,allow,ctl:ruleEngine=off,chain"SecRule REQUEST_HEADERS:Host "@streq nextcloud.yourdomain.com" "t:none"
 

 Die chain Schlüsselwort am Ende der ersten Regel gibt an, dass ruleEngine=off Eine Aktion wird nur ausgeführt, wenn die Bedingung in der nächsten Regel ebenfalls wahr ist.
 
(Optional) Integrieren Sie ModSecurity in Project Honeypot
 

 Project Honeypot führt eine Liste bekannter bösartiger IP-Adressen, die der Öffentlichkeit kostenlos zur Verfügung stehen. ModSecurity kann in Project Honeypot integriert werden und IP-Adressen auf der Project Honeypot-Liste blockieren.
 

 Beachten Sie, dass die Verwendung von Project Honeypot Ihre Website für neue Besucher langsamer macht, da Ihr Webserver eine Anfrage an Project Honeypot senden muss, bevor er eine Antwort an den neuen Besucher senden kann. Sobald die IP-Reputationsdaten jedoch auf Ihrem Webserver zwischengespeichert sind, ist die Auswirkung auf die Leistung sehr gering.
 

 Um Project Honeypot zu verwenden, erstellen Sie zunächst ein kostenloses Konto auf seiner Website. Gehen Sie dann zu Ihrem Konto-Dashboard und klicken Sie auf get one Link zum Anfordern eines Zugriffsschlüssels für die HTTP-Blacklist.
 

 
 

 Bearbeiten Sie als Nächstes die crs-setup.conf Datei.
 
sudo nano /etc/nginx/modsec/coreruset-3.3.0/crs-setup.conf
 

 Suchen Sie die folgenden Zeilen.
 
#SecHttpBlKey XXXXXXXXXXXXXXXXX#SecAction "id:900500,\# phase:1,\# nolog,\# pass,\# t:none,\# setvar:tx.block_search_ip=1,\# setvar:tx.block_suspicious_ip =1,\# setvar:tx.block_harvester_ip=1,\# setvar:tx.block_spammer_ip=1"
 

 Entfernen Sie das beginnende # Zeichen, um sie zu entkommentieren, und fügen Sie Ihren HTTPBL-API-Schlüssel hinzu, den Sie von Project Honeypot erhalten haben.
 

 
 

 Beachten Sie, dass block_search_ip sollte auf 0 gesetzt werden (deaktiviert), da wir Suchmaschinen-Crawler nicht blockieren möchten. Speichern und schließen Sie die Datei. Laden Sie dann Nginx neu.
 
sudo systemctl reload nginx
 

 Jetzt fragt ModSecurity Project Honeypot bei allen HTTP-Anfragen ab. Um zu testen, ob dies funktioniert, bearbeiten Sie die Datei /etc/nginx/modsec/main.conf.
 
sudo nano /etc/nginx/modsec/main.conf
 

 Fügen Sie am Ende dieser Datei die folgende Zeile hinzu. Dadurch können wir eine IP-Adresse in einer URL weitergeben. (Sobald der Test erfolgreich war, können Sie diese Zeile aus der Datei entfernen.)
 
SecRule ARGS:IP "@rbl dnsbl.httpbl.org" "phase:1,id:171,t:none,deny,nolog,auditlog,msg:'RBL Match for SPAM Source'
 

 Speichern und schließen Sie die Datei. Nginx-Konfigurationen testen.
 
sudo nginx -t
 

 Laden Sie dann Nginx neu.
 
sudo systemctl reload nginx
 

 Gehen Sie zur Website von Project Honeypot und finden Sie eine bösartige IP-Adresse, zum Beispiel 134.119.218.243. Führen Sie den folgenden Befehl aus, um die HTTP-Blacklist zu testen.
 
curl -i -s -k -X $'GET' 'https://yourdomain.com/?IP=134.119.218.243'
 

 Ihr Webserver sollte eine verbotene 403-Antwort zurückgeben, weil die IP-Adresse auf Project Honeypot.
 
So verwenden Sie Brotli mit ModSecurity in Nginx
 

 Traditionell werden Webseiten für eine schnellere Ladegeschwindigkeit mit GZIP komprimiert. Brotli wurde von Google entwickelt und ist ein neuer Komprimierungsalgorithmus, der ein besseres Komprimierungsverhältnis bietet. It’s supported by all major web browsers. To use Brotli in Nginx, first you need to install the Brotli Nginx module from the the ondrej/nginx-mainline PPA.
 
sudo apt install libnginx-mod-brotli
 

 Then open the main Nginx configuration file.
 
sudo nano /etc/nginx/nginx.conf
 

 Add the following lines in the http {...} context.
 
 brotli on; brotli_comp_level 6; brotli_static on; brotli_types application/atom+xml application/javascript application/json application/rss+xml application/vnd.ms-fontobject application/x-font-opentype application/x-font-truetype application/x-font-ttf application/x-javascript application/xhtml+xml application/xml font/eot font/opentype font/otf font/truetype image/svg+xml image/vnd.microsoft.icon image/x-icon image/x-win-bitmap text/css text/javascript text/plain text/xml;
 

 Save and close the file, then test Nginx configurations.
 
sudo nginx -t
 

 If the test is successful, restart Nginx.
 
sudo systemctl restart nginx
 

 Now go to the home page your website, open the developer tools in your web browser (In Firefox you can press Ctrl+Alt+I to open it up). Select the Network tab, and press F5 to reload the web page. Click on the main HTML page.
 

 
 

 Check the response header on the right sidebar. If the content-encoding is set to br , then you have successfully enabled Brotli compression in Nginx.
 

 
 

 If the content-encoding is gzip , then your Nginx web server is still using GZIP.
 
Upgrading Nginx
 

 ModSecurity integrates with Nginx as a dynamic module, so every time the Nginx binary is upgraded, you need to rebuild the ModSecurity module for Nginx. This will make your application offline for a few minutes.
 

 If a newer version of Nginx is available in the repository, the sudo apt upgrade command will upgrade Nginx. The newer version of Nginx is not going to be compatible with the previously compiled ModSecurity module. If Nginx is upgraded by the sudo apt upgrade command, it will fail to restart as shown in the screenshot below.
 

 
 

 And if you run sudo nginx -t command, it tells you that Nginx expects a new version of the ModSecurity module.
 

 
 

 My advice is to prevent Nginx from being upgraded when you run sudo apt upgrade Befehl. This can be achieved by the following command:
 
sudo apt-mark hold nginx
 

 Now if you run sudo apt update;sudo apt upgrade , and the package manager tells you that the nginx package is held back from upgrading, then it means there’s a new nginx version available in the repository.
 

 
 

 You should download the new Nginx source package and compile the ModSecurity module again. Move the newly-compiled ModSecurity module to /usr/share/nginx/modules/ Verzeichnis. Basically that means you need to remove everything under /usr/local/src/ directory (sudo rm /usr/local/src/* -rf ) and go through step 2 and step 4 again.
 

 Then unhold Nginx.
 
sudo apt-mark unhold nginx
 

 And upgrade Nginx.
 
sudo apt upgrade nginx
 

 Once the upgrade is complete, hold Nginx again.
 
sudo apt-mark hold nginx
 

 To show what packages are held, run
 
apt-mark showhold
 
Nginx Plus
 

 If you use the commercial Nginx Plus web server, then ModSecurity is included in the Nginx Plus binary. It’s known as the NGINX WAF .
 

 If you don’t want to spend time re-compiling the ModSecurity source code, then you might want to purchase Nginx Plus, as the ModSecurity module is pre-compiled in the Nginx Plus binary. Benefits of Using ModSecurity 3.0 with NGINX Plus:
 
 
You don’t need to compile the ModSecurity dynamic module yourself;  NGINX, Inc. provides a precompiled module for you, saving time and effort.
 
NGINX, Inc. has extensively tested the dynamic module, so you know it’s suitable for production usage.
 
NGINX, Inc. continually tracks changes and updates the module for every important change and security vulnerability, so you don’t have to do this yourself.
 
Each new release of NGINX Plus includes a new version of the dynamic module, so you can upgrade without having to re-compile ModSecurity.
 
You get 24×7 support with both installation of the ModSecurity and the OWASP Core Rule Set, as well as troubleshooting and debugging assistance.
 
 
How to Disable ModSecurity for a Virtual Host
 

 In this tutorial, I added the following line in the http {...} context.
 
modsecurity on;
 

 This will enable ModSecurity for all Nginx server blocks (aka virtual hosts). If you want to disable ModSecurity for a specific server block, then edit the server block file (/etc/nginx/conf.d/example.com.conf ) and add the following line to the server {...} context.
 
modsecurity off;
 

 Reload Nginx for the change to take effect.
 
sudo systemctl reload nginx
 
FAQ
 
Static Module vs Dynamic Module in Nginx
 
 
A static module must be compiled with Nginx and it’s integrated with Nginx as one binary. It can’t be unloaded from Nginx.
 
A dynamic module is a separate package from the main Nginx binary. It can be loaded and unloaded in Nginx.
 
 
What does Binary Compatible Mean?
 
 
If a dynamic module is not binary compatible, then the module and Nginx should be compiled together. If there’s an existing Nginx binary installed from a software repository using apt-get , it must be removed and you need to install the compiled Nginx binary in order to use the dynamic module.
 
If a dynamic module is binary compatible, then this module can be compiled individually without compiling Nginx. The module can be used with your existing Nginx binary installed from a software repository. It’s not perfect, though.
 
 

 No matter a module is static or dynamic, binary compatible or non binary compatible, if you upgrade the Nginx binary later, you need to compile the module again.
 
Upgrade Server RAM
 

 ModSecurity can use a fair amount of RAM. If you can see the following error in your Nginx error log (/var/log/nginx/error.log), it means your server is short of RAM.
 
fork() failed while spawning "worker process" (12:Cannot allocate memory)sendmsg() failed (9:Bad file descriptor)sendmsg() failed (9:Bad file descriptor)sendmsg() failed (9:Bad file descriptor)
 

 You need to restart Nginx and upgrade server RAM, then the above error is not going to happen again.
 
How to Upgrade OWASP CRS
 

 Besides upgrading the ModSecurity Nginx module, you also need to upgrade the core rule set when a new version comes out. The process is straightforward.
 
 
Go through step 6 again to install the new version of core rule set.
 
Then go to step 10. Copy of your custom rules in the crs-setup.conf   and REQUEST-900-EXCLUSION-RULES-BEFORE-CRS Datei.
 
 

 Next, test Nginx configurations.
 
sudo nginx -t
 

 If the test is successful, reload Nginx for the change to take effect.
 
sudo systemctl reload nginx
 

 How do you know if the new version is working? Launch a simple SQL injection attack like in step 8 and check your server logs. It will show you the CRS version that’s preventing this attack.