Condividi tramite


Risolvere i problemi di Web application firewall (WAF) per gateway applicazione di Azure

Sommario

Questo articolo illustra come risolvere i problemi di Web application firewall (WAF) per gateway applicazione di Azure quando le richieste legittime vengono bloccate, in modo da consentire il traffico valido mantenendo la protezione.

Per iniziare, esaminare la panoramica di WAF e la documentazione sulla configurazione di WAF e assicurarsi che il monitoraggio di WAF sia abilitato. Questi articoli illustrano il funzionamento del WAF, il funzionamento dei set di regole e come accedere ai log WAF.

I set di regole OWASP sono progettati per essere rigidi e ottimizzati in base alle esigenze specifiche dell'applicazione o dell'organizzazione che usano WAF. È del tutto normale, e previsto in molti casi, creare esclusioni, regole personalizzate e persino disabilitare regole che potrebbero causare problemi o falsi positivi. I criteri per sito e per URI consentono di apportare queste modifiche solo a siti/URI specifici. Pertanto, le modifiche non devono influire su altri siti che potrebbero non affrontare gli stessi problemi.

Informazioni sui log WAF

Lo scopo dei log waf è mostrare ogni richiesta che WAF corrisponde o blocca. Si tratta di un libro mastro di tutte le richieste valutate e accettate o bloccate. Se si nota che WAF blocca una richiesta che non deve (un falso positivo), è possibile eseguire alcune operazioni. Prima di tutto, restringi e trova la richiesta specifica. Esaminare i log per trovare l'URI, il timestamp o l'ID transazione specifici della richiesta. Quando si trovano le voci di log associate, è possibile iniziare a agire sui falsi positivi.

Si supponga, ad esempio, di avere un traffico legittimo contenente la stringa 1=1 che si vuole passare attraverso il WAF. Se si prova la richiesta, WAF blocca il traffico che contiene la 1=1 stringa in qualsiasi parametro o campo. Si tratta di una stringa spesso associata a un attacco SQL injection. È possibile esaminare i log e visualizzare il timestamp della richiesta e le regole bloccate/corrispondenti.

Nell'esempio seguente è possibile notare che quattro regole vengono attivate durante la stessa richiesta (usando il campo TransactionId). Il primo indica che corrisponde perché l'utente ha usato un URL numerico/IP per la richiesta, che aumenta il punteggio di anomalia di tre perché è un avviso. La regola successiva corrispondente è 942130, ovvero quella che si sta cercando. È possibile vedere il 1=1 nel campo details.data. Questo aumenta ulteriormente il punteggio di anomalia ancora di tre, perché è anche un avviso. In genere, ogni regola con l'azione Matched aumenta il punteggio di anomalia e a questo punto il punteggio di anomalia sarà sei. Per ulteriori informazioni, vedere Modalità di valutazione delle anomalie.

Le due voci di log finali mostrano che la richiesta è stata bloccata perché il punteggio di anomalia è stato sufficientemente elevato. Queste voci hanno un'azione diversa rispetto alle altre due. Mostrano che hanno effettivamente bloccato la richiesta. Queste regole sono obbligatorie e non possono essere disabilitate. Non dovrebbero essere considerati come regole, ma più come infrastruttura di base degli interni WAF.

{ 
    "resourceId": "/SUBSCRIPTIONS/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/RESOURCEGROUPS/MYRESOURCEGROUP/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/DEMOWAF-V2",
    "operationName": "ApplicationGatewayFirewall",
    "category": "ApplicationGatewayFirewallLog",
    "properties": { 
        "instanceId": "appgw_3",
        "clientIp": "203.0.113.139",
        "clientPort": "",
        "requestUri": "\/",
        "ruleSetType": "OWASP_CRS",
        "ruleSetVersion": "3.0.0",
        "ruleId": "920350",
        "message": "Host header is a numeric IP address",
        "action": "Matched",
        "site": "Global",
        "details": { 
            "message": "Warning. Pattern match \\\"^[\\\\\\\\d.:]+$\\\" at REQUEST_HEADERS:Host. ",
            "data": "40.90.218.160",
            "file": "rules\/REQUEST-920-PROTOCOL-ENFORCEMENT.conf\\\"",
            "line": "791" 
        },
        "hostname": "vm000003",
        "transactionId": "AcAcAcAcAKH@AcAcAcAcAyAt" 
    } 
} 
{ 
    "resourceId": "/SUBSCRIPTIONS/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/RESOURCEGROUPS/MYRESOURCEGROUP/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/DEMOWAF-V2",
    "operationName": "ApplicationGatewayFirewall",
    "category": "ApplicationGatewayFirewallLog",
    "properties": { 
        "instanceId": "appgw_3",
        "clientIp": "203.0.113.139",
        "clientPort": "",
        "requestUri": "\/",
        "ruleSetType": "OWASP_CRS",
        "ruleSetVersion": "3.0.0",
        "ruleId": "942130",
        "message": "SQL Injection Attack: SQL Tautology Detected.",
        "action": "Matched",
        "site": "Global",
        "details": { 
            "message": "Warning. Pattern match \\\"(?i:([\\\\\\\\s'\\\\\\\"`\\\\\\\\(\\\\\\\\)]*?)([\\\\\\\\d\\\\\\\\w]++)([\\\\\\\\s'\\\\\\\"`\\\\\\\\(\\\\\\\\)]*?)(?:(?:=|\\u003c=\\u003e|r?like|sounds\\\\\\\\s+like|regexp)([\\\\\\\\s'\\\\\\\"`\\\\\\\\(\\\\\\\\)]*?)\\\\\\\\2|(?:!=|\\u003c=|\\u003e=|\\u003c\\u003e|\\u003c|\\u003e|\\\\\\\\^|is\\\\\\\\s+not|not\\\\\\\\s+like|not\\\\\\\\s+regexp)([\\\\\\\\s'\\\\\\\"`\\\\\\\\(\\\\\\\\)]*?)(?!\\\\\\\\2)([\\\\\\\\d\\\\\\\\w]+)))\\\" at ARGS:text1. ",
            "data": "Matched Data: 1=1 found within ARGS:text1: 1=1",
            "file": "rules\/REQUEST-942-APPLICATION-ATTACK-SQLI.conf\\\"",
            "line": "554" 
        },
        "hostname": "vm000003",
        "transactionId": "AcAcAcAcAKH@AcAcAcAcAyAt" 
    } 
} 
{ 
    "resourceId": "/SUBSCRIPTIONS/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/RESOURCEGROUPS/MYRESOURCEGROUP/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/DEMOWAF-V2",
    "operationName": "ApplicationGatewayFirewall",
    "category": "ApplicationGatewayFirewallLog",
    "properties": { 
        "instanceId": "appgw_3",
        "clientIp": "203.0.113.139",
        "clientPort": "",
        "requestUri": "\/",
        "ruleSetType": "",
        "ruleSetVersion": "",
        "ruleId": "0",
        "message": "Mandatory rule. Cannot be disabled. Inbound Anomaly Score Exceeded (Total Score: 8)",
        "action": "Blocked",
        "site": "Global",
        "details": { 
            "message": "Access denied with code 403 (phase 2). Operator GE matched 5 at TX:anomaly_score. ",
            "data": "",
            "file": "rules\/REQUEST-949-BLOCKING-EVALUATION.conf\\\"",
            "line": "57" 
        },
        "hostname": "vm000003",
        "transactionId": "AcAcAcAcAKH@AcAcAcAcAyAt" 
    } 
} 
{ 
    "resourceId": "/SUBSCRIPTIONS/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/RESOURCEGROUPS/MYRESOURCEGROUP/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/DEMOWAF-V2",
    "operationName": "ApplicationGatewayFirewall",
    "category": "ApplicationGatewayFirewallLog",
    "properties": { 
        "instanceId": "appgw_3",
        "clientIp": "203.0.113.139",
        "clientPort": "",
        "requestUri": "\/",
        "ruleSetType": "",
        "ruleSetVersion": "",
        "ruleId": "0",
        "message": "Mandatory rule. Cannot be disabled. Inbound Anomaly Score Exceeded (Total Inbound Score: 8 - SQLI=5,XSS=0,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): SQL Injection Attack: SQL Tautology Detected.",
        "action": "Blocked",
        "site": "Global",
        "details": { 
            "message": "Warning. Operator GE matched 5 at TX:inbound_anomaly_score. ",
            "data": "",
            "file": "rules\/RESPONSE-980-CORRELATION.conf\\\"",
            "line": "73" 
        },
        "hostname": "vm000003",
        "transactionId": "AcAcAcAcAKH@AcAcAcAcAyAt" 
    }
}

Correggere i falsi positivi

Con queste informazioni e la conoscenza che la regola 942130 è quella corrispondente alla 1=1 stringa, è possibile eseguire alcune operazioni per impedire il blocco del traffico:

  • Usare un elenco di esclusione. Per altre informazioni sugli elenchi di esclusione, vedere Elenchi di esclusione WAF.

  • Disabilitare la regola.

Usare un elenco di esclusione

Per prendere una decisione informata sulla gestione di un falso positivo, è importante acquisire familiarità con le tecnologie usate dall'applicazione. Diciamo, ad esempio, che non sia presente un server SQL nel tuo stack tecnologico e che si ottengano falsi positivi correlati a quelle regole. La disabilitazione di queste regole non indeboli necessariamente la sicurezza.

Un vantaggio dell'uso di un elenco di esclusione è che solo una parte specifica di una richiesta è disabilitata. Ciò significa tuttavia che un'esclusione specifica è applicabile a tutto il traffico che passa attraverso il WAF perché si tratta di un'impostazione globale. Ad esempio, questo potrebbe causare un problema se 1=1 è una richiesta valida nel corpo di una determinata app, ma non per altri. Un altro vantaggio è che è possibile scegliere tra corpo, intestazioni e cookie da escludere se viene soddisfatta una determinata condizione, anziché escludere l'intera richiesta.

Occasionalmente, ci sono casi in cui i parametri specifici vengono passati nel WAF in un modo che potrebbe non essere intuitivo. Ad esempio, è presente un token che viene passato durante l'autenticazione usando Microsoft Entra ID. __RequestVerificationToken viene in genere passato come cookie di richiesta. Tuttavia, in alcuni casi in cui i cookie sono disabilitati, questo token viene passato anche come attributo di richiesta o arg. In questo caso, è necessario assicurarsi che __RequestVerificationToken venga aggiunto anche all'elenco di esclusione come nome dell'attributo Request .

Screenshot delle impostazioni dell'elenco di esclusione del WAF nel portale di Azure.

In questo esempio si vuole escludere il nome dell'attributo Request uguale a text1. Questo è evidente perché è possibile visualizzare il nome dell'attributo nei log del firewall: dati: dati corrispondenti: 1=1 trovati in ARGS:text1: 1=1. L'attributo è text1. È anche possibile trovare il nome di questo attributo in altri modi, vedere Ricerca dei nomi degli attributi della richiesta.

Screenshot delle opzioni di configurazione WAF per gli elenchi di esclusione in Application Gateway.

È possibile creare esclusioni per WAF nell'Application Gateway a vari livelli di ambito. Per altre informazioni, vedere Web application firewall liste di esclusione.

Disabilitare le regole

Un altro modo per aggirare un falso positivo consiste nel disabilitare la regola corrispondente all'input che il WAF pensava fosse dannoso. Poiché sono stati analizzati i log WAF e la regola è stata ridotta a 942130, è possibile disabilitarla nel portale di Azure. Vedere Personalizzare le regole del firewall delle applicazioni web tramite il portale di Azure.

Un vantaggio della disabilitazione di una regola è che se si conosce tutto il traffico che contiene una determinata condizione che normalmente è bloccata è traffico valido, è possibile disabilitare tale regola per l'intero WAF. Tuttavia, se si tratta solo di traffico valido in un caso d'uso specifico, si apre una vulnerabilità disabilitando tale regola per l'intero WAF perché si tratta di un'impostazione globale.

Se si vuole usare Azure PowerShell, vedere Customize web application firewall rules through PowerShell (Creare regole web application firewall tramite PowerShell. Per usare interfaccia della riga di comando di Azure, vedere Customize web application firewall rules through the interfaccia della riga di comando di Azure.

Registrare i file HAR

È possibile usare il browser o uno strumento esterno come Fiddler per registrare file di archivio HTTP (HAR). I file HAR contengono informazioni sulle richieste e le risposte eseguite dal browser durante il caricamento di una pagina Web. Queste informazioni possono essere utili per la risoluzione dei problemi di WAF.

Suggerimento

È consigliabile preparare il file HAR quando si contatta il supporto tecnico. Il team di supporto può usare il file HAR per diagnosticare il problema.

Per registrare e salvare un file HAR in Microsoft Edge, seguire questa procedura

  1. Premere F12 o Ctrl+Shift+I per avviare gli Strumenti di sviluppo di Edge. È anche possibile avviare gli strumenti dal menu della barra degli strumenti in Strumenti > Strumenti di sviluppo.

  2. Nella scheda Console selezionare Cancella console o premere CTRL+L.

Screenshot della scheda Console di Microsoft Edge developer tools.

  1. Selezionare la scheda Rete .

  2. Selezionare Cancella log di rete o premere CTRL+L, e quindi selezionare Registra log di rete se non viene registrato.

Screenshot della scheda Rete degli strumenti di sviluppo di Microsoft Edge.

  1. Carica la pagina Web protetta dal tuo WAF per cui vuoi risolvere problemi.

  2. Interrompere la registrazione selezionando il pulsante Arresta registrazione del log della rete.

  3. Selezionare Esporta HAR (sanificata) e salvare il file HAR.

Screenshot dell'opzione Esporta HAR (sanitizzata) negli strumenti di sviluppo di Microsoft Edge.

Trovare i nomi degli attributi della richiesta

È possibile usare Fiddler per esaminare le singole richieste e determinare quali campi specifici di una pagina Web vengono chiamati. L'uso di queste informazioni consente di escludere determinati campi dall'ispezione usando elenchi di esclusione.

In questo esempio è possibile notare che il campo in cui è stata immessa la stringa 1=1 è denominato text1.

Screenshot di Fiddler Web Debugger. Nella scheda Raw, 1=1 è visibile dopo il testo name text1.

Si tratta di un campo che è possibile escludere. Per altre informazioni sugli elenchi di esclusione, vedere Elenchi di esclusione del web application firewall. È possibile escludere la valutazione in questo caso configurando l'esclusione seguente:

Screenshot di un'esclusione WAF configurata per un attributo specifico della richiesta.

È anche possibile esaminare i log del firewall per ottenere le informazioni necessarie per visualizzare gli elementi da aggiungere all'elenco di esclusione. Per abilitare il logging, vedere Integrità back-end, log delle risorse e metriche per Application Gateway.

Esaminare il log del firewall e visualizzare il file PT1H.json per l'ora in cui si desidera controllare la richiesta.

In questo esempio è possibile osservare che sono presenti quattro regole con lo stesso TransactionID e che si sono verificate tutte nello stesso momento:

{
    "resourceId": "/SUBSCRIPTIONS/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/RESOURCEGROUPS/MYRESOURCEGROUP/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/DEMOWAF-V2",
    "operationName": "ApplicationGatewayFirewall",
    "category": "ApplicationGatewayFirewallLog",
    "properties": {
        "instanceId": "appgw_3",
        "clientIp": "203.0.113.139",
        "clientPort": "",
        "requestUri": "\/",
        "ruleSetType": "OWASP_CRS",
        "ruleSetVersion": "3.0.0",
        "ruleId": "920350",
        "message": "Host header is a numeric IP address",
        "action": "Matched",
        "site": "Global",
        "details": {
            "message": "Warning. Pattern match \\\"^[\\\\\\\\d.:]+$\\\" at REQUEST_HEADERS:Host. ",
            "data": "40.90.218.160",
            "file": "rules\/REQUEST-920-PROTOCOL-ENFORCEMENT.conf\\\"",
            "line": "791"
        },
        "hostname": "vm000003",
        "transactionId": "AcAcAcAcAKH@AcAcAcAcAyAt"
    }
}
{
    "resourceId": "/SUBSCRIPTIONS/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/RESOURCEGROUPS/MYRESOURCEGROUP/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/DEMOWAF-V2",
    "operationName": "ApplicationGatewayFirewall",
    "category": "ApplicationGatewayFirewallLog",
    "properties": {
        "instanceId": "appgw_3",
        "clientIp": "203.0.113.139",
        "clientPort": "",
        "requestUri": "\/",
        "ruleSetType": "OWASP_CRS",
        "ruleSetVersion": "3.0.0",
        "ruleId": "942130",
        "message": "SQL Injection Attack: SQL Tautology Detected.",
        "action": "Matched",
        "site": "Global",
        "details": {
            "message": "Warning. Pattern match \\\"(?i:([\\\\\\\\s'\\\\\\\"`\\\\\\\\(\\\\\\\\)]*?)([\\\\\\\\d\\\\\\\\w]++)([\\\\\\\\s'\\\\\\\"`\\\\\\\\(\\\\\\\\)]*?)(?:(?:=|\\u003c=\\u003e|r?like|sounds\\\\\\\\s+like|regexp)([\\\\\\\\s'\\\\\\\"`\\\\\\\\(\\\\\\\\)]*?)\\\\\\\\2|(?:!=|\\u003c=|\\u003e=|\\u003c\\u003e|\\u003c|\\u003e|\\\\\\\\^|is\\\\\\\\s+not|not\\\\\\\\s+like|not\\\\\\\\s+regexp)([\\\\\\\\s'\\\\\\\"`\\\\\\\\(\\\\\\\\)]*?)(?!\\\\\\\\2)([\\\\\\\\d\\\\\\\\w]+)))\\\" at ARGS:text1. ",
            "data": "Matched Data: 1=1 found within ARGS:text1: 1=1",
            "file": "rules\/REQUEST-942-APPLICATION-ATTACK-SQLI.conf\\\"",
            "line": "554"
        },
        "hostname": "vm000003",
        "transactionId": "AcAcAcAcAKH@AcAcAcAcAyAt"
    }
}
{
    "resourceId": "/SUBSCRIPTIONS/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/RESOURCEGROUPS/MYRESOURCEGROUP/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/DEMOWAF-V2",
    "operationName": "ApplicationGatewayFirewall",
    "category": "ApplicationGatewayFirewallLog",
    "properties": {
        "instanceId": "appgw_3",
        "clientIp": "203.0.113.139",
        "clientPort": "",
        "requestUri": "\/",
        "ruleSetType": "",
        "ruleSetVersion": "",
        "ruleId": "0",
        "message": "Mandatory rule. Cannot be disabled. Inbound Anomaly Score Exceeded (Total Score: 8)",
        "action": "Blocked",
        "site": "Global",
        "details": {
            "message": "Access denied with code 403 (phase 2). Operator GE matched 5 at TX:anomaly_score. ",
            "data": "",
            "file": "rules\/REQUEST-949-BLOCKING-EVALUATION.conf\\\"",
            "line": "57"
        },
        "hostname": "vm000003",
        "transactionId": "AcAcAcAcAKH@AcAcAcAcAyAt"
    }
}
{
    "resourceId": "/SUBSCRIPTIONS/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/RESOURCEGROUPS/MYRESOURCEGROUP/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/DEMOWAF-V2",
    "operationName": "ApplicationGatewayFirewall",
    "category": "ApplicationGatewayFirewallLog",
    "properties": {
        "instanceId": "appgw_3",
        "clientIp": "203.0.113.139",
        "clientPort": "",
        "requestUri": "\/",
        "ruleSetType": "",
        "ruleSetVersion": "",
        "ruleId": "0",
        "message": "Mandatory rule. Cannot be disabled. Inbound Anomaly Score Exceeded (Total Inbound Score: 8 - SQLI=5,XSS=0,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): SQL Injection Attack: SQL Tautology Detected.",
        "action": "Blocked",
        "site": "Global",
        "details": {
            "message": "Warning. Operator GE matched 5 at TX:inbound_anomaly_score. ",
            "data": "",
            "file": "rules\/RESPONSE-980-CORRELATION.conf\\\"",
            "line": "73"
        },
        "hostname": "vm000003",
        "transactionId": "AcAcAcAcAKH@AcAcAcAcAyAt"
    }
}

Con la conoscenza del funzionamento dei set di regole CRS e del funzionamento del set di regole CRS 3.0 con un sistema di assegnazione dei punteggi anomalie (vedere Web application firewall per gateway applicazione di Azure) si sa che le due regole inferiori con il action: Blocked proprietà bloccano in base al punteggio di anomalia totale. Le regole su cui concentrarsi sono le prime due.

La prima voce viene registrata perché l'utente ha usato un indirizzo IP numerico per navigare verso l'Application Gateway, che in questo caso può essere ignorato.

Il secondo (regola 942130) è quello interessante. È possibile visualizzare nei dettagli che corrisponde a un criterio (1=1)e il campo è denominato text1. Seguire gli stessi passaggi precedenti per escludere il nome dell'attributo della richiesta uguale a 1=1.

Trovare i nomi delle intestazioni della richiesta

È possibile usare Fiddler per trovare i nomi delle intestazioni delle richieste. Nello screenshot seguente è possibile visualizzare le intestazioni per questa richiesta GET, che includono Content-Type, User-Agent e così via.

Screenshot di Fiddler Web Debugger. Nella scheda Raw sono elencati i dettagli dell'intestazione della richiesta, ad esempio la connessione, il tipo di contenuto e l'agente utente.

Un altro modo per visualizzare le intestazioni di richiesta e risposta consiste nell'usare gli strumenti di sviluppo di Microsoft Edge o Google Chrome. Per altre informazioni, vedere Registrare i file HAR.

Se la richiesta contiene cookie, è possibile selezionare la scheda Cookie per visualizzarle in Fiddler.

Limitare i parametri globali per eliminare i falsi positivi

  • Disabilitare l'ispezione del corpo della richiesta

    Impostando Inspect request body su disattivato, i corpi delle richieste del tuo traffico non vengono valutati dal WAF. Questo può essere utile se si sa che i contenuti delle richieste non sono pericolosi per l'applicazione.

    Quando si disabilita questa opzione, solo il corpo della richiesta ignora l'ispezione. Le intestazioni e i cookie vengono ancora controllati, a meno che i singoli utenti non vengano esclusi usando la funzionalità dell'elenco di esclusione.

  • Disabilitare il limite massimo del corpo della richiesta

    Disabilitando il limite massimo del corpo della richiesta, WAF può elaborare corpi di richieste di grandi dimensioni senza rifiutarli per superare il limite di dimensioni. Questa impostazione è utile se si hanno regolarmente richieste di grandi dimensioni.

    Quando si disabilita questa opzione, il corpo della richiesta verrà controllato solo fino al limite massimo di ispezione del corpo della richiesta. Se nella richiesta sono presenti contenuti dannosi oltre il limite massimo di ispezione del corpo della richiesta, il WAF non lo rileverà.

  • Disabilitare i limiti massimi per le dimensioni dei file

    Disabilitando i limiti delle dimensioni dei file per WAF, è possibile caricare file di grandi dimensioni senza che il WAF rifiuti questi caricamenti di file. Consentendo il caricamento di file di grandi dimensioni, aumenta il rischio che il back-end venga sovraccaricato. Se si conosce la dimensione massima che un caricamento di file può essere, è possibile impostare un limite di dimensioni per i caricamenti di file leggermente superiore alle dimensioni massime previste. Limitare le dimensioni del file a un caso d'uso normale per l'applicazione è un altro modo per evitare attacchi. Tuttavia, se i caricamenti dei file superano regolarmente il limite massimo di dimensioni di caricamento dei file applicabili, potrebbe essere necessario disabilitare completamente i limiti delle dimensioni di caricamento dei file per evitare falsi positivi.

    Annotazioni

    Se sai che l'app non richiederà mai alcun caricamento di file superiore a una determinata dimensione, puoi limitarlo impostando un limite.

    Avvertimento

    Quando si assegna un nuovo set di regole gestite a un criterio WAF, tutte le personalizzazioni precedenti dei set di regole gestite esistenti, ad esempio lo stato della regola, le azioni delle regole e le esclusioni a livello di regola verranno reimpostate sulle impostazioni predefinite del nuovo set di regole gestite. Tuttavia, tutte le regole personalizzate, le impostazioni dei criteri e le esclusioni globali rimarranno invariate durante la nuova assegnazione del set di regole.

Metriche del firewall (solo WAF v1)

Per i web application firewall v1, nel portale sono ora disponibili le metriche seguenti:

  1. Web application firewall Numero richieste bloccate Numero di richieste bloccate
  2. Web application firewall Conteggio regole bloccate Tutte le regole corrispondenti e la richiesta è stata bloccata
  3. Web application firewall Distribuzione totale delle regole Tutte le regole abbinate durante la valutazione

Per abilitare le metriche, selezionare la scheda Metriche nel portale e selezionare una delle tre metriche.

Passo successivo