Questo tutorial ti mostrerà come installare e utilizzare ModSecurity con Nginx su server Debian/Ubuntu. ModSecurity è il più noto firewall per applicazioni Web open source (WAF), fornendo una protezione completa per le tue applicazioni web (come WordPress, Nextcloud, Ghost ecc.) contro un'ampia gamma di attacchi Layer 7 (HTTP), come SQL injection, cross-site scripting e inclusione di file locali.
Nota :questo tutorial funziona su tutte le versioni correnti di Debian e Ubuntu, inclusi Debian 10, Ubuntu 18.04, Ubuntu 20.04 e Ubuntu 20.10.
Le applicazioni Web sono intrinsecamente insicure. Se sei un amministratore di WordPress, probabilmente sentirai notizie di hacker che sfruttano le vulnerabilità nei plugin e nei temi di WordPress ogni tanto. È essenziale distribuire un WAF sul tuo server web, soprattutto quando hai vecchie applicazioni che non ricevono aggiornamenti. ModSecurity è stato originariamente creato da Ivan Ristić nel 2002, attualmente gestito da Trustwave SpiderLabs. È il WAF più diffuso al mondo, utilizzato da oltre un milione di siti Web. cPanel, il pannello di controllo dell'hosting più utilizzato, include ModSecurity come WAF.
Potresti aver sentito altri firewall basati su host come iptables, UFW e Firewalld, ecc. La differenza è che funzionano sui livelli 3 e 4 del modello OSI e intraprendono azioni in base all'indirizzo IP e al numero di porta. ModSecurity, o in generale i firewall delle applicazioni web, è specializzato per concentrarsi sul traffico HTTP (livello 7 del modello OSI) e agisce in base al contenuto della richiesta e della risposta HTTP.
ModSecurity 3
ModSecurity è stato originariamente progettato per il server Web Apache. Potrebbe funzionare con Nginx prima della versione 3.0 ma soffriva di scarse prestazioni. ModSecurity 3.0 (noto anche come libmodsecurity ) è stato rilasciato nel 2017. È una versione fondamentale, in particolare per gli utenti di Nginx, poiché è la prima versione a funzionare in modo nativo con Nginx. L'avvertenza di ModSecurity 3 è che non ha ancora tutte le funzionalità della versione precedente (2.9), anche se ogni nuova versione aggiungerà alcune delle funzionalità mancanti.
Passaggio 1:installa l'ultima versione di Nginx su Debian/Ubuntu
ModSecurity si integra con Nginx come modulo dinamico, che consente di compilare il codice sorgente dei singoli moduli senza compilare Nginx stesso.
Il binario Nginx deve essere compilato con --with-compat argomento, che renderà i moduli dinamici binari compatibili con il tuo binario Nginx esistente. Tuttavia, non tutti i binari di Nginx forniti dal repository Debian/Ubuntu predefinito sono compilati con --with-compat discussione. Per semplificare le cose, possiamo installare l'ultima versione di Nginx da ondrej/nginx-mainline PPA, che è gestito da uno sviluppatore Debian.
Nota :Il repository nginx.org fornisce anche l'ultima versione di Nginx. Tuttavia, il ondrej/nginx-mainline PPA fornisce moduli dinamici aggiuntivi che potresti trovare utili, come il modulo Brotli.
Ubuntu
Se usi Ubuntu 16.04, 18.04, 20.04 o 20.10, esegui i seguenti comandi per installare l'ultima versione di Nginx.
sudo add-apt-repository ppa:ondrej/nginx-mainline -y sudo apt update sudo apt install nginx-core nginx-common nginx nginx-full
Durante il processo di installazione, potrebbe dirti che il distributore del pacchetto ha spedito una versione aggiornata del file di configurazione principale. Si consiglia di premere n per mantenere la tua versione attuale. Puoi sempre esaminare la differenza in un secondo momento.
Per impostazione predefinita, è abilitato solo il repository binario. Dobbiamo anche abilitare il repository del codice sorgente per scaricare il codice sorgente di Nginx. Modifica il file del repository della linea principale di Nginx.
sudo nano /etc/apt/sources.list.d/ondrej-ubuntu-nginx-mainline-*.list
Trova la riga che inizia con # deb-src .
# deb-src http://ppa.launchpad.net/ondrej/nginx-mainline/ubuntu/ focal main
Rimuovi il # carattere per abilitare questo repository di codice sorgente.
deb-src http://ppa.launchpad.net/ondrej/nginx-mainline/ubuntu/ focal main
Salva e chiudi il file. Quindi aggiorna l'indice del repository.
sudo apt update
Debian
Se usi Debian 10 o Debian 11, esegui i seguenti comandi per installare l'ultima versione di Nginx.
curl -sSL https://packages.sury.org/nginx-mainline/README.txt | sudo bash -x sudo apt update sudo apt install nginx-core nginx-common nginx nginx-full
Durante il processo di installazione, potrebbe dirti che il distributore del pacchetto ha spedito una versione aggiornata del file di configurazione principale. Si consiglia di premere n per mantenere la tua versione attuale. Puoi sempre esaminare la differenza in un secondo momento.
Per impostazione predefinita, è abilitato solo il repository binario. Dobbiamo anche abilitare il repository del codice sorgente per scaricare il codice sorgente di Nginx. Modifica il file del repository della linea principale di Nginx.
sudo nano /etc/apt/sources.list.d/nginx-mainline.list
Dovresti trovare una singola riga che abilita il repository binario Nginx. Aggiungi la riga seguente per abilitare il repository del codice sorgente Nginx su Debian 10.
deb-src https://packages.sury.org/nginx-mainline/ buster main
Se usi Debian 11, aggiungi invece la seguente riga.
deb-src https://packages.sury.org/nginx-mainline/ bullseye main
Salva e chiudi il file. Quindi aggiorna l'indice del repository.
sudo apt update
Controllo Nginx Configura argomenti
Ora controlla gli argomenti di configurazione di Nginx con il seguente comando:
sudo nginx -V
Tutti i binari Nginx nel PPA sono compilati con --with-compat argomento.
Fase 2:scarica il pacchetto sorgente Nginx
Sebbene non sia necessario compilare Nginx stesso, abbiamo bisogno del pacchetto di codice sorgente Nginx per compilare il modulo dinamico ModSecurity. Esegui il comando seguente per creare un nginx directory in /usr/local/src/ per memorizzare il pacchetto di codice sorgente Nginx. Sostituisci username con il tuo vero nome utente.
sudo chown username:username /usr/local/src/ -R mkdir -p /usr/local/src/nginx
cd nella directory di origine di Nginx.
cd /usr/local/src/nginx/
Scarica il pacchetto sorgente Nginx con i comandi seguenti:
sudo apt install dpkg-dev apt source nginx
Se vedi il seguente messaggio di avviso, puoi tranquillamente ignorarlo.
W: Download is performed unsandboxed as root as file 'nginx_1.19.5.orig.tar.gz' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
Dai un'occhiata ai file del codice sorgente scaricati.
ls
Esempio di output:
nginx-1.19.5 nginx_1.19.5-3+ubuntu20.04.1+deb.sury.org+1.debian.tar.xz nginx_1.19.5-3+ubuntu20.04.1+deb.sury.org+1.dsc nginx_1.19.5.orig.tar.gz
Assicurati che la versione del codice sorgente sia la stessa della tua versione binaria di Nginx (sudo nginx -v ).
Fase 3:installa libmodsecurity3
libmodsecurity è la libreria ModSecurity che esegue effettivamente il filtraggio HTTP per le tue applicazioni web. Su Debian 10 e Ubuntu 20.04, 20.10, puoi installarlo con sudo apt install libmodsecurity3 , ma ti consiglio di compilarlo dal sorgente.
Per compilare libmodsecurity , prima clona il codice sorgente da Github.
sudo apt install git git clone --depth 1 -b v3/master --single-branch https://github.com/SpiderLabs/ModSecurity /usr/local/src/ModSecurity/ cd /usr/local/src/ModSecurity/
Installa le dipendenze di build.
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
Installa i sottomoduli richiesti.
git submodule init git submodule update
Configura l'ambiente di compilazione.
./build.sh ./configure
Se vedi il seguente errore, puoi ignorarlo.
fatal: No names found, cannot describe anything.
Compila il codice sorgente con il comando seguente. Per impostazione predefinita, make utilizzerà solo un core della CPU. Ho 4 core CPU sul mio server, quindi specifico 4 job (-j4 ) per make per velocizzare il processo di compilazione. Cambia 4 al tuo numero di core della CPU.
make -j4
Dopo il make comando terminato senza errori, installa il binario.
sudo make install
Verrà installato in /usr/local/modsecurity/ directory.
Risoluzione dei problemi di compilazione
errore n. 1
Se viene visualizzato il seguente errore durante l'esecuzione di make comando, è probabilmente perché il tuo server ha esaurito la RAM.
g++: internal compiler error: Killed (program cc1plus)
Le seguenti righe in /var/log/syslog file indica che il server ha esaurito la memoria, quindi valuta la possibilità di aggiornare le specifiche del server.
In alternativa, puoi creare spazio di scambio per risolvere il problema di memoria insufficiente. Tuttavia, dovrebbe essere utilizzato solo come misura temporanea. L'utilizzo dello spazio di swap sui server SSD può essere dannoso per le prestazioni del sistema.
errore n. 2
Se viene visualizzato il seguente errore durante la compilazione di ModSecurity,
utils/geo_lookup.cc: In member function ‘bool modsecurity::Utils::GeoLookup::lookup(const string&, modsecurity::Transaction*, std::function<bool(int, const std::__cxx11::basic_string<char>&)>) const’: utils/geo_lookup.cc:124:32: error: invalid conversion from ‘const MMDB_s*’ to ‘MMDB_s*’ [-fpermissive] r = MMDB_lookup_string(&mmdb, target.c_str(), &gai_error, &mmdb_error);
Probabilmente è perché hai installato una versione obsoleta di libmaxminddb-dev . Puoi rimuovere questo pacchetto.
sudo apt remove libmaxminddb-dev
E installa libgeoip-dev , che è un'alternativa a libmaxminddb-dev .
sudo apt install libgeoip-dev
Quindi ricompila ModSecurity.
make clean ./configure make -j4
Installa il binario.
sudo make install
Fase 4:scarica e compila il codice sorgente del connettore Nginx ModSecurity v3
Il connettore ModSecurity Nginx link libmodsecurity al server web Nginx. Clona il repository Git di ModSecurity v3 Nginx Connector.
git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git /usr/local/src/ModSecurity-nginx/
Assicurati di essere nella directory di origine di Nginx.
cd /usr/local/src/nginx/nginx-1.19.5/
Installa le dipendenze di build per Nginx.
sudo apt build-dep nginx sudo apt install uuid-dev
Quindi, configura l'ambiente con il comando seguente. Non compileremo Nginx stesso, ma compileremo il ModSecurity Nginx Connector solo modulo. Il --with-compat flag renderà il modulo binario compatibile con il tuo binario Nginx esistente.
./configure --with-compat --add-dynamic-module=/usr/local/src/ModSecurity-nginx
Crea il Connettore ModSecurity Nginx modulo.
make modules
Il modulo verrà salvato come objs/ngx_http_modsecurity_module.so . Copialo in /usr/share/nginx/modules/ directory.
sudo cp objs/ngx_http_modsecurity_module.so /usr/share/nginx/modules/
Fase 5:carica il modulo connettore Nginx ModSecurity v3
Modifica il file di configurazione principale di Nginx.
sudo nano /etc/nginx/nginx.conf
Aggiungi la riga seguente all'inizio del file.
load_module modules/ngx_http_modsecurity_module.so;
Inoltre, aggiungi le seguenti due righe in http {...} sezione, quindi ModSecurity sarà abilitato per tutti gli host virtuali Nginx.
modsecurity on; modsecurity_rules_file /etc/nginx/modsec/main.conf;
Salva e chiudi il file. Quindi, crea il /etc/nginx/modsec/ directory in cui memorizzare la configurazione di ModSecurity
sudo mkdir /etc/nginx/modsec/
Quindi copia il file di configurazione di ModSecurity.
sudo cp /usr/local/src/ModSecurity/modsecurity.conf-recommended /etc/nginx/modsec/modsecurity.conf
Modifica il file.
sudo nano /etc/nginx/modsec/modsecurity.conf
Trova la riga seguente.
SecRuleEngine DetectionOnly
Questa configurazione dice a ModSecurity di registrare le transazioni HTTP, ma non esegue alcuna azione quando viene rilevato un attacco. Modificalo come segue, così ModSecurity rileverà e bloccherà gli attacchi web.
SecRuleEngine On
Quindi trova la riga seguente (riga 224), che dice a ModSecurity quali informazioni devono essere incluse nel registro di controllo.
SecAuditLogParts ABIJDEFHZ
Tuttavia, l'impostazione predefinita è errata. Saprai perché più avanti quando spiegherò come capire i log di ModSecurity. L'impostazione dovrebbe essere modificata come segue.
SecAuditLogParts ABCEFHJKZ
Se disponi di un sito Web di codifica, potresti voler disabilitare l'ispezione del corpo di risposta, altrimenti potresti ricevere 403 errori vietati semplicemente caricando una pagina Web con molto contenuto di codice.
SecResponseBodyAccess Off
Salva e chiudi il file. Quindi, crea il /etc/nginx/modsec/main.conf file.
sudo nano /etc/nginx/modsec/main.conf
Aggiungi la riga seguente per includere /etc/nginx/modsec/modsecurity.conf file.
Include /etc/nginx/modsec/modsecurity.conf
Salva e chiudi il file. Dobbiamo anche copiare il file di mappatura Unicode.
sudo cp /usr/local/src/ModSecurity/unicode.mapping /etc/nginx/modsec/
Quindi testa la configurazione di Nginx.
sudo nginx -t
Se il test ha esito positivo, riavvia Nginx.
sudo systemctl restart nginx
Passaggio 6:abilita il set di regole di base OWASP
Per fare in modo che ModSecurity protegga le tue applicazioni web, devi definire delle regole per rilevare i malintenzionati e bloccarli. Per i principianti, è una buona idea installare i set di regole esistenti, in modo da poter iniziare rapidamente e poi imparare il nocciolo della strada lungo la strada. Esistono diversi set di regole gratuiti per ModSecurity. Il insieme di regole di base OWASP (CRS) è il set di regole standard utilizzato con ModSecurity.
- È gratuito, gestito dalla community e il set di regole più utilizzato che fornisce una configurazione predefinita venduta per ModSecurity.
- Contiene regole per aiutare a fermare i vettori di attacco comuni, inclusi SQL injection (SQLi), cross-site scripting (XSS) e molti altri.
- Può integrarsi con Project Honeypot.
- Contiene anche regole per rilevare bot e scanner.
- È stato ottimizzato attraverso un'ampia esposizione per avere pochissimi falsi positivi.
Scarica l'ultimo OWASP CRS da GitHub.
wget https://github.com/coreruleset/coreruleset/archive/v3.3.0.tar.gz
Estrai il file.
tar xvf v3.3.0.tar.gz
Sposta la directory in /etc/nginx/modsec/ .
sudo mv coreruleset-3.3.0/ /etc/nginx/modsec/
Rinomina il crs-setup.conf.example file.
sudo mv /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf.example /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf
Quindi modifica il file di configurazione principale.
sudo nano /etc/nginx/modsec/main.conf
Aggiungi le due righe seguenti, in modo che Nginx includa il file di configurazione CRS e le singole regole.
Include /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf Include /etc/nginx/modsec/coreruleset-3.3.0/rules/*.conf
Salva e chiudi il file. Quindi testa la configurazione di Nginx.
sudo nginx -t
Se il test ha esito positivo, riavvia Nginx.
sudo systemctl restart nginx
Fase 7:scopri come funziona OWASP CRS
Diamo un'occhiata al file di configurazione CRS, che fornisce una buona documentazione su come funziona CRS.
sudo nano /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf
Puoi vedere che OWASP CRS può essere eseguito in due modalità:
- modalità autonoma . Questa è la modalità tradizionale utilizzata in CRS v2.x. Se una richiesta HTTP corrisponde a una regola, ModSecurity bloccherà immediatamente la richiesta HTTP e interromperà la valutazione delle regole rimanenti.
- Modalità punteggio anomalia . Questa è la modalità predefinita utilizzata in CRS v3.x. ModSecurity verificherà una richiesta HTTP rispetto a tutte le regole e aggiungerà un punteggio a ciascuna regola corrispondente. Se viene raggiunta una soglia, la richiesta HTTP viene considerata un attacco e verrà bloccata. Il punteggio predefinito per le richieste in entrata è 5 e per la risposta in uscita è 4.
Quando si esegue in modalità punteggio anomalia, ci sono 4 livelli di paranoia.
- Livello di paranoia 1 (predefinito)
- Paranoia livello 2
- Paranoia livello 3
- Paranoia livello 4
Con ogni aumento del livello di paranoia, il CRS abilita regole aggiuntive offrendoti un livello di sicurezza più elevato. Tuttavia, livelli di paranoia più elevati aumentano anche la possibilità di bloccare parte del traffico legittimo a causa di falsi allarmi.
Questi sono i due concetti di base che devi comprendere prima di utilizzare il CRS. Ora possiamo chiudere il file. Le singole regole CRS sono memorizzate in /etc/nginx/modsec/coreruleset-3.3.0/rules/ directory. Ogni regola di corrispondenza aumenterà il punteggio di anomalia.
Fase 8:test
Per verificare se ModSecurity funziona, puoi lanciare un semplice attacco SQL injection sul tuo sito web. (Tieni presente che è illegale eseguire test di sicurezza sui siti Web di altre persone senza autorizzazione.) Inserisci l'URL followign nel tuo browser web.
https://yourdomain.com/?id=3 or 'a'='a'
Se ModSecurity funziona correttamente, il tuo server web Nginx dovrebbe restituire un messaggio di errore 403 vietato.
Il browser Firefox potrebbe non mostrare il messaggio di errore 403. Puoi premere Ctrl+Shift+I per aprire la finestra degli strumenti per sviluppatori e selezionare la network scheda. Quindi premi F5 per ricaricare la pagina web. Ora dovresti vedere il codice di errore 403 in Firefox.
Se ModSecurity viene eseguito in DetectionOnly modalità, non bloccherà questo attacco SQL injection.
Fase 9:Comprensione dei registri di ModSecurity
È importante analizzare i log di ModSecurity, così saprai che tipo di attacchi sono diretti alle tue applicazioni web e intraprenderai azioni migliori per difenderti dagli attori delle minacce. Ci sono principalmente due tipi di log in ModSecurity:
- log di debug:disabilitato per impostazione predefinita.
- registro di controllo:
/var/log/modsec_audit.log
Per comprendere i log di controllo di ModSecurity, è necessario conoscere le 5 fasi di elaborazione in ModSecurity, che sono:
- Fase 1:ispeziona le intestazioni delle richieste
- Fase 2:ispezione del corpo della richiesta
- Fase 3:ispeziona le intestazioni delle risposte
- Fase 4:ispezionare il corpo della risposta
- Fase 5:Azione (registrazione/blocco delle richieste dannose)
Sono anche due tipi di file di registrazione.
- Serie :un file per tutti i log. Questa è l'impostazione predefinita.
- Simultanea :più file per la registrazione. Ciò può fornire prestazioni di scrittura migliori. Se noti che le tue pagine web rallentano dopo aver abilitato ModSecurity, puoi scegliere di utilizzare il tipo di registrazione simultanea.
Gli eventi nel registro sono divisi in diverse sezioni.
- sezione A:intestazione del registro di controllo
- sezione B:intestazione della richiesta
- sezione C:organismo di richiesta
- sezione D:riservata
- sezione E:organismo di risposta intermedio
- sezione F:intestazioni della risposta finale
- sezione G:riservata
- sezione H:trailer del registro di controllo
- sezione I:alternativa al corpo della richiesta compatta, che esclude i file
- sezione J:informazioni sui file caricati
- sezione K:ogni regola abbinata a un evento, in ordine di corrispondenza
- sezione Z:confine finale
Se gestisci un sito Web ad alto traffico, il registro di controllo di ModSecurity può diventare troppo grande molto rapidamente, quindi è necessario configurare la rotazione del registro per il registro di controllo di ModSecurity. Crea un file di configurazione logrotate per ModSecurity.
sudo nano /etc/logrotate.d/modsecurity
Aggiungi le seguenti righe a questo file.
/var/log/modsec_audit.log
{
rotate 14
daily
missingok
compress
delaycompress
notifempty
}
Questo ruoterà il file di registro ogni giorno (ogni giorno ), comprimendo le vecchie versioni (comprimi ). I 14 file di registro precedenti verranno conservati (ruota 14 ), e non si verificherà alcuna rotazione se il file è vuoto (notifempty ). Salva e chiudi il file.
Se il registro di ModSecurity è vuoto, forse è necessario riavviare Nginx.
sudo systemctl restart nginx
Fase 10:gestione dei falsi positivi
ModSecurity è un firewall per applicazioni Web generico e non progettato per un'applicazione Web specifica. Il set di regole di base OWASP è anche un set di regole generico senza una particolare applicazione in mente, quindi è probabile che vedrai falsi positivi dopo aver abilitato ModSecurity e OWASP CRS. Se aumenti il livello di paranoia nel CRS, ci saranno più falsi positivi.
Ad esempio, per impostazione predefinita, il CRS vieta l'iniezione di comandi Unix come l'immissione di sudo su una pagina web, cosa piuttosto comune nel mio blog. Per eliminare i falsi positivi, devi aggiungere esclusioni di regole al CRS.
Esclusioni delle regole specifiche dell'applicazione
Ci sono alcune esclusioni predefinite e specifiche dell'applicazione fornite con OWASP CRS. Modifica il crs-setup.conf file.
sudo nano /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf
Vai a Esclusioni delle regole specifiche dell'applicazione sezione e trova le righe seguenti.
#SecAction \ # "id:900130,\ # phase:1,\ # nolog,\ # pass,\ # t:none,\ # setvar:tx.crs_exclusions_cpanel=1,\ # setvar:tx.crs_exclusions_drupal=1,\ # setvar:tx.crs_exclusions_dokuwiki=1,\ # setvar:tx.crs_exclusions_nextcloud=1,\ # setvar:tx.crs_exclusions_wordpress=1,\ # setvar:tx.crs_exclusions_xenforo=1"
Ad esempio, se voglio abilitare le esclusioni di WordPress, le righe precedenti dovrebbero essere modificate come segue. Si prega di fare attenzione alla sintassi. Non dovrebbero esserci commenti tra t:none,\ e setvar:tx.crs_exclusions_wordpress=1" . (La barra rovesciata \ il carattere alla fine indica che la riga successiva è una continuazione della riga corrente.)
SecAction \ "id:900130,\ phase:1,\ nolog,\ pass,\ t:none,\ setvar:tx.crs_exclusions_wordpress=1" # setvar:tx.crs_exclusions_cpanel=1,\ # setvar:tx.crs_exclusions_drupal=1,\ # setvar:tx.crs_exclusions_dokuwiki=1,\ # setvar:tx.crs_exclusions_nextcloud=1,\ # setvar:tx.crs_exclusions_xenforo=1"
Salva e chiudi il file. Quindi testa le configurazioni di Nginx.
sudo nginx -t
Se il test ha esito positivo, ricarica Nginx per rendere effettive le modifiche.
sudo systemctl reload nginx
Tieni presente che se hai più applicazioni come (WordPress, Nextcloud, Drupal, ecc.) installate sullo stesso server, le esclusioni delle regole di cui sopra verranno applicate a tutte le applicazioni. Per ridurre al minimo i rischi per la sicurezza, è necessario abilitare un'esclusione della regola per una sola applicazione. Per farlo, vai su /etc/nginx/modsec/coreruleset-3.3.0/rules/ directory.
cd /etc/nginx/modsec/coreruleset-3.3.0/rules
Rinomina il REQUEST-900-EXCLUSION-RULES-BEFORE-CRS file.
sudo mv REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
Quindi modifica questo file.
sudo nano REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
Aggiungi la seguente riga in fondo a questo file. Se il tuo WordPress utilizza blog.yourdomain.com sottodominio e l'intestazione della richiesta inviata dal browser del visitatore contiene questo sottodominio, quindi ModSecurity applicherà le esclusioni delle regole per WordPress.
SecRule REQUEST_HEADERS:Host "@streq blog.yourdomain.com" "id:1000,phase:1,setvar:tx.crs_exclusions_wordpress=1"
Se hai installato Nextcloud sullo stesso server, puoi anche aggiungere la seguente riga in questo file, quindi se un visitatore sta accedendo al tuo sottodominio Nextcloud, ModSecurity applicherà le esclusioni della regola Nextcloud.
SecRule REQUEST_HEADERS:Host "@streq nextcloud.yourdomain.com" "id:1001,phase:1,setvar:tx.crs_exclusions_nextcloud=1"
Salva e chiudi questo file. Quindi testa le configurazioni di Nginx.
sudo nginx -t
Se il test ha esito positivo, ricarica Nginx per rendere effettive le modifiche.
sudo systemctl reload nginx
Esclusioni regole personalizzate
L'abilitazione delle esclusioni delle regole specifiche dell'applicazione predefinite potrebbe non eliminare tutti i falsi positivi. In tal caso, è necessario esaminare il registro di controllo di ModSecurity (/var/log/modsec_audit.log ), controlla quale regola ha causato il falso positivo e aggiungi le esclusioni delle regole personalizzate in REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf file.
La sezione H nel registro di controllo indica quale regola corrisponde. Ad esempio, se provo a utilizzare il <code>...</code> HTML nel modulo di commento, ModSecurity blocca il mio commento. Il registro seguente mi dice che la richiesta HTTP corrisponde a una regola in REQUEST-941-APPLICATION-ATTACK-XSS.conf (riga 527). L'ID della regola è 941310. L'URI della richiesta è /wp-comments-post.php .
Viene rilevato come attacco del filtro XSS di codifica non valido. Tuttavia, voglio che gli utenti possano utilizzare il <code>...</code> e <pre>...</pre> Tag HTML nel modulo di commento, quindi ho creato un'esclusione della regola. Aggiungi la seguente riga in fondo a REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf file.
SecRule REQUEST_URI "@streq /wp-comments-post.php" "id:1002,phase:1,ctl:ruleRemoveById=941310"
Questa riga dice a ModSecurity che se l'URI della richiesta è /wp-comments-post.php , quindi non applicare l'ID regola 941310. Salvare e chiudere il file. Quindi prova la configurazione di Nginx.
sudo nginx -t
Se il test ha esito positivo, ricarica Nginx.
sudo systemctl reload nginx
Se un falso positivo corrisponde a più ID regola, puoi aggiungere esclusioni di regole in una riga in questo modo:
SecRule REQUEST_URI "@streq /wp-admin/post.php" "id:1003,phase:1,ctl:ruleRemoveById=941160,ctl:ruleRemoveById=941310,ctl:ruleRemoveById=942100"
Nota :Non è consigliabile disabilitare troppe regole di livello 1 in OWASP CRS, in quanto renderà il tuo sito Web violato molto più facilmente. Disattiva le regole solo se sai cosa stai facendo.
Inserimento nella whitelist IP
Se desideri disabilitare ModSecurity per il tuo indirizzo IP, ma lasciarlo abilitato per tutti gli altri indirizzi IP, aggiungi la seguente regola personalizzata in REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf file. Sostituisci 12.34.56.78 con il tuo vero indirizzo IP.
SecRule REMOTE_ADDR "^12\.34\.56\.78" "id:1004,phase:1,allow,ctl:ruleEngine=off"
Per autorizzare una sottorete, utilizzare la seguente sintassi, che consentirà di inserire nella whitelist 10.10.10.0/24 rete.
SecRule REMOTE_ADDR "^10\.10\.10.*" "id:1005,phase:1,allow,ctl:ruleEngine=off"
Salva e chiudi il file. Quindi testa le configurazioni di Nginx.
sudo nginx -t
Se il test ha esito positivo, riavvia Nginx per rendere effettive le modifiche.
sudo systemctl restart nginx
Regole di concatenamento
Se il tuo Nginx ha più host virtuali, potresti voler inserire nella whitelist il tuo indirizzo IP per un host virtuale specifico. Devi concatenare due regole in questo modo:
SecRule REMOTE_ADDR "^12\.34\.56\.78" "id:1004,phase:1,allow,ctl:ruleEngine=off,chain" SecRule REQUEST_HEADERS:Host "@streq nextcloud.yourdomain.com" "t:none"
La chain la parola chiave alla fine della prima regola indica che il ruleEngine=off l'azione verrà intrapresa solo se anche la condizione nella regola successiva è vera.
(Facoltativo) Integra ModSecurity con Project Honeypot
Project Honeypot mantiene un elenco di indirizzi IP dannosi noti, disponibili gratuitamente al pubblico. ModSecurity può integrarsi con Project Honeypot e bloccare gli indirizzi IP nell'elenco Project Honeypot.
Tieni presente che l'utilizzo di Project Honeypot renderà il tuo sito Web più lento per i nuovi visitatori, poiché il tuo server Web dovrà inviare una query a Project Honeypot prima che possa inviare una risposta al nuovo visitatore. Tuttavia, una volta che i dati sulla reputazione IP sono memorizzati nella cache del tuo server web, l'impatto sulle prestazioni sarà minimo.
Per utilizzare Project Honeypot, crea prima un account gratuito sul suo sito web. Quindi vai alla dashboard del tuo account e fai clic su get one link per richiedere una chiave di accesso per la blacklist HTTP.
Quindi, modifica crs-setup.conf file.
sudo nano /etc/nginx/modsec/coreruleset-3.3.0/crs-setup.conf
Trova le seguenti righe.
#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"
Rimuovi l'inizio # caratteri per rimuovere il commento e aggiungere la chiave API HTTPBL ottenuta da Project Honeypot.
Nota che block_search_ip dovrebbe essere impostato su 0 (disabilitato), poiché non vogliamo bloccare i crawler dei motori di ricerca. Salva e chiudi il file. Quindi ricarica Nginx.
sudo systemctl reload nginx
Ora ModSecurity interrogherà Project Honeypot su tutte le richieste HTTP. Per verificare se funziona, modifica il file /etc/nginx/modsec/main.conf.
sudo nano /etc/nginx/modsec/main.conf
Aggiungi la riga seguente alla fine di questo file. Questo ci consente di passare un indirizzo IP in un URL. (Una volta che il test ha esito positivo, puoi rimuovere questa riga dal file.)
SecRule ARGS:IP "@rbl dnsbl.httpbl.org" "phase:1,id:171,t:none,deny,nolog,auditlog,msg:'RBL Match for SPAM Source'
Salva e chiudi il file. Testa le configurazioni di Nginx.
sudo nginx -t
Quindi ricarica Nginx.
sudo systemctl reload nginx
Vai al sito Web di Project Honeypot e trova un indirizzo IP dannoso, ad esempio 134.119.218.243. Esegui il comando seguente per testare la blacklist HTTP.
curl -i -s -k -X $'GET' 'https://yourdomain.com/?IP=134.119.218.243'
Il tuo server web dovrebbe restituire una risposta vietata 403, perché l'indirizzo IP su Project Honeypot.
Come utilizzare Brotli con ModSecurity in Nginx
Tradizionalmente, le pagine Web sono compresse con GZIP per una maggiore velocità di caricamento. Sviluppato da Google, Brotli è un nuovo algoritmo di compressione che fornisce un migliore rapporto di compressione. It’s supported by all major web browsers. To use Brotli in Nginx, first you need to install the Brotli Nginx module from the the ondrej/nginx-mainline PPA.
sudo apt install libnginx-mod-brotli
Then open the main Nginx configuration file.
sudo nano /etc/nginx/nginx.conf
Add the following lines in the http {...} context.
brotli on;
brotli_comp_level 6;
brotli_static on;
brotli_types application/atom+xml application/javascript application/json application/rss+xml
application/vnd.ms-fontobject application/x-font-opentype application/x-font-truetype
application/x-font-ttf application/x-javascript application/xhtml+xml application/xml
font/eot font/opentype font/otf font/truetype image/svg+xml image/vnd.microsoft.icon
image/x-icon image/x-win-bitmap text/css text/javascript text/plain text/xml;
Save and close the file, then test Nginx configurations.
sudo nginx -t
If the test is successful, restart Nginx.
sudo systemctl restart nginx
Now go to the home page your website, open the developer tools in your web browser (In Firefox you can press Ctrl+Alt+I to open it up). Select the Network tab, and press F5 to reload the web page. Click on the main HTML page.
Check the response header on the right sidebar. If the content-encoding is set to br , then you have successfully enabled Brotli compression in Nginx.
If the content-encoding is gzip , then your Nginx web server is still using GZIP.
Upgrading Nginx
ModSecurity integrates with Nginx as a dynamic module, so every time the Nginx binary is upgraded, you need to rebuild the ModSecurity module for Nginx. This will make your application offline for a few minutes.
If a newer version of Nginx is available in the repository, the sudo apt upgrade command will upgrade Nginx. The newer version of Nginx is not going to be compatible with the previously compiled ModSecurity module. If Nginx is upgraded by the sudo apt upgrade command, it will fail to restart as shown in the screenshot below.
And if you run sudo nginx -t command, it tells you that Nginx expects a new version of the ModSecurity module.
My advice is to prevent Nginx from being upgraded when you run sudo apt upgrade comando. This can be achieved by the following command:
sudo apt-mark hold nginx
Now if you run sudo apt update;sudo apt upgrade , and the package manager tells you that the nginx package is held back from upgrading, then it means there’s a new nginx version available in the repository.
You should download the new Nginx source package and compile the ModSecurity module again. Move the newly-compiled ModSecurity module to /usr/share/nginx/modules/ directory. Basically that means you need to remove everything under /usr/local/src/ directory (sudo rm /usr/local/src/* -rf ) and go through step 2 and step 4 again.
Then unhold Nginx.
sudo apt-mark unhold nginx
And upgrade Nginx.
sudo apt upgrade nginx
Once the upgrade is complete, hold Nginx again.
sudo apt-mark hold nginx
To show what packages are held, run
apt-mark showhold
Nginx Plus
If you use the commercial Nginx Plus web server, then ModSecurity is included in the Nginx Plus binary. It’s known as the NGINX WAF .
If you don’t want to spend time re-compiling the ModSecurity source code, then you might want to purchase Nginx Plus, as the ModSecurity module is pre-compiled in the Nginx Plus binary. Benefits of Using ModSecurity 3.0 with NGINX Plus:
- You don’t need to compile the ModSecurity dynamic module yourself; NGINX, Inc. provides a precompiled module for you, saving time and effort.
- NGINX, Inc. has extensively tested the dynamic module, so you know it’s suitable for production usage.
- NGINX, Inc. continually tracks changes and updates the module for every important change and security vulnerability, so you don’t have to do this yourself.
- Each new release of NGINX Plus includes a new version of the dynamic module, so you can upgrade without having to re-compile ModSecurity.
- You get 24×7 support with both installation of the ModSecurity and the OWASP Core Rule Set, as well as troubleshooting and debugging assistance.
How to Disable ModSecurity for a Virtual Host
In this tutorial, I added the following line in the http {...} context.
modsecurity on;
This will enable ModSecurity for all Nginx server blocks (aka virtual hosts). If you want to disable ModSecurity for a specific server block, then edit the server block file (/etc/nginx/conf.d/example.com.conf ) and add the following line to the server {...} context.
modsecurity off;
Reload Nginx for the change to take effect.
sudo systemctl reload nginx
FAQ
Static Module vs Dynamic Module in Nginx
- A static module must be compiled with Nginx and it’s integrated with Nginx as one binary. It can’t be unloaded from Nginx.
- A dynamic module is a separate package from the main Nginx binary. It can be loaded and unloaded in Nginx.
What does Binary Compatible Mean?
- If a dynamic module is not binary compatible, then the module and Nginx should be compiled together. If there’s an existing Nginx binary installed from a software repository using
apt-get, it must be removed and you need to install the compiled Nginx binary in order to use the dynamic module. - If a dynamic module is binary compatible, then this module can be compiled individually without compiling Nginx. The module can be used with your existing Nginx binary installed from a software repository. It’s not perfect, though.
No matter a module is static or dynamic, binary compatible or non binary compatible, if you upgrade the Nginx binary later, you need to compile the module again.
Upgrade Server RAM
ModSecurity can use a fair amount of RAM. If you can see the following error in your Nginx error log (/var/log/nginx/error.log), it means your server is short of RAM.
fork() failed while spawning "worker process" (12: Cannot allocate memory) sendmsg() failed (9: Bad file descriptor) sendmsg() failed (9: Bad file descriptor) sendmsg() failed (9: Bad file descriptor)
You need to restart Nginx and upgrade server RAM, then the above error is not going to happen again.
How to Upgrade OWASP CRS
Besides upgrading the ModSecurity Nginx module, you also need to upgrade the core rule set when a new version comes out. The process is straightforward.
- Go through step 6 again to install the new version of core rule set.
- Then go to step 10. Copy of your custom rules in the
crs-setup.confandREQUEST-900-EXCLUSION-RULES-BEFORE-CRSfile.
Next, test Nginx configurations.
sudo nginx -t
If the test is successful, reload Nginx for the change to take effect.
sudo systemctl reload nginx
How do you know if the new version is working? Launch a simple SQL injection attack like in step 8 and check your server logs. It will show you the CRS version that’s preventing this attack.