So installieren Sie ModSecurity 3 &OWASP Core Rule Set mit Nginx auf Debian 11 Bullseye

ModSecurity, oft als Modsec bezeichnet ist eine kostenlose Open-Source-Firewall für Webanwendungen (WAF) . ModSecurity wurde als Modul für den Apache HTTP Server erstellt. Seit ihren Anfängen ist die WAF jedoch gewachsen und deckt nun eine Reihe von Filterfunktionen für Anforderungen und Antworten des HyperText Transfer Protocol für verschiedene Plattformen wie Microsoft IIS, Nginx und natürlich Apache ab.

Funktionsweise der WAF:Die ModSecurity-Engine wird vor der Webanwendung bereitgestellt, sodass die Engine die eingehenden und ausgehenden HTTP-Verbindungen scannen kann. ModSecurity wird am häufigsten in Verbindung mit dem OWASP Core Rule Set (CRS) verwendet , ein Open-Source-Regelsatz, der in der SecRules-Sprache von ModSecurity geschrieben ist und in der Sicherheitsbranche hoch angesehen ist.

OWASP Rule Set mit ModSecurity kann fast sofort helfen, Ihren Server vor Folgendem zu schützen:

• Schlechte Benutzeragenten
• DDOS
• Cross-Website-Scripting
• SQL-Injection
• Session-Hijacking
• Andere Bedrohungen

Im folgenden Tutorial erfahren Sie, wie Sie ModSecurity mit Nginx auf einem Debian 11 Bullseye-Desktop oder -Server installieren.

Voraussetzungen

• Empfohlenes Betriebssystem: Debian 11 Bullseye.
• Benutzerkonto: Ein Benutzerkonto mit Sudo- oder Root-Zugriff.
• Erforderliche Pakete: im gesamten Tutorial aufgeführt

Betriebssystem aktualisieren

Aktualisieren Sie Ihr Debian Betriebssystem, um sicherzustellen, dass alle vorhandenen Pakete auf dem neuesten Stand sind:

sudo apt update && sudo apt upgrade -y

Das Tutorial verwendet den sudo-Befehl und vorausgesetzt, Sie haben den Sudo-Status .

So überprüfen Sie den Sudo-Status Ihres Kontos:

sudo whoami

Beispielausgabe, die den Sudo-Status zeigt:

[joshua@debian~]$ sudo whoami
root

Um ein bestehendes oder neues Sudo-Konto einzurichten, besuchen Sie unser Tutorial zum Hinzufügen eines Benutzers zu Sudoers unter Debian .

So verwenden Sie das Root-Konto verwenden Sie den folgenden Befehl mit dem Root-Passwort, um sich anzumelden.

su

CURL &UNZIP-Paket installieren

Das Tutorial verwendet den curl and unzip Befehl während bestimmter Teile. Um sicherzustellen, dass dies installiert ist, führen Sie den folgenden Befehl in Ihrem Terminal aus:

sudo apt install curl unzip -y

Neueste Nginx installieren

Zuerst müssen Sie Nginx installieren, und es wird empfohlen, dies mit der neuesten stabilen oder Mainline-Nginx-Version zu tun. Bevor Sie fortfahren, wird empfohlen, alle vorhandenen Installationen zu entfernen von Nginx und installieren Sie die neueste stabile oder Hauptversion von Nginx .

Vorhandene Nginx-Installation entfernen

Stoppen Sie den aktuellen Nginx-Dienst:

sudo systemctl stop nginx

Entfernen Sie nun die vorhandene Nginx-Installation wie folgt:

apt-get purge nginx -y && sudo apt autoremove nginx -y

Neuestes Nginx-Repository importieren und installieren

Um die neueste Version von entweder nginx mainline oder stable zu verwenden, müssen Sie zuerst das Repository importieren.

So importieren Sie das Mainline-Repository:

curl -sSL https://packages.sury.org/nginx-mainline/README.txt | sudo bash -x

So importieren Sie ein stabiles Repository:

curl -sSL https://packages.sury.org/nginx/README.txt | sudo bash -x

Aktualisieren Sie Ihr Repository, um die neue Änderung widerzuspiegeln:

apt update

Nachdem Sie nun das Nginx-Repository installiert haben und die Repository-Liste aktualisiert haben, installieren Sie Nginx wie folgt:

apt install nginx-core nginx-common nginx nginx-full

Beachten Sie, dass Sie möglicherweise aufgefordert werden, Ihre vorhandene /etc/nginx/ beizubehalten oder zu ersetzen nginx.conf Konfigurationsdatei während der Installation. Es wird empfohlen, Ihre aktuelle Konfigurationsdatei beizubehalten, indem Sie (n) drücken . Unabhängig von der Version des Betreuers wird eine Kopie erstellt, und Sie können dies auch in Zukunft überprüfen.

Nginx-Quellcode zum Repository hinzufügen

Bei der Installation der neuesten Version von Nginx Mainline oder Stable wird standardmäßig nur die Binärdatei installiert. Sie benötigen jedoch den Quellcode, um Modsecurity im weiteren Verlauf des Tutorials zu kompilieren.

Öffnen Sie zuerst die Konfigurationsdatei in /etc/apt/sources.list.d mit Nano wie folgt:

Hauptlinie:

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

Stabil:

nano /etc/apt/sources.list.d/nginx.list

Sowohl in Mainline als auch in Stable sehen Sie beim Öffnen der Datei nur eine einzige Zeile wie folgt:

#Mainline File#
deb-src https://packages.sury.org/nginx-mainline/ bullseye main
#Stable File#
deb-src https://packages.sury.org/nginx/ bullseye main

Fügen Sie unter der ursprünglichen Zeile die folgende Zeile hinzu:

Hauptlinie:

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

Stabil:

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

Beispiel dafür, wie es aussehen sollte (nur Mainline-Beispiel):

Nginx-Quelle herunterladen

Sie müssen den Nginx-Quellcode herunterladen, um das dynamische Modul von ModSecurity zu kompilieren . Dazu müssen Sie das Quellpaket herunterladen und im Verzeichnis /etc/local/src/nginx speichern .

Verzeichnisse erstellen und konfigurieren

Erstellen Sie den Standort wie folgt:

mkdir /usr/local/src/nginx && cd /usr/local/src/nginx

Optional – Weisen Sie dem Verzeichnis bei Bedarf wie folgt eine Berechtigung zu:

chown username:username /usr/local/src/ -R 

Abhängigkeiten installieren und Download ausführen

Laden Sie als Nächstes das Quellpaket wie folgt herunter:

apt install dpkg-dev -y && sudo apt source nginx

Beachten Sie, dass die folgende Fehlermeldung angezeigt wird:

dpkg-source: info: extracting nginx in nginx-1.21.1
dpkg-source: info: unpacking nginx_1.21.1.orig.tar.gz
dpkg-source: info: unpacking nginx_1.21.1-1+0~20210802.31+debian11~1.gbp08d591.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 0001-Make-sure-signature-stays-the-same-in-all-nginx-buil.patch
dpkg-source: info: applying 0002-define_gnu_source-on-other-glibc-based-platforms.patch
W: Download is performed unsandboxed as root as file 'nginx_1.21.1-1+0~20210802.31+debian11~1.gbp08d591.dsc' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

Dies kann getrost ignoriert werden.

Quellversion überprüfen

Listen Sie als Nächstes die Verzeichnisdateien mit dem ls auf Befehl wie folgt:

ls

Sie sollten die folgende Ausgabe in Ihrem /usr/src/local/nginx sehen Verzeichnis:

nginx-1.21.1
nginx_1.21.1-1+0~20210802.31+debian11~1.gbp08d591.debian.tar.xz
nginx_1.21.1-1+0~20210802.31+debian11~1.gbp08d591.dsc
nginx_1.21.1.orig.tar.gz
nginx_1.21.1.orig.tar.gz.asc

Bestätigen Sie als Nächstes, dass das Quellpaket mit Ihrer auf Ihrem Debian-Betriebssystem installierten Nginx-Version identisch ist. Verwenden Sie dazu das folgende nginx -v Befehl wie folgt:

sudo nginx -v

Die heruntergeladene Quelle sollte mit der auf Ihrem System installierten Binärversion übereinstimmen.

Beispiel:

nginx version: nginx/1.21.1

Installieren Sie libmodsecurity3 für ModSecurity

Das Paket libmodsecurity3 ist der eigentliche Teil der WAF, der die HTTP-Filterung durchführt für Ihre Webanwendungen. Unter Debian 11 können Sie dies aus dem standardmäßigen Debian 11-Repository installieren. Dies wird jedoch nicht empfohlen, wie bei den meisten stabilen Versionen, und es kommt häufig zu Verzögerungen. Stattdessen kompilieren Sie aus der wesentlich aktuelleren Quelle wie folgt.

ModSecurity Repository von Github klonen

Der erste Schritt ist der Klon von Github, und wenn Sie Git nicht installiert haben, müssen Sie den folgenden Befehl ausführen:

apt install git -y

Als nächstes klonen Sie das GIT-Repository libmodsecurity3 wie folgt:

git clone --depth 1 -b v3/master --single-branch https://github.com/SpiderLabs/ModSecurity /usr/local/src/ModSecurity/

Nach dem Klonen müssen Sie eine CD erstellen in das Verzeichnis:

cd /usr/local/src/ModSecurity/

Installieren Sie libmodsecurity3-Abhängigkeiten

Zum Kompilieren müssen Sie die folgenden Abhängigkeiten wie folgt 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 -y

Installieren Sie nun abschließend die folgenden GIT-Submodule wie folgt:

git submodule init

Dann aktualisieren Sie die Submodule:

git submodule update

Aufbau der ModSecurity-Umgebung

Der nächste Schritt besteht nun tatsächlich darin, zuerst die Umgebung zu bauen. Verwenden Sie den folgenden Befehl:

./build.sh

Führen Sie als Nächstes den Konfigurationsbefehl aus:

./configure

Beachten Sie, dass möglicherweise der folgende Fehler angezeigt wird:

fatal: No names found, cannot describe anything.

Sie können dies getrost ignorieren und mit dem nächsten Schritt fortfahren.

Kompilieren des ModSecurity-Quellcodes

Nachdem Sie die Umgebung für libmodsecurity3 erstellt und konfiguriert haben, ist es an der Zeit, sie mit dem Befehl make zu kompilieren .

make

Ein praktischer Trick ist die Angabe von -j da dies die Kompilierungsgeschwindigkeit erheblich erhöhen kann, wenn Sie einen leistungsstarken Server haben. Zum Beispiel hat der LinuxCapable-Server 6 CPUs, und ich kann alle 6 oder zumindest 4 bis 5 verwenden, um die Geschwindigkeit zu erhöhen.

make -j 6

Führen Sie nach dem Kompilieren des Quellcodes nun den Installationsbefehl in Ihrem Terminal aus:

make install

Beachten Sie, dass die Installation im Verzeichnis /usr/local/modsecurity/, erfolgt auf die Sie später in diesem Handbuch verweisen werden.

ModSecurity-nginx Connector installieren

Der ModSecurity-nginx-Konnektor ist der Verbindungspunkt zwischen nginx und libmodsecurity. Im Grunde ist es die Komponente, die zwischen Nginx und ModSecurity (libmodsecurity3) kommuniziert .

Klonen Sie das ModSecurity-nginx-Repository von Github

Ähnlich wie beim vorherigen Schritt zum Klonen des libmodsecurity3-Repositorys müssen Sie das Connector-Repository mit dem folgenden Befehl erneut klonen:

sudo git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git /usr/local/src/ModSecurity-nginx/

ModSecurity-nginx-Abhängigkeiten installieren

Als nächstes CD-Verzeichnis in das Nginx-Quellverzeichnis wie folgt:

cd /usr/local/src/nginx/nginx-1.21.1

Hinweis:Ersetzen Sie die Version des Handbuchs durch die aktuelle Nginx-Version in Ihrem System.

Führen Sie nun den Befehl in Ihrem Debian-Terminal aus, um die erforderlichen Abhängigkeiten zu installieren:

apt build-dep nginx && sudo apt install uuid-dev -y

Als Nächstes kompilieren Sie den ModSecurity-nginx Connector Modul nur mit –with-compat wie folgt kennzeichnen:

./configure --with-compat --add-dynamic-module=/usr/local/src/ModSecurity-nginx

Jetzt machen (erstellen) Sie die dynamischen Module mit dem folgenden Befehl:

make modules

Verwenden Sie als Nächstes im Nginx-Quellverzeichnis den folgenden Befehl, um das soeben erstellte dynamische Modul zu verschieben, das am Speicherort objs/ngx_http_modsecurity_module.so gespeichert wurde und kopieren Sie es nach /usr/share/nginx/modules Verzeichnis.

sudo cp objs/ngx_http_modsecurity_module.so /usr/share/nginx/modules/

Sie können das dynamische Modul überall speichern, solange Sie beim Laden den vollständigen Pfad angeben.

Laden und konfigurieren Sie den ModSecurity-nginx Connector mit dem Nginx-Webserver

Nachdem Sie das dynamische Modul kompiliert und entsprechend lokalisiert haben, müssen Sie Ihre /etc/nginx/nginx.conf bearbeiten Konfigurationsdatei, um ModSecurity mit Ihrem Nginx-Webserver zum Laufen zu bringen.

ModSecurity in nginx.conf aktivieren

Zuerst müssen Sie load_module angeben und Pfad zu Ihrem Modsecurity-Modul.

Öffnen Sie nginx.conf mit jedem Texteditor. Für das Tutorial wird nano verwendet:

sudo nano /etc/nginx/nginx.conf

Fügen Sie als Nächstes die folgende Zeile zur Datei ganz oben hinzu:

load_module modules/ngx_http_modsecurity_module.so;

Wenn Sie das Modul woanders gefunden haben, achten Sie darauf, den vollständigen Pfad anzugeben.

Fügen Sie nun den folgenden Code unter HTTP {} hinzu Abschnitt wie folgt:

modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/modsec-config.conf;

NUR Beispiel:

Wenn Sie das Modul woanders gefunden haben, achten Sie darauf, den vollständigen Pfad anzugeben.

Speichern Sie die nginx.conf Datei (STRG+O), Beenden Sie dann (STRG+X) .

Verzeichnis und Dateien für ModSecurity erstellen und konfigurieren

Sie müssen ein Verzeichnis zum Speichern der Konfigurationsdateien und zukünftigen Regeln erstellen, OWASP CRS für das Tutorial.

Verwenden Sie den folgenden Befehl, um die Datei /etc/nginx/modsec zu erstellen Verzeichnis wie folgt:

sudo mkdir /etc/nginx/modsec/

Jetzt müssen Sie die ModSecurity-Beispielkonfigurationsdatei aus unserem geklonten GIT-Verzeichnis zurückkopieren:

sudo cp /usr/local/src/ModSecurity/modsecurity.conf-recommended /etc/nginx/modsec/modsecurity.conf

Öffnen Sie die Datei modsecurity.conf mit Ihrem bevorzugten Texteditor wie folgt:

sudo nano /etc/nginx/modsec/modsecurity.conf

Standardmäßig ist in der ModSecurity-Konfiguration die Regel-Engine als (DetectionOnly) angegeben , das mit anderen Worten ModSecurity ausführt und alle böswilligen Verhaltensweisen erkennt, aber keine Aktion blockiert oder verbietet und alle HTTP-Transaktionen protokolliert, die es kennzeichnet. Dies sollte nur verwendet werden, wenn Sie viele Fehlalarme haben oder die Sicherheitseinstellungen auf ein extremes Niveau erhöht haben und testen, ob Fehlalarme auftreten.

Um dieses Verhalten auf (ein) zu ändern , finden Sie Folgendes in Zeile 7 :

SecRuleEngine DetectionOnly

Ändern Sie die Zeile wie folgt, um ModSecurity zu aktivieren:

SecRuleEngine On

Jetzt müssen Sie Folgendes finden, das sich in Zeile 224 befindet :

# Log everything we know about a transaction.
SecAuditLogParts ABIJDEFHZ

Das ist nicht richtig und muss geändert werden. Ändern Sie die Zeile wie folgt:

SecAuditLogParts ABCEFHJKZ

Speichern Sie nun die modsecurity.conf Datei mit (STRG+O) Beenden Sie dann (STRG+X) .

Der nächste Teil besteht darin, die folgende Datei modsec-config.conf zu erstellen . Hier fügen Sie die modsecurity.conf hinzu Datei mit und später andere Regeln wie OWASP CRS , und wenn Sie WordPress verwenden, das WPRS CRS Regelsatz.

Verwenden Sie den folgenden Befehl, um die Datei zu erstellen und zu öffnen:

sudo nano /etc/nginx/modsec/modsec-config.conf

Sobald Sie sich in der Datei befinden, fügen Sie die folgende Zeile hinzu:

Include /etc/nginx/modsec/modsecurity.conf

Speichern Sie die modsec-config.conf Datei mit (STRG+O) dann (STRG+X) beenden.

Kopieren Sie zuletzt die unicode.mapping von ModSecurity Datei mit dem CP Befehl wie folgt:

sudo cp /usr/local/src/ModSecurity/unicode.mapping /etc/nginx/modsec/

Bevor Sie fortfahren, sollten Sie Ihren Nginx-Dienst mit dem folgenden Terminalbefehl testen:

sudo nginx -t

Wenn Sie alles richtig eingerichtet haben, sollten Sie die folgende Ausgabe erhalten:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Um die Änderungen live zu schalten, starten Sie Ihren Nginx-Dienst mit dem Befehl systemctl neu:

sudo systemctl restart nginx

Installieren Sie den OWASP-Kernregelsatz für ModSecurity

ModSecurity allein schützt Ihren Webserver nicht, und Sie müssen Regeln haben. Eine der bekanntesten, respektiertesten und bekanntesten Regeln ist der OWASP CRS-Regelsatz. Die Regeln werden unter Webservern und anderen WAFs am häufigsten verwendet, und die meisten anderen ähnlichen Systeme basieren die meisten ihrer Regeln auf diesem CRS. Durch die Installation dieses Regelsatzes erhalten Sie automatisch einen hervorragenden Schutz gegen die meisten neuen Bedrohungen im Internet, indem böswillige Akteure erkannt und blockiert werden.

Mit dem wget-Befehl Laden Sie das OWASP CRS 3.3.2-Archiv herunter wie folgt:

wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.2.zip

Für diejenigen, die am Limit leben möchten, können Sie den nächtlichen Build herunterladen. Verwenden Sie die Nightly nur, wenn Sie bereit sind, CoreRuleSet Github regelmäßig neu zu kompilieren und auf Aktualisierungen zu überprüfen, und sicherer bei der Lösung von Problemen sind. Technisch gesehen kann das Nightly sicherer sein, aber möglicherweise Probleme verursachen.

Verwenden Sie für unerfahrene Benutzer die stabile Version und verwenden Sie nicht die untenstehende Version.

wget https://github.com/coreruleset/coreruleset/archive/refs/tags/nightly.zip

Installieren Sie das Paket entpacken falls Sie dies nicht auf Ihrem Server installiert haben:

sudo apt install unzip -y

Jetzt entpacken die master.zip wie folgt archivieren:

sudo unzip v3.3.2.zip -d /etc/nginx/modsec

Wie zuvor, wie die modsecurity.conf Beispielkonfiguration, OWASP CRS enthält eine Beispielkonfigurationsdatei, die Sie umbenennen müssen. Verwenden Sie am besten den CP Befehl und bewahren Sie ein Backup für die Zukunft auf, falls Sie erneut neu starten müssen.

sudo cp /etc/nginx/modsec/coreruleset-3.3.2/crs-setup.conf.example /etc/nginx/modsec/coreruleset-3.3.2/crs-setup.conf

Um die Regeln zu aktivieren, öffnen Sie die Datei /etc/nginx/modsec/modsec-config.conf Verwenden Sie erneut einen beliebigen Texteditor:

sudo nano /etc/nginx/modsec/modsec-config.conf

Sobald Sie sich wieder in der Datei befinden, fügen Sie die folgenden zwei zusätzlichen Zeilen hinzu:

Include /etc/nginx/modsec/coreruleset-3.3.2/crs-setup.conf
Include /etc/nginx/modsec/coreruleset-3.3.2/rules/*.conf

Speichern Sie die Datei (STRG+O) und beenden (STRG+X) .

Wie zuvor müssen Sie alle neuen Ergänzungen zu Ihrem Nginx-Dienst testen, bevor Sie ihn live schalten:

sudo nginx -t

Sie sollten die folgende Ausgabe erhalten, was bedeutet, dass alles korrekt funktioniert:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Starten Sie Ihren Nginx-Dienst neu, um die Änderungen wie folgt live zu schalten:

sudo systemctl restart nginx

Verwendung und Verständnis von OWASP CRS

OWASP CRS hat ziemlich viele Optionen, die Standardeinstellungen schützen jedoch sofort die meisten Server, ohne Ihre echten Besucher und gute SEO-Bots zu verletzen. Im Folgenden werden einige Bereiche zur Erläuterung behandelt. Weiteres Lesen wäre am besten, alle Optionen in den Konfigurationsdateien selbst zu untersuchen, da sie ziemlich viele Textdaten enthalten, um zu erklären, was sie sind.

Öffnen Sie Ihre CRS-setup.conf Datei wie folgt:

nano /etc/nginx/modsec/coreruleset-3.4-dev/crs-setup.conf

Beachten Sie, dass dies die Konfiguration der Dev-Version mit zusätzlichen Elementen im Vergleich zu Version 3.3 ist.

Von hier aus können Sie die meisten Ihrer OWASP CRS-Einstellungen ändern.

OWASP CRS-Bewertung

Um es aufzuschlüsseln, ModSecurity hat zwei Modi:

Anomalie-Bewertungsmodus

# -- [[ Anomaly Scoring Mode (default) ]] --
# In CRS3, anomaly mode is the default and recommended mode, since it gives the
# most accurate log information and offers the most flexibility in setting your
# blocking policies. It is also called "collaborative detection mode".
# In this mode, each matching rule increases an 'anomaly score'.
# At the conclusion of the inbound rules, and again at the conclusion of the
# outbound rules, the anomaly score is checked, and the blocking evaluation
# rules apply a disruptive action, by default returning an error 403.

Eigenständiger Modus

# -- [[ Self-Contained Mode ]] --
# In this mode, rules apply an action instantly. This was the CRS2 default.
# It can lower resource usage, at the cost of less flexibility in blocking policy
# and less informative audit logs (only the first detected threat is logged).
# Rules inherit the disruptive action that you specify (i.e. deny, drop, etc).
# The first rule that matches will execute this action. In most cases this will
# cause evaluation to stop after the first rule has matched, similar to how many
# IDSs function.

Anomaly Scoring ist im Allgemeinen für die meisten Benutzer der beste Modus.

Es gibt vier Paranoia-Stufen:

• Paranoia Stufe 1 – Standardstufe und für die meisten Benutzer empfohlen.
• Paranoia Stufe 2 – Nur für fortgeschrittene Benutzer.
• Paranoia Stufe 3 – Nur erfahrene Benutzer.
• Paranoia Stufe 4 – Überhaupt nicht zu empfehlen, außer in Ausnahmefällen.

# -- [[ Paranoia Level Initialization ]] ---------------------------------------
#
# The Paranoia Level (PL) setting allows you to choose the desired level
# of rule checks that will add to your anomaly scores.
#
# With each paranoia level increase, the CRS enables additional rules
# giving you a higher level of security. However, higher paranoia levels
# also increase the possibility of blocking some legitimate traffic due to
# false alarms (also named false positives or FPs). If you use higher
# paranoia levels, it is likely that you will need to add some exclusion
# rules for certain requests and applications receiving complex input.
#
# - A paranoia level of 1 is default. In this level, most core rules
#   are enabled. PL1 is advised for beginners, installations
#   covering many different sites and applications, and for setups
#   with standard security requirements.
#   At PL1 you should face FPs rarely. If you encounter FPs, please
#   open an issue on the CRS GitHub site and don't forget to attach your
#   complete Audit Log record for the request with the issue.
# - Paranoia level 2 includes many extra rules, for instance enabling
#   many regexp-based SQL and XSS injection protections, and adding
#   extra keywords checked for code injections. PL2 is advised
#   for moderate to experienced users desiring more complete coverage
#   and for installations with elevated security requirements.
#   PL2 comes with some FPs which you need to handle.
# - Paranoia level 3 enables more rules and keyword lists, and tweaks
#   limits on special characters used. PL3 is aimed at users experienced
#   at the handling of FPs and at installations with a high security
#   requirement.
# - Paranoia level 4 further restricts special characters.
#   The highest level is advised for experienced users protecting
#   installations with very high security requirements. Running PL4 will
#   likely produce a very high number of FPs which have to be
#   treated before the site can go productive.
#
# All rules will log their PL to the audit log;
# example: [tag "paranoia-level/2"]. This allows you to deduct from the
# audit log how the WAF behavior is affected by paranoia level.
#
# It is important to also look into the variable
# tx.enforce_bodyproc_urlencoded (Enforce Body Processor URLENCODED)
# defined below. Enabling it closes a possible bypass of CRS.

Testen Sie OWASP CRS auf Ihrem Server

Um zu testen, ob OWASP CRS auf Ihrem Server funktioniert, öffnen Sie Ihren Internetbrowser und verwenden Sie Folgendes:

https://www.yourdomain.com/index.html?exec=/bin/bash

Sie sollten einen 403 verbotenen Fehler erhalten Wenn nicht, wurde ein Schritt ausgelassen.

Das häufigste Problem besteht darin, DetectionOnly nicht zu ändern auf Ein, wie zuvor im Tutorial behandelt.

Umgang mit Fehlalarmen und dem Ausschluss benutzerdefinierter Regeln

Eine der oft nie endenden Aufgaben ist der Umgang mit Fehlalarmen. ModSecurity und OWASP CRS leisten zusammen großartige Arbeit, aber es geht auf Kosten Ihrer Zeit, aber angesichts des Schutzes, den Sie erhalten, ist es das wert. Für den Anfang ist es die goldene Regel, die Paranoia-Stufe niemals hoch zu treiben.

Eine gute Faustregel ist, das Regelwerk einige Wochen bis Monate mit kaum Fehlalarmen laufen zu lassen, dann zum Beispiel Paranoia Level 1 auf Paranoia Level 2 zu erhöhen, damit man nicht gleichzeitig mit einer Tonne überschwemmt wird.

Falsch-Positive-bekannte Anwendungen ausgenommen

Modsecurity kann standardmäßig alltägliche Aktionen, die zu Fehlalarmen führen, wie folgt auf die Whitelist setzen:

#SecAction \
# "id:900130,\
#  phase:1,\
#  nolog,\
#  pass,\
#  t:none,\
#  setvar:tx.crs_exclusions_cpanel=1,\
#  setvar:tx.crs_exclusions_dokuwiki=1,\
#  setvar:tx.crs_exclusions_drupal=1,\
#  setvar:tx.crs_exclusions_nextcloud=1,\
#  setvar:tx.crs_exclusions_phpbb=1,\
#  setvar:tx.crs_exclusions_phpmyadmin=1,\
#  setvar:tx.crs_exclusions_wordpress=1,\
#  setvar:tx.crs_exclusions_xenforo=1"

Um beispielsweise WordPress, phpBB und phpMyAdmin zu aktivieren Wenn Sie alle drei verwenden, kommentieren Sie die Zeilen aus und verlassen Sie die (1) Nummer intakt, ändern Sie die anderen Dienste, die Sie nicht verwenden, z. B. Xenforo auf (0) da Sie diese Regeln nicht auf die Whitelist setzen möchten.

Beispiel unten:

SecAction \
 "id:900130,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:tx.crs_exclusions_cpanel=0,\
  setvar:tx.crs_exclusions_dokuwiki=0,\
  setvar:tx.crs_exclusions_drupal=0,\
  setvar:tx.crs_exclusions_nextcloud=0,\
  setvar:tx.crs_exclusions_phpbb=1,\
  setvar:tx.crs_exclusions_phpmyadmin=1,\
  setvar:tx.crs_exclusions_wordpress=1,\
  setvar:tx.crs_exclusions_xenforo=0"

Sie können auch die Syntax ändern, was sauberer wäre. Zum Beispiel:

SecAction \
 "id:900130,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:tx.crs_exclusions_phpbb=1,\
  setvar:tx.crs_exclusions_phpmyadmin=1,\
  setvar:tx.crs_exclusions_wordpress=1"

Wie Sie sehen, wurden die nicht benötigten Optionen entfernt und (“) hinzugefügt am Ende von WordPress für die korrekte Syntax.

Ausschließen von Regeln in Before CRS

Um mit benutzerdefinierten Ausschlüssen umzugehen, müssen Sie zunächst den Namen aus REQUEST-900-EXCLUSION-RULES-BEFORE-CRS-SAMPLE.conf ändern Datei mit dem cp-Befehl wie folgt:

sudo cp /etc/nginx/modsec/coreruleset-3.4-dev/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example /etc/nginx/modsec/coreruleset-3.4-dev/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

Denken Sie daran, dass beim Erstellen von Ausschlussregeln jede id: haben und eindeutig sein muss. Andernfalls erhalten Sie beim Testen Ihres Nginx-Dienstes eine Fehlermeldung. Beispiel "id:1544,phase:1,log,allow,ctl:ruleEngine=off" , kann die ID 1544 nicht für eine zweite Regel verwendet werden.

Beispielsweise werden einige REQUEST_URIs falsch positive Ergebnisse hervorrufen. Das folgende Beispiel ist zwei mit Google Pagespeed Beacon und WMUDEV-Plugin für WordPress:

SecRule REQUEST_URI "@beginsWith /wp-load.php?wpmudev" "id:1544,phase:1,log,allow,ctl:ruleEngine=off"

SecRule REQUEST_URI "@beginsWith /ngx_pagespeed_beacon" "id:1554,phase:1,log,allow,ctl:ruleEngine=off"

Wie Sie sehen können, wird jede URL, die mit dem Pfad beginnt, automatisch zugelassen.

Eine weitere Option ist das Setzen von IP-Adressen auf die Whitelist. Dazu gibt es einige Möglichkeiten:

SecRule REMOTE_ADDR "^195\.151\.128\.96" "id:1004,phase:1,nolog,allow,ctl:ruleEngine=off"
## or ###
SecRule REMOTE_ADDR "@ipMatch 127.0.0.1/8, 195.151.0.0/24, 196.159.11.13" "phase:1,id:1313413,allow,ctl:ruleEngine=off"

Das @ipMatch kann für Subnetze umfassender verwendet werden. Wenn Sie ein Subnetz ablehnen möchten oder IP-Adresse ändern, erlauben zu leugnen. Mit etwas Know-how können Sie auch Blacklists und Whitelists erstellen und diese mit fail2ban konfigurieren . Die Möglichkeiten können oft endlos sein.

Ein letztes Beispiel besteht darin, nur Regeln zu deaktivieren, die falsch positive Ergebnisse auslösen, und nicht den gesamten Pfad auf die weiße Liste zu setzen, wie Sie im ersten REQUEST_URI-Beispiel gesehen haben. Dies erfordert jedoch mehr Zeit und Tests. Sie möchten beispielsweise die Regeln 941000 entfernen und 942999 aus Ihrem /admin/-Bereich, da dieser weiterhin falsche Bans und Blockierungen für Ihr Team auslöst, finden Sie in Ihrer Modsecurity-Protokolldatei die Regel-ID und deaktivieren Sie dann nur diese ID mit RemoveByID wie im folgenden Beispiel:

SecRule REQUEST_FILENAME "@beginsWith /admin" "id:1004,phase:1,pass,nolog,ctl:ruleRemoveById=941000-942999"

Beispiele finden Sie auf der ModSecurity-GIT-Wiki-Seite; LinuxCapable wird in Zukunft ein Tutorial zu diesem Teil erstellen, da es ziemlich viel zu behandeln gibt.

Optional – Projekt-Honeypot einbeziehen

Project Honey Pot ist das erste und einzige verteilte System zur Identifizierung von Spammern und den Spambots, die sie verwenden, um Adressen von Ihrer Website zu entfernen. Mit dem Project Honey Pot-System können Sie Adressen mit benutzerdefinierten Tags für die Uhrzeit und die IP-Adresse eines Besuchers Ihrer Website installieren. Wenn eine dieser Adressen beginnt, E-Mails zu erhalten, können wir erkennen, dass es sich bei den Nachrichten um Spam handelt, den genauen Zeitpunkt, an dem die Adresse erfasst wurde, und die IP-Adresse, die sie erfasst hat.

ModSecurity kann die Option haben, Project Honeypot zu integrieren, das die Datenbank abfragt und alle Adressen blockiert, die auf der HoneyPot-Blacklist stehen. Beachten Sie, dass die Verwendung dieser Option zu Fehlalarmen führen kann, aber insgesamt wird sie im Vergleich zu ähnlichen Alternativen als sehr zuverlässig angesehen.

Schritt 1. Erstellen Sie ein kostenloses Konto.

Schritt 2. Nachdem Sie sich registriert und angemeldet haben, finden Sie auf dem Dashboard die Zeile (Your http:BL API key) und klicken Sie auf einen kaufen .

Schritt 3. Kehren Sie zur Datei CRS-setup.conf zurück, indem Sie sie mit einem Texteditor öffnen:

sudo nano /etc/nginx/modsec/coreruleset-3.3.3/crs-setup.conf

Schritt 4. Suchen Sie die Zeile, die mit #SecHttpBlKey, beginnt das ist auf Zeile 629.

#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"

Schritt 5. Ändern Sie den SecHttpBlKey XXXXXXXXXXXXXXXXX mit Ihrem Schlüssel von Project HoneyPot.

Beispiel:

SecHttpBlKey amhektvkkupe

Schritt 6. Kommentieren Sie als Nächstes alle Zeilen aus, um die Regel zu aktivieren. Um eine Regel zu deaktivieren, statt (1), setzen Sie (0) stattdessen, wenn Sie eine der Regeln deaktiviert haben möchten. Standardmäßig ist block_search_ip=0 für Suchmaschinen-Bots, aktivieren Sie dies nicht, es sei denn, Sie möchten, dass Bing, Google und andere gute Bots auf Ihre Website kommen.

SecHttpBlKey amhektvkkupe
SecAction "id:900500,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:tx.block_search_ip=0,\
  setvar:tx.block_suspicious_ip=1,\
  setvar:tx.block_harvester_ip=1,\
  setvar:tx.block_spammer_ip=1"

Note, do not use amhektvkkupe. Use your key instead!

Step 7. Test Nginx to make sure no errors have occurred with the following:

sudo nginx -t

Example output if all correct:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Now restart your Nginx service:

sudo systemctl restart nginx

WordPress WPRS Rule Set for ModSecurity

Another option for WordPress users is to install and run alongside your OWASP CRS rule set, a well-known project entitled WPRS rule set. As this is optional and isn’t for everyone, the tutorial will not cover it in this section. However, if you would like to install this for extra protection if you use WordPress on your server, please visit our tutorial on Installing WordPress ModSecurity Rule Set (WPRS).

Create ModSecurity LogRotate File

Given how many lines and information it can log, ModSecurity will grow quite quickly. As you are compiling the module and it isn’t installed through any official repository from Debian, you will need to create your own log rotate file.

First, create and open your ModSecurity rotate file modsec :

sudo nano /etc/logrotate.d/modsec

Add the following code:

/var/log/modsec_audit.log
{
        rotate 31
        daily
        missingok
        compress
        delaycompress
        notifempty
}

This will keep logs for 31 days. If you prefer to have less, change 31 to say 7 days equally a week’s worth of logs. You should be rotating daily for ModSecurity. If you need to review the log files having a weekly file will be a disaster to sift through, given how large it will be.