Come installare ModSecurity con Nginx su Rocky Linux 8

ModSecurity, spesso denominato Modsec, è un firewall per applicazioni web gratuito e open source (WAF). ModSecurity è stato creato come modulo per Apache HTTP Server. Tuttavia, sin dai suoi primi giorni, il WAF è cresciuto e ora copre una serie di funzionalità di filtraggio 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 Rocky Linux 8.

Prerequisiti

  • Sistema operativo consigliato: Rocky Linux 8.+.
  • Account utente: Un account utente con accesso sudo o root.

Aggiorna il sistema operativo

Aggiorna il tuo Rocky linux sistema operativo per assicurarsi che tutti i pacchetti esistenti siano aggiornati:

sudo dnf upgrade --refresh -y

Il tutorial utilizzerà il comando sudo che collaborano con noi, attingono direttamente dalla storia e dalla tradizione veneziana supponendo che tu abbia lo stato di sudo.

Per verificare lo stato di sudo sul tuo account:

sudo whoami

Esempio di output che mostra lo stato di sudo:

[joshua@rockylinux ~]$ sudo whoami
root

Per configurare un account sudo esistente o nuovo, visita il nostro tutorial su Come aggiungere un utente a Sudoers su Rocky Linux.

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

su

Abilita repository EPEL

Per installare correttamente ModSecurity con Rocky Linux 8, dovrai abilitare il repository EPEL per completare l'installazione di Modsecurity.

Installa il repository EPEL:

sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm -y

pubblicità


Installa l'ultimo Nginx su Rocky Linux 8

Per impostazione predefinita, puoi mantenere la tua versione esistente di Nginx installata se riesci a trovare un'origine della versione corrispondente. In caso contrario, si consiglia di installare l'ultima build stabile o principale di Nginx, poiché il tutorial verrà illustrato di seguito.

Rimuovere l'installazione di Nginx esistente

Interrompi il servizio Nginx corrente:

sudo systemctl stop nginx

Ora rimuovi l'installazione di Nginx esistente come segue:

sudo dnf remove nginx

Aggiunta del repository Ngnix

Ora che hai rimosso con successo la vecchia versione di Nginx, se l'avevi installata, per installare la linea principale di Nginx, devi prima installare la dipendenza per essa, che è dnf-utilities con il seguente comando:

sudo dnf install dnf-utils -y

Una volta installato, usa il tuo editor di testo preferito, crea il seguente file:

sudo nano /etc/yum.repos.d/nginx.repo

Successivamente, è necessario aggiungere il seguente codice, che specifica i repository Nginx da cui è possibile installare stable o mainline:

[nginx-stable]
name=nginx stable repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=1
enabled=1
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true

[nginx-mainline]
name=nginx mainline repo
baseurl=http://nginx.org/packages/mainline/centos/$releasever/$basearch/
gpgcheck=1
enabled=0
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true

Per risparmiare uso (CTRL+O), poi esci (CTRL+X).

Installa Nginx

Per impostazione predefinita, viene utilizzato per primo l'ultimo repository per i pacchetti Nginx stabili. Tuttavia, il tutorial verrà installato Nginx linea principale, quindi dovrai eseguire il seguente comando per abilitare il repository principale come segue:

sudo yum-config-manager --enable nginx-mainline

Nota se preferisci la stabilità, non utilizzare il comando precedente e passa alla parte successiva del tutorial.

Quindi, installa la linea principale di Nginx come segue:

sudo dnf install nginx
Come installare ModSecurity con Nginx su Rocky Linux 8

Nota che vedrai un pop-up che ti avvisa dell'importazione del Chiave GPG durante l'installazione. Questo è sicuro da fare ed è necessario per completare l'installazione di Nginx mainline con successo. Tipo "Y" e premere "ACCEDERE".

Come installare ModSecurity con Nginx su Rocky Linux 8

Per impostazione predefinita, Nginx non viene abilitato e viene disattivato durante l'installazione. Per attivare il tuo servizio Nginx, usa:

sudo systemctl start nginx

Per consentire l'avvio di Nginx all'avvio, utilizzare il seguente comando:

sudo systemctl enable nginx

Per verificare la tua versione di Nginx, nel nostro caso la versione Nginx Mainline, usa il seguente comando per confermare:

nginx -v

Esempio di output:

Come installare ModSecurity con Nginx su Rocky Linux 8

Configura firewall

Se non si sostituisce un servizio Nginx esistente e non si installa Nginx per la prima volta, potrebbe essere necessario configurare il firewall per il traffico HTTP e HTTPS. Di seguito è riportato un esempio di come eseguire questa operazione:

Per consentire il traffico HTTP utilizzare il seguente comando:

sudo firewall-cmd --permanent --zone=public --add-service=http

Per consentire il traffico HTTPS utilizzare il seguente comando:

sudo firewall-cmd --permanent --zone=public --add-service=https

Una volta fatto, devi rendere effettive le modifiche ricaricando il firewall:

sudo firewall-cmd --reload

pubblicità


Opzionale. Proteggi Nginx con il certificato gratuito SSL di Let's Encrypt

Idealmente, vorresti eseguire il tuo Nginx su HTTPS utilizzando un certificato SSL. Il modo migliore per farlo è usare Criptiamo, un'autorità di certificazione gratuita, automatizzata e aperta gestita dal Internet Security Research Group (ISRG) senza scopo di lucro.

Innanzitutto, installa il EPEL repository e il mod_ssl pacchetto per pacchetti e sicurezza più aggiornati.

sudo dnf install epel-release mod_ssl -y

Quindi, installare il pacchetto certbot come segue:

sudo dnf install python3-certbot-nginx -y

Una volta installato, esegui il seguente comando per avviare la creazione del tuo certificato:

sudo certbot --nginx --agree-tos --redirect --hsts --staple-ocsp --email you@example.com -d www.example.com

Questa è la configurazione ideale che include reindirizzamenti forzati HTTPS 301, intestazione Strict-Transport-Security e Stapling OCSP. Assicurati solo di adattare l'e-mail e il nome di dominio alle tue esigenze.

Ora il tuo URL sarà HTTPS://www.esempio.com invece di HTTP://www.esempio.com.

Nota, se usi il vecchio URL HTTP, reindirizzerà automaticamente a HTTPS.

Facoltativamente, puoi impostare un cron job per rinnovare automaticamente i certificati. Certbot offre uno script che lo fa automaticamente e puoi prima testare per assicurarti che tutto funzioni eseguendo una corsa a secco.

sudo certbot renew --dry-run

Se tutto funziona, apri la finestra di crontab utilizzando il seguente comando da terminale.

sudo crontab -e

Quindi, specifica l'ora in cui dovrebbe rinnovarsi automaticamente. Questo dovrebbe essere controllato almeno giornalmente e, se il certificato deve essere rinnovato, lo script non aggiornerà il certificato. Se hai bisogno di aiuto per trovare un buon momento per impostare, usa il crontab.guru strumento gratuito.

00 00 */1 * * /usr/sbin/certbot-auto renew

Risparmi (CTRL+O) poi esci (CTRL+X), e il cronjob verrà abilitato automaticamente.

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:

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

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

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

Scarica archivio sorgente

Quindi, scarica l'archivio sorgente di Nginx dalla pagina dei download in modo che corrisponda alla versione di Nginx che hai identificato in precedenza. Anche se non hai aggiornato all'ultima versione di Nginx stabile o principale e utilizzi una versione precedente, dovresti essere in grado di trovare una fonte che corrisponda alla tua.

Scarica la fonte usando il wget comando come segue (solo esempio):

wget http://nginx.org/download/nginx-1.21.1.tar.gz

Quindi, estrai l'archivio come segue:

tar -xvzf nginx-1.21.1.tar.gz

Verifica la versione di origine

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

ls

Esempio di output nel tuo /usr/src/local/nginx directory:

jjames@rockylinux:/usr/local/src/nginx$ ls
nginx-1.21.1

nginx_1.21.1.orig.tar.gz

Quindi, conferma che il pacchetto sorgente è lo stesso della tua versione di Nginx installata sul tuo sistema operativo Rocky Linux.

Per fare ciò, utilizzare quanto segue nginx -v comando come segue:

nginx -v

Dovresti ottenere la stessa versione di output della sorgente come segue:

jjames@rockylinux:/usr/local/src/nginx$ nginx -v
nginx version: nginx/1.21.1

pubblicità


Installa libmodsecurity3 per ModSecurity

Il pacchetto libmodsecurity3 è la parte fondamentale del WAF che fa il Filtraggio HTTP per le tue applicazioni web. Compilerai dalla fonte.

Clona ModSecurity Repsoitory da Github

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

sudo dnf install git -y

Quindi, clona il libmodsecurity3 GIT deposito come segue:

sudo 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 dnf install gcc-c++ flex bison yajl curl-devel zlib-devel pcre-devel autoconf automake git curl make libxml2-devel pkgconfig libtool httpd-devel redhat-rpm-config wget openssl openssl-devel nano

Successivamente, installa altre dipendenze usando il repository di PowerTool:

sudo dnf --enablerepo=powertools install doxygen yajl-devel

Ora installa GeoIP utilizzando il repository REMI che hai aggiunto all'inizio del tutorial:

sudo dnf --enablerepo=remi install GeoIP-devel

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

sudo git submodule init

Quindi aggiorna i sottomoduli:

sudo git submodule update

Costruire l'ambiente ModSecurity

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

sudo ./build.sh

Quindi, esegui il comando configure:

sudo ./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.

sudo make

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

sudo make -j 6

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

sudo make install

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

Installa il connettore ModSecurity-nginx

Connettore ModSecurity-nginx è il punto di connessione tra Nginx e libmodsecurity. È 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 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.

Successivamente, compilerai il Connettore ModSecurity-nginx modulo solo con il -con-compat bandiera come segue:

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

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

sudo 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/lib64/user/modules directory.

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

pubblicità


Carica e configura il connettore ModSecurity-nginx con Nginx

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

Abilita ModSecurity in nginx.conf

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 ModSecurity con Nginx su Rocky Linux 8

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 -p /etc/nginx/modsec/

Ora, devi copiare il file di configurazione ModSecurity di esempio dal nostro clone GIT directory:

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

Usando il tuo editor di testo preferito in Rocky Linux, apri il modsecurity.conf file 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 apportare le modifiche dal vivo, riavvia il servizio Nginx utilizzando il pulsante systemctl comando:

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 in genere versioni stabili, che spesso impiegano circa un anno tra i rilasci. La versione attuale è la 3.3. Il problema è che le nuove regole su cui si lavora per miglioramenti, nuovi rilevamenti, rimozione di falsi positivi e ulteriori esclusioni per software standard come i forum phpBB introdotti negli sviluppatori 3.4 (beta) versione non sono inclusi fino alla prossima versione completa.

Lo svantaggio può essere visto in due modi: utilizzare i pacchetti 3.3, avere regole eccellenti stabili e possibilmente non essere aggiornati per le ultime minacce, correzioni e miglioramenti utilizzando la versione 3.4 dev. Avrai tutto questo, ma forse potresti vedere 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 effettuare la chiamata, ma un intero team che esamina le modifiche e le approva come collettivo di solito rende 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 dnf install unzip -y

ORA decomprimere le master.zip archiviare come segue:

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

Come a prima, come il modsecurity.conf configurazione di esempio, 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

Opzione 2. Installa OWASP CRS 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.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:

sudo dnf install unzip -y

ORA decomprimere le dev.zip archiviare come segue:

sudo unzip dev.zip /etc/nginx/modsec

Come a prima, come il modsecurity.conf configurazione di esempio, 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 mv /etc/nginx/modsec/coreruleset-3.3.4-dev/crs-setup.conf.example /etc/nginx/modsec/coreruleset-3.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:

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

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

sudo systemctl restart nginx

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


pubblicità


Utilizzo e comprensione di OWASP CRS

La regola principale di OWASP ha molte opzioni, tuttavia, le impostazioni predefinite, 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:

sudo 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 è generalmente per la maggior parte degli utenti la modalità migliore da utilizzare.

Ci sono quattro livelli di paranoia:

  • Paranoia Livello 1 – Livello predefinito e consigliato per la maggior parte degli utenti.
  • Paranoia Livello 2 – Solo utenti avanzati.
  • Paranoia Livello 3 – Solo utenti esperti.
  • Paranoia Livello 4 – 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 le regole OWASP funzionano 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 alzare mai il livello di paranoia 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, può autorizzare le azioni quotidiane che portano a falsi positivi come di seguito:

#SecAction \
# "id:900130,\
#  phase:1,\
#  nolog,\
#  pass,\
#  t:none,\
#  setvar:tx.crs_exclusions_cpanel=1,\
#  setvar:tx.crs_exclusions_dokuwiki=1,\
#  setvar:tx.crs_exclusions_drupal=1,\
#  setvar:tx.crs_exclusions_nextcloud=1,\
#  setvar:tx.crs_exclusions_phpbb=1,\
#  setvar:tx.crs_exclusions_phpmyadmin=1,\
#  setvar:tx.crs_exclusions_wordpress=1,\
#  setvar:tx.crs_exclusions_xenforo=1"

Per abilitare, ad esempio, WordPress, phpBB e phpMyAdmin mentre 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"

@ipMatch può essere utilizzato più ampiamente per le sottoreti. Se vuoi negare un sottorete or Indirizzo IP cambiare, permettere di negare. Con un po' di know-how, puoi anche 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.

Come installare ModSecurity con Nginx su Rocky Linux 8

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

sudo nano /etc/nginx/modsec/coreruleset-3.4-dev/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. Usa invece la tua chiave!

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

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


pubblicità


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 Rocky Linux, 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.

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