Felsök Web Application Firewall (WAF) på Azure Application Gateway

Sammanfattning

Den här artikeln hjälper dig att felsöka Web Application Firewall (WAF) för Azure Application Gateway när legitima begäranden blockeras, så att du kan tillåta giltig trafik samtidigt som skyddet bibehålls.

Börja med att granska WAF-översikten och WAF-konfigurationsdokumentationen och se till att WAF-övervakning är aktiverat. I de här artiklarna beskrivs hur WAF fungerar, hur regeluppsättningarna fungerar och hur du får åtkomst till WAF-loggar.

OWASP-regeluppsättningarna är utformade för att vara strikta och finjusteras så att de passar programmets eller organisationens specifika behov med hjälp av WAF. Det är helt normalt och i många fall förväntat att skapa undantag, anpassade regler och till och med inaktivera regler som kan orsaka problem eller falska positiva resultat. Med principer per webbplats och per URI kan dessa ändringar endast påverka specifika webbplatser eller URI:er. Ändringar bör därför inte påverka andra webbplatser som kanske inte stöter på samma problem.

Förstå WAF-loggar

Syftet med WAF-loggar är att visa varje begäran som WAF matchar eller blockerar. Det är en loggbok för alla utvärderade begäranden som matchas eller blockeras. Om du märker att WAF blockerar en begäran som den inte borde blockera (en falsk positiv), kan du vidta några åtgärder. Börja med att begränsa och hitta den specifika begäran. Titta igenom loggarna för att hitta den specifika URI:n, tidsstämpeln eller transaktions-ID:t för begäran. När du hittar de associerade loggposterna kan du börja agera på falska positiva identifieringar.

Anta till exempel att du har en legitim trafik som innehåller strängen 1=1 som du vill skicka genom din WAF. Om du provar begäran blockerar WAF trafik som innehåller din 1=1 sträng i valfri parameter eller fält. Den här strängen är ofta associerad med en SQL-inmatningsattack. Du kan titta igenom loggarna och se tidsstämpeln för begäran och de regler som blockerade eller matchade.

I följande exempel kan du se att fyra regler utlöses under samma begäran (med fältet TransactionId). Den första säger att den matchade eftersom användaren använde en numerisk IP-adress för begäran, vilket ökar avvikelsepoängen med tre eftersom det är en varning. Nästa regel som matchade är 942130, som är den du letar efter. Du kan se 1=1 i details.data-fältet. Detta ökar avvikelsepoängen ytterligare med tre igen, eftersom det också är en varning. I allmänhet ökar varje regel som har åtgärden Matchad avvikelsepoängen och vid den här tidpunkten är avvikelsepoängen sex. Mer information finns i Avvikelsebedömningsläge.

De sista två loggposterna visar att begäran blockerades eftersom avvikelsepoängen var tillräckligt hög. Dessa poster har en skillnad i åtgärd jämfört med de andra två. De visar att de faktiskt blockerade begäran. Dessa regler är obligatoriska och kan inte inaktiveras. Tänk inte på de här reglerna som regler, utan mer som kärninfrastrukturen i WAF internals.

{ 
    "resourceId": "/SUBSCRIPTIONS/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1/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/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1/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/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1/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/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1/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" 
    }
}

Åtgärda falska positiva identifieringar

Med den här informationen och kunskapen om att regel 942130 är den som matchade strängen 1=1 kan du vidta några steg för att hindra den här regeln från att blockera trafiken:

  • Använd en undantagslista. Mer information om undantagslistor finns i WAF-undantagslistor.

  • Inaktivera regeln.

Minimera paranoia nivå 2 falska positiva identifieringar

I OWASP CRS 3.2, SQL-inmatningsregler 942430, 942440och 942450 tillhör Paranoia Level 2 (PL2). Om WAF-loggar visar att en legitim autentiseringsbegäran matchade någon av dessa regler identifierar du fältet för bidragande begäran innan du lägger till ett undantag. Bekräfta att begäran är legitim och identifiera dess regel-ID och konfigurerade regeluppsättning. Beskrivningar och versionsspecifika ersättningar finns i WAF-regelgrupper och regler. Aktivera inte inaktiva regel- eller ändringsregeluppsättningar bara för att följa det här exemplet.

  1. I Log Analytics använder du följande fråga om diagnostikinställningen AzureDiagnostics skickar brandväggsloggar till tabellen. Ersätt resurs-ID:t och tidsintervallet med den gateway och det intervall som du undersöker. Dessa loggar kan innehålla känsliga begärandedata. dela inte fältvärden eller autentiseringstoken.

Kör följande fråga.

AzureDiagnostics
| where TimeGenerated > ago(1h)
| where _ResourceId =~ "<application-gateway-resource-id>"
| where Category == "ApplicationGatewayFirewallLog"
| where ruleId_s in ("942430", "942440", "942450")
| project TimeGenerated, transactionId_g, requestUri_s,
    ruleId_s, action_s, details_message_s, details_data_s
| order by TimeGenerated desc
  1. Hitta transaktionen för den misslyckade begäran. En bidragande regel kan ha en åtgärd Matched, medan en separat regel för avvikelsebedömning blockerar transaktionen. Om du vill granska alla matchningar för transaktionen ersätter du regel-ID-filtret med ett filter på transactionId_g. Uteslut inte en regel för avvikelsebedömning i stället för den bidragande regeln.
  2. För en bekräftad falsk positiv identifiering konfigurerar du ett undantag för det specifika fältet och endast de bidragande regel-ID:na. Undantag per regel kräver en WAF-principregeluppsättning som stöds, till exempel OWASP CRS 3.2. Använd Equals för fältväljaren och bevara andra regler och befintliga principinställningar. Se CLI- och PowerShell-proceduren för en viss regel och exempel på exkluderingar per regel. Information om regelidentifiering finns i anpassningsguiden för PowerShell och CLI-anpassningsguiden.
  3. Läs tillbaka principen för att bekräfta att undantaget innehåller den avsedda regeluppsättningsversionen, gruppen, regel-ID:t, matchningsvariabeln och väljaren. Ett globalt undantag som redan omfattar det fältet gäller fortfarande. Att lägga till ett smalare undantag tar inte bort det. Granska alla befintliga breda undantag separat i stället för att rensa alla undantag.
  4. Upprepa samma legitima begäran och kontrollera dess svar och nya transaktionsloggar. Bekräfta att den valda regeln inte längre matchar det exkluderade fältet och undersöka eventuella andra bidragsregler om begäran förblir blockerad. En tom fråga utan reproducerad trafik och fungerande insamling av diagnostikdata visar inte att det har lyckats. Kontrollera att orelaterade fält fortfarande kontrolleras i en kontrollerad testmiljö.

Uteslut inte automatiskt alla tre ID:na eller alla autentiseringsfält. Behåll WAF i förebyggande läge för den här riktade ändringen. Om du behöver ångra det tar du bara bort det regelomfattningsundantag som du lade till efter att ha granskat principen. bevara befintliga undantag.

Använda en undantagslista

Om du vill fatta ett välgrundat beslut om att hantera falska positiva identifieringar kan du bekanta dig med de tekniker som programmet använder. Om din teknikstack till exempel inte omfattar en SQL-server och du får falska positiva resultat relaterade till de reglerna, innebär det inte nödvändigtvis att säkerheten försvagas om du inaktiverar dem.

Ett undantag utelämnar ett valt begärandeattribut från inspektionen. Ett globalt undantag gäller för alla hanterade regler, medan ett undantag per regel endast gäller för de valda reglerna i en regeluppsättning som stöds. Båda gäller överallt där WAF-principen är kopplad, så kontrollera principens tillämpningar och sökvägar innan du ändrar den. Om du till exempel undantar ett fält kan det skapa en risk när 1=1 är giltigt för ett program men inte ett annat som delar principen. Föredra ett snävt avgränsat undantag i stället för att exkludera hela begäran.

Ibland skickas specifika parametrar till WAF på ett sätt som kanske inte är intuitivt. Det finns till exempel en token som skickas vid autentisering med hjälp av Microsoft Entra ID. __RequestVerificationToken skickas vanligtvis som en cookie för begäran. Men i vissa fall där cookies är inaktiverade skickas denna token också som ett begärandeattribut eller arg. Om detta händer måste du se till att __RequestVerificationToken också läggs till i undantagslistan som ett namn på begärandeattributet .

Skärmbild av inställningarna för WAF-undantagslistan i Azure portal.

I det här exemplet vill du exkludera det namn på attributet Request som är lika med text1. Det här attributnamnet framgår tydligt eftersom du kan se attributnamnet i brandväggsloggarna: data: Matched Data: 1=1 found within ARGS:text1: 1=1. Attributet är text1. Du kan också hitta det här attributnamnet på några andra sätt, se Söka efter attributnamn för begäran.

Skärmbild av WAF-konfigurationsalternativ för undantagslistor i Application Gateway.

Du kan skapa undantag för WAF i Application Gateway på olika omfångsnivåer. Mer information finns i Web Application Firewall undantagslistor.

Inaktivera regler

Ett annat sätt att hantera ett falskt positivt resultat är att inaktivera regeln som matchade den indata som WAF:en trodde var skadlig. Eftersom du parsade WAF-loggarna och begränsade regeln till 942130 kan du inaktivera den i Azure-portalen. Se Anpassa brandväggsregler för webbprogram via Azure-portalen.

Om du vet att all trafik som innehåller ett visst villkor som normalt blockeras är giltig trafik kan du inaktivera den regeln för hela WAF. Men om det bara är giltig trafik i ett specifikt användningsfall öppnar du en säkerhetsrisk genom att inaktivera regeln för hela WAF eftersom det är en global inställning.

Information om hur du använder Azure PowerShell finns i Anpassa brandväggsregler för webbprogram via PowerShell. Information om hur du använder Azure CLI finns i Anpassa brandväggsregler för webbprogram via Azure CLI.

Registrera HAR-filer

Du kan använda webbläsaren eller ett externt verktyg som Fiddler för att spela in HAR-filer (HTTP Archive). HAR-filer innehåller information om de begäranden och svar som webbläsaren gör när du läser in en webbsida. Den här informationen kan vara användbar för att felsöka WAF-problem.

Tips/Råd

Det är en bra idé att ha HAR-filen redo när du kontaktar supporten. Supportteamet kan använda HAR-filen för att diagnostisera problemet.

Följ dessa steg för att registrera och spara en HAR-fil i Microsoft Edge:

  1. Tryck på F12 eller Ctrl+Skift+I för att öppna Edge-Vývojárske nástroje. Du kan också öppna verktygen från verktygsfältsmenyn under Fler verktyg>Vývojárske nástroje.

  2. På fliken Konsol väljer du Rensa konsol eller trycker på Ctrl+L.

Skärmbild på fliken Konsol i Microsoft Edge developer tools.

  1. Välj fliken Nätverk .

  2. Välj Rensa nätverkslogg eller tryck Ctrl+L och välj sedan Aktivera loggning av nätverk om den inte spelas in.

Skärmbild på fliken Nätverk i Microsoft Edge utvecklarverktyg.

  1. Läs in webbsidan som skyddas av din WAF och som du vill felsöka.

  2. Stoppa inspelningen genom att välja Stoppa inspelning av nätverksloggen.

  3. Välj Exportera HAR (sanerat)... och spara HAR-filen.

Skärmbild av alternativet Exportera HAR (sanerat) i Microsoft Edge developer tools.

Hitta namn på begärandeattribut

Använd Fiddler för att inspektera enskilda begäranden och avgöra vilka specifika fält på en webbsida som anropas. Med hjälp av den här informationen kan du undanta vissa fält från inspektion med hjälp av undantagslistor.

I det här exemplet kan du se att fältet där strängen 1=1 angavs kallas text1.

Skärmbild av Fiddler Web Debugger. På fliken Rå visas 1=1 efter namnet text1.

Det här är ett fält som du kan exkludera. Mer information om undantagslistor finns i Undantagslistor för brandvägg för webbprogram. Du kan exkludera utvärderingen i det här fallet genom att konfigurera följande undantag:

Skärmbild av ett WAF-undantag som konfigurerats för ett specifikt begärandeattribut.

Du kan också granska brandväggsloggarna för att hämta informationen för att se vad du behöver lägga till i undantagslistan. Information om hur du aktiverar loggning finns i Serverdelshälsa, resursloggar och mått för Application Gateway.

Granska brandväggsloggen och visa filen PT1H.json för den timme som begäran som du vill inspektera inträffade.

I det här exemplet ser du att du har fyra regler med samma TransactionID och att de alla inträffade exakt samtidigt:

{
    "resourceId": "/SUBSCRIPTIONS/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1/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/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1/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/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1/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/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1/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"
    }
}

Med dina kunskaper om hur CRS-regeluppsättningarna fungerar och att CRS-regeluppsättningen 3.0 fungerar med ett system för avvikelsebedömning (se Web Application Firewall för Azure Application Gateway) vet du att de två nedre reglerna med egenskapen action: Blockerad blockeras baserat på den totala avvikelsepoängen. Reglerna att fokusera på är de två främsta.

Den första posten loggas eftersom användaren använde en numerisk IP-adress för att navigera till Application Gateway, som du kan ignorera i det här fallet.

Den andra posten (regel 942130) visas i informationen eftersom den matchar ett mönster (1=1)och fältet heter text1. Följ samma föregående steg för att exkludera begärandeattributnamn som är lika med text1.

Hitta namn på begärandehuvud

Använd Fiddler för att hitta namnen på rubriker i begäran. I följande skärmbild kan du se rubrikerna för den här GET-begäran, som innehåller Innehållstyp, Användaragent och andra rubriker.

Skärmbild av Fiddler Web Debugger. På fliken Rådata visas information om begäranderubriker som anslutning, innehållstyp och användaragent.

Du kan också använda utvecklarverktygen i Microsoft Edge eller Google Chrome för att visa sidhuvuden för begäran och svar. Mer information finns i Spela in HAR-filer.

Om begäran innehåller cookies väljer du fliken Cookies för att visa dem i Fiddler.

Begränsa globala parametrar för att eliminera falska positiva resultat

  • Inaktivera kontroll av begärandetext

    När du ställer in Inspektera förfrågetext till av utvärderar WAF inte förfrågetexterna i trafiken. Den här inställningen är användbar om du vet att begärandeorganen inte är skadliga för ditt program.

    När du inaktiverar det här alternativet kringgår endast begärandetexten kontrollen. HTTP-huvuden och cookies granskas fortfarande, om du inte undantar enskilda med funktionen för undantagslista.

  • Inaktivera maxgränsen för begärandetext

    När du inaktiverar den maximala storleksgränsen för begärandetext kan WAF bearbeta stora begärandetexter utan att avvisa dem för att de överskrider storleksgränsen. Den här inställningen är användbar om du regelbundet har stora begäranden.

    När du inaktiverar det här alternativet granskas begärandetexten endast upp till den maximala granskningsgränsen för begärandetexten. Om det finns skadligt innehåll i begäran utöver maxgränsen för kontroll av begärandetext identifierar WAF inte det.

  • Inaktivera maximala filstorleksgränser

    När du inaktiverar filstorleksgränserna för din WAF kan stora filer laddas upp utan att WAF avvisar dessa filuppladdningar. Genom att tillåta att stora filer laddas upp ökar risken för att serverdelen överbelastas. Om du vet den maximala storleken som en filuppladdning kan vara anger du en storleksgräns för filuppladdningar som är något över den förväntade maxstorleken. Att begränsa filstorleken till ett normalt användningsfall för ditt program är ett annat sätt att förhindra attacker. Men om dina filuppladdningar regelbundet överskrider den maximala gränsen för tvingande filuppladdningsstorlek kan du behöva inaktivera storleksbegränsningarna för filuppladdning helt för att undvika falska positiva identifieringar.

    Anmärkning

    Om du vet att din app aldrig behöver någon filuppladdning över en viss storlek kan du begränsa den storleken genom att ange en gräns.

    Varning

    När du tilldelar en ny hanterad regeluppsättning till en WAF-princip återställs alla tidigare anpassningar från befintliga hanterade regeluppsättningar, till exempel regeltillstånd, regelåtgärder och undantag på regelnivå till standardinställningarna för den nya hanterade regeluppsättningen. Anpassade regler, principinställningar och globala undantag påverkas dock inte under tilldelningen av den nya regeluppsättningen.

Brandväggsmått (endast WAF v1)

För v1 Web Application Firewalls innehåller portalen nu följande mått:

  1. Web Application Firewall Antal blockerade begäranden Antalet begäranden som blockeras.
  2. Web Application Firewall Antal blockerade regler Alla regler som matchar och begäran blockeras.
  3. Web Application Firewall Total Rule Distribution Alla regler som matchar under utvärderingen.

Om du vill aktivera mått väljer du fliken Mått i portalen och väljer ett av de tre måtten.

References