Amazon WAF – Proteggere il tuo sito con Web Application Firewall
da Massimo Della Rovere · pubblicato il 21 maggio, 2017 · modificato il 22 maggio, 2017

Nella maggior parte dei casi siamo abituati a proteggere le richieste del nostro server web tramite delle regole che inseriamo nel server stesso. Ad esempio si usano le regole nel file .htaccess su Apache o si installano dei moduli specifici dedicati alla sicurezza in generale. In realtà questo approccio è idoneo su diverse realtà, anche perché risulta economico, però non è detto che sia sempre la soluzione migliore.

Molte volte, specialmente se un vostro cliente può permettersi un spesa di circa 30€ al mese è meglio utilizzare una struttura dedicata al controllo e al filtro delle richieste http secondo regole che possiamo personalizzare. Questi strumenti vengono chiamati Web Applicacion Firewall e sono servizi con hardware dedicato che analizzano la richiesta HTTP ancora prima di arrivare ai nostri server, aumentando la sicurezza generale e non caricando in modo eccessivo i nostri server che riceveranno solo le richieste pulite.

Amazon WAF

Nei servizi degli Amazon Web Services viene messo a disposizione uno strumento che risolve proprio questa necessità. Il servizio si chiama Amazon WAF e lo troviamo nel gruppo dei servizi che riguardano la sicurezza. È possibile usare WAF per creare regole personalizzate che bloccano gli schemi di attacco più comuni, ad esempio gli attacchi di tipo SQL injection o cross-site scripting, e regole specifiche per l’applicazione.

Il servizio di Firewall messo a disposizione da Amazon viene collegato alle distribuzioni di Amazon CloudFront per le richieste di contenuti statici e dinamici o ai bilanciatori di traffico (Elastic Load Balancer) per chi gestisce diversi server. Il suo utilizzo è molto semplice, una volta collegato alla risorsa interessata basta definire tutte le regole di accesso e controllare il risultato. Le regole vengono applicate in pochi secondi.

Come funziona

Il servizio è suddiviso in tre gruppi gerarchici, nel primo troviamo le ACLs (Access Control List), nel secondo le Regole e nel terzo le Condizioni. Diverse condizioni definiscono una regola, mentre diverse regole definiscono una ACL. Quest’ultima sarà la risorsa che verrà collegata alle applicazioni che necessitano di protezione. Per chiarire meglio questo concetto andiamo a vedere nel dettaglio i diversi gruppi.

Nel proseguimento di questo articolo cercherò di presentare i componenti del servizio con una configurazione reale che potrebbe andare bene in una installazione classica di WordPress senza necessità specifiche. Quindi non la prendete come una soluzione assoluta, è solo un esempio che potrebbe essere la base della vostra esigenza.

Le ACLs

Le Access Control List vengono usate per indicate tutte le regole da controllare e per ognuna di queste l’azione da eseguire nel caso in cui la regola risultasse vera. Le azioni disponibili al momento sono: Allow, Block e Count. Con Allow si permette l’accesso e quindi la richiesta viene inviata al nostro server, con Block la richiesta viene bloccata e il nostro server non riceve nulla, mentre con Count si simula un blocco virtuale.

Con Count la richiesta viene mandata al nostro server ma si incrementa un contatore che indica che la richiesta ha prodotto un blocco informativo. L’opzione Count risulta molto utile in fase di TEST in modo da analizzare il comportamento della regola senza che questa venga realmente usata nelle richieste dei nostri visitatori.

Nell’esempio riportato ho inserito le seguenti regole:

RulesWhiteList: Elenco degli indirizzi IP o di alcune condizioni per cui l’accesso è sempre permesso. Io normalmente lascio questa regola sempre vuota, per poi usarla nel momento in cui ho una esigenza particolare e voglio bypassare il firewall.

RulesWhiteAdmin: Dato che molte richieste che vengono fatte nella parte admin di WordPress vengono bloccate dalle regole successive, qui inserisco gli indirizzi IP che sono autorizzati ad entrare nella sezione di amministrazione.

RulesBlackList: Elenco degli indirizzi IP o altre informazioni come User-Agent, Referer o altre opzioni personalizzabili con cui bloccare l’accesso al nostro sito. Questa regola può essere integrata con delle condizioni automatiche utilizzando delle API.

RulesBadPath: Elenco dei path che non sono permessi, come ad esempio gli scripts presenti nella directory wp-include, wp-content, etc etc. Io ad esempio blocco anche i file PHP presenti nella directory principale di WordPress come wp-config.php.

RulesBadPrefix: Elenco dei prefissi dei file che non sono permessi e per i quali non deve essere generata una richiesta al nostro server. Ad esempio io escludo molte volte i suffissi: *.ini, *.swp, *.log, *.txt e tutto ciò che non ritengo idoneo ad una richiesta.

RulesBadBot: In questa regola indico tutti gli User Agent dei bot che danno fastidio al mio sito e di cui non mi interessa essere indicizzato. In questo modo evito migliaia di richiesta HTTP al mio server e non riempo i log con info che non mi interessano.

RulesBadReferer: Questa regola funziona come la precedente con la differenza che invece che controllare la stringa User Agent controllo quella Referer. Questa tecnica mi permette di evitare molti fastidi su Google Analytics di siti SPAM.

RulesSQLinjection: Controllo se la richiesta URI o la parte di Query String contiene codice SQL che può essere usato come SQL injection. La cosa buona di questa condizione è che non bisogna impazzire con espressioni regolari o cose complicate come si fa normalmente sui server classici, la regola è automatica e l’algoritmo che viene usato è lo stesso che viene usato per i siti di amazon.com.

RulesXSSinjection: Con questa regola si controlla se la richiesta contiene nella stringa URL o nel body di un metodo POST codice cross site scripting. Come per la regola di SQL anche questa è automatica e l’algoritmo è stato creato da Amazon. Ovviamente per esigenze particolari si aggiungono delle regole manuali.

Nota Bene: Come potete notare dalla immagine allegata ogni regola ha una sequenza nell’ambito della ACL, questa sequenza è molto importante, in quanto se si verifica una condizione questa viene eseguita senza analizzare le regole successive. Per questo ho usato le regole Allow prima, altrimenti in alcuni casi non sarebbero state eseguite.

Le Regole

Le regole contengono delle condizioni e come visto in precedenza vengono inserire in una ACL per specificarne l’azione legata e la sequenza progressiva nella lista. Nel mio esempio ho elencato diverse regole, però non andremo a vederle tutte nel dettaglio, l’articolo diventerebbe troppo lungo, quindi ve ne riporto una in modo da vedere insieme come crearla e come si connetta alle condizioni che vogliamo.

Per gestire le regole bisogna selezionare il menu Rules sulla sinistra della pagina che riguarda il servizio di Amazon WAF, vi verrà presentata una schermata simile a questa in cui potete creare una nuova regola o modificarne una esistente. In questo esempio possiamo notare che la regola selezionata RulesBadPrefix ha due condizioni, nella prima ci sono i file per cui bisogna fare una eccezione e nella seconda i prefissi dei file per cui non è permesso l’accesso. Ad esempio io blocco i file *.txt ad eccezione del file robots.txt che viene utilizzato dai motori di ricerca come google.

Se volete cambiare questa regola usate il bottone in alto (edit rule) con cui attiverete una pagina su cui sarà possibile aggiungere o eliminare le condizioni. Ovviamente le condizioni devono essere state già precedentemente definite. Proprio per questo io consiglio sempre di creare prima le condizioni e poi le regole, anche se dal punto di vista della spiegazione le ho presentate in sequenza inversa.

Le condizioni

Come detto in precedenza una sequenza di condizioni genera una regola, ogni condizione è composta da una serie di test che possono essere eseguiti su parti diverse di una richiesta HTTP, come ad esempio IP, URL, Header, Body, etc. Anche le condizioni sono suddivise per gruppi in base alla tipologia di controllo:

  • Cross-site scripting (algoritmo automatico)
  • IP addresses (condizioni legate agli indirizzi IP)
  • Size constraints (condizioni legate alla dimensione della richiesta)
  • SQL injection (algoritmo automatico)
  • String matching (controllo stringa su diversi componenti)

Ogni condizione ha un tipo di configurazione differente, anche se di base il concetto rimane il medesimo. Sicuramente le condizioni più utilizzate sono il controllo stringa e l’elenco degli indirizzi IP permessi o bloccati. Vi riporto un esempio a seguire:

Esattamente come per le Regole anche nelle condizioni abbiamo questa schermata in cui sulla sinistra possiamo creare o modificare una condizione, mentre sulla destra possiamo aggiungere o cancellare i controlli che compongono la condizione. In questo esempio abbiamo la condizione StringBadPrefix con l’elenco dei prefissi che non sono ammessi nella richiesta. Però per essere più specifici sulle possibilità che ci sono nella creazione di una condizione vi faccio vedere la schermata di creazione.

Come potete vedere possiamo selezionare la parte della richiesta che deve essere analizzata, il tipo di match che deve essere eseguito, una eventuale trasformazione prima del controllo (come ad esempio tutto in minuscolo) e la stringa finale che deve essere usata come controllo di valore. Ovviamente è possibile mettere diversi filtri nella stessa condizione come potete vedere dall’immagine del StringBadPrefix.

Guida completa su AWS

Questo articolo appartiene ad una serie di pubblicazioni che costituiscono una guida completa dedicata agli Amazon Web Services. Molti servizi che trattiamo in questo blog vengono anche spiegati con dei video che trovate nel nostro canale youtube. Se volete seguire questo percorso didattico iscrivetevi alla community Cloud AWS.

1 Commento

  1. Il prezzo non mi sembra alto per un servizo enterprise. La logica delle regole, condizioni, etc è chiara ma facendo qualche prova con il servizio ho visto che le condizioni sono tutte in AND non è un limite? Comunque sarebbe meglio specificare nell'articolo che questa soluzione va bene se il sito gira già in ambiente AWS.

condividi