Domande frequenti per Web application firewall di Azure sul servizio Frontdoor di Azure

Questo articolo risponde a domande comuni sul Web application firewall (WAF) di Azure nelle funzionalità del servizio Frontdoor di Azure.

Cos'è il web application firewall di Azure?

Il WAF di Azure è un web application firewall che consente di proteggere le applicazioni Web da minacce comuni, quali attacchi SQL injection, script da altri siti e altri exploit Web. L'utente può definire un criterio WAF costituito da una combinazione di regole personalizzate e gestite per controllare l'accesso alle applicazioni Web.

I criteri WAF di Azure possono essere applicati alle applicazioni Web ospitate nel gateway applicazione o in Frontdoor di Azure.

Cosa di intende per WAF nel servizio Frontdoor di Azure?

Frontdoor di Azure è un'applicazione distribuita a livello globale e altamente scalabile e una rete per la distribuzione di contenuti. Se integrato con Frontdoor, WAF di Azure arresta gli attacchi Denial of Service e delle applicazioni di destinazione al perimetro di rete di Azure, vicino alle origini degli attacchi prima che questi entrino nella rete virtuale, offre protezione senza compromettere le prestazioni.

WAF di Azure supporta HTTPS?

Frontdoor offre l'offload TLS. WAF è integrato in modo nativo con Frontdoor e può controllare una richiesta dopo averla decrittografata.

WAF di Azure supporta IPv6?

Sì. È possibile configurare la restrizione IP per IPv4 e IPv6.

Quanto sono aggiornati i set di regole gestiti?

Microsoft fa del suo meglio per rimanere al passo con il panorama delle minacce sempre in evoluzione. Una volta aggiornata, una nuova regola viene aggiunta al set di regole predefinito con un nuovo numero di versione.

Qual è il tempo di propagazione se si apporta una modifica ai criteri WAF?

La maggior parte delle distribuzioni dei criteri WAF viene completata in meno di 20 minuti. È possibile prevedere che i criteri vengano applicati non appena l'aggiornamento viene completato in tutte le posizioni perimetrali a livello globale.

I criteri WAF possono essere diversi per aree diverse?

Se integrato con Frontdoor, WAF è una risorsa globale. La stessa configurazione si applica a tutte le posizioni di Frontdoor.

Come limitare l'accesso al back-end solo da Frontdoor?

È possibile configurare l'elenco di controllo di accesso IP nel back-end per consentire solo gli intervalli di indirizzi IP in uscita di Frontdoor e negare l'accesso diretto da Internet. I tag di servizio sono supportati per consentirne l'uso nella rete virtuale. È anche possibile verificare che il campo di intestazione HTTP X-Forwarded-Host sia valido per l'applicazione Web.

Quali opzioni di WAF di Azure è consigliabile scegliere?

Quando si applicano i criteri WAF in Azure, sono disponibili due opzioni. WAF con Frontdoor di Azure è una soluzione di sicurezza perimetrale distribuita a livello globale. WAF con il gateway applicazione è una soluzione dedicata a livello di area. È consigliabile scegliere una soluzione in base alle prestazioni complessive e ai requisiti di sicurezza. Per altre informazioni, vedere Bilanciamento del carico con la suite per il recapito di applicazioni di Azure.

Qual è l'approccio consigliato per abilitare WAF in Frontdoor?

Quando si abilita WAF in un'applicazione esistente, è comune che vengano rilevati falsi positivi quando le regole WAF rilevano il traffico legittimo come minaccia. Per ridurre al minimo il rischio di un impatto sugli utenti, è consigliabile seguire questa procedura:

  • Abilitare WAF in modalità di rilevamento per assicurarsi che non blocchi le richieste durante l'esecuzione del processo.

    Importante

    Questo processo descrive come abilitare WAF in una soluzione nuova o esistente quando la priorità è ridurre al minimo il disturbo per gli utenti dell'applicazione. In caso di attacco o minaccia imminente, è invece consigliabile distribuire immediatamente WAF in modalità prevenzione e usare il processo di ottimizzazione per monitorare e ottimizzare WAF nel tempo. Questo causerà probabilmente il blocco di parte del traffico legittimo, motivo per cui è consigliabile eseguire questa operazione solo quando si rileva una minaccia.

  • Seguire le indicazioni per l'ottimizzazione di WAF. Questo processo richiede l'abilitazione della registrazione diagnostica, la revisione periodica dei log e l'aggiunta di esclusioni di regole e altre mitigazioni.
  • Ripetere l'intero processo controllando regolarmente i log fino a quando non si è certi che il traffico legittimo non venga bloccato. L'intero processo può richiedere diverse settimane. In una situazione ideale il numero di falsi positivi rilevati dovrebbe ridursi dopo ogni modifica apportata all'ottimizzazione.
  • Abilitare infine WAF in modalità di prevenzione.
  • Anche dopo aver eseguito WAF nell'ambiente di produzione, è consigliabile continuare a monitorare i log per identificare eventuali altri rilevamenti di falsi positivi. La revisione periodica dei log consente anche di identificare eventuali tentativi di attacco reali che sono stati bloccati.

Le stesse funzionalità di WAF sono supportate in tutte le piattaforme integrate?

Attualmente, le regole ModSec CRS 2.2.9, CRS 3.0 e CRS 3.1 sono supportate con WAF solo nel gateway applicazione. La limitazione della frequenza, il filtro geografico e le regole del set di regole predefinite gestite da Azure sono supportate con WAF solo in Frontdoor di Azure.

La protezione DDoS è integrata con Frontdoor?

Frontdoor di Azure, distribuito a livello globale nei perimetri di rete di Azure, può assorbire e isolare geograficamente gli attacchi con volumi di grandi dimensioni. È possibile creare criteri WAF personalizzati per bloccare e limitare automaticamente la frequenza degli attacchi http con firme note. È anche possibile abilitare la Protezione DDoS Standard nella rete virtuale in cui vengono distribuiti i back-end. I clienti di Protezione DDoS di Azure Standard ricevono vantaggi aggiuntivi, tra cui la protezione dei costi, la garanzia del contratto di servizio e l'accesso agli esperti del team di risposta rapida DDoS per assistenza immediata durante un attacco. Per altre informazioni, vedere Protezione DDoS di Azure su Frontdoor.

Perché le richieste aggiuntive che superano la soglia configurata per la regola per il limite di frequenza vengono passate al server back-end?

Una regola per il limite di frequenza può limitare il traffico eccessivamente elevato proveniente da un indirizzo IP client. È possibile configurare una soglia per il numero di richieste Web consentite provenienti da un indirizzo IP client per un intervallo di un minuto o di cinque minuti. Per il controllo della frequenza a livello granulare, la limitazione della frequenza può essere combinata con condizioni di corrispondenza aggiuntive, ad esempio parametri HTTP(S) corrispondenti.

La soglia del limite di frequenza viene in genere impostata su un altro valore per difendersi da attacchi Denial of Service provenienti da qualsiasi indirizzo IP client. Le richieste dello stesso client spesso arrivano allo stesso server Frontdoor. In tal caso, le richieste aggiuntive oltre la soglia verranno bloccate immediatamente. Tuttavia, è possibile che le richieste dello stesso client arrivino a un server Frontdoor diverso che non ha ancora aggiornato il contatore del limite di frequenza. Ad esempio, il client può aprire una nuova connessione per ogni richiesta e, se la soglia è sufficiente, la prima richiesta al nuovo server Frontdoor passerà il controllo del limite di velocità. Quindi, per una soglia molto bassa (ad esempio inferiore a ~50 RPM), è possibile che vengano visualizzate richieste aggiuntive al di sopra della soglia.

Quali tipi di contenuto supporta WAF?

Frontdoor WAF supporta i tipi di contenuto seguenti:

  • Ripristino di emergenza 2.0

    Regole gestite

    • application/json
    • application/xml
    • application/x-www-form-urlencoded
    • multipart/form-data

    Regole personalizzate

    • application/x-www-form-urlencoded
  • Ripristino di emergenza 1.x

    Regole gestite

    • application/x-www-form-urlencoded
    • text/plain

    Regole personalizzate

    • application/x-www-form-urlencoded

Passaggi successivi