Come installare ModSecurity 3 e OWASP Core Rule Set con Nginx su Debian 11 Bullseye

ModSecurity, spesso denominato Modsec, è un firewall per applicazioni Web gratuito e open source (WAF) . ModSecurity è stato creato come modulo per Apache HTTP Server. Tuttavia, sin dai suoi primi giorni, il WAF è cresciuto e ora copre una serie di funzionalità di filtraggio delle richieste e delle risposte HyperText Transfer Protocol per varie piattaforme come Microsoft IIS, Nginx e, naturalmente, Apache.

Come funziona il WAF, il motore ModSecurity viene distribuito davanti all'applicazione web, consentendo al motore di scansionare le connessioni HTTP in entrata e in uscita. ModSecurity è più comunemente usato insieme al OWASP Core Rule Set (CRS) , un insieme di regole open source scritte nel linguaggio SecRules di ModSecurity ed è molto apprezzato nel settore della sicurezza.

OWASP Rule Set con ModSecurity può aiutare quasi istantaneamente a proteggere il tuo server da:

• Cattivi user agent
• DDOS
• Scripting su più siti web
• Iniezione SQL
• Dirottamento della sessione
• Altre minacce

Nel seguente tutorial imparerai come installare ModSecurity con Nginx su desktop o server Debian 11 Bullseye.

Prerequisiti

• Sistema operativo consigliato: Debian 11 Bullseye.
• Account utente: Un account utente con accesso sudo o root.
• Pacchetti richiesti: elencati durante il tutorial

Aggiorna sistema operativo

Aggiorna la tua Debian sistema operativo per assicurarsi che tutti i pacchetti esistenti siano aggiornati:

sudo apt update && sudo apt upgrade -y

Il tutorial utilizzerà il comando sudo e supponendo che tu abbia lo stato sudo .

Per verificare lo stato di sudo sul tuo account:

sudo whoami

Esempio di output che mostra lo stato di sudo:

[joshua@debian~]$ sudo whoami
root

Per configurare un account sudo esistente o nuovo, visita il nostro tutorial su Aggiunta di un utente a Sudoer su Debian .

Per utilizzare l'account root , usa il comando seguente con la password di root per accedere.

su

Installa il pacchetto CURL e UNZIP

Il tutorial utilizza il comando curl e unzip durante alcune parti. Per assicurarti che sia installato, esegui il seguente comando nel tuo terminale:

sudo apt install curl unzip -y

Installa Nginx più recente

Innanzitutto, dovrai installare Nginx e si consiglia di farlo con l'ultima versione stabile o principale di Nginx. Prima di continuare, ti consigliamo di rimuovere eventuali installazioni esistenti di Nginx e installa l'ultima versione stabile o mainline di Nginx .

Rimuovi l'installazione Nginx esistente

Arresta il servizio Nginx corrente:

sudo systemctl stop nginx

Ora rimuovi l'installazione di Nginx esistente come segue:

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

Importa il repository Nginx più recente e installa

Per utilizzare l'ultima versione di nginx mainline o stable, dovrai prima importare il repository.

Per importare il repository della linea principale:

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

Per importare un repository stabile:

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

Aggiorna il tuo repository per riflettere la nuova modifica:

apt update

Ora che hai installato il repository Nginx e aggiornato l'elenco dei repository, installa Nginx con quanto segue:

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

Tieni presente che ti potrebbe essere richiesto di mantenere o sostituire il tuo /etc/nginx/ esistente nginx.conf file di configurazione durante l'installazione. Si consiglia di conservare il file di configurazione corrente premendo (n) . Verrà eseguita una copia indipendentemente dalla versione del manutentore e potrai verificarla anche in futuro.

Aggiungi codice sorgente Nginx al repository

Solo il binario viene installato quando si installa l'ultima versione di Nginx mainline o stable per impostazione predefinita. Tuttavia, avrai bisogno del sorgente per compilare Modsecurity ulteriormente nel tutorial.

Innanzitutto, apri il file di configurazione in /etc/apt/sources.list.d con nano come di seguito:

Linea principale:

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

Stabile:

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

Sia in mainline che in stable, quando apri il file, vedrai solo una singola riga come segue:

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

Sotto la riga originale, aggiungi la seguente riga:

Linea principale:

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

Stabile:

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

Esempio di come dovrebbe essere (solo esempio Mainline):

Scarica sorgente Nginx

Dovrai scaricare il codice sorgente di Nginx per compilare il modulo dinamico ModSecurity . Per fare ciò, dovrai scaricare e archiviare il pacchetto sorgente nella posizione della directory /etc/local/src/nginx .

Crea e configura directory

Crea la posizione come segue:

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

Facoltativo:assegnare l'autorizzazione alla directory, se necessario, come di seguito:

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

Installa dipendenze ed esegui download

Quindi, scarica il pacchetto sorgente con quanto segue:

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

Nota, vedrai il seguente messaggio di errore come di seguito:

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)

Questo può essere tranquillamente ignorato.

Verifica versione sorgente

Quindi, elenca i file delle directory con ls comando come segue:

ls

Dovresti vedere il seguente output nel tuo /usr/src/local/nginx directory:

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

Quindi, conferma che il pacchetto sorgente è lo stesso della tua versione di Nginx installata sul tuo sistema operativo Debian. A tale scopo, utilizza il seguente nginx -v comando come segue:

sudo nginx -v

La fonte che hai scaricato dovrebbe corrispondere alla versione binaria installata sul tuo sistema.

Esempio:

nginx version: nginx/1.21.1

Installa libmodsecurity3 per ModSecurity

Il pacchetto libmodsecurity3 è la parte effettiva del WAF che esegue il filtro HTTP per le tue applicazioni web Su Debian 11, puoi installarlo dal repository Debian 11 predefinito. Tuttavia, questo non è raccomandato come con la maggior parte delle versioni stabili e spesso è in ritardo. Invece, compilerai dalla fonte molto più aggiornata come segue.

Clone ModSecurity Repsoitory da Github

Il primo passo è il clone da Github e, se non hai git installato, dovrai eseguire il seguente comando:

apt install git -y

Quindi, clona il repository GIT di libmodsecurity3 come segue:

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

Una volta clonato, dovrai eseguire il CD alla directory:

cd /usr/local/src/ModSecurity/

Installa le dipendenze di libmodsecurity3

Per compilare, dovrai installare le seguenti dipendenze come segue:

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

Ora per finire, installa i seguenti sottomoduli GIT come segue:

git submodule init

Quindi aggiorna i sottomoduli:

git submodule update

Costruzione dell'ambiente ModSecurity

Il passaggio successivo è ora quello di creare prima l'ambiente. Usa il seguente comando:

./build.sh

Quindi, esegui il comando configure:

./configure

Nota, probabilmente vedrai il seguente errore:

fatal: No names found, cannot describe anything.

Puoi tranquillamente ignorarlo e passare al passaggio successivo.

Compilazione del codice sorgente di ModSecurity

Ora che hai creato e configurato l'ambiente per libmodsecurity3, è il momento di compilarlo con il comando make .

make

Un trucco pratico consiste nello specificare -j poiché ciò può aumentare significativamente la velocità di compilazione se si dispone di un server potente. Ad esempio, il server LinuxCapable ha 6 CPU e posso usarne tutte e 6 o almeno usarne da 4 a 5 per aumentare la velocità.

make -j 6

Dopo aver compilato il codice sorgente, ora esegui il comando di installazione nel tuo terminale:

make install

Nota, l'installazione viene eseguita in /usr/local/modsecurity/, a cui farete riferimento più avanti nella guida.

Installa il connettore ModSecurity-nginx

Il connettore ModSecurity-nginx è il punto di connessione tra nginx e libmodsecurity. Fondamentalmente, è il componente che comunica tra Nginx e ModSecurity (libmodsecurity3) .

Clone ModSecurity-nginx Repsoitory da Github

Simile al passaggio precedente della clonazione del repository libmodsecurity3, dovrai clonare nuovamente il repository del connettore utilizzando il comando seguente:

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

Installa le dipendenze ModSecurity-nginx

Quindi, directory del CD nella directory di origine di Nginx come segue:

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

Nota, sostituisci la versione della guida con la versione corrente di Nginx nel tuo sistema.

Ora, esegui il comando nel tuo terminale Debian per installare le dipendenze richieste:

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

Successivamente, compilerai il ModSecurity-nginx Connector modulo solo con –with-compat contrassegnare come segue:

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

Ora crea (crea) i moduli dinamici con il seguente comando:

make modules

Quindi, mentre sei nella directory di origine di Nginx, usa il comando seguente per spostare il modulo dinamico appena creato che è stato salvato nella posizione objs/ngx_http_modsecurity_module.so e copialo in /usr/share/nginx/modules directory.

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

Puoi memorizzare il modulo dinamico ovunque, purché specifichi il percorso completo durante il caricamento.

Carica e configura il connettore ModSecurity-nginx con il server Web Nginx

Ora che hai compilato il modulo dinamico e lo hai individuato di conseguenza, devi modificare il tuo /etc/nginx/nginx.conf file di configurazione per far funzionare ModSecurity con il tuo server web Nginx.

Abilita ModSecurity in nginx.conf

Innanzitutto, devi specificare load_module e il percorso del tuo modulo modsecurity.

Apri nginx.conf con qualsiasi editor di testo. Per il tutorial verrà utilizzato nano:

sudo nano /etc/nginx/nginx.conf

Quindi, aggiungi la seguente riga al file nella parte superiore:

load_module modules/ngx_http_modsecurity_module.so;

Se hai individuato il modulo altrove, assicurati di includere il percorso completo.

Ora aggiungi il seguente codice sotto HTTP{} sezione come segue:

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

SOLO esempio:

Se hai individuato il modulo altrove, assicurati di includere il percorso completo.

Salva nginx.conf file (CTRL+O), quindi esci da (CTRL+X) .

Crea e configura directory e file per ModSecurity

Dovrai creare una directory in cui archiviare i file di configurazione e le regole future, OWASP CRS per il tutorial.

Utilizzare il comando seguente per creare /etc/nginx/modsec directory come segue:

sudo mkdir /etc/nginx/modsec/

Ora devi copiare il file di configurazione ModSecurity di esempio dalla nostra directory GIT clonata:

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

Usando il tuo editor di testo preferito, apri il file modsecurity.conf come segue:

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

Per impostazione predefinita, la configurazione di ModSecurity ha il motore delle regole specificato come (DetectionOnly) , che in altre parole, esegue ModSecurity e rileva tutti i comportamenti dannosi ma non blocca o vieta l'azione e registra tutte le transazioni HTTP che contrassegna. Questo dovrebbe essere utilizzato solo se hai molti falsi positivi o hai aumentato le impostazioni del livello di sicurezza a un livello estremo e test per vedere se si verificano falsi positivi.

Per modificare questo comportamento in (attivo) , trova quanto segue alla riga 7 :

SecRuleEngine DetectionOnly

Cambia la riga in questa per abilitare ModSecurity:

SecRuleEngine On

Ora devi individuare quanto segue, che si trova sulla linea 224 :

# Log everything we know about a transaction.
SecAuditLogParts ABIJDEFHZ

Questo non è corretto e deve essere modificato. Modifica la riga come segue:

SecAuditLogParts ABCEFHJKZ

Ora salva il modsecurity.conf file utilizzando (CTRL+O) quindi esci da (CTRL+X) .

La parte successiva consiste nel creare il seguente file modsec-config.conf . Qui aggiungerai il modsecurity.conf archiviare insieme e successivamente su altre regole come OWASP CRS e, se utilizzi WordPress, il WPRS CRS insieme di regole.

Utilizzare il comando seguente per creare il file e aprirlo:

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

Una volta all'interno del file, aggiungi la seguente riga:

Include /etc/nginx/modsec/modsecurity.conf

Salva il modsec-config.conf file con (CTRL+O) quindi (CTRL+X) esci.

Infine, copia unicode.mapping di ModSecurity file con il CP comando come segue:

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

Ora, prima di andare avanti, dovresti eseguire un test a secco del tuo servizio Nginx con il seguente comando da terminale:

sudo nginx -t

Se hai impostato tutto correttamente, dovresti ottenere il seguente output:

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

Per rendere attive le modifiche, riavvia il servizio Nginx utilizzando il comando systemctl:

sudo systemctl restart nginx

Installa il set di regole di base OWASP per ModSecurity

ModSecurity da solo non protegge il tuo server web e devi avere delle regole. Una delle regole più famose, rispettate e conosciute è il set di regole OWASP CRS. Le regole sono le più utilizzate tra i server Web e altri WAF e la maggior parte degli altri sistemi simili basa la maggior parte delle proprie regole su questo CRS. L'installazione di questo set di regole ti fornirà automaticamente un'ottima fonte di protezione contro la maggior parte delle minacce emergenti su Internet rilevando gli attori malintenzionati e bloccandoli.

Utilizzando il comando wget, scarica l'archivio OWASP CRS 3.3.2 come segue:

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

Per coloro che vogliono vivere al limite, puoi scaricare la build notturna. Usa il nightly solo se sei pronto a continuare a ricompilare e controllare frequentemente CoreRuleSet Github per gli aggiornamenti ed essere più sicuro nel risolvere i problemi. Tecnicamente il nightly può essere più sicuro ma potenzialmente può creare problemi.

Per gli utenti inesperti, usa la versione stabile e non la versione seguente.

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

Installa il Decomprimi pacchetto se non lo hai installato sul tuo server:

sudo apt install unzip -y

Ora decomprimi il master.zip archiviare come segue:

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

Come prima, come modsecurity.conf configurazione di esempio, CRS OWASP viene fornito con un file di configurazione di esempio che è necessario rinominare. È meglio utilizzare il CP comando e conservane un backup per il futuro nel caso sia necessario riavviare di nuovo.

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

Per abilitare le regole, apri /etc/nginx/modsec/modsec-config.conf utilizzando di nuovo qualsiasi editor di testo:

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

Una volta all'interno del file, aggiungi le seguenti due righe aggiuntive:

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

Salva il file (CTRL+O) ed esci (CTRL+X) .

Come prima, devi testare eventuali nuove aggiunte al tuo servizio Nginx prima di renderlo attivo:

sudo nginx -t

Dovresti ottenere il seguente output, il che significa che tutto funziona correttamente:

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

Riavvia il tuo servizio Nginx per rendere attive le modifiche come segue:

sudo systemctl restart nginx

Utilizzo e comprensione di OWASP CRS

OWASP CRS ha molte opzioni, tuttavia, le impostazioni predefinite proteggeranno immediatamente la maggior parte dei server senza danneggiare i tuoi visitatori reali e buoni bot SEO. Di seguito, alcune aree saranno trattate per aiutare a spiegare. Un'ulteriore lettura sarebbe la cosa migliore per esaminare tutte le opzioni nei file di configurazione stessi poiché hanno un bel po' di dati di testo per spiegare cosa sono.

Apri il tuo CRS-setup.conf file come segue:

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

Nota, questa è la configurazione della versione di sviluppo con elementi aggiuntivi rispetto alla versione 3.3.

Da qui puoi modificare la maggior parte delle tue impostazioni OWASP CRS.

Punteggio CRS OWASP

Per scomporlo, ModSecurity ha due modalità:

Modalità punteggio anomalia

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

Modalità autonoma

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

Il punteggio delle anomalie è generalmente per la maggior parte degli utenti la modalità migliore da utilizzare.

Ci sono quattro livelli di paranoia:

• Paranoia livello 1 – Livello predefinito e consigliato per la maggior parte degli utenti.
• Paranoia livello 2 – Solo utenti avanzati.
• Paranoia livello 3 – Solo utenti esperti.
• Paranoia livello 4 – Non consigliato affatto, salvo circostanze eccezionali.

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

Testa OWASP CRS sul tuo server

Per verificare se OWASP CRS funziona sul tuo server, apri il tuo browser Internet e usa quanto segue:

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

Dovresti ricevere un errore vietato 403. In caso contrario, un passaggio è stato perso.

Il problema più comune manca per modificare Solo rilevamento su Attivo come spiegato in precedenza nel tutorial.

Gestire i falsi positivi e l'esclusione di regole personalizzate

Uno dei compiti spesso senza fine è gestire i falsi positivi, ModSecurity e OWASP CRS fanno un ottimo lavoro insieme, ma a scapito del tuo tempo, ma data la protezione, ne vale la pena. Tanto per cominciare, la regola d'oro non è mai alzare il livello di paranoia.

Una buona regola pratica è eseguire la regola impostata per alcune settimane o mesi senza quasi nessun falso positivo, quindi aumentare, ad esempio, il livello di paranoia 1 al livello di paranoia 2, in modo da non essere sommerso da una tonnellata contemporaneamente.

Escluse le domande note di falsi positivi

Modsecurity, per impostazione predefinita, può inserire nella whitelist le azioni quotidiane che portano a falsi positivi come di seguito:

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

Per abilitare, ad esempio, WordPress, phpBB e phpMyAdmin mentre li usi tutti e tre, decommenta le righe e lascia il (1) numero intatto, cambia gli altri servizi che non utilizzi, ad esempio Xenforo in (0) poiché non vuoi autorizzare queste regole.

Esempio sotto:

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"

Puoi anche modificare la sintassi, che sarebbe più pulita. Ad esempio:

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"

Come puoi vedere, sono state rimosse le opzioni non necessarie e aggiunte (“) alla fine di WordPress per la sintassi corretta.

Esclusione delle regole in Before CRS

Per gestire le esclusioni personalizzate, in primo luogo, devi cambiare il nome da REQUEST-900-EXCLUSION-RULES-BEFORE-CRS-SAMPLE.conf file con il comando cp come segue:

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

Un punto da ricordare, quando si creano regole di esclusione, ognuna deve avere id: ed essere univoca, altrimenti quando testerai il tuo servizio Nginx, riceverai un errore. Esempio “id:1544,phase:1,log,allow,ctl:ruleEngine=off” , l'id 1544 non può essere utilizzato per una seconda regola.

Ad esempio, alcuni REQUEST_URI genereranno falsi positivi. L'esempio seguente è due con il beacon pagespeed di Google e il plug-in WMUDEV per 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"

Come puoi vedere, qualsiasi URL che inizia con il percorso sarà automaticamente consentito.

Un'altra opzione è autorizzare gli indirizzi IP, alcuni modi per farlo:

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"

Il @ipMatch può essere utilizzato in modo più esteso per le sottoreti. Se desideri negare una sottorete o indirizzo IP cambiare, permettere di negare. Con un po' di know-how, puoi anche creare blacklist e whitelist e configurarlo con fail2ban . Le possibilità spesso possono essere infinite.

Un ultimo esempio consiste nel disabilitare solo le regole che attivano falsi positivi, non inserendo nella whitelist l'intero percorso, come hai visto con il primo esempio di REQUEST_URI. Tuttavia, questo richiede più tempo e test. Ad esempio, vuoi rimuovere le regole 941000 e 942999 dalla tua area /admin/ in quanto continua ad attivare falsi ban e blocchi per il tuo team, trova nel file di log di modsecurity l'ID della regola e quindi disabilita solo quell'ID con RemoveByID come nell'esempio seguente:

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

Esempi possono essere trovati sulla pagina wiki ModSecurity GIT; LinuxCapable, in futuro, creerà un tutorial su questa parte poiché c'è un bel po' di cose da trattare.

Facoltativo:includi Project Honeypot

Progetto Honey Pot è il primo e unico sistema distribuito per identificare gli spammer e gli spambot che utilizzano per raschiare gli indirizzi dal tuo sito web. Utilizzando il sistema Project Honey Pot, puoi installare indirizzi con tag personalizzati sull'ora e sull'indirizzo IP di un visitatore del tuo sito. Se uno di questi indirizzi inizia a ricevere e-mail, possiamo dire che i messaggi sono spam, il momento esatto in cui l'indirizzo è stato raccolto e l'indirizzo IP che lo ha raccolto.

ModSecurity può avere la possibilità di integrare Project Honeypot, che interrogherà il database e bloccherà tutti gli indirizzi che si trovano nella blacklist di HoneyPot. Nota, l'utilizzo di questo può portare a falsi positivi, ma nel complesso è considerato molto affidabile rispetto ad alternative simili.

Passaggio 1. Crea un account un account gratuito.

Passaggio 2. Dopo esserti registrato e aver effettuato l'accesso, nella dashboard, trova la riga (Your http:BL API key) e fai clic su prendine uno .

Passaggio 3. Torna al file CRS-setup.conf aprendolo utilizzando un editor di testo:

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

Passaggio 4. Trova la riga che inizia con #SecHttpBlKey, che è sulla linea 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"

Step 5. Change the SecHttpBlKey XXXXXXXXXXXXXXXXX with your key from Project HoneyPot.

Esempio:

SecHttpBlKey amhektvkkupe

Step 6. Next, uncomment all the lines to enable the rule. To deactivate a rule, instead of (1), put (0) instead if you wish to have any of the rules disabled. By default, block_search_ip=0 is for search engine bots, do not enable this unless you want Bing, Google, and other good bots coming to your site.

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 giorni. 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.