Jak nastavit ModSecurity s Nginx na Debian/Ubuntu

Tento tutoriál vám ukáže, jak nainstalovat a používat ModSecurity s Nginx na serverech Debian/Ubuntu. ModSecurity je nejznámější open source webový aplikační firewall (WAF), poskytující komplexní ochranu pro vaše webové aplikace (jako WordPress, Nextcloud, Ghost atd.) proti široké škále útoků na vrstvě 7 (HTTP), jako je SQL injection, cross-site scripting a začlenění místních souborů.

Poznámka :Tento tutoriál funguje na všech aktuálních verzích Debianu a Ubuntu, včetně Debianu 10, Ubuntu 18.04, Ubuntu 20.04 a Ubuntu 20.10.

Webové aplikace jsou ze své podstaty nezabezpečené. Pokud jste správcem WordPress, pravděpodobně jednou za čas uslyšíte zprávy o hackerech, kteří zneužívají zranitelnosti pluginů a témat WordPress. Je nezbytné, abyste na svůj webový server nasadili WAF, zvláště když máte staré aplikace, které nedostávají aktualizace. ModSecurity byl původně vytvořen Ivanem Ristićem v roce 2002, v současnosti je spravován Trustwave SpiderLabs. Je to nejrozšířenější WAF na světě, který používá více než milion webových stránek. cPanel, nejrozšířenější hostitelský ovládací panel, zahrnuje ModSecurity jako WAF.

Možná jste slyšeli o jiných hostitelských firewallech, jako jsou iptables, UFW a Firewalld atd. Rozdíl je v tom, že fungují na vrstvě 3 a 4 modelu OSI a provádějí akce na základě IP adresy a čísla portu. ModSecurity nebo firewally webových aplikací obecně se specializují na to, aby se zaměřovaly na provoz HTTP (vrstva 7 modelu OSI) a provádí akce na základě obsahu požadavku a odpovědi HTTP.

ModSecurity 3

ModSecurity byl původně navržen pro webový server Apache. Mohlo to fungovat s Nginx před verzí 3.0, ale trpělo špatným výkonem. ModSecurity 3.0 (neboli libmodsecurity ) byla vydána v roce 2017. Je to milník vydání, zejména pro uživatele Nginx, protože je to první verze, která nativně pracuje s Nginx. Upozornění ModSecurity 3 je, že ještě nemá všechny funkce jako v předchozí verzi (2.9), i když každé nové vydání přidá některé z chybějících funkcí.

Krok 1:Nainstalujte nejnovější verzi Nginx na Debian/Ubuntu

ModSecurity se integruje s Nginx jako dynamický modul, který vám umožňuje kompilovat zdrojový kód jednotlivých modulů bez kompilace samotného Nginxu.

Binární soubor Nginx musí být zkompilován pomocí --with-compat argument, díky kterému budou dynamické moduly binárně kompatibilní s vaší stávající binární hodnotou Nginx. Ne každý binární soubor Nginx dodaný z výchozího úložiště Debian/Ubuntu je však zkompilován s --with-compat argument. Abychom to usnadnili, můžeme nainstalovat nejnovější verzi Nginx z ondrej/nginx-mainline PPA, který spravuje vývojář Debianu.

Poznámka :Úložiště nginx.org také poskytuje nejnovější verzi Nginx. Nicméně ondrej/nginx-mainline PPA poskytuje další dynamické moduly, které by se vám mohly hodit, jako je například modul Brotli.

Ubuntu

Pokud používáte Ubuntu 16.04, 18.04, 20.04 nebo 20.10, spusťte následující příkazy k instalaci nejnovější verze Nginx.

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

Během procesu instalace vám může sdělit, že distributor balíčku dodal aktualizovanou verzi hlavního konfiguračního souboru. Doporučuje se stisknout n pro zachování aktuální verze. Rozdíl můžete vždy prozkoumat později.

Ve výchozím nastavení je povoleno pouze binární úložiště. Abychom mohli stáhnout zdrojový kód Nginx, musíme také povolit úložiště zdrojového kódu. Upravte soubor úložiště hlavní řady Nginx.

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

Najděte řádek, který začíná # deb-src .

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

Odstraňte # znak pro povolení tohoto úložiště zdrojového kódu.

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

Uložte a zavřete soubor. Poté aktualizujte index úložiště.

aktualizace sudo apt

Debian

Pokud používáte Debian 10 nebo Debian 11, spusťte následující příkazy k instalaci nejnovější verze Nginx.

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

Během procesu instalace vám může sdělit, že distributor balíčku dodal aktualizovanou verzi hlavního konfiguračního souboru. Doporučuje se stisknout n pro zachování aktuální verze. Rozdíl můžete vždy prozkoumat později.

Ve výchozím nastavení je povoleno pouze binární úložiště. Abychom mohli stáhnout zdrojový kód Nginx, musíme také povolit úložiště zdrojového kódu. Upravte soubor úložiště hlavní řady Nginx.

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

Měli byste najít jeden řádek, který umožňuje binární úložiště Nginx. Přidejte následující řádek, abyste povolili úložiště zdrojového kódu Nginx v Debianu 10.

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

Pokud používáte Debian 11, přidejte místo toho následující řádek.

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

Uložte a zavřete soubor. Poté aktualizujte index úložiště.

aktualizace sudo apt

Kontrola argumentů konfigurace Nginx

Nyní zkontrolujte konfigurační argumenty Nginx pomocí následujícího příkazu:

sudo nginx -V

Všechny binární soubory Nginx v PPA jsou kompilovány pomocí --with-compat argument.

Krok 2:Stáhněte si zdrojový balíček Nginx

Ačkoli nepotřebujeme kompilovat samotný Nginx, potřebujeme balíček zdrojového kódu Nginx, abychom mohli zkompilovat dynamický modul ModSecurity. Spusťte následující příkaz a vytvořte nginx adresář pod /usr/local/src/ k uložení balíčku zdrojového kódu Nginx. Nahraďte username s vaším skutečným uživatelským jménem.

uživatelské jméno sudo chown:uživatelské jméno /usr/local/src/ -R mkdir -p /usr/local/src/nginx

cd do zdrojového adresáře Nginx.

cd /usr/local/src/nginx/

Stáhněte si zdrojový balíček Nginx pomocí příkazů níže:

sudo apt install dpkg-devapt source nginx

Pokud uvidíte následující varovnou zprávu, můžete ji bezpečně ignorovat.

W:Stahování se provádí bez sandboxu jako root, protože k souboru 'nginx_1.19.5.orig.tar.gz' nemá uživatel '_apt' přístup. - pkgAcquire::Run (13:Oprávnění odepřeno)

Podívejte se na stažené soubory zdrojového kódu.

ls

Ukázkový výstup:

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. .orig.tar.gz

Ujistěte se, že verze zdrojového kódu je stejná jako vaše binární verze Nginx (sudo nginx -v ).

Krok 3:Nainstalujte libmodsecurity3

libmodsecurrity je knihovna ModSecurity, která ve skutečnosti provádí filtrování HTTP pro vaše webové aplikace. Na Debian 10 a Ubuntu 20.04, 20.10 jej můžete nainstalovat pomocí sudo apt install libmodsecurity3 , ale doporučuji vám jej zkompilovat ze zdroje.

Ke kompilaci libmodsecurity , nejprve naklonujte zdrojový kód z Github.

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

Nainstalujte závislosti sestavení.

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 libgevlicurl-dev liblua5.3-dev před> 

 Nainstalujte požadované submoduly.
 
aktualizace submodulu git initgit submodulu
 

 Nakonfigurujte prostředí sestavení.
 
./build.sh ./configure
 

 Pokud se zobrazí následující chyba, můžete ji ignorovat.
 
fatal:Nebyla nalezena žádná jména, nelze nic popsat.
 

 Zkompilujte zdrojový kód pomocí následujícího příkazu. Ve výchozím nastavení make bude používat pouze jedno jádro CPU. Na svém serveru mám 4 jádra CPU, takže specifikuji 4 úlohy (-j4 ) pro make pro urychlení procesu kompilace. Změňte 4 na váš vlastní počet jader CPU.
 
make -j4
 

 Po make příkaz dokončen bez chyb, nainstalujte binární soubor.
 
sudo make install
 

 Bude nainstalován pod /usr/local/modsecurity/ adresář.
 
Odstraňování problémů při kompilaci
 
chyba #1
 

 Pokud se při spuštění make zobrazí následující chyba je to pravděpodobně proto, že váš server nemá dostatek paměti RAM.
 
g++:interní chyba kompilátoru:zabito (program cc1plus)
 

 Následující řádky v /var/log/syslog soubor označuje, že server nemá dostatek paměti, takže zvažte aktualizaci specifikací serveru.
 

 
 

 Případně můžete vytvořit odkládací prostor pro vyřešení problému s nedostatkem paměti. Mělo by se však používat pouze jako dočasné opatření. Používání odkládacího prostoru na serverech SSD může mít negativní vliv na výkon systému.
 
chyba #2
 

 Pokud se při kompilaci ModSecurity zobrazí následující chyba,
 
utils/geo_lookup.cc:V členské funkci 'bool modsecurity::Utils::GeoLookup::lookup(const string&, modsecurity::Transaction*, std::function&)>) const':utils/geo_lookup.cc:124:32:chyba:neplatný převod z 'const MMDB_s*' na 'MMDB_s*' [-fpermissive]r =MMDB_lookup_string(&mmdb, target.c_str( ), &gai_error, &mmdb_error);
 

 Je to pravděpodobně proto, že jste nainstalovali zastaralou verzi libmaxminddb-dev . Tento balíček můžete odstranit.
 
sudo apt odstranit libmaxminddb-dev
 

 A nainstalujte libgeoip-dev , což je alternativa k libmaxminddb-dev .
 
sudo apt install libgeoip-dev
 

 Poté znovu zkompilujte ModSecurity.
 
make clean./configuremake -j4
 

 Nainstalujte binární soubor.
 
sudo make install
 
Krok 4:Stažení a kompilace zdrojového kódu konektoru ModSecurity v3 Nginx
 

 Konektor ModSecurity Nginx odkazy libmodsecurity na webový server Nginx. Klonujte úložiště ModSecurity v3 Nginx Connector Git.
 
klon git --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git /usr/local/src/ModSecurity-nginx/
 

 Ujistěte se, že jste ve zdrojovém adresáři Nginx.
 
cd /usr/local/src/nginx/nginx-1.19.5/
 

 Nainstalujte závislosti sestavení pro Nginx.
 
sudo apt build-dep nginxsudo apt install uuid-dev
 

 Dále nakonfigurujte prostředí pomocí následujícího příkazu. Nebudeme kompilovat Nginx samotný, ale kompilovat ModSecurity Nginx Connector pouze modul. --with-compat flag učiní modul binárně kompatibilní s vaší stávající binární Nginx.
 
./configure --with-compat --add-dynamic-module=/usr/local/src/ModSecurity-nginx
 

 Vytvořte ModSecurity Nginx Connector modul.
 
vytvářejte moduly
 

 Modul bude uložen jako objs/ngx_http_modsecurity_module.so . Zkopírujte jej do /usr/share/nginx/modules/ adresář.
 
sudo cp objs/ngx_http_modsecurity_module.so /usr/share/nginx/modules/
 
Krok 5:Načtěte modul konektoru ModSecurity v3 Nginx
 

 Upravte hlavní konfigurační soubor Nginx.
 
sudo nano /etc/nginx/nginx.conf
 

 Přidejte následující řádek na začátek souboru.
 
load_module modules/ngx_http_modsecurity_module.so;
 

 Přidejte také následující dva řádky do http {...} část, takže ModSecurity bude povolen pro všechny virtuální hostitele Nginx.
 
modsecurity on;modsecurity_rules_file /etc/nginx/modsec/main.conf;
 

 
 

 Uložte a zavřete soubor. Dále vytvořte /etc/nginx/modsec/ adresář pro uložení konfigurace ModSecurity
 
sudo mkdir /etc/nginx/modsec/
 

 Poté zkopírujte konfigurační soubor ModSecurity.
 
sudo cp /usr/local/src/ModSecurity/modsecurity.conf-recommended /etc/nginx/modsec/modsecurity.conf
 

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

 Najděte následující řádek.
 
Pouze detekce SecRuleEngine
 

 Tato konfigurace říká modulu ModSecurity, aby protokoloval transakce HTTP, ale při zjištění útoku neprovede žádnou akci. Změňte jej na následující, aby ModSecurity detekoval a blokoval webové útoky.
 
SecRuleEngine On
 

 Poté najděte následující řádek (řádek 224), který říká ModSecurity, jaké informace by měly být zahrnuty do protokolu auditu.
 
SecAuditLogParts ABIJDEFHZ
 

 Výchozí nastavení je však chybné. Později budete vědět proč, když vysvětlím, jak rozumět protokolům ModSecurity. Nastavení by se mělo změnit na následující.
 
SecAuditLogParts ABCEFHJKZ
 

 Pokud máte webovou stránku s kódováním, možná budete chtít zakázat kontrolu těla odpovědi, jinak byste mohli získat 403 zakázaných chyb pouhým načtením webové stránky se spoustou obsahu kódu.
 
SecResponseBodyAccess vypnuto
 

 Uložte a zavřete soubor. Dále vytvořte /etc/nginx/modsec/main.conf soubor.
 
sudo nano /etc/nginx/modsec/main.conf
 

 Přidejte následující řádek, abyste zahrnuli /etc/nginx/modsec/modsecurity.conf soubor.
 
Zahrnout /etc/nginx/modsec/modsecurity.conf
 

 Uložte a zavřete soubor. Potřebujeme také zkopírovat mapovací soubor Unicode.
 
sudo cp /usr/local/src/ModSecurity/unicode.mapping /etc/nginx/modsec/
 

 Poté otestujte konfiguraci Nginx.
 
sudo nginx -t
 

 Pokud je test úspěšný, restartujte Nginx.
 
sudo systemctl restart nginx
 
Krok 6:Povolte sadu základních pravidel OWASP
 

 Aby ModSecurity chránil vaše webové aplikace, musíte definovat pravidla pro detekci škodlivých aktérů a jejich blokování. Pro začátečníky je dobrý nápad nainstalovat stávající sady pravidel, abyste mohli rychle začít a pak se to naučili až po cestě. Existuje několik bezplatných sad pravidel pro ModSecurity. Sada základních pravidel OWASP (CRS) je standardní sada pravidel používaná s ModSecurity.
 
 
Je to bezplatná, komunitou spravovaná a nejrozšířenější sada pravidel, která poskytuje prodávanou výchozí konfiguraci pro ModSecurity.
 
Obsahuje pravidla, která pomáhají zastavit běžné útoky, včetně SQL injection (SQLi), cross-site scripting (XSS) a mnoha dalších.
 
Lze integrovat s Project Honeypot.
 
Obsahuje také pravidla pro detekci robotů a skenerů.
 
Bylo vyladěno pomocí široké expozice, aby mělo velmi málo falešných poplachů.
 
 

 Stáhněte si nejnovější OWASP CRS z GitHubu.
 
wget https://github.com/coreruleset/coreruleset/archive/v3.3.0.tar.gz
 

 Extrahujte soubor.
 
tar xvf v3.3.0.tar.gz
 

 Přesuňte adresář do /etc/nginx/modsec/ .
 
sudo mv coreruleset-3.3.0/ /etc/nginx/modsec/
 

 Přejmenujte crs-setup.conf.example soubor.
 
sudo mv /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf.example /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf
 

 Poté upravte hlavní konfigurační soubor.
 
sudo nano /etc/nginx/modsec/main.conf
 

 Přidejte následující dva řádky, díky nimž bude Nginx obsahovat konfigurační soubor CRS a jednotlivá pravidla.
 
Zahrnout /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.confInclude /etc/nginx/modsec/coreruleset-3.3.0/rules/*.conf
 

 
 

 Uložte a zavřete soubor. Poté otestujte konfiguraci Nginx.
 
sudo nginx -t
 

 Pokud je test úspěšný, restartujte Nginx.
 
sudo systemctl restart nginx
 
Krok 7:Zjistěte, jak OWASP CRS funguje
 

 Pojďme se podívat na konfigurační soubor CRS, který vám poskytuje dobrou dokumentaci o tom, jak CRS funguje.
 
sudo nano /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf
 

 Můžete vidět, že OWASP CRS může běžet ve dvou režimech:
 
 
samostatný režim . Toto je tradiční režim používaný v CRS v2.x. Pokud požadavek HTTP odpovídá pravidlu, ModSecurity požadavek HTTP okamžitě zablokuje a přestane vyhodnocovat zbývající pravidla.
 
režim hodnocení anomálií . Toto je výchozí režim používaný v CRS v3.x. ModSecurity zkontroluje požadavek HTTP se všemi pravidly a přidá skóre ke každému odpovídajícímu pravidlu. Pokud je dosaženo prahové hodnoty, je požadavek HTTP považován za útok a bude zablokován. Výchozí skóre pro příchozí požadavky je 5 a pro odchozí odpověď 4.
 
 

 
 

 Při spuštění v režimu hodnocení anomálií existují 4 úrovně paranoie.
 
 
Paranoia úrovně 1 (výchozí)
 
Paranoia úrovně 2
 
Paranoia úrovně 3
 
Paranoia úrovně 4
 
 

 S každým zvýšením úrovně paranoie umožňuje CRS další pravidla, která vám poskytují vyšší úroveň zabezpečení. Vyšší úrovně paranoie však také zvyšují možnost zablokování některého legitimního provozu kvůli falešným poplachům.
 

 
 

 Toto jsou dva základní pojmy, kterým musíte porozumět, než začnete CRS používat. Nyní můžeme soubor zavřít. Jednotlivá pravidla CRS jsou uložena v /etc/nginx/modsec/coreruleset-3.3.0/rules/ adresář. Každé odpovídající pravidlo zvýší skóre anomálie.
 
Krok 8:Testování
 

 Chcete-li zkontrolovat, zda ModSecurity funguje, můžete spustit jednoduchý útok SQL injection na svůj vlastní web. (Upozorňujeme, že je nezákonné provádět bezpečnostní testy na cizích webech bez oprávnění.) Do webového prohlížeče zadejte následující URL.
 
https://yourdomain.com/?id=3 nebo 'a'='a'
 

 Pokud ModSecurity funguje správně, váš webový server Nginx by měl vrátit chybovou zprávu 403 zakázané.
 

 
 

 Prohlížeč Firefox nemusí zobrazit chybovou zprávu 403. Můžete stisknout Ctrl+Shift+I otevřete okno nástrojů pro vývojáře a vyberte network tab. Poté stiskněte F5 znovu načíst webovou stránku. Nyní byste měli ve Firefoxu vidět chybový kód 403.
 

 Pokud ModSecurity běží v DetectionOnly režimu, nezablokuje tento útok SQL injection.
 
Krok 9:Pochopení protokolů ModSecurity
 

 Je důležité analyzovat protokoly ModSecurity, abyste věděli, jaké druhy útoků směřují na vaše webové aplikace, a podnikněte lepší kroky k obraně proti aktérům hrozeb. V ModSecurity existují hlavně dva druhy protokolů:
 
 
protokol ladění:ve výchozím nastavení zakázán.
 
protokol auditu:/var/log/modsec_audit.log 
 
 

 Abyste porozuměli protokolům auditu ModSecurity, musíte znát 5 fází zpracování v ModSecurity, kterými jsou:
 
 
Fáze 1:Kontrola záhlaví požadavků
 
Fáze 2:Kontrola těla požadavku
 
Fáze 3:Kontrola záhlaví odpovědí
 
Fáze 4:Kontrola těla odpovědi
 
Fáze 5:Akce (protokolování/blokování škodlivých požadavků)
 
 

 Jsou to také dva typy souborů protokolování.
 
 
Sériové :jeden soubor pro všechny protokoly. Toto je výchozí.
 
Souběžně :více souborů pro protokolování. To může poskytnout lepší výkon zápisu. Pokud si všimnete, že se vaše webové stránky po aktivaci ModSecurity zpomalují, můžete zvolit typ souběžného protokolování.
 
 

 Události v protokolu jsou rozděleny do několika sekcí.
 
 
sekce A:záhlaví protokolu auditu
 
část B:záhlaví požadavku
 
sekce C:tělo požadavku
 
sekce D:vyhrazena
 
oddíl E:zprostředkující orgán odpovědí
 
sekce F:závěrečná záhlaví odpovědí
 
sekce G:vyhrazena
 
sekce H:upoutávka na protokol auditu
 
část I:Kompaktní alternativa těla požadavku, která vylučuje soubory
 
sekce J:informace o nahraných souborech
 
sekce K:každé pravidlo odpovídající události v pořadí podle shody
 
sekce Z:konečná hranice
 
 

 Pokud provozujete web s vysokou návštěvností, protokol auditu ModSecurity se může velmi rychle zvětšit, takže musíme nakonfigurovat rotaci protokolu pro protokol auditu ModSecurity. Vytvořte konfigurační soubor logrotate pro ModSecurity.
 
sudo nano /etc/logrotate.d/modsecurity
 

 Přidejte do tohoto souboru následující řádky.
 
/var/log/modsec_audit.log{ otočit 14 denně missingok komprese delaycompress notifempty}
 

 Tím se bude soubor protokolu střídat každý den (denně ), komprimuje staré verze (compress ). Předchozích 14 souborů protokolu bude zachováno (střídat 14 ), a pokud je soubor prázdný, nedojde k žádné rotaci (notifempty ). Uložte a zavřete soubor.
 

 Pokud je váš protokol ModSecurity prázdný, možná budete muset restartovat Nginx.
 
sudo systemctl restart nginx
 
Krok 10:Řešení falešně pozitivních výsledků
 

 ModSecurity je obecný firewall webových aplikací a není určen pro konkrétní webovou aplikaci. Sada základních pravidel OWASP je také obecná sada pravidel bez ohledu na konkrétní aplikaci, takže je pravděpodobné, že po povolení ModSecurity a OWASP CRS uvidíte falešně pozitivní výsledky. Pokud zvýšíte úroveň paranoie v CRS, bude více falešných pozitiv.
 

 CRS například ve výchozím nastavení zakazuje vkládání příkazů Unixu, jako je zadávání sudo na webové stránce, což je na mém blogu docela běžné. Chcete-li odstranit falešné poplachy, musíte do CRS přidat vyloučení pravidel.
 
Vyloučení pravidel specifických pro aplikaci 
 

 S OWASP CRS jsou dodávány některé předem sestavené výjimky specifické pro aplikaci. Upravte soubor crs-setup.conf soubor.
 
sudo nano /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf
 

 Přejděte na Výjimky z pravidel pro konkrétní aplikace a najděte následující řádky.
 
#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"
 

 Například, pokud chci povolit vyloučení WordPress, výše uvedené řádky by měly být změněny na následující. Dávejte pozor na syntaxi. Mezi t:none,\ by neměly být žádné komentáře a setvar:tx.crs_exclusions_wordpress=1" . (Zpětné lomítko \ znak na konci označuje, že další řádek je pokračováním aktuálního řádku.)
 
SecAction \ "id:900130,\ fáze: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"
 

 Uložte a zavřete soubor. Poté otestujte konfigurace Nginx.
 
sudo nginx -t
 

 Pokud je test úspěšný, znovu načtěte Nginx, aby se změna projevila.
 
sudo systemctl reload nginx
 

 Všimněte si, že pokud máte na stejném serveru nainstalovaných více aplikací, jako jsou (WordPress, Nextcloud, Drupal atd.), pak se výše uvedená vyloučení pravidel použijí na všechny aplikace. Chcete-li minimalizovat bezpečnostní rizika, měli byste povolit vyloučení pravidla pouze pro jednu aplikaci. Chcete-li to provést, přejděte na /etc/nginx/modsec/coreruleset-3.3.0/rules/ adresář.
 
cd /etc/nginx/modsec/coreruleset-3.3.0/rules
 

 Přejmenujte REQUEST-900-EXCLUSION-RULES-BEFORE-CRS soubor.
 
sudo mv REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
 

 Poté tento soubor upravte.
 
sudo nano REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
 

 Přidejte následující řádek na konec tohoto souboru. Pokud váš WordPress používá blog.yourdomain.com subdoména a hlavička požadavku odeslaná z prohlížeče návštěvníka obsahuje tuto subdoménu, pak ModSecurity použije vyloučení pravidel pro WordPress.
 
SecRule REQUEST_HEADERS:Host "@streq blog.yourdomain.com" "id:1000,phase:1,setvar:tx.crs_exclusions_wordpress=1"
 

 Pokud jste na stejný server nainstalovali Nextcloud, můžete do tohoto souboru také přidat následující řádek, takže pokud návštěvník přistupuje k vaší subdoméně Nextcloud, ModSecurity použije výjimky z pravidla Nextcloud.
 
SecRule REQUEST_HEADERS:Host "@streq nextcloud.yourdomain.com" "id:1001,phase:1,setvar:tx.crs_exclusions_nextcloud=1"
 

 Uložte a zavřete tento soubor. Poté otestujte konfigurace Nginx.
 
sudo nginx -t
 

 Pokud je test úspěšný, znovu načtěte Nginx, aby se změna projevila.
 
sudo systemctl reload nginx
 
Vyloučení vlastních pravidel
 

 Povolení předem sestavených výjimek pravidel specifických pro aplikaci nemusí odstranit všechny falešně pozitivní výsledky. Pokud ano, musíte prozkoumat protokol auditu ModSecurity (/var/log/modsec_audit.log ), zkontrolujte, které pravidlo způsobilo falešně pozitivní výsledek, a přidejte svá vlastní vyloučení pravidla do REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf soubor.
 

 Oddíl H v protokolu auditu vám řekne, které pravidlo se shoduje. Pokud se například pokusím použít <code>...</code> HTML ve formuláři komentáře, ModSecurity blokuje můj komentář. Následující protokol mi říká, že požadavek HTTP odpovídal pravidlu v REQUEST-941-APPLICATION-ATTACK-XSS.conf (linka 527). ID pravidla je 941310. Identifikátor URI požadavku je /wp-comments-post.php .
 

 
 

 Je detekován jako útok s nesprávným kódováním XSS filtrem. Chci však, aby uživatelé mohli používat <code>...</code> a <pre>...</pre> HTML tag ve formuláři komentáře, takže jsem vytvořil vyloučení pravidla. Přidejte následující řádek na konec REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf soubor.
 
SecRule REQUEST_URI "@streq /wp-comments-post.php" "id:1002,phase:1,ctl:ruleRemoveById=941310"
 

 Tento řádek říká ModSecurity, že pokud je URI požadavku /wp-comments-post.php , pak nepoužívejte pravidlo ID 941310. Uložte a zavřete soubor. Poté otestujte konfiguraci Nginx.
 
sudo nginx -t
 

 Pokud je test úspěšný, znovu načtěte Nginx.
 
sudo systemctl reload nginx
 

 Pokud falešně pozitivní odpovídá více ID pravidel, můžete přidat vyloučení pravidla na jeden řádek takto:
 
SecRule REQUEST_URI "@streq /wp-admin/post.php" "id:1003,phase:1,ctl:ruleRemoveById=941160 ,ctl:ruleRemoveById=941310 ,ctl:ruleRemoveById=942100 "
." 

 Poznámka :Nedoporučuje se deaktivovat příliš mnoho pravidel úrovně 1 v OWASP CRS, protože to usnadní napadení vašeho webu. Pravidla deaktivujte, pouze pokud víte, co děláte.
 
Přidání na seznam povolených IP adres
 

 Pokud chcete zakázat ModSecurity pro svou vlastní IP adresu, ale ponechat jej povolený pro všechny ostatní IP adresy, přidejte následující vlastní pravidlo do REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf soubor. Nahraďte 12.34.56.78 s vaší skutečnou IP adresou.
 
SecRule REMOTE_ADDR "^12\.34\.56\.78" "id:1004,phase:1,allow,ctl:ruleEngine=off"
 

 Chcete-li podsíť přidat na seznam povolených, použijte následující syntaxi, která přidá 10.10.10.0/24 síť.
 
SecRule REMOTE_ADDR "^10\.10\.10.*" "id:1005,phase:1,allow,ctl:ruleEngine=off"
 

 Uložte a zavřete soubor. Poté otestujte konfigurace Nginx.
 
sudo nginx -t
 

 Pokud je test úspěšný, restartujte Nginx, aby se změna projevila.
 
sudo systemctl restart nginx
 
Pravidla řetězení
 

 Pokud má váš Nginx více virtuálních hostitelů, možná budete chtít přidat svou IP adresu na seznam povolených pro konkrétního virtuálního hostitele. Musíte zřetězit dvě pravidla takto:
 
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"
 

 chain klíčové slovo na konci prvního pravidla označuje, že ruleEngine=off akce bude provedena pouze v případě, že podmínka v dalším pravidle je také pravdivá.
 
(Volitelné) Integrujte ModSecurity s Project Honeypot
 

 Project Honeypot spravuje seznam známých škodlivých IP adres, které jsou zdarma dostupné veřejnosti. ModSecurity lze integrovat s Project Honeypot a blokovat IP adresy na seznamu Project Honeypot.
 

 Pamatujte, že používání Project Honeypot zpomalí váš web pro nové návštěvníky, protože váš webový server bude muset odeslat dotaz do Project Honeypot, než bude moci odeslat odpověď novému návštěvníkovi. Jakmile se však data reputace IP uloží do mezipaměti na vašem webovém serveru, dopad na výkon bude velmi minimální.
 

 Chcete-li používat Project Honeypot, vytvořte si nejprve bezplatný účet na jeho webových stránkách. Poté přejděte na hlavní panel svého účtu a klikněte na get one odkaz pro vyžádání přístupového klíče pro HTTP blacklist.
 

 
 

 Dále upravte crs-setup.conf soubor.
 
sudo nano /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf
 

 Najděte následující řádky.
 
#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"
 

 Odstraňte začátek # znaky, abyste je odkomentovali, a přidejte svůj klíč HTTPBL API získaný z Project Honeypot.
 

 
 

 Všimněte si, že block_search_ip by měl být nastaven na 0 (vypnuto), protože nechceme blokovat prohledávače vyhledávačů. Uložte a zavřete soubor. Poté znovu načtěte Nginx.
 
sudo systemctl reload nginx
 

 Nyní bude ModSecurity dotazovat Project Honeypot na všechny požadavky HTTP. Chcete-li otestovat, zda by to fungovalo, upravte soubor /etc/nginx/modsec/main.conf.
 
sudo nano /etc/nginx/modsec/main.conf
 

 Přidejte následující řádek na konec tohoto souboru. To nám umožňuje předat IP adresu v URL. (Jakmile je test úspěšný, můžete tento řádek ze souboru odstranit.)
 
SecRule ARGS:IP "@rbl dnsbl.httpbl.org" "phase:1,id:171,t:none,deny,nolog,auditlog,msg:'RBL Match for SPAM Source'
 

 Uložte a zavřete soubor. Otestujte konfigurace Nginx.
 
sudo nginx -t
 

 Poté znovu načtěte Nginx.
 
sudo systemctl znovu načíst nginx
 

 Přejděte na web Project Honeypot a najděte škodlivou IP adresu, například 134.119.218.243. Spuštěním následujícího příkazu otestujte blacklist HTTP.
 
curl -i -s -k -X $'GET' 'https://yourdomain.com/?IP=134.119.218.243'
 

 Váš webový server by měl vrátit zakázanou odpověď 403, protože IP adresa na Project Honeypot.
 
Jak používat Brotli s ModSecurity v Nginx
 

 Webové stránky jsou tradičně komprimovány pomocí GZIP pro rychlejší načítání. Developed by Google, Brotli is a new compression algorithm that provides better compression ratio. 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 příkaz. 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/ adresář. 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 file.
 
 

 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.