Come installare e configurare ModSecurity con Nginx su Debian 11

ModSecurity o spesso indicato come 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 di richieste e risposte di 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 in combinazione con il Set di regole base OWASP (CRS), un insieme di regole open source scritte nel linguaggio SecRules di ModSecurity ed è molto apprezzato nel settore della sicurezza.

Il set di regole OWASP con ModSecurity può aiutare quasi istantaneamente a proteggere il tuo server da:

  • Cattivi agenti utente
  • DDOS
  • Script di siti web incrociati
  • SQL Injection
  • Dirottamento di sessione
  • Altre minacce

Nel seguente tutorial imparerai come installare ModSecurity con Nginx su Debian 11.

Prerequisiti

  • Sistema operativo consigliato: Debian 11 Bullseye
  • Account utente: Un account utente con privilegi sudo or accesso root (comando su).
  • Pacchetti richiesti: arricciare

Aggiornamento del sistema operativo

Aggiorna il tuo Debian 11 sistema operativo per assicurarsi che tutti i pacchetti esistenti siano aggiornati:

sudo apt update && sudo apt upgrade

Accesso root o sudo

Per impostazione predefinita, quando crei il tuo account all'avvio con Debian rispetto ad altre distribuzioni, non riceve automaticamente lo stato di sudoers. Devi avere accesso a password di root usare il comando su o visita il nostro tutorial su Come aggiungere un utente a Sudoers su Debian.

Installa il pacchetto CURL

Il tutorial utilizzerà il pacchetto curl; per prima cosa verifica se il pacco è presente:

curl --version

Esempio di output se installato:

curl 7.74.0 (x86_64-pc-linux-gnu) libcurl/7.74.0 OpenSSL/1.1.1k zlib/1.2.11 brotli/1.0.9 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.43.0 librtmp/2.3
Release-Date: 2020-12-09

Se non hai curl installato, usa il seguente comando:

sudo apt install curl -y

pubblicità


Installa l'ultimo Nginx stabile o principale

Innanzitutto, si consiglia di rimuovere eventuali installazioni esistenti di Nginx e installa l'ultima Versione stabile o principale di Nginx.

Rimuovere l'installazione di Nginx esistente

Interrompi 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 l'ultimo repository e installazione di Nginx

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

Per importare il repository 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 potrebbe esserti richiesto di mantenere o sostituire il tuo esistente / etc / nginx /nginx.conf file di configurazione durante l'installazione. Si consiglia di conservare il file di configurazione esistente premendo (N). Verrà fatta una copia indipendentemente dalla versione del manutentore, e puoi anche verificarlo in futuro.

Aggiungi il codice sorgente Nginx al repository

Quando si installa l'ultima versione di Nginx mainline o stabile per impostazione predefinita, viene installato solo il binario. Tuttavia, avrai bisogno del sorgente per compilare Modsecurity più avanti nel tutorial.

Per prima cosa, 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 apparire (solo esempio principale):

Come installare e configurare ModSecurity con Nginx su Debian 11

Scarica Nginx Source

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

Creare e configurare directory

Crea la posizione come segue:

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

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

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

Installa le dipendenze ed esegui il 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 la versione di origine

Quindi, elenca i file delle directory con il 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. Per fare ciò, utilizzare quanto segue 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

pubblicità


Installa libmodsecurity3 per ModSecurity

Il pacchetto libmodsecurity3 è la parte effettiva del WAF che fa il Filtraggio 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 che è molto più aggiornata come segue.

Clona 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 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 CD alla rubrica:

cd /usr/local/src/ModSecurity/

Installa libmodsecurity3 Dipendenze

Per compilare, sarà necessario 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

Costruire l'ambiente ModSecurity

Il prossimo passo è ora quello di costruire prima l'ambiente. Usa il seguente comando:

./build.sh

Quindi, esegui il comando configure:

./configure

Nota, potresti vedere il seguente errore:

fatal: No names found, cannot describe anything.

Puoi tranquillamente ignorarlo e passare al passaggio successivo.

Compilazione del codice sorgente ModSecurity

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

make

Un trucco pratico è specificare il -J in quanto ciò può aumentare notevolmente la velocità di compilazione se si dispone di un server potente. Ad esempio, il server LinuxCapable ha 6 CPU e posso usarle 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 nel /usr/local/modsecurity/, a cui farete riferimento più avanti nella guida.

Installa il connettore ModSecurity-nginx

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

Clona ModSecurity-nginx Repsoitory da Github

Simile al passaggio precedente per la clonazione del repository libmodsecurity3, sarà necessario clonare nuovamente il repository del connettore utilizzando il seguente comando:

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

Installa le dipendenze ModSecurity-nginx

Quindi, la directory del CD nella directory dei sorgenti di Nginx come segue:

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

Nota, sostituisci la versione della guida con l'attuale versione 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 Connettore ModSecurity-nginx modulo solo con il -con-compat bandiera come segue:

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

ORA make (creare) i moduli dinamici con il seguente comando:

make modules

Successivamente, mentre sei nella directory dei sorgenti di Nginx, usa il seguente comando 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/

È possibile memorizzare il modulo dinamico ovunque, purché si specifichi il percorso completo durante il caricamento.


pubblicità


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

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

In primo luogo, è necessario specificare load_module e il percorso del tuo modulo modsecurity.

Aprire 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 il HTTP {} sezione come segue:

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

SOLO esempio:

Come installare e configurare ModSecurity con Nginx su Debian 11

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

Salvare l' nginx.conf filetto (CTRL+O), poi esci (CTRL+X).

Crea e configura directory e file per ModSecurity

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

Utilizzare il seguente comando per creare il /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 (Solo rilevamento), che in altre parole, esegue ModSecurity e rileva tutti i comportamenti dannosi, ma non blocca o vieta azioni e registra tutte le transazioni HTTP contrassegnate. Questo dovrebbe essere usato solo se hai molti falsi positivi o hai aumentato le impostazioni del livello di sicurezza a un livello estremo e testando per vedere se si verificano falsi positivi.

Per modificare questo comportamento in (sopra), trova quanto segue su Linea 7:

SecRuleEngine DetectionOnly

Cambia la riga in questo per abilitare ModSecurity:

SecRuleEngine On

Ora, devi individuare quanto segue, che si trova su Linea 224:

# Log everything we know about a transaction.
SecAuditLogParts ABIJDEFHZ

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

SecAuditLogParts ABCEFHJKZ

Ora salva il modsecurity.conf L'utilizzo di file (CTRL+O) poi esci (CTRL+X).

La parte successiva è creare il seguente file modsec-config.conf. Qui aggiungerai il modsecurity.conf file insieme e in seguito su altre regole come OWASP CRS, e se stai usando WordPress, il WPRS CRS insieme di regole.

Utilizzare il seguente comando 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

Salvare l' modsec-config.conf file con (CTRL+O) poi (CTRL+X) uscire.

Infine, copia ModSecurity's unicode.mapping depositare presso la CP comando come segue:

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

Ora, prima di andare avanti, dovresti dare al tuo servizio Nginx una prova 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 principali di OWASP per ModSecurity

ModSecurity da solo non protegge il tuo server web e devi avere regole. Una delle regole più famose, rispettate e conosciute è il Set di regole CRS OWASP. Le regole qui sono le più utilizzate tra i server Web e altri WAF. In effetti, e la maggior parte degli altri sistemi simili basano la maggior parte delle loro 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.

È degno di nota che OWASP CRS ha normalmente versioni stabili, che spesso impiegano circa un anno tra i rilasci. La versione attuale è la 3.3.3. Il problema è che le regole più recenti su cui si è lavorato per miglioramenti, nuovi rilevamenti, rimozione di falsi positivi e inclusione di nuove esclusioni per software comuni come i forum phpBB introdotti nella versione per sviluppatori 3.3.4 (beta) non sono incluse fino alla prossima versione completa .

Lo svantaggio può essere visto in due modi, usare il pacchetto 3.3.3, avere regole eccellenti stabili ma possibilmente non essere aggiornate per le ultime minacce, correzioni e miglioramenti ma usando la versione dev 3.3.4, avrai tutto questo ma forse potrebbero verificarsi altri problemi, tuttavia, questo è raro poiché prima che il team del set di regole OWASP Core inserisca nuovi impegni nel repository principale, ha riunioni mensili per discutere le modifiche così spesso non è solo un individuo a chiamare ma un intero team rivedere le modifiche e approvarlo come collettivo normalmente rendendo la versione dev abbastanza stabile.

Nel tutorial verranno trattati entrambi e sta a te decidere come procedere. Assicurati, in ogni caso, di monitorare i tuoi registri ModSecurity indipendentemente dai problemi, specialmente in caso di falsi positivi.

Opzione 1. Installa OWASP CRS 3.3 (Stabile)

Usando il comando wget, scarica il Archivio OWASP CRS 3.3 come segue:

wget https://github.com/coreruleset/coreruleset/archive/refs/heads/v3.3/master.zip

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

sudo apt install unzip -y

Ora decomprimi l'archivio come segue:

sudo unzip /etc/nginx/master.zip -d /etc/nginx/modsec

Come prima, come la configurazione di esempio di modsecurity.conf, OWASP CRS viene fornito con un file di configurazione di esempio che è necessario rinominare. È meglio usare il CP command e conserva un backup per il futuro nel caso in cui sia necessario riavviare di nuovo.

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

Per abilitare le regole, apri il /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-master/crs-setup.conf
Include /etc/nginx/modsec/coreruleset-3.3-master/rules/*.conf

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

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

sudo nginx -t

Dovresti ottenere il seguente output 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

pubblicità


Opzione 2. Installa OWASP CRS 3.3.4 (dev)

Nota, usando il 3.4 deve sarà necessario monitorare costantemente il repository per le modifiche. Spesso le nuove aggiunte arrivano da poche volte al mese a poche volte a settimana. Se non hai l'impegno o non sei sicuro, installa l'opzione 1 e salta del tutto questa opzione.

Usando il comando wget, scarica il Archivio OWASP CRS 3.4 come segue:

wget https://github.com/coreruleset/coreruleset/archive/refs/heads/v3.4/dev.zip

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

apt install unzip -y

Ora decomprimi il dev.zip archiviare come segue:

unzip dev.zip -d /etc/nginx/modsec

Come prima, come la configurazione di esempio di modsecurity.conf, OWASP CRS viene fornito con un file di configurazione di esempio che è necessario rinominare. È meglio usare il Comando CP e conserva un backup per il futuro nel caso in cui sia necessario riavviare di nuovo.

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

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

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.4-dev/crs-setup.conf
Include /etc/nginx/modsec/coreruleset-3.4-dev/rules/*.conf

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

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

sudo nginx -t

Dovresti ottenere il seguente output 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

Aggiornamento 3.3.4-dev

Se hai bisogno di aggiornare le regole per la versione dev OWASP CRS, scarica nuovamente l'archivio come il primo passo ed estrai nuovamente i file. I file progettati per essere modificati non verranno sostituiti, ecco perché hai visto così tante pagine di esempio durante l'installazione.

Utilizzo e comprensione di OWASP CRS

OWASP CRS ha molte opzioni, le impostazioni predefinite, tuttavia, pronte all'uso, proteggeranno immediatamente la maggior parte dei server senza danneggiare i tuoi visitatori reali e buoni SEO bot. Di seguito, verranno trattate alcune aree per aiutare a spiegare. Un'ulteriore lettura sarebbe la cosa migliore per investigare tutte le opzioni nei file di configurazione stessi in quanto 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 dev con elementi aggiuntivi rispetto alla versione 3.3.

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

Punteggio OWASP CRS

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 di anomalia è normalmente 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 – Assolutamente sconsigliato, 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.

Prova 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 403 errore proibito. In caso contrario, è stato perso un passaggio.

Il problema più comune è la mancanza di cambiare Solo rilevamento a Sopra, come spiegato in precedenza nel tutorial.

Gestire i falsi positivi e l'esclusione delle regole personalizzate

Uno dei compiti spesso infiniti è gestire i falsi positivi, ModSecurity e OWASP CRS fanno un ottimo lavoro insieme, ma ti costa tempo, ma data la protezione, ne vale la pena. Per cominciare, non mettere mai il livello di paranoia in alto per cominciare è la regola d'oro.

Una buona regola pratica è eseguire il set di regole 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 sommersi da una tonnellata contemporaneamente.

Esclusione delle applicazioni note di falsi positivi

Modsecurity per impostazione predefinita ha la capacità di autorizzare azioni comuni 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 usi tutti e tre, decommenta le righe e lascia il file (1) numero intatto, cambia gli altri servizi che non usi, ad esempio Xenforo in (0) poiché non desideri inserire nella whitelist queste regole.

Esempio di seguito:

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. Per 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 di regole in Prima del CRS

Per gestire le esclusioni personalizzate, in primo luogo, è necessario modificare il nome da RICHIESTA-900-ESCLUSIONE-REGOLE-BEFORE-CRS-SAMPLE.conf depositare presso la 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 univoco, altrimenti quando testerai il tuo servizio Nginx, otterrai un errore. Esempio “id:1544,fase:1,log,consenti,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 Google pagespeed beacon e 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 è quella di inserire nella whitelist 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"

I @ipMatch può essere utilizzato più ampiamente per le sottoreti. Se vuoi negare un sottorete or Indirizzo IP cambiare, permettere di negare. Puoi anche, con un po' di know-how, creare blacklist e whitelist e configurarle con fail2ban. Le possibilità possono essere spesso infinite.

Un ultimo esempio è disabilitare solo le regole che attivano falsi positivi, non inserire in whitelist l'intero percorso, come hai visto con il primo esempio REQUEST_URI. Tuttavia, questo richiede più tempo e test. Ad esempio, vuoi rimuovere le regole 941000 , che collaborano con noi, attingono direttamente dalla storia e dalla tradizione veneziana 942999 dalla tua area /admin/ poiché continua a innescare falsi ban e blocchi per la tua squadra, trova nel tuo file di log di modsecurity l'ID della regola e quindi disabilita solo quell'ID con Rimuovi per ID come l'esempio qui sotto:

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

Esempi possono essere trovati su ModSecurity GIT pagina wiki; LinuxCapable, in futuro, creerà un tutorial su questa parte poiché c'è molto da coprire.

Opzionale – Includi progetto Honeypot

Progetto Honey Pot è il primo e unico sistema distribuito per identificare gli spammer e gli spambot che usano per estrarre 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, non solo possiamo dire che i messaggi sono spam, ma anche 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 presenti nella blacklist di HoneyPot. Nota, l'utilizzo di questo può portare a falsi positivi. Tuttavia, questo è piccolo in quanto i dati sono affidabili, ma a volte i buoni bot vengono principalmente contrassegnati, quindi fai attenzione.

L'altro problema utilizzando questo servizio con ModSecurity è che la prima volta che un visitatore arriva sul tuo sito, i tempi di caricamento preziosi e spesso critici per i nuovi visitatori saranno più lenti perché il tuo server web invierà a interrogare Project Honeypot e attenderà una risposta. In futuro, una volta inviato l'IP, la risposta inviata viene memorizzata nella cache, rendendo più rapida la visita successiva. Tuttavia, data così tanta enfasi sui tempi di caricamento con la SEO, alcuni potrebbero non godere del tempo di caricamento extra, non importa quanto sia minimo.

Passo 1. Crea un account a account gratuito.

Passo 2. Dopo esserti registrato e aver effettuato l'accesso, sulla dashboard, trova la linea (La tua chiave API http:BL) e fare clic su prendine uno.

Passo 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

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

Passo 5. Cambia SecHttpBlKey XXXXXXXXXXXXXXXXX con la tua chiave da Project HoneyPot.

Esempio:

SecHttpBlKey amhektvkkupe

Passo 6. Quindi, decommenta tutte le righe per abilitare la regola. Se vuoi disattivare una regola, invece di (1) metti (0) invece se vuoi disabilitare una qualsiasi delle regole. Per impostazione predefinita, block_search_ip=0 è per i bot dei motori di ricerca, non abilitarlo a meno che tu non voglia che Bing, Google e altri buoni bot arrivino al tuo sito.

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"

Nota, non usare amhektvkkupe. Utilizzo la tua chiave invece!

Passo 7. Prova Nginx per assicurarti che non si siano verificati errori con quanto segue:

sudo nginx -t

Esempio di output se tutto corretto:

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

Ora riavvia il tuo servizio Nginx:

sudo systemctl restart nginx

pubblicità


Set di regole WPRS di WordPress per ModSecurity

Un'altra opzione per WordPress utenti deve installare ed eseguire insieme al set di regole CRS OWASP, un noto progetto intitolato set di regole WPRS. Poiché questo è facoltativo e non è per tutti, il tutorial non lo tratterà in questa sezione. Tuttavia, se desideri installarlo per una protezione extra se utilizzi WordPress sul tuo server, visita il nostro tutorial su Installazione di WordPress ModSecurity Rule Set (WPRS).

Crea il file ModSecurity LogRotate:

ModSecurity, dato il numero di righe e informazioni che può registrare, crescerà abbastanza rapidamente. Poiché stai compilando il modulo e non è installato tramite alcun repository ufficiale di Debian, dovrai creare il tuo file di rotazione del registro.

Innanzitutto, crea e apri il tuo file di rotazione ModSecurity modsec:

sudo nano /etc/logrotate.d/modsec

Aggiungi il seguente codice:

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

Ciò manterrà i registri per 31 giorni. Se preferisci avere meno, cambia 31 dire 7 giorni pari a una settimana di log. Dovresti ruotare ogni giorno per ModSecurity. Se hai bisogno di rivedere i file di registro avere un file settimanale sarà un disastro da vagliare, data la sua grandezza.


pubblicità


Domande comuni

Come disabilitare temporaneamente Modsecurity

Per disabilitare temporaneamente Modsecurity, apri il tuo file di configurazione nginx.conf e modifica la seguente riga:

Cambio da:

modsecurity on;

Cambia in:

modsecurity off;

Aggiornamenti Nginx

Quando le nuove versioni di Nginx mainline o stable arrivano e vengono scaricate e installate, ciò interromperà l'installazione di Nginx poiché hai compilato il modulo dinamico utilizzando una versione precedente; tutto ciò che devi fare è ripetere il download del sorgente nginx aggiornato e ricompilare di nuovo e spostare il nuovo modulo modsecurity e sostituire quello esistente.

In alternativa, puoi interrompere l'applicazione degli aggiornamenti di Nginx, e questo è per fermare quei momenti di brainfarts che a volte tutti noi abbiamo:

sudo apt-mark hold nginx

Ti verrà comunicato che alcuni pacchi sono stati trattenuti. Durante questo tempo, ricompilare il nuovo modulo, quindi staccare l'aggiornamento di Nginx e aggiorna la tua versione binaria di Nginx all'ultima versione in offerta:

Rimuovi Nginx:

apt-mark unhold nginx

Ora aggiorna nginx:

apt upgrade nginx

Il comando utile per sapere se non sei sicuro di quali pacchetti siano conservati è da usare:

apt-mark showhold

Questo ti mostrerà se la tua attesa Nginx è ancora attiva o meno e con qualsiasi altro pacchetto che hai in attesa.

Commenti e Conclusione

Nel tutorial, hai una conoscenza dell'installazione del sorgente Nginx, della compilazione di ModSecurity e dell'impostazione delle regole OWASP tra le parti principali. Nel complesso, l'implementazione di ModSecurity sul tuo server fornirà una protezione istantanea. Tuttavia, la pazienza, il tempo e la dedizione nell'apprendimento dovranno essere una caratteristica così eccezionale. L'ultima cosa che vuoi è bloccare i bot SEO o, cosa più importante, gli utenti reali che potrebbero essere potenziali clienti.

Sottoscrivi
Notifica
0 Commenti
Feedback in linea
Visualizza tutti i commenti
0
Amerei i tuoi pensieri, per favore commenta.x