Come installare ModSecurity 2 con Apache su Debian 12 o 11

ModSecurity 2 è un firewall per applicazioni web (WAF) essenziale per proteggere i server HTTP Apache, offrendo monitoraggio in tempo reale e filtraggio basato su regole. Installato su un server Linux Debian 12 o 11, ModSecurity aiuta a prevenire iniezioni SQL, cross-site scripting (XSS) e altri attacchi. Il Digitalwave ModSecurity Repository semplifica l'installazione, assicurandoti di utilizzare la versione stabile più recente.

Per migliorare la sicurezza, l'OWASP Core Rule Set (CRS) fornisce regole preconfigurate che mirano alle vulnerabilità comuni. Impostandolo, gli amministratori possono rafforzare le difese con una configurazione manuale minima. Questa guida ti mostrerà come installare ModSecurity 2 su Debian usando il repository Digitalwave e configurare OWASP CRS per una protezione ottimale.

Aggiornare i pacchetti di sistema Debian per l'installazione di ModSecurity 2

Il nostro primo passo è assicurarci che il nostro sistema Debian sia aggiornato. In questo modo manteniamo aggiornati tutti i pacchetti esistenti, garantiamo prestazioni ottimali e riduciamo al minimo i rischi per la sicurezza. Per farlo, eseguiamo il seguente comando:

sudo apt update && sudo apt upgrade

Dopo aver aggiornato il sistema, controlla se Apache è installato. In caso contrario, usa il seguente comando per installarlo:

sudo apt install apache2

Importa il modulo ModSecurity PPA

Impostazione del repository richiesto

Il prossimo compito sulla nostra lista è installare il ModSecurity Apache Module. La versione disponibile nei repository predefiniti di Debian potrebbe non essere la più recente e utilizzarla può portare a errori immediati. Invece, importeremo un repository di terze parti per installare l'ultimo ModSecurity Module per Apache. Questo repository di terze parti, gestito da Digitalwave, è rinomato per i suoi binari stabili.

Iniziare installando un set di pacchetti necessari:

sudo apt install apt-transport-https lsb-release ca-certificates curl -y

Procediamo quindi ad importare il repository PPA del modulo ModSecurity 2 Chiave GPG:

curl -fsSL https://modsecurity.digitalwave.hu/archive.key | sudo gpg --dearmor | sudo tee /usr/share/keyrings/digitalwave-modsecurity.gpg > /dev/null

Dopo aver acquisito la chiave GPG, aggiungi il repository al tuo sistema:

echo "deb [signed-by=/usr/share/keyrings/digitalwave-modsecurity.gpg] http://modsecurity.digitalwave.hu/debian/ $(lsb_release -sc) main" | sudo tee -a /etc/apt/sources.list.d/digitalwave-modsecurity.list
echo "deb [signed-by=/usr/share/keyrings/digitalwave-modsecurity.gpg] http://modsecurity.digitalwave.hu/debian/ $(lsb_release -sc)-backports main" | sudo tee -a /etc/apt/sources.list.d/digitalwave-modsecurity.list

Dare priorità al nuovo repository PPA del modulo Apache

Con il repository in posizione, è ora necessario modificare la policy APT per dare priorità a questo repository per pacchetti specifici correlati a ModSecurity. Il seguente comando realizza ciò:

cat << EOF | sudo tee -a /etc/apt/preferences.d/99modsecurity
Package: *nginx*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900

Package: *libapache2-mod-security2*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900

Package: *modsecurity-crs*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900

Package: *libmodsecurity*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900
EOF

Quindi, esegui un aggiornamento APT per riflettere la sorgente appena importata:

sudo apt update

Inoltre, per confermare le preferenze, puoi confermare questa modifica della policy con quanto segue:

sudo apt-cache policy libapache2-mod-security2 modsecurity-crs libmodsecurity3

Installa il modulo ModSecurity 2

Ora che il repository è pronto, procediamo con l'installazione del modulo libapache2-mod-security2:

sudo apt install libapache2-mod-security2

Dopo l'installazione, il modulo deve essere abilitato. Per farlo, utilizzare il seguente comando:

sudo a2enmod security2

Riavvio del servizio Apache

Infine, riavviamo il servizio Apache per assicurarci che tutte le modifiche abbiano effetto e che il modulo ModSecurity appena aggiunto sia correttamente integrato:

sudo nano /etc/apache2/mods-enabled/security2.conf

Abilita il modulo ModSecurity 2 su Apache HTTP

Accesso al file di configurazione ModSecurity

Il file di configurazione per Apache ModSecurity si trova in /etc/apache2/mods-enabled/security2.conf. Accedi a questo file usando l'editor di testo nano (o il tuo editor di testo preferito) con il seguente comando:

sudo nano /etc/apache2/mods-enabled/security2.conf

Cerca la riga che dice:

IncludeOptional /etc/modsecurity/*.conf

Assicuratevi che questa riga non sia commentata, poiché include altri file di configurazione necessari dalla directory /etc/modsecurity. Dovrebbe essere decommentata per impostazione predefinita.

Modifica della configurazione di ModSecurity 2

Dobbiamo rinominare il file di configurazione modsecurity.conf-recommended in modsecurity.conf per renderlo attivo. Questo può essere fatto con il seguente comando:

sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

Ora apriamo questo file di configurazione appena denominato:

sudo nano /etc/modsecurity/modsecurity.conf

Il motore di regole ModSecurity è impostato su DetectionOnly per impostazione predefinita all'interno di questo file. Ciò significa che identificherà e registrerà comportamenti potenzialmente dannosi senza bloccarli. Per modificare questa impostazione e abilitare le capacità di blocco di ModSecurity, individua la riga SecRuleEngine (attorno alla riga 7) e sostituisci DetectionOnly con On.

Da:

SecRuleEngine DetectionOnly

A:

SecRuleEngine On

Regolazione delle impostazioni di registro per Apache

Più avanti nel file di configurazione, troverete la riga SecAuditLogParts (attorno alla riga 224). L'impostazione predefinita per questa riga non è del tutto corretta; deve essere regolata per registrare tutte le informazioni sulle transazioni in modo accurato.

Modifica:

SecAuditLogParts ABDEFHIJZ

A:

SecAuditLogParts ABCEFHJKZ

Una volta apportate queste modifiche, salvale e esci dall'editor.

Riavvio di Apache per applicare le modifiche

Il nostro ultimo passaggio in questo processo è riavviare il servizio Apache in modo che le nostre modifiche alla configurazione ModSecurity abbiano effetto. Questo si ottiene usando il seguente comando:

sudo systemctl restart apache2

Installa il set di regole OWASP Core per ModSecurity2

ModSecurity da solo non salvaguarda il tuo webserver. Richiede un set di regole per identificare potenziali minacce e bloccare attività dannose. Il Core Rule Set (CRS) dell'OWASP (Open Web Application Security Project) è un set di regole molto apprezzato utilizzato da vari webserver e Web Application Firewall (WAF). L'implementazione di questo set di regole fornisce al tuo server una solida protezione contro una gamma di minacce emergenti su Internet.

Prima di procedere, è essenziale verificare di avere l'ultima versione di OWASP CRS visitando il sito Pagina dei tag di rilascio OWASPQuesto passaggio garantisce che tu scarichi e installi le misure di sicurezza più aggiornate per il tuo server.

Creazione della directory padre per OWASP CRS

Per prima cosa, creiamo la directory padre principale per OWASP utilizzando il comando mkdir:

sudo mkdir /etc/apache2/modsec/

Scarica l'archivio OWASP CRS su Debian

Successivamente, useremo il comando wget per recuperare l'archivio OWASP CRS 3.3.4, che è la versione stabile al momento della scrittura. Ricorda che dovresti verificare la versione usando il link menzionato in precedenza.

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

La build notturna potrebbe offrire misure di sicurezza più aggiornate, ma potrebbe causare problemi a causa del suo stato di sviluppo. Per i nuovi utenti, è consigliabile utilizzare la versione stabile per evitare potenziali complicazioni.

Nota: dovresti controllare costantemente gli aggiornamenti; le regole stabili non cambiano settimanalmente ma ogni trimestre o a meno che non sia richiesto un aggiornamento urgente.

Estrazione dell'archivio

Una volta scaricato l'archivio, possiamo estrarlo nella directory creata in precedenza:

sudo tar xvf v3.3.4.tar.gz -C /etc/apache2/modsec

Ricordatevi di modificare i comandi in base alla versione OWASP CRS scaricata.

Configurazione del set di regole

L'OWASP CRS ha un file di configurazione di esempio che dovresti rinominare mantenendo l'originale come backup. Puoi farlo usando il comando 'cp':

sudo cp /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf.example /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf

Nota: ricordatevi di sostituire /coreruleset-3.3.4/ con la versione esatta dell'OWASP CRS che avete scelto.

Abilitare le regole

Per attivare le regole, aprire il file /etc/apache2/mods-enabled/security2.conf:

sudo apt install unzip -y

Quindi, inserisci le due righe seguenti:

Include /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf
Include /etc/apache2/modsec/coreruleset-3.3.4/rules/*.conf

Nota: assicurati ancora una volta di sostituire /coreruleset-3.3.4/ con la versione esatta di OWASP CRS che hai selezionato, poiché il coreruleset che scaricherai sarà molto probabilmente più recente dell'esempio della guida.

Inoltre, commenta o rimuovi la seguente riga:

IncludeOptional /usr/share/modsecurity-crs/*.load

Una volta fatto, salva e esci dal file:

Riavvio di Apache per applicare le modifiche

L'ultimo passaggio consiste nel riavviare il servizio Apache per garantire che le modifiche abbiano effetto:

sudo systemctl restart apache2

Introduzione al set di regole OWASP Core e ModSecurity 2

L'OWASP Core Rule Set (CRS) è uno strumento completo con numerose opzioni personalizzabili. La sua configurazione predefinita fornisce miglioramenti immediati della sicurezza per la maggior parte dei server senza influire sui visitatori autentici o sui bot di Search Engine Optimization (SEO). Discuteremo alcuni aspetti significativi del CRS in questa sezione, ma esplorare i file di configurazione per una comprensione completa di tutte le opzioni disponibili è sempre utile.

Regolazione della configurazione CRS

Iniziamo aprendo il file crs-setup.conf in cui è possibile modificare la maggior parte delle impostazioni CRS:

sudo nano /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf

Comprensione del sistema di punteggio CRS

ModSecurity opera in due modalità distinte:

• Modalità punteggio anomalia: consigliata per la maggior parte degli utenti, questa modalità assegna un "punteggio anomalia" ogni volta che una regola corrisponde. Dopo aver elaborato le regole in entrata e in uscita, il punteggio anomalia viene controllato e, se necessario, viene attivata un'azione di interruzione. Questa azione spesso assume la forma di un errore 403. Questa modalità fornisce informazioni di registro accurate e offre una maggiore flessibilità nell'impostazione delle policy di blocco.
• Modalità autosufficiente: in questa modalità, un'azione viene applicata istantaneamente ogni volta che una regola viene abbinata. Sebbene possa ridurre l'utilizzo delle risorse, offre meno flessibilità e produce registri di controllo meno informativi. Il processo di abbinamento delle regole si interrompe quando viene soddisfatta la prima regola e viene eseguita l'azione specificata.

Comprendere i livelli di paranoia

L'OWASP CRS definisce quattro livelli di paranoia:

• Livello di paranoia 1: il livello predefinito è adatto alla maggior parte degli utenti.
• Paranoia Livello 2: per utenti avanzati.
• Livello di paranoia 3: per utenti esperti.
• Livello di paranoia 4: consigliabile solo in circostanze straordinarie.

Livelli di paranoia più elevati abilitano regole aggiuntive, aumentano la sicurezza e aumentano la probabilità di bloccare il traffico legittimo a causa di falsi positivi. Scegliere un livello di paranoia che si allinei con la tua competenza e le tue esigenze di sicurezza è essenziale.

Test di OWASP CRS sul tuo server

Per assicurarti che l'OWASP CRS funzioni correttamente sul tuo server, usa il tuo browser internet per accedere al seguente URL. Ricordati di sostituire "yourdomain.com" con il tuo dominio effettivo:

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

Se ricevi un errore 403 Forbidden, OWASP CRS funzionerà come previsto. In caso contrario, potrebbe esserci un passo falso nel processo di configurazione che richiede la tua attenzione; il problema più comune può essere dimenticare di modificare DetectionOnly in On o qualcosa di simile.

Indirizzo falsi positivi e regole di esclusione personalizzate

La gestione dei falsi positivi con ModSecurity e OWASP Core Rule Set (CRS) può essere un compito continuo. Tuttavia, la solida difesa che questi sistemi offrono contro un'ampia gamma di minacce rende questo sforzo essenziale. Per ridurre al minimo i falsi positivi inizialmente, è consigliabile impostare un basso livello di paranoia.

Eseguendo il set di regole a un livello di paranoia inferiore per diverse settimane o addirittura mesi, puoi ridurre la probabilità di un numero schiacciante di falsi positivi. Questo approccio ti dà il tempo di familiarizzare con gli avvisi e le risposte appropriate prima di aumentare gradualmente il livello di paranoia per una sicurezza più rigorosa.

Gestione dei falsi positivi nelle applicazioni note su Debian con OWASP, ModSecurity 2

ModSecurity include la capacità di mettere in whitelist determinate azioni che potrebbero involontariamente innescare falsi positivi. Ad esempio:

#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 attivare la whitelist per applicazioni come WordPress, phpBB e phpMyAdmin, rimuovi il commento dalle rispettive righe e mantieni il valore (1). Per impedire la whitelist di servizi non in uso, modifica il valore su (0).

La configurazione aggiornata potrebbe apparire come segue:

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"

In questo caso, le opzioni estranee sono state rimosse, lasciando la sintassi corretta per le configurazioni richieste.

Creazione di esclusioni di regole prima dell'implementazione di CRS

Per creare esclusioni personalizzate, iniziare rinominando il file “REQUEST-900-EXCLUSION-RULES-BEFORE-CRS-SAMPLE.conf” utilizzando il seguente comando:

sudo cp /etc/apache2/modsec/coreruleset-3.3.4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example /etc/apache2/modsec/coreruleset-3.3.4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

Ricorda che ogni regola di esclusione deve avere un "idnumber" univoco per evitare errori durante il test del servizio Apache2.

Ad esempio, alcuni "REQUEST_URI" potrebbero causare falsi positivi. L'esempio seguente illustra due di questi casi che coinvolgono il beacon Google PageSpeed ​​e il plugin WPMU DEV 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"

Queste regole consentono automaticamente qualsiasi URL che inizia con il percorso specificato.

Puoi anche inserire specifici indirizzi IP nella whitelist:

SecRule REMOTE_ADDR "^195\.151\.128\.96" "id:1004,phase:1,nolog,allow,ctl:ruleEngine=off"

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"

Nella prima regola, un singolo indirizzo IP viene inserito nella whitelist, mentre la seconda regola utilizza la direttiva '@ipMatch' per una corrispondenza più ampia della subnet. Per bloccare una subnet o un indirizzo IP, basta sostituire 'allow' con 'deny'. Questa flessibilità consente di creare blacklist e whitelist dettagliate, che possono essere integrate con Fail2Ban per una strategia di sicurezza avanzata.

Disabilitare regole specifiche su Debian con OWASP, ModSecurity 2

Invece di mettere in whitelist un intero percorso, un altro approccio è quello di disabilitare regole specifiche che causano falsi positivi persistenti. Sebbene questo metodo richieda più test, offre vantaggi a lungo termine.

Ad esempio, se le regole 941000 e 942999 nell'area "/admin/" attivano falsi positivi per il tuo team, puoi individuare l'ID della regola nei tuoi log ModSecurity e disabilitare solo quegli ID specifici utilizzando il comando "RemoveByID":

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

Monitoraggio dei registri e identificazione dei modelli

Il monitoraggio continuo dei log è essenziale quando si gestiscono falsi positivi con Apache, ModSecurity e OWASP. Aiuta a identificare i pattern che attivano i falsi positivi, consentendo di creare regole personalizzate per affrontarli.

Ad esempio, se regole specifiche causano costantemente falsi positivi, puoi creare una regola di esclusione per gestire queste istanze specifiche. Questo approccio personalizzato assicura una gestione più efficace dei falsi positivi.

Esaminando regolarmente i registri e modificando le regole, puoi mantenere un ambiente più sicuro ed efficiente per le tue applicazioni.

Rotazione dei registri per ModSecurity 2

A causa della natura dinamica delle transazioni web, i log di ModSecurity possono crescere rapidamente, rendendo cruciale una gestione efficace dei log. La rotazione dei log è uno strumento utile per la gestione di questi log, sebbene non sia configurata di default in ModSecurity. Questa sezione ti guiderà attraverso l'impostazione della rotazione dei log specificatamente per ModSecurity.

Creazione di un file di rotazione ModSecurity

Per prima cosa, devi creare un file dedicato per la rotazione dei log di ModSecurity. Per farlo, usa il seguente comando per creare e aprire un nuovo file denominato modsec:

sudo nano /etc/logrotate.d/modsec

Configurazione del file di rotazione

Nel file di configurazione ModSecurity (modsec) appena creato, aggiungere quanto segue:

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

Questa configurazione conserva i log per 31 giorni, ma puoi modificare il numero in base alle tue esigenze. Ad esempio, cambiandolo in "rotate 7" manterrà invece i log di una settimana.

La direttiva 'daily' assicura che i log vengano ruotati ogni giorno, mentre 'compress' risparmia spazio comprimendo i vecchi log. L'opzione 'delaycompress' ritarda la compressione fino al secondo ciclo di rotazione e 'missingok' impedisce errori se il file di log è assente. Inoltre, 'notifempty' assicura che i file di log vuoti non vengano ruotati.

Suggerimento: è consigliabile effettuare la rotazione giornaliera dei registri per evitare di dover gestire file di registro eccessivamente grandi, che potrebbero richiedere più tempo per l'analisi.

Conclusione

Ora hai installato ModSecurity 2 sul tuo server Debian 12 o 11 usando il repository Digitalwave e configurato l'OWASP Core Rule Set. Con questi strumenti in atto, il tuo server è equipaggiato per bloccare molte minacce comuni alle applicazioni web.

Ricordatevi di aggiornare regolarmente il CRS e di monitorare eventuali falsi positivi o vulnerabilità perse. Test e aggiustamenti costanti sono essenziali per mantenere una configurazione di sicurezza solida.