Installieren Sie ModSecurity für Nginx bei Debian/Ubuntu
Sie, als Betreiber eines vom Internet zugänglichen Speichermediums, sind für den Schutz der darauf befindlichen daten und für die Verbreitung von Daten, über dieses Speichermedium, verantwortlich.
Das bedeutet, wenn sich jemand unerlaubt zugriff auf Ihren Server verschafft, können Sie dafür zur Verantwortung gezogen werden, wenn dadurch einem Dritten Schaden entsteht.
Um Ihren Server und Ihre Daten so gut als möglich zu schützen, nutzen sie alle Möglichkeiten die es gibt. Eine davon ist ModSecurity. Im Folgenden beschreibe ich wie Sie ModSecurity installieren können und Ihr Dolibarr einbinden. Aufgebaut wird auf einen Server auf dem ein Ubuntu oder Debian Betriebssystem installiert ist, zusätzlich gehe ich davon aus das Sie Dolibarr entsprechend der Installationsanleitung von hier oder hier installiert haben.
ModSecurity lässt sich als dynamisches Modul in Nginx integrieren, mit dem Sie den Quellcode einzelner Module kompilieren können, ohne Nginx selbst zu kompilieren.
Die Nginx-Binärdatei muss mit dem Argument --with-compat kompiliert werden, wodurch dynamische Module mit Ihrer vorhandenen Nginx-Binärdatei binärkompatibel werden. Allerdings wird nicht jede Nginx-Binärdatei, die aus dem standardmäßigen Debian/Ubuntu-Repository geliefert wird, mit dem Argument --with-compat kompiliert. Zur Vereinfachung können wir die neueste Version von Nginx aus dem PPA ondrej/nginx-mainline installieren, das von einem Debian-Entwickler gepflegt wird.
Das nachfolgende ist nur für 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.
Im Laufe der Installation werden Sie gefragt ob die nginx-conf aktualisiert werden soll ( *** nginx.conf (Y/I/N/O/D/Z) [default=N] ? n ), diese Frage beantworten Sie bitte mit n für nein (no).
sudo add-apt-repository ppa:ondrej/nginx-mainline -y
sudo apt update
sudo apt install nginx-core nginx-common nginx nginx-full
Bei der Standard Installation von Nginx ist nur die - binare Repository - aktiviert. Sie benötigen allerdings auch die - source code repository – um Nginx source Code herunterladen zu können.
Dafür editieren Sie bitte die Nginx mainline repository – Datei
sudo nano /etc/apt/sources.list.d/ondrej-ubuntu-nginx-mainline-*.list
entfernen Sie das # zeichen vor deb-src http://ppa.launchpad…
Das nachfolgende ist nur für Debian
Wenn Sie Debian 10 oder Debian 11 verwenden, führen Sie die folgenden Befehle aus, um die neueste Version von Nginx zu installieren.
Im Laufe der Installation werden Sie gefragt ob die nginx-conf aktualisiert werden soll ( *** nginx.conf (Y/I/N/O/D/Z) [default=N] ? n ), diese Frage beantworten Sie bitte mit n für nein (no).
curl -sSL https://packages.sury.org/nginx-mainline/README.txt | sudo bash -x
sudo apt update
sudo apt install nginx-core nginx-common nginx nginx-full
Bei der Standard Installation von Nginx ist nur die - binare Repository - aktiviert. Sie benötigen allerdings auch die - source code repository – um Nginx source Code herunterladen zu können.
Dafür editieren Sie bitte 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
Ab jetzt sind die Befehle wieder für beide Betriebssysteme identisch
Nach dem Speichern machen Sie bitte ein Update
sudo apt update
Überprüfen Sie die Configuration von Nginx
nginx -V
Sie werden feststellen das alle Nginx binaries im PPA mit dem --with-compat Argument kompiliert wurden
Download Nginx Source Packet
Natürlich müssen Sie nicht Nginx komilieren, jedoch benötigen Sie den Nginx Source Code um das ModSecurity dynamic module zu kompilieren.
Führen Sie den nachfolgenden Befehl aus um den Nginx source Code im verzeichnis /usr/local/src/ ausführen zu können.
Das rot geschriebene mit Ihrem USERNAMEN ersetzen
sudo chown USERNAMEN:USERNAMEN /usr/local/src/ -R
mkdir -p /usr/local/src/nginx
Arbeiten Sie in der Nginx source Directory
cd /usr/local/src/nginx/
Mit dem folgenden Befehlen laden Sie das Nginx source Packet herunter
sudo apt install dpkg-dev
apt source nginx
Sollten Sie die nachfolgende Fehlermeldung bekommen, können Sie diese einfach ignorieren
W: Download is performed unsandboxed as root as file ‚nginx_1.19.5.orig.tar.gz‘ couldn’t be accessed by user ‚_apt‘. - pkgAcquire::Run (13: Permission denied)
Überprüfen Sie die geladenen Dateien
ls
Sie sollten etwas ähnliches wie folgende Zeilen sehen
nginx-1.21.6
nginx_1.21.6-1+ubuntu20.04.1+deb.sury.org+2.debian.tar.xz
nginx_1.21.6-1+ubuntu20.04.1+deb.sury.org+2.dsc
nginx_1.21.6.orig.tar.gz
nginx_1.21.6.orig.tar.gz.asc
Stellen Sie sicher, dass die source Code Version dieselbe wie die Binäre Version ist
sudo nginx -v
Install libmodsecurity3
Nun können Sie libmodsecurrity Installieren, libmodsecurrity stellt die Bibliothek zur Filterung Ihrer http Webanwendungen bereit.
Zuerst klonen Sie den source Code von Github
Dazu Installieren Sie erst git
sudo apt install git
und führen dann den clone befehl aus.
git clone --depth 1 -b v3/master --single-branch https://github.com/SpiderLabs/ModSecurity /usr/local/src/ModSecurity/
wechseln Sie für die weitere Bearbeitung ins ModSecurity Verzeichnis
cd /usr/local/src/ModSecurity/
und Installieren Sie die benötigten Bibliotheken
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 `zlib1g`
Jetzt installieren Sie noch die zusätzlichen Module
git submodule init
git submodule update
Jetzt konfigurieren Sie die Umgebung
./build.sh
Sollten Sie nachfolgende Fehlermeldung sehen – können Sie diese ignorieren
fatal: No names found, cannot describe anything.
./configure
Kompilieren Sie den source Code mit folgendem Befehl. In der Grundeinstellung arbeitet „ make „ mit einem Prozessor Kern. In Abhängigkeit wie viele Kerne Sie Ihrem Server zur Verfügung gestellt haben, ändern Sie bitte die Anzahl der Kerne im Befehl
Das kann ein bisschen dauern, abhängig von Ihrer Anzahl an CPU-Kernen und der Menge an RAM Speicher.
Passen Sie das ROT geschriebene Ihren Daten an
make -j3
Fehlerbehebung
Error 1
Wenn Sie diese Fehlermeldung sehen liegt das wahrscheinlich daran das Ihr Server zu wenig RAM-Speicher hat
g++: internal compiler error: Killed (program cc1plus)
Bitte stellen Sie Ihrem Server mehr RAM-Speicher zur verfügung.
Error #2
Wenn Sie folgenden fehler, beim kompilieren von ModSecurity sehen
utils/geo_lookup.cc: In member function ‘bool modsecurity::Utils::GeoLookup::lookup(const string&, modsecurity::Transaction*, std::function<bool(int, const std::__cxx11::basic_string<char>&)>) const’:
utils/geo_lookup.cc:124:32: error: invalid conversion from ‘const MMDB_s*’ to ‘MMDB_s*’ [-fpermissive]
r = MMDB_lookup_string(&mmdb, target.c_str(), &gai_error, &mmdb_error);
liegt das wahrscheinlich daran das Sie eine veraltete Version von libmaxminddb-dev instaliert haben. Sie können dieses Packet löschen und gegen eine aktuelle ersetzen.
Löschen der alten libmaxminddb-dev
sudo apt remove libmaxminddb-dev
Installieren von libgeoip-dev, das ist eine Alternative zu libmaxminddb-dev
sudo apt install libgeoip-dev
jetzt können Sie ModSecurity erneut kompilieren. Bitte die Anzakl der CPU Kerne anpassen
Passen Sie das ROT geschriebene Ihren Daten an
make clean
./configure
make -j3
und die Binary installieren
Wenn der make Befehl fehlerfrei abgeschlossen ist, installieren Sie die binary
sudo make install
Installieren von ModSecurity v3
Klonen Sie ModSecurity Nginx Connector von der Git repository.
git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git /usr/local/src/ModSecurity-nginx/
Wächseln Sie in Ihren Nginx Source Ortner
Passen Sie das ROT geschriebene Ihren Daten an
nginx -v
cd /usr/local/src/nginx/nginx-1.21.6
Installieren Sie die angepassten Nginx Abhängigkeiten
sudo apt build-dep nginx
sudo apt install uuid-dev
Als nächstes konfigurieren Sie die Umgebung mit dem folgenden Befehl. Wir werden Nginx selbst nicht kompilieren, sondern nur das ModSecurity Nginx Connector-Modul kompilieren. Das Flag --with-compat macht das Modul binärkompatibel mit Ihrer vorhandenen Nginx-Binärdatei.
./configure --with-compat --add-dynamic-module=/usr/local/src/ModSecurity-nginx
Erstellen Sie das ModSecurity Nginx Connector Modul
make modules
Das Modul wird gespeichert als objs/ngx_http_modsecurity_module.so.
Kopieren Sie es in Ihren Odrner
sudo cp objs/ngx_http_modsecurity_module.so /usr/share/nginx/modules/
Laden Sie das ModSecurity v3 Nginx Connector Modul
Bearbeitungen Sie die nginx.conf
sudo nano /etc/nginx/nginx.conf
und fügen vor dem events nachfolgende Zeile ein
load_module modules/ngx_http_modsecurity_module.so;
In Ihre conf.d/Konfigurations.conf in diesem Fall für Dolibarr
nano /etc/nginx/conf.d/dolibarr.conf
fügen Sie nach → listen [::]:443 ssl http2;
folgende Zeilen ein
modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/main.conf;
Speichern und Schließen Sie die Datei.
Die vHosts Konfigurationsdatei erweitern Sie ebenfalls
nano /etc/nginx/conf.d/http.conf
und fügen nach → listen [::]:80 default_server;
folgende Zeilen ein
modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/main.conf;
Speichern und Schließen Sie die Datei.
Als nächstes erstellen Sie einen neuen Ordner → /etc/nginx/modsec/
sudo mkdir /etc/nginx/modsec/
in diesen Kopieren Sie die ModSecurity Konfigurations Datei,
sudo cp /usr/local/src/ModSecurity/modsecurity.conf-recommended /etc/nginx/modsec/modsecurity.conf
und bearbeiten die Konfigurationsdatei im Anschluss.
sudo nano /etc/nginx/modsec/modsecurity.conf
Suchen und ersetzen Sie folgende Zeilen
SecRuleEngine DetectionOnly -> SecRuleEngine On
SecAuditLogParts ABIJDEFHZ -> SecAuditLogParts ABCEFHJKZ
SecResponseBodyAccess On -> SecResponseBodyAccess Off
Speichern und verlassen Sie die Datei
Jetzt erstellen Sie die main.conf
sudo nano /etc/nginx/modsec/main.conf
fügen folgende Zeile ein.
Speichen und schließen Sie die Datei im Anschluss
Include /etc/nginx/modsec/modsecurity.conf
Sie benötigen auch die unicode.mapping datei, die Sie jetzt Kopieren
sudo cp /usr/local/src/ModSecurity/unicode.mapping /etc/nginx/modsec/
nun testen Sie die Nginx Konfiguration
sudo nginx -t
Error #5
Sollten Sie diese Fehlermeldung bekommen
nginx: [warn] duplicate extension "woff", content type: "font/woff2", previous content type: "font/woff" in /etc/nginx/mime.types:29
bearbeiten Sie die mime.types Datei
nano /etc/nginx/mime.types
Suchen und ersetzen Sie folgende Zeile
font/woff2 woff; -> font/woff2 woff2;
speichern und schließen
nun testen Sie die Nginx Konfiguration
sudo nginx -t
Wenn es keine Fehler gab starten Sie Nginx neu
sudo systemctl restart nginx
Aktiviere OWASP Core Regel Set
Um Ihre Webanwendung zu schützen, müssen Sie Regeln festlegen um Angreifer zu erkennen und diese zu Blocken.
Für den Anfing ist es am besten ein vordefiniertes Archiv von Regeln zu verwenden
Das OWASP Core Rule Set ist das Standard Set für die Verwendung von ModSecurity
Laden Sie das Aktuelle OWASP CRS von GitHub herunter
Die rote Versionsnummer passen Sie bitte der Aktuellen an
wget https://github.com/coreruleset/coreruleset/archive/v3.3.2.tar.gz
entpacken Sie die Datei und verschieben sie in den Ordner /etc/nginx/modsec/
Die rote Versionsnummer passen Sie bitte der Aktuellen an
tar xvf v3.3.2.tar.gz
sudo mv coreruleset-3.3.2/ /etc/nginx/modsec/
Benennen sie die crs-setup.conf.example Datei um in crs-setup.conf
Die rote Versionsnummer passen Sie bitte der Aktuellen an
sudo mv /etc/nginx/modsec/coreruleset-3.3.2/crs-setup.conf.example /etc/nginx/modsec/coreruleset-3.3.2/crs-setup.conf
Jetzt bearbeiten Sie die Konfigurationsdatei
sudo nano /etc/nginx/modsec/main.conf
und fügen folgende Zeilen ein
Die rote Versionsnummer passen Sie bitte der Aktuellen an
Include /etc/nginx/modsec/coreruleset-3.3.2/crs-setup.conf
Include /etc/nginx/modsec/coreruleset-3.3.2/rules/*.conf
Im Anschluss testen Sie die Nginx Konfiguration
sudo nginx -t
wenn dieser Test funktioniert hat starten Sie Nginx als Service neu
sudo systemctl restart nginx
um zu verhindern das Ihre Logdatei bis ins unendliche wächst legen Sie eine Regel fest nach der Ihre Logdatei sich Täglich erneuert und nur die Letzten 14 Einträge erhalten bleiben.
Erstellen Sie dafür /logrotate.d/modsecurity
sudo nano /etc/logrotate.d/modsecurity
und fügen nachfolgendes ein
/var/log/modsec_audit.log
{
rotate 14
daily
missingok
compress
delaycompress
notifempty
}
Speichern und schließen
Nginx erneut als Starten um die änderungen zu aktivieren
sudo systemctl restart nginx
Handling Falscher Ereignisse
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 falsch positive Ergebnisse angezeigt.
Zum Beispiel verbietet das CRS standardmäßig das Einfügen von Unix-Befehlen wie die Eingabe von sudo auf einer Webseite, was in meinem Blog ziemlich üblich ist. Um Fehlalarme zu eliminieren, müssen Sie dem CRS Regelausschlüsse hinzufügen.
Es gibt einige vorgefertigte, anwendungsspezifische Ausnahmen, die mit OWASP CRS geliefert werden. Bearbeiten Sie die dafür Datei crs-setup.conf.
Die rote Versionsnummer passen Sie bitte der Aktuellen an
sudo nano /etc/nginx/modsec/coreruleset-3.3.2/crs-setup.conf
Gehen Sie zum Abschnitt Anwendungsspezifische Regelausschlüsse und suchen Sie die folgenden Zeilen.
Suchen sie nach → Application Specific Rule Exclusions
Gehen Sie nach unten bis Sie diesen Eintrag finden
#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"
Um diese Einträge aus zu schließen entfernen Sie alle # Zeichen von SecAction \ bis t:none,\
Wenn Sie jetzt zum Beispiel WordPress ausschließen möchten, entfernen Sie einfach das # zeichen vor dem Eintrag → # setvar:tx.crs_exclusions_wordpress=1,\
Die Zeichenfolge ,\ am Ende der Ziele zeigt an das diese Ziele eine folge Zeile hat
Wenn Sie also nur, wie im Beispiel oben, WordPress anschließen wollen, müssen auch die Zeichen ,\ am Ende löschen. Sollte noch zusätzlich z.B. eine Nextcloud über diesen Server laufen dann löschen Sie auch das # Zeichen vor diesem Eintrag. Lassen aber die Zeichen ,\ am Ende stehen da WordPress danach folgt.
Beachten Sie, dass, wenn Sie mehrere Anwendungen wie (WordPress, Nextcloud, Drupal, Dolibarr usw.) auf demselben Server installiert haben, die oben genannten Regelausschlüsse auf alle Anwendungen angewendet werden.
Um jetzt Dolibarr in die Regeln ein zu beziehen, muss ein neuer Eintrag erstellt werden ohne ,\ am ende da Sie nur Dolibarr ausschließen.
SecAction \
"id:900130,\
phase:1,\
nolog,\
pass,\
t:none,\
setvar:tx.crs_exclusions_dolilibarr=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_wordpress=1,\
# setvar:tx.crs_exclusions_xenforo=1"
Für Dolibarr müssen Sie noch zusätzlich einen weiteren Regel Ausschluss bearbeiten.
Suchen Sie dafür den Eintrag
# -=[ Anomaly Mode: Overall Transaction Anomaly Score ]=-
Und fügen vor jedem eintrag bis einschließlich
setvar:'tx.inbound_anomaly_score=%{tx.anomaly_score}'"
ein # Zeichen ein
# -=[ Anomaly Mode: Overall Transaction Anomaly Score ]=-
#
#SecRule TX:ANOMALY_SCORE "@ge %{tx.inbound_anomaly_score_threshold}" \
# "id:949110,\
# phase:2,\
# deny,\
# t:none,\
# log,\
# msg:'Inbound Anomaly Score Exceeded (Total Score: %{TX.ANOMALY_SCORE})',\
# tag:'application-multi',\
# tag:'language-multi',\
# tag:'platform-multi',\
# tag:'attack-generic',\
# ver:'OWASP_CRS/3.3.2',\
# severity:'CRITICAL',\
# setvar:'tx.inbound_anomaly_score=%{tx.anomaly_score}'"
Dies ist nötig da ModSecurity sonst eine Änderung von Sicherheitsrelevanten Einträgen in Dolibarr nicht mehr zugelassen wird. Sie könnten zum Beispiel Ihr Passwort oder das von Nutzern nicht mehr ändern. Das anlegen von neuen Benutzern ist ebenfalls nicht mehr möglich.
Sie können, die oben beschriebenen, Einstellungen durchführen um Sicherheitsrelevante Änderungen durch zu führen und sie, als zusätzliche Absicherung, danach wieder zurücksetzen.
Um die Sicherheitsrisiken zu minimieren, sollten Sie einen Regelausschluss nur für eine Anwendung aktivieren. Wechseln Sie dazu in das Verzeichnis /etc/nginx/modsec/coreruleset-3.3.*/rules/
Die rote Versionsnummer passen Sie bitte der Aktuellen an
cd /etc/nginx/modsec/coreruleset-3.3.2/rules
benennen Sie REQUEST-900-EXCLUSION-RULES-BEFORE-CRS um
sudo mv REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
und bearbeiten Sie die Datei
sudo nano REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
Fügen Sie am Ende dieser Datei die folgende Zeile hinzu. Wenn Ihr WordPress die Unterdomäne blog.yourdomain.com verwendet und der vom Browser des Besuchers gesendete Anforderungsheader diese Unterdomäne enthält, wendet ModSecurity die Regelausschlüsse für WordPress an.
Das rot geschriebene passen Sie bitte an Ihre Daten an
In unserm Fall haben Sie Dolibarr hinzugefügt und diese Regel wird nun unter REQUEST-900 übernommen
SecRule REQUEST_HEADERS:Host "@streq dolibarr.yourdomain.com" "id:1000,phase:1,setvar:tx.crs_exclusions_dolibarr=1"
Weitere Regeln wie zum Beispiel Ihr Blog den Sie auf WordPress am selben Server laufen haben können Sie so freigeben. Beachten Sie bitte das weitere Einträge auch unter sudo nano /etc/nginx/modsec/coreruleset-3.3.2/crs-setup.conf angepasst werden müssen
SecRule REQUEST_HEADERS:Host "@streq blog.yourdomain.com" "id:1001,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:1002,phase:1,setvar:tx.crs_exclusions_nextcloud=1"
Speichern und schließen Sie die Datei und testen Sie Nginx
sudo nginx -t
War der Test fehlerfrei starten Sie Nginx neu
sudo systemctl reload nginx
(Optional) Integation von Project Honeypot bei ModSecurity
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, sind die Auswirkungen 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 den Link Get One, um einen Zugriffsschlüssel für die HTTP-Blacklist anzufordern.
Wenn das erledigt ist bearbeiten Sie wieder die crs-setup.conf
Die rote Versionsnummer passen Sie bitte der Aktuellen an
sudo nano /etc/nginx/modsec/coreruleset-3.3.2/crs-setup.conf
Suchen Sie folgende 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"
Diese ändern Sie wie folgt und ersetzen die roten XXXX gegen den, bei Honeypot, erhaltenen HTTPBL API key
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"
Beachten Sie, dass block_search_ip auf 0 (deaktiviert) gesetzt werden sollte, wenn Sie Suchmaschinen-Crawler nicht blockieren möchten. Im Fall von Dolibarr, das vorwiegend betriebsintern Verwendung findet und nicht einer breiten Masse zugänglich gemacht wird, belass ich es bei 1 (aktiviert). Ihren Blog oder eine Webseite möchten Sie jedoch, in den meisten Fällen, von Suchmaschinen gelistet werden.
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. (wenn 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.
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.
Das rot geschriebene passen Sie bitte an Ihre Daten an
curl -i -s -k -X $'GET' 'https://yourdomain.com/?IP=134.119.218.243'
Ihr Webserver sollte eine verbotene 403-Antwort zurückgeben, da die IP-Adresse bei Project Honeypot gelistet ist.
Wenn der Test erfolgreich war, können Sie die eingefügte Zeile aus der main.conf Datei wieder entfernen
sudo nano /etc/nginx/modsec/main.conf
Upgrading Nginx
Wenn Sie Dolibarr mit meiner Anleitung Installiert haben, dann haben Sie auch eine Automatisierte Server Aktualisierung mit Installiert.
Um jetzt zu verhindern das Ihr Nginx dynamiy modul eine andere Version als Nginx binary hat verhindern Sie zuerst das Nginx beim Update aktualisiert wird wenn Sie den Befehl zum upgrade ausführen.
Dies kann durch den folgenden Befehl erreicht werden
sudo apt-mark hold nginx
Wenn Sie nun den Befehl sudo apt-get dist-upgrade ausführen und der Paketmanager Ihnen mitteilt, dass das Nginx-Paket vom Upgrade zurückgehalten wird, bedeutet dies, dass eine neue Nginx-Version verfügbar ist.
Nun Sie müssen das neue Nginx-Quellpaket herunterladen und das ModSecurity-Modul erneut kompilieren. Verschieben Sie das neu kompilierte ModSecurity-Modul in das Verzeichnis /usr/share/nginx/modules/. Im Grunde bedeutet das, dass Sie alles im Verzeichnis /usr/local/src/ entfernen müssen (sudo rm /usr/local/src/* -rf ) und Schritt 2 und Schritt 4 erneut durchlaufen müssen.
Gehen Sie wie folgt vor
Löschen Sie alles im Verzeichnis /usr/local/src/
sudo rm /usr/local/src/* -rf
Führen Sie den nachfolgenden Befehl aus um den Nginx source Code im verzeichnis /usr/local/src/ ausführen zu können.
Das rot geschriebene mit Ihrem USERNAMEN ersetzen
sudo chown USERNAMEN: USERNAMEN /usr/local/src/ -R
mkdir -p /usr/local/src/nginx
Arbeiten Sie in der Nginx source Directory
cd /usr/local/src/nginx/
Mit dem folgenden Befehlen laden Sie das Nginx source Packet herunter
sudo apt install dpkg-dev
apt source nginx
Sollten Sie die nachfolgende Fehlermeldung bekommen, können Sie diese einfach ignorieren
W: Download is performed unsandboxed as root as file ‚nginx_1.21.6.orig.tar.gz‘ couldn’t be accessed by user ‚_apt‘. - pkgAcquire::Run (13: Permission denied)
Überprüfen Sie die geladenen Dateien
ls
Sie sollten etwas ähnliches wie folgende Zeilen sehen
nginx-1.21.6
nginx_1.21.6-1+ubuntu20.04.1+deb.sury.org+2.debian.tar.xz
nginx_1.21.6-1+ubuntu20.04.1+deb.sury.org+2.dsc
nginx_1.21.6.orig.tar.gz
nginx_1.21.6.orig.tar.gz.asc
Stellen Sie sicher, dass die source Code Version dieselbe wie die Binäre Version ist
`sudo nginx -v`
Klonen Sie ModSecurity Nginx Connector von der Git repository.
git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git /usr/local/src/ModSecurity-nginx/
Wächseln Sie in Ihren Nginx Source Ortner
Passen Sie das ROT geschriebene Ihren Daten an
nginx -v
cd /usr/local/src/nginx/nginx-NEUE.VERSIONS.NUMMER
Installieren Sie die angepassten Nginx Abhängigkeiten
sudo apt build-dep nginx
sudo apt install uuid-dev
Als nächstes konfigurieren Sie die Umgebung mit dem folgenden Befehl. Wir werden Nginx selbst nicht kompilieren, sondern nur das ModSecurity Nginx Connector-Modul kompilieren. Das Flag --with-compat macht das Modul binärkompatibel mit Ihrer vorhandenen Nginx-Binärdatei.
./configure --with-compat --add-dynamic-module=/usr/local/src/ModSecurity-nginx
Erstellen Sie das ModSecurity Nginx Connector Modul
make modules
Das Modul wird gespeichert als objs/ngx_http_modsecurity_module.so.
Kopieren Sie es in Ihren Odrner
sudo cp objs/ngx_http_modsecurity_module.so /usr/share/nginx/modules/
jetzt heben Sie den Aktualisierungs Stopp von Nginx auf.
sudo apt-mark unhold nginx
und führen das Upgrade aus
sudo apt upgrade nginx
wenn das abgeschlossen ist setzen Sie wieder den Aktualisierungs Stopp für Nginx
sudo apt-mark hold nginx
zur überprüfung können Sie mit diesem Befehl alle getopten Packete sehen
apt-mark showhold
Starten Sie Nginx neu
sudo systemctl restart nginx
Upgrade OWASP CRS
Laden Sie das Aktuelle OWASP CRS von GitHub herunter
Die rote Versionsnummer passen Sie bitte der Aktuellen an
wget https://github.com/coreruleset/coreruleset/archive/vNEUE.VERSIONS.NUMMER.tar.gz
entpacken Sie die Datei und verschieben sie in den Ordner /etc/nginx/modsec/
Die rote Versionsnummer passen Sie bitte der Aktuellen an
tar xvf vNEUE.VERSIONS.NUMMER.tar.gz
sudo mv coreruleset-NEUE.VERSIONS.NUMMER/ /etc/nginx/modsec/
Benennen sie die crs-setup.conf.example Datei um in crs-setup.conf
Die rote Versionsnummer passen Sie bitte der Aktuellen an
sudo mv /etc/nginx/modsec/coreruleset-NEUE.VERSIONS.NUMMER/crs-setup.conf.example /etc/nginx/modsec/coreruleset-NEUE.VERSIONS.NUMMER/crs-setup.conf
Jetzt bearbeiten Sie die Konfigurationsdatei
sudo nano /etc/nginx/modsec/main.conf
und passen die Versionsnummern an die Aktuellen an
Die rote Versionsnummer passen Sie bitte den Aktuellen an
Include /etc/nginx/modsec/coreruleset-NEUE.VERSIONS.NUMMER/crs-setup.conf
Include /etc/nginx/modsec/coreruleset-NEUE.VERSIONS.NUMMER/rules/*.conf
Im Anschluss testen Sie die Nginx Konfiguration
sudo nginx -t
wenn dieser Test funktioniert hat starten Sie Nginx als Service neu
sudo systemctl restart nginx
Passen Sie den Inhalt Ihrer bisherigen coreruleset-ALTE.VERSIONS.NUMMER/crs-setup.conf an Ihre neue /crs-setup.conf
Die rote Versionsnummer passen Sie bitte der Aktuellen an
mv /etc/nginx/modsec/coreruleset-ALTE.VERSIONS.NUMMER/rules/ etc/nginx/modsec/coreruleset-NEUE.VERSIONS.NUMMER/crs-setup.conf
Zum abschluß testen Sie die Nginx Konfiguration
sudo nginx -t
wenn alles fehlerfrei läuft Nginx neu starten
sudo systemctl reload nginx
Woher wissen Sie, ob die neue Version funktioniert? Starten Sie einen einfachen SQL-Injection-Angriff und überprüfen Sie Ihre Serverprotokolle. Es zeigt Ihnen die CRS-Version, die diesen Angriff verhindert.
Die rote Domain an Ihre eigene Anpassen
https://yourdomain.com/?id=3 or 'a'='a'
Sie sollten eine 403 Forbidden Seite erhalten
Ich hoffe, dieses Tutorial hat Ihnen geholfen, die ModSecurity-Webanwendungs-Firewall mit Nginx unter Debian/Ubuntu einzurichten.
Jetzt auch auf Dolibarr Wiki
Gruß Scalar
