Jak nainstalovat sadu základních pravidel ModSecurity 3 a OWASP s Nginx na Debian 11 Bullseye

ModSecurity, často označované jako Modsec, je bezplatný firewall webových aplikací s otevřeným zdrojovým kódem (WAF) . ModSecurity byl vytvořen jako modul pro Apache HTTP Server. Od svých počátků se však WAF rozrostl a nyní pokrývá řadu možností filtrování požadavků a odpovědí HyperText Transfer Protocol pro různé platformy, jako je Microsoft IIS, Nginx a samozřejmě Apache.

Jak WAF funguje, modul ModSecurity je nasazen před webovou aplikací, což umožňuje modulu skenovat příchozí a odchozí HTTP připojení. ModSecurity se nejčastěji používá ve spojení s OWASP Core Rule Set (CRS) , sada pravidel s otevřeným zdrojovým kódem napsaná v jazyce SecRules od ModSecurity a je vysoce uznávaná v bezpečnostním průmyslu.

Sada pravidel OWASP s ModSecurity může téměř okamžitě pomoci chránit váš server před:

• Špatní uživatelští agenti
• DDOS
• Skriptování napříč weby
• Vložení SQL
• Únos relace
• Jiné hrozby

V následujícím tutoriálu se dozvíte, jak nainstalovat ModSecurity s Nginx na desktop nebo server Debian 11 Bullseye.

Předpoklady

• Doporučený operační systém: Debian 11 Bullseye.
• Uživatelský účet: Uživatelský účet s přístupem sudo nebo root.
• Požadované balíčky: uvedeny v celém tutoriálu

Aktualizace operačního systému

Aktualizujte svůj Debian operační systém, abyste se ujistili, že všechny existující balíčky jsou aktuální:

sudo apt update && sudo apt upgrade -y

Výukový program bude používatpříkaz sudo a za předpokladu, že máte status sudo .

Chcete-li ověřit stav sudo na vašem účtu:

sudo whoami

Ukázkový výstup zobrazující stav sudo:

[joshua@debian~]$ sudo whoami
root

Chcete-li nastavit stávající nebo nový účet sudo, navštivte náš tutoriál o Přidání uživatele do Sudoers na Debianu .

Chcete-li použít rootový účet , použijte k přihlášení následující příkaz s heslem uživatele root.

su

Instalovat balíček CURL &UNZIP

Výukový program využívá příkaz curl and unzip během určitých částí. Chcete-li se ujistit, že je nainstalován, spusťte ve svém terminálu následující příkaz:

sudo apt install curl unzip -y

Nainstalujte nejnovější Nginx

Nejprve budete muset nainstalovat Nginx a doporučuje se to provést s nejnovější stabilní nebo hlavní verzí Nginx. Než budete pokračovat, doporučujeme odstranit všechny existující instalace Nginx a nainstalujte nejnovější stabilní nebo hlavní verzi Nginx .

Odeberte existující instalaci Nginx

Zastavte aktuální službu Nginx:

sudo systemctl stop nginx

Nyní odstraňte stávající instalaci Nginx následovně:

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

Importovat nejnovější úložiště Nginx a nainstalovat

Chcete-li použít nejnovější verzi hlavní nebo stabilní verze nginx, budete muset nejprve importovat úložiště.

Import hlavního úložiště:

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

Import stabilního úložiště:

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

Aktualizujte své úložiště, aby odráželo novou změnu:

apt update

Nyní, když jste nainstalovali úložiště Nginx a aktualizovali seznam úložišť, nainstalujte Nginx s následujícím:

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

Upozorňujeme, že můžete být vyzváni, abyste si ponechali nebo nahradili stávající /etc/nginx/ nginx.conf konfigurační soubor během instalace. Doporučujeme ponechat aktuální konfigurační soubor stisknutím (n) . Kopie bude vytvořena bez ohledu na verzi správce a můžete to také zkontrolovat v budoucnu.

Přidat zdrojový kód Nginx do úložiště

Při instalaci nejnovější verze hlavní nebo stabilní verze Nginx se ve výchozím nastavení nainstaluje pouze binární. Zdroj však budete potřebovat ke kompilaci Modsecurity dále v tutoriálu.

Nejprve otevřete konfigurační soubor v /etc/apt/sources.list.d s nano, jak je uvedeno níže:

Hlavní řada:

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

Stabilní:

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

V hlavní i stabilní verzi, když otevřete soubor, uvidíte pouze jeden řádek takto:

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

Pod původní řádek přidejte následující řádek:

Hlavní řada:

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

Stabilní:

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

Příklad toho, jak by to mělo vypadat (pouze hlavní příklad):

Stáhnout zdroj Nginx

Ke kompilaci dynamického modulu ModSecurity si budete muset stáhnout zdrojový kód Nginx . Chcete-li to provést, budete si muset stáhnout a uložit zdrojový balíček do umístění adresáře /etc/local/src/nginx .

Vytváření a konfigurace adresářů

Umístění vytvořte následovně:

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

Volitelné – V případě potřeby přidělte oprávnění k adresáři, jak je uvedeno níže:

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

Instalovat závislosti a spustit stahování

Dále si stáhněte zdrojový balíček s následujícím:

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

Všimněte si, že se zobrazí následující chybová zpráva:

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)

To lze bezpečně ignorovat.

Ověřte zdrojovou verzi

Dále vypište seznam souborů adresářů s ls příkaz takto:

ls

Ve vašem /usr/src/local/nginx byste měli vidět následující výstup adresář:

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

Dále se ujistěte, že zdrojový balíček je stejný jako vaše verze Nginx nainstalovaná v operačním systému Debian. Chcete-li to provést, použijte následující nginx -v příkaz takto:

sudo nginx -v

Zdroj, který jste stáhli, by se měl shodovat s binární verzí nainstalovanou ve vašem systému.

Příklad:

nginx version: nginx/1.21.1

Nainstalujte libmodsecurity3 pro ModSecurity

Balíček libmodsecurity3 je skutečná část WAF, která provádí filtrování HTTP pro vaše webové aplikace. Na Debian 11 to můžete nainstalovat z výchozího úložiště Debian 11. To se však jako u většiny stabilních verzí nedoporučuje a často to zaostává. Místo toho budete kompilovat z mnohem aktuálnějšího zdroje následovně.

Klonujte úložiště ModSecurity Repsoitory z Github

Prvním krokem je klon z Githubu, a pokud nemáte nainstalovaný git, budete muset provést následující příkaz:

apt install git -y

Dále naklonujte úložiště libmodsecurity3 GIT následovně:

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

Po naklonování budete muset CD do adresáře:

cd /usr/local/src/ModSecurity/

Nainstalujte závislosti libmodsecurity3

Ke kompilaci budete muset nainstalovat následující závislosti takto:

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

Nyní na závěr nainstalujte následující submoduly GIT takto:

git submodule init

Poté aktualizujte submoduly:

git submodule update

Vytvoření prostředí ModSecurity

Dalším krokem je nyní vlastně nejprve vytvořit prostředí. Použijte následující příkaz:

./build.sh

Dále spusťte příkaz configure:

./configure

Všimněte si, že se pravděpodobně zobrazí následující chyba:

fatal: No names found, cannot describe anything.

Toto můžete klidně ignorovat a přejít k dalšímu kroku.

Kompilace zdrojového kódu ModSecurity

Nyní, když jste vytvořili a nakonfigurovali prostředí pro libmodsecurity3, je čas jej zkompilovat pomocí příkazu make .

make

Šikovným trikem je zadat -j protože to může výrazně zvýšit rychlost kompilace, pokud máte výkonný server. Například server LinuxCapable má 6 CPU a já mohu použít všech 6 nebo alespoň použít 4 až 5 ke zvýšení rychlosti.

make -j 6

Po zkompilování zdrojového kódu nyní spusťte instalační příkaz ve svém terminálu:

make install

Poznámka, instalace se provádí v /usr/local/modsecurity/, na který se odkážete později v příručce.

Nainstalujte konektor ModSecurity-nginx

Konektor ModSecurity-nginx je spojovací bod mezi nginx a libmodsecurity. V podstatě je to komponenta, která komunikuje mezi Nginx a ModSecurity (libmodsecurity3) .

Klonujte úložiště ModSecurity-nginx z Github

Podobně jako v předchozím kroku klonování úložiště libmodsecurity3 budete muset znovu naklonovat úložiště konektoru pomocí následujícího příkazu:

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

Nainstalujte závislosti ModSecurity-nginx

Dále adresář CD do zdrojového adresáře Nginx takto:

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

Poznámka:Nahraďte verzi průvodce aktuální verzí Nginx ve vašem systému.

Nyní spusťte příkaz v terminálu Debianu a nainstalujte požadované závislosti:

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

Dále zkompilujete ModSecurity-nginx Connector modul pouze s –with-compat příznak takto:

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

Nyní vyrobte (vytvořte) dynamické moduly pomocí následujícího příkazu:

make modules

Poté, když jste ve zdrojovém adresáři Nginx, použijte následující příkaz k přesunutí dynamického modulu, který jste právě vytvořili a který byl uložen v umístění objs/ngx_http_modsecurity_module.so a zkopírujte jej do /usr/share/nginx/modules adresář.

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

Dynamický modul můžete uložit kdekoli, pokud při načítání zadáte úplnou cestu.

Načíst a nakonfigurovat konektor ModSecurity-nginx pomocí webového serveru Nginx

Nyní, když jste zkompilovali dynamický modul a odpovídajícím způsobem jej umístili, musíte upravit soubor /etc/nginx/nginx.conf konfigurační soubor, aby ModSecurity fungoval s vaším webovým serverem Nginx.

Povolte ModSecurity v nginx.conf

Nejprve musíte zadat load_module a cestu k vašemu modulu modsecurity.

Otevřete nginx.conf s libovolným textovým editorem. Pro tutoriál bude použito nano:

sudo nano /etc/nginx/nginx.conf

Dále přidejte do souboru v horní části následující řádek:

load_module modules/ngx_http_modsecurity_module.so;

Pokud jste modul umístili jinde, nezapomeňte uvést úplnou cestu.

Nyní přidejte následující kód pod HTTP {} oddíl takto:

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

POUZE příklad:

Pokud jste modul umístili jinde, nezapomeňte uvést úplnou cestu.

Uložte soubor nginx.conf soubor (CTRL+O), poté ukončete (CTRL+X) .

Vytvoření a konfigurace adresáře a souborů pro ModSecurity

Budete muset vytvořit adresář pro uložení konfiguračních souborů a budoucích pravidel, OWASP CRS pro tutoriál.

Pomocí následujícího příkazu vytvořte /etc/nginx/modsec adresář takto:

sudo mkdir /etc/nginx/modsec/

Nyní musíte zkopírovat ukázkový konfigurační soubor ModSecurity zpět z našeho klonovaného adresáře GIT:

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

Pomocí svého oblíbeného textového editoru otevřete soubor modsecurity.conf následovně:

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

Ve výchozím nastavení má konfigurace ModSecurity modul pravidel určený jako (DetectionOnly) , který jinými slovy spouští ModSecurity a detekuje veškeré škodlivé chování, ale neblokuje ani nezakazuje a nezaznamenává všechny transakce HTTP, které označí. Toto by mělo být použito pouze v případě, že máte hodně falešných poplachů nebo jste zvýšili nastavení úrovně zabezpečení na extrémní úroveň a testovali, zda se nevyskytnou nějaké falešně pozitivní.

Chcete-li toto chování změnit na (zapnuto) , najděte následující na řádku 7 :

SecRuleEngine DetectionOnly

Změňte řádek na tento, abyste povolili ModSecurity:

SecRuleEngine On

Nyní musíte najít následující položku, která se nachází na řádku 224 :

# Log everything we know about a transaction.
SecAuditLogParts ABIJDEFHZ

To není správné a je třeba to změnit. Upravte řádek na následující:

SecAuditLogParts ABCEFHJKZ

Nyní uložte modsecurity.conf pomocí (CTRL+O) poté ukončete (CTRL+X) .

Další částí je vytvoření následujícího souboru modsec-config.conf . Zde přidáte modsecurity.conf soubor podél a později na další pravidla, jako je OWASP CRS a pokud používáte WordPress, WPRS CRS sada pravidel.

Pomocí následujícího příkazu vytvořte soubor a otevřete jej:

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

Jakmile jste uvnitř souboru, přidejte následující řádek:

Include /etc/nginx/modsec/modsecurity.conf

Uložte soubor modsec-config.conf soubor pomocí (CTRL+O) poté (CTRL+X) ukončete.

Nakonec zkopírujte unicode.mapping od ModSecurity soubor s CP příkaz takto:

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

Nyní, než budete pokračovat, měli byste službu Nginx nechat nasucho s následujícím příkazem terminálu:

sudo nginx -t

Pokud jste vše nastavili správně, měli byste získat následující výstup:

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

Chcete-li provést změny, restartujte službu Nginx pomocí příkazu systemctl:

sudo systemctl restart nginx

Instalovat sadu základních pravidel OWASP pro ModSecurity

ModSecurity sám o sobě nechrání váš webový server a musíte mít pravidla. Jedním z nejznámějších, nejrespektovanějších a nejznámějších pravidel je sada pravidel OWASP CRS. Pravidla jsou nejrozšířenější mezi webovými servery a dalšími WAF a většina ostatních podobných systémů zakládá většinu svých pravidel na tomto CRS. Instalace této sady pravidel vám automaticky poskytne skvělý zdroj ochrany proti většině vznikajících hrozeb na internetu tím, že odhalí škodlivé aktéry a zablokuje je.

Pomocí příkazu wget stáhněte si archiv OWASP CRS 3.3.2 takto:

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

Pro ty, kteří chtějí žít na hraně, si můžete stáhnout noční sestavení. Používejte noční, pouze pokud jste připraveni neustále znovu kompilovat a často kontrolovat aktualizace CoreRuleSet Github a budete si jistější při řešení problémů. Technicky může být noční program bezpečnější, ale může způsobit problémy.

Pro začínající uživatele použijte stabilní verzi a nepoužívejte verzi níže.

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

Nainstalujte Rozbalit balíček pokud toto nemáte na svém serveru nainstalováno:

sudo apt install unzip -y

Nyní rozbalte master.zip archivujte následovně:

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

Jako dříve, jako modsecurity.conf ukázková konfigurace, OWASP CRS je dodáván s ukázkovým konfiguračním souborem, který je třeba přejmenovat. Nejlepší je použít CP příkaz a uschovejte si zálohu pro budoucnost pro případ, že budete muset restartovat znovu.

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

Chcete-li pravidla aktivovat, otevřete /etc/nginx/modsec/modsec-config.conf znovu pomocí libovolného textového editoru:

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

Jakmile jste znovu uvnitř souboru, přidejte následující dva další řádky:

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

Uložte soubor (CTRL+O) a ukončete (CTRL+X) .

Stejně jako dříve musíte otestovat jakékoli nové přírůstky do vaší služby Nginx, než ji zprovozníte:

sudo nginx -t

Měli byste získat následující výstup, což znamená, že vše správně funguje:

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

Restartujte službu Nginx, aby se změny projevily následovně:

sudo systemctl restart nginx

Používání a porozumění OWASP CRS

OWASP CRS má poměrně mnoho možností, výchozí nastavení však ihned po vybalení ochrání většinu serverů, aniž by poškodilo vaše skutečné návštěvníky a dobré SEO roboty. Níže budou uvedeny některé oblasti, které vám pomohou vysvětlit. Další čtení by bylo nejlepší prozkoumat všechny možnosti v samotných konfiguračních souborech, protože obsahují poměrně dost textových dat k vysvětlení, co to je.

Otevřete soubor CRS-setup.conf soubor takto:

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

Všimněte si, že toto je konfigurace verze pro vývojáře s dalšími položkami ve srovnání s verzí 3.3.

Odtud můžete upravit většinu nastavení OWASP CRS.

Hodnocení OWASP CRS

Abychom to rozebrali, ModSecurity má dva režimy:

Režim hodnocení anomálií

# -- [[ 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.

Samostatný režim

# -- [[ 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.

Skóre anomálií je obecně pro většinu uživatelů tím nejlepším režimem.

Existují čtyři úrovně paranoie:

• Paranoia Úroveň 1 – Výchozí úroveň a doporučená pro většinu uživatelů.
• Paranoia 2. úrovně – Pouze pro pokročilé uživatele.
• Paranoia 3. úrovně – Pouze zkušení uživatelé.
• Paranoia Úroveň 4 – Nedoporučuje se vůbec, s výjimkou výjimečných okolností.

# -- [[ 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.

Otestujte OWASP CRS na svém serveru

Chcete-li otestovat, zda OWASP CRS na vašem serveru funguje, otevřete svůj internetový prohlížeč a použijte následující:

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

Měli byste obdržet chybu 403 zakázáno. Pokud ne, pak byl vynechán krok.

Nejběžnějším problémem chybí změna Pouze detekce na Zapnuto jak bylo popsáno dříve v tutoriálu.

Zacházení s falešně pozitivními výsledky a vyloučením vlastních pravidel

Jedním z často nekončících úkolů je řešení falešných poplachů, ModSecurity a OWASP CRS spolu odvádějí skvělou práci, ale jde to za cenu vašeho času, ale vzhledem k ochraně to stojí za to. Pro začátek je zlatým pravidlem nikdy nezvyšovat paranoiu na vyšší úroveň.

Dobrým pravidlem je několik týdnů až měsíců provozovat nastavená pravidla s téměř žádnými falešně pozitivními výsledky a poté zvýšit například úroveň paranoie 1 na úroveň 2, takže vás nezaplaví spousta současně.

Vyloučení známých aplikací s falešně pozitivními výsledky

Modsecurity ve výchozím nastavení může přidat na seznam povolených každodenních akcí, které vedou k falešně pozitivním výsledkům, jak je uvedeno níže:

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

Chcete-li povolit například WordPress, phpBB a phpMyAdmin při používání všech tří odkomentujte řádky a opusťte (1) číslo neporušené, změňte ostatní služby, které nepoužíváte, například Xenforo, na (0) protože tato pravidla nechcete přidat na seznam povolených.

Příklad níže:

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"

Můžete také upravit syntaxi, která by byla čistší. Například:

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"

Jak vidíte, byly odstraněny nepotřebné možnosti a přidány (“) na konci WordPressu pro správnou syntaxi.

Vyloučení pravidel v Před CRS

Chcete-li se vypořádat s vlastními vyloučeními, musíte nejprve změnit název z REQUEST-900-EXCLUSION-RULES-BEFORE-CRS-SAMPLE.conf soubor pomocí příkazu cp takto:

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

Je třeba si pamatovat, že při vytváření pravidel vyloučení musí mít každé z nich id:<číslo pravidla> a být jedinečné, jinak se při testování služby Nginx zobrazí chyba. Příklad „id:1544,phase:1,log,allow,ctl:ruleEngine=off“ , ID 1544 nelze použít pro druhé pravidlo.

Například některé REQUEST_URI vyvolají falešné poplachy. Níže uvedený příklad je dva s majákem Google pagespeed a pluginem WMUDEV pro 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"

Jak vidíte, každá adresa URL, která začíná cestou, bude automaticky povolena.

Další možností je přidat IP adresy na seznam povolených, několik způsobů, jak toho dosáhnout:

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"

@ipMatch lze použít ve větší míře pro podsítě. Pokud chcete zakázat podsíť nebo IP adresa změnit, dovolit popřít. S trochou know-how můžete také vytvářet černé a bílé listiny a konfigurovat je pomocí fail2ban . Možnosti mohou být často nekonečné.

Posledním příkladem je deaktivace pouze pravidel, která spouštějí falešná pozitiva, nikoli plošné přidávání celé cesty na seznam povolených, jak jste viděli v prvním příkladu REQUEST_URI. To však vyžaduje více času a testování. Chcete například odstranit pravidla 941000 a 942999 z vaší /admin/ oblasti, protože to neustále spouští falešné zákazy a blokování pro váš tým, najděte ve svých protokolech modsecurity soubor ID pravidla a poté deaktivujte pouze toto ID pomocí RemoveByID jako příklad níže:

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

Příklady lze nalézt na wiki stránce ModSecurity GIT; LinuxCapable v budoucnu vytvoří tutoriál k této části, protože je toho docela hodně, co je potřeba probrat.

Volitelné – Zahrnout Project Honeypot

Projekt Honey Pot je první a jediný distribuovaný systém pro identifikaci spammerů a spambotů, které používají k získávání adres z vašeho webu. Pomocí systému Project Honey Pot můžete nainstalovat vlastní označené adresy k času a IP adrese návštěvníka vašich stránek. Pokud jedna z těchto adres začne dostávat e-maily, můžeme zjistit, že zprávy jsou spam, přesný okamžik, kdy byla adresa získána, a IP adresu, která ji shromáždila.

ModSecurity může mít možnost integrovat Project Honeypot, který bude dotazovat databázi a blokovat všechny adresy, které jsou na černé listině HoneyPot. Všimněte si, že použití tohoto může vést k falešným pozitivním výsledkům, ale celkově je to považováno za velmi spolehlivé ve srovnání s podobnými alternativami.

Krok 1. Vytvořte si účet zdarma.

Krok 2. Jakmile se zaregistrujete a přihlásíte, na hlavním panelu najděte řádek (Váš http:BL API klíč) a klikněte na získat jeden .

Krok 3. Vraťte se zpět k souboru CRS-setup.conf jeho otevřením pomocí textového editoru:

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

Krok 4. Najděte řádek začínající #SecHttpBlKey, která je na lince 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"

Krok 5. Změňte SecHttpBlKey XXXXXXXXXXXXXXXXXX pomocí klíče z Project HoneyPot.

Příklad:

SecHttpBlKey amhektvkkupe

Krok 6. Dále odkomentujte všechny řádky, abyste pravidlo aktivovali. Chcete-li deaktivovat pravidlo, namísto (1) zadejte (0) místo toho, pokud chcete některé z pravidel deaktivovat. Ve výchozím nastavení je block_search_ip=0 pro roboty vyhledávačů, nepovolujte to, pokud nechcete, aby na váš web chodili Bing, Google a další dobří roboti.

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 dní. 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.