Integrazione di Coraza WAF in Traefik: Proteggi le Tue Applicazioni Web

Coraza è uno strumento avanzato per proteggere le applicazioni web da attacchi come SQL injection, XSS e altre vulnerabilità. Integrabile con Traefik come middleware, consente di applicare regole personalizzate per filtrare richieste basate su indirizzi IP, URI e altri parametri. In questo articolo esploreremo come configurare regole che coinvolgono più indirizzi IP e URI e come integrarlo in Traefik.

Che cos’è Coraza WAF?

Coraza è un web application firewall per applicazioni web, open-source progettato per proteggere i servizi web da una vasta gamma di attacchi. È altamente configurabile e compatibile con le regole ModSecurity, rendendolo una scelta versatile per scenari di sicurezza avanzata. Coraza opera analizzando e filtrando le richieste HTTP in diverse fasi del loro ciclo di vita, consentendo di bloccare o consentire traffico in base a regole definite dall’utente. La sua integrazione con strumenti come Traefik lo rende ideale per ambienti moderni basati su container e microservizi da esporre.

Prerequisiti:

• Delle applicazioni esposte attraverso Traefik e containerizzate in Docker.
• Traefik configurato sulla rete overlay, che per l’esempio chiameremo proxy.
• Conoscenze di base sui file di configurazione statici e dinamici di Traefik.

Abilitare Coraza come plugin

Il primo passo è abilitare il plugin Coraza WAF nella configurazione statica di Traefik (file static.toml o .yml a seconda di come son state dichiarate da voi, per l’esempio utlizzeremo le dichiarazione in formato yaml).

Questo file definisce le impostazioni essenziali per Traefik e viene caricato all’avvio del reverse proxy.

experimental:
  plugins:
    coraza:
      moduleName: "github.com/jcchavezs/coraza-http-wasm-traefik"
      version: "v0.3.0"

Riavvia il container Traefik per applicare definitivamente le modifiche che si effettuano su questo file statico.

Definisci il middleware Coraza WAF nel file dinamico dynamic.yml

Successivamente, definisci il middleware Coraza WAF nel file dinamico

Questo middleware in esempio bloccherà l’accesso a /admin e ne registrerà l’evento.

http:
  middlewares:
    waf:
      plugin:
        coraza:
          directives:
            - SecRuleEngine On
            - SecRule REQUEST_URI "@streq /admin" "id:101,phase:1,log,deny,status:403"

• SecRuleEngine On attiva l’engine del WAF.
• SecRule REQUEST_URI "@streq /admin" questo controlla che la request URI uguale alla stringa /admin dia un risultato.
• Action se ottiene il risultato indicato, il WAF tenta di non dare l’accesso, traccia sul log e risponde alla richiesta con un 403 Forbidden.

Le modifiche effettuate sul file dinamico verranno prese in tempo reale da traefik senza bisogno di riavviare il container del reverse proxy

Concetto di Phase

Le phase in Coraza (e ModSecurity) rappresentano i diversi momenti del ciclo di vita di una richiesta HTTP in cui le regole vengono applicate.

Di seguito una breve panoramica delle principali phase:

• Phase 1: Viene applicata all’inizio della richiesta, prima che il server web elabori i dati. Utilizzata per filtrare indirizzi IP, intestazioni e altre informazioni preliminari.
• Phase 2: Applicata dopo che il server ha letto l’intestazione HTTP completa. Ideale per controllare URI, parametri e altre parti della richiesta.
• Phase 3: Applicata durante il corpo della richiesta, utile per analizzare i dati inviati (ad esempio i payload JSON).
• Phase 4: Applicata alla risposta del server, ad esempio per analizzare i dati di risposta o per aggiungere intestazioni personalizzate.
• Phase 5: Applicata alla fine del ciclo di vita della risposta, spesso utilizzata per logging o azioni post-risposta.

Nella dichiarazione delle regole, cercate di assegnare per ogni regola un id univoco e la giusta phase a secondo di quello che volete controllare log, permettere allow o bloccare deny.

Aggiungere Più Indirizzi IP in una Regola

Supporta diversi approcci per gestire liste di indirizzi IP consentiti o bloccati. Vediamo i principali metodi.

1. Usare @ipMatch per Liste Brevi

La direttiva @ipMatch consente di specificare più indirizzi IP o subnet direttamente all’interno della regola

SecRule REMOTE_ADDR "@ipMatch 192.168.1.1,192.168.1.2,10.0.0.0/8" "id:1001,phase:1,allow,msg:'Allowed IPs'"

Nel nostro esempio: 192.168.1.1 e 192.168.1.2 sono IP specifici. 10.0.0.0/8 rappresenta un’intera subnet.

2.Usare @pm per Liste Statiche

@pm è una soluzione rapida per liste di indirizzi IP non troppo lunghe.

SecRule REMOTE_ADDR "@pm 192.168.1.1 192.168.1.2 10.0.0.0/8" "id:1002,phase:1,allow,msg:'Allowed IPs using @pm'"

3. Usare un File con @ipMatchFromFile

Per liste lunghe di IP, è più pratico memorizzare gli indirizzi in un file esterno e usarlo con la direttiva @ipMatchFromFile.

Crea un File con gli IP: Salva gli indirizzi IP in un file chiamato ad esempio allowed_ips.txt:

192.168.1.1 192.168.1.2 10.0.0.0/8 172.16.0.0/12

Usa il File nella Regola:

SecRule REMOTE_ADDR "@ipMatchFromFile /path/del/file/allowed_ips.txt" "id:1003,phase:1,allow,msg:'Allowed IPs from file'"

4. Bloccare Tutto il Resto

Dopo aver configurato una regola per consentire determinati IP, puoi aggiungerne una per bloccare tutto ciò che non è incluso.

SecRule REMOTE_ADDR "!@ipMatch 192.168.1.1,192.168.1.2,10.0.0.0/8" "id:1004,phase:1,deny,status:403,msg:'Blocked unauthorized IPs'"

Aggiungere Più URI in una Regola

Per filtrare le richieste in base a più URI, si può utilizzare espressioni regolari, liste statiche o file esterni.

1.Usare Pattern Multipli con Espressioni Regolari

Puoi combinare più URI in una singola regola usando il simbolo | (OR).

SecRule REQUEST_URI "@rx ^(/login|/admin|/signup)$" "id:2001,phase:2,deny,status:403,msg:'Blocked sensitive URIs'"

• ^: Inizio del percorso.
• |: Separatore logico (OR).
• $: Fine del percorso.

2. Usare @pm per Liste di URI

Se gli URI sono statici, puoi utilizzare @pm per confrontarli direttamente.

SecRule REQUEST_URI "@pm /login /admin /signup" "id:2002,phase:2,deny,status:403,msg:'Blocked sensitive URIs'"

3. Usare un File con @pmFromFile

Per liste lunghe di URI, è possibile memorizzarli in un file esterno.

Crea un File con gli URI:

Salva gli URI in un file chiamato ad esempio blocked_uris.txt:

/login /admin /signup /api/private

Usa il File nella Regola:

SecRule REQUEST_URI "@pmFromFile /path/to/blocked_uris.txt" "id:2003,phase:2,deny,status:403,msg:'Blocked sensitive URIs from file'"

Considerazioni sulle Prestazioni waf riguardo alcune direttive

Liste Brevi: Usa @ipMatch o @pm per una gestione rapida e semplice.

Liste Lunghe: Per elenchi di grandi dimensioni (centinaia o migliaia di voci), preferisci file esterni con @ipMatchFromFile o @pmFromFile.

Espressioni Regolari: Sono potenti ma meno performanti con pattern complessi o molto lunghi.

Al seguente link se volete ampliare le direttive e le azioni disponibili sulla documentazione ufficiale.

Aggiungere il Set di Rules Core OWASP (CRS) a Coraza

il WAF Coraza non include il CRS OWASP di default, ma è possibile integrare manualmente il CRS per rafforzare la sicurezza. Per scaricare, personalizzare e applicare il CRS al WAF.

1: Scarica il Core Rule Set

clona il repository ufficiale su un volume del tuo host e monta quel path sul container di Trafik, in modo di dare i permessi di lettura a quella directory

git clone https://github.com/coreruleset/coreruleset.git

2: Integrazione del CRS su Coraza

aggiornate il file dinamico con le direttive di Include e i path corretti montati precedentemente nel container che contengono i file del repository git precedentemente clonato

http:
  middlewares:
    waf:
      plugin:
        coraza:
          directives:
            - SecRuleEngine On
            - "Include /etc/modsecurity.d/coreruleset/crs-setup.conf"
            - "Include /etc/modsecurity.d/coreruleset/rules/*.conf"

La configurazione indica al waf coraza di caricare il Core Rule Set. Il file crs-setup.conf viene utilizzato per la configurazione di base del CRS, mentre i file rules/*.conf contengono i singoli set di regole.

Esempi addizionali: Core Rule Set Enhancements

1. Bloccare SQL Injection

Aggiungi questa regola per bloccare i tentativi di SQL injection nelle request url

SecRule ARGS "@rx select.*from.*" "id:103,phase:2,log,deny,status:403,msg:'SQL Injection Attempt'"

2. Abilitare il Rate Limiting

Per prevenire attacchi di brute force o richieste eccessive, puoi implementare il rate limiting utilizzando ModSecurity:

SecAction "id:104,phase:1,pass,nolog,initcol:ip=%{REMOTE_ADDR},expirevar:ip.counter=60"
SecRule IP:COUNTER "@gt 100" "id:105,phase:1,deny,status:429,msg:'Too Many Requests'"

questa regola in esempio bloccherà ogni client che farà più di 100 richieste nell’arco di 60 secondi.

Conclusione

Con Coraza WAF integrato in Traefik, si può proteggere efficacemente le applicazioni web definendo regole avanzate per filtrare richieste basate su indirizzi IP e URI. Seguendo questa guida, puoi personalizzare le configurazioni in base alle tue esigenze e garantire un livello di sicurezza ottimale per il tuo ambiente.

Se hai bisogno di ulteriori approfondimenti, non esitare a chiederlo nei commenti!