Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Web application firewall (WAF) è uno strumento importante che consente di proteggere le applicazioni Web da attacchi dannosi. Può filtrare, monitorare e arrestare il traffico Web usando regole predefinite e personalizzate. È possibile creare una regola personalizzata che WAF verificherà per ogni richiesta ricevuta. Le regole personalizzate hanno priorità rispetto alle regole gestite e vengono verificate per prime.
Una delle funzionalità più potenti di Web Application Firewall di Azure è rappresentata dalle regole personalizzate di corrispondenza geografica. Queste regole consentono di associare le richieste Web alla posizione geografica da cui provengono. Ad esempio, è possibile decidere di bloccare le richieste provenienti da aree geografiche note per attività dannose oppure consentire le richieste provenienti da aree importanti per la propria attività. Le regole personalizzate di corrispondenza geografica possono anche semplificare la conformità alle leggi sulla sovranità dei dati e sulla privacy, limitando l'accesso alle applicazioni Web in base alla posizione delle persone che le usano.
Usare il parametro di priorità con attenzione quando si ricorre alle regole personalizzate di corrispondenza geografica, in modo da inutili processi di elaborazione o conflitti. Azure WAF valuta le regole nell'ordine determinato dal parametro di priorità, un valore numerico compreso tra 1 e 100, in cui i valori più bassi indicano una priorità più alta. La priorità deve essere univoca in tutte le regole personalizzate. Assegnare una priorità più alta alle regole critiche o specifiche per la sicurezza dell'applicazione Web e una priorità più bassa alle regole generali o meno essenziali. In questo modo, WAF applica le azioni più appropriate al traffico Web. Uno scenario in cui si identifica un percorso URI esplicito, ad esempio, è molto specifico e dovrebbe quindi avere una regola con priorità più elevata rispetto ad altri tipi di criteri. La priorità più alta protegge un percorso critico nell'applicazione, consentendo al tempo stesso di valutare un traffico più generico tra altre regole personalizzate o set di regole gestite.
Testare sempre le regole prima di applicarle all'ambiente di produzione e monitorare regolarmente le prestazioni e l'impatto. Seguendo queste procedure consigliate, è possibile migliorare la sicurezza delle applicazioni Web usando la potenza delle regole personalizzate per la corrispondenza geografica.
Questo articolo presenta le regole personalizzate per la corrispondenza geografica waf di Azure e illustra come crearle e gestirle usando il portale di Azure, Bicep e Azure PowerShell.
Criteri delle regole personalizzate di corrispondenza geografica
Le regole personalizzate di corrispondenza geografica consentono di soddisfare diversi obiettivi di sicurezza, ad esempio bloccando le richieste provenienti da aree ad alto rischio e autorizzando quelle provenienti da aree affidabili. Sono efficaci per mitigare gli attacchi DDoS (Distributed Denial of Service), che cercano di inondare l'applicazione Web con numerose richieste provenienti da diverse origini. Con le regole personalizzate di corrispondenza geografica, è possibile individuare e bloccare tempestivamente le aree che generano il maggior traffico DDoS, garantendo comunque l'accesso agli utenti legittimi. In questo articolo vengono illustrati vari criteri di regole personalizzate che è possibile usare per ottimizzare Azure WAF mediante regole personalizzate di corrispondenza geografica.
Scenario 1 - Bloccare il traffico da tutti i paesi o aree geografiche, ad eccezione di "x"
Le regole personalizzate di corrispondenza geografica risultano utili quando si mira a bloccare il traffico da tutti i paesi o le aree geografiche, ad eccezione di uno. Se, ad esempio, un'applicazione Web è destinata esclusivamente agli utenti negli Stati Uniti, è possibile formulare una regola personalizzata di corrispondenza geografica che blocchi tutte le richieste non provenienti dagli Stati Uniti. Questa strategia riduce in modo efficace la superficie di attacco dell'applicazione Web e scoraggia accessi non autorizzati da altre aree. Questa tecnica specifica usa una condizione di negazione per facilitare un criterio di gestione del traffico di questo tipo. Per creare una regola personalizzata di geomatch che impedisce il traffico da tutti i paesi o le aree geografiche, ad eccezione degli Stati Uniti, consultare i seguenti esempi nel portale, in PowerShell o in Bicep:
Note
Nel WAF frontdoor di Azure usare SocketAddr come variabile di corrispondenza e non RemoteAddr. La variabile RemoteAddr è l'indirizzo IP client originale che viene in genere inviato tramite l'intestazione della richiesta di X-Forwarded-For. La variabile SocketAddr è l'indirizzo IP di origine visualizzato dal WAF.
Scenario 2 - Bloccare il traffico da tutti i paesi o aree geografiche ad eccezione di "x" e "y" destinati all'URI "foo" o "bar"
Si consideri uno scenario in cui è necessario usare regole personalizzate di corrispondenza geografica per bloccare il traffico proveniente da tutti i paesi o le aree geografiche, ad eccezione di due o più aree specifiche, corrispondenti a un determinato URI. Si supponga inoltre che l'applicazione Web abbia percorsi URI specifici destinati solo agli utenti in Stati Uniti e Canada. In questo caso, è necessario creare una regola personalizzata di corrispondenza geografica che blocchi tutte le richieste non provenienti da questi paesi o aree geografiche.
Questo criterio elabora i payload delle richieste provenienti dagli Stati Uniti e dal Canada attraverso set di regole gestiti, intercettando eventuali attacchi dannosi e bloccando le richieste provenienti da qualsiasi altro paese o area geografica. Questo approccio garantisce che solo i destinatari possano accedere all'applicazione Web, evitando il traffico indesiderato da altre aree.
Per ridurre al minimo i potenziali falsi positivi, includere il codice paese ZZ nell'elenco per acquisire gli indirizzi IP non ancora mappati a un paese o a un’area geografica nel set di dati di Azure. Questa tecnica usa una condizione di negazione per il tipo di georilevazione e una condizione di non negazione per la corrispondenza dell’URI.
Per creare una regola personalizzata di corrispondenza geografica che blocchi il traffico proveniente da tutti i paesi o le aree geografiche (eccetto Stati Uniti e Canada) verso l'URI specificato, fare riferimento agli esempi forniti nel portale, in PowerShell e in Bicep.
Scenario 3 - Bloccare il traffico proveniente da un paese o un'area "x" specifica
È possibile usare regole personalizzate di corrispondenza geografica per bloccare il traffico proveniente da paesi o aree specifiche. Se, ad esempio, la tua applicazione Web riceve molte richieste dannose dal paese o dall'area “x”, creare una regola personalizzata di corrispondenza geografica per bloccare tutte le richieste provenienti da quel paese o quell'area. In questo modo si protegge l'applicazione Web da attacchi potenziali e riduce il carico delle risorse. Applicare questo criterio per bloccare più paesi o aree ostili o dannose. Questa tecnica richiede una condizione di corrispondenza per il criterio di traffico. Per bloccare il traffico proveniente dal paese o dalla regione "x", consultare i seguenti esempi relativi al portale, a PowerShell e a Bicep.
Anti-criteri delle regole personalizzate di corrispondenza geografica
Evitare anti-criteri quando si utilizzano regole personalizzate di corrispondenza geografica, ad esempio l'impostazione dell'azione della regola personalizzata su allow anziché su block. Un'azione di questo tipo, infatti, può avere conseguenze indesiderate, come consentire al traffico di ignorare WAF ed esporre potenzialmente l'applicazione Web ad altre minacce.
Anziché adottare un'azione allow, usare un'azione blockcon una condizione di negazione, come mostrato nei criteri precedenti. In questo modo viene consentito solo il traffico proveniente dai paesi o dalle aree desiderate, mentre WAF blocca tutto il traffico restante.
Scenario 4 - Consentire il traffico da un paese o un'area geografica "x"
Evitare di impostare la regola personalizzata di corrispondenza geografica in modo da consentire il traffico proveniente da un Paese o un'area specifica. Se, ad esempio, si desidera consentire il traffico proveniente dagli Stati Uniti per la presenza di un'ampia base clienti, la soluzione potrebbe essere quella di creare una regola personalizzata con l'azione allow e il valore United States. Questa regola, tuttavia, consente tutto il traffico proveniente dagli Stati Uniti, indipendentemente dal fatto che contenga o meno un payload dannoso, poiché l'azione allow aggira la successiva elaborazione dei set di regole gestiti. Inoltre, WAF elabora ancora il traffico da tutti gli altri paesi o aree geografiche, consumando risorse. In questo modo, l'applicazione Web viene esposta a richieste dannose provenienti dagli Stati Uniti che altrimenti sarebbero bloccate dal WAF.
Scenario 5 - Consentire il traffico da tutti i paesi ad eccezione di "x"
Quando si usano regole personalizzate di corrispondenza geografica, evitare di impostare l'azione della regola su allow e di specificare un elenco di paesi o aree da escludere. Se, ad esempio, si vuole consentire il traffico da tutti i paesi o le aree ad eccezione degli Stati Uniti, in cui si sospetta un'attività dannosa, questo approccio potrebbe avere conseguenze impreviste. Potrebbe consentire il traffico da paesi/aree geografiche non verificate o non sicure o paesi/aree geografiche con standard di sicurezza ridotti o assenti, esponendo l'applicazione Web a potenziali vulnerabilità o attacchi. L'uso dell'azione allow per tutti i paesi o le aree geografiche, ad eccezione degli Stati Uniti, indica al WAF di interrompere i payload della richiesta di elaborazione rispetto ai set di regole gestiti. Una volta elaborata la regola personalizzata con allow, la valutazione delle regole viene interrotta, esponendo l'applicazione ad attacchi dannosi indesiderati.
Usare invece un'azione più restrittiva e specifica, come il blocco, e specifica un elenco di paesi o aree da consentire con una condizione di negazione. In questo modo, all'applicazione Web potrà accedere solo il traffico proveniente da origini affidabili e verificate, mentre tutto il traffico sospetto o indesiderato verrà bloccato.