Azure Front Door용 Azure Web Application Firewall이란?

아티클
03/07/2024

Microsoft 관리형 기본 규칙 집합은 OWASP CRS(핵심 규칙 집합)를 기반으로 하며 Microsoft 위협 인텔리전스 수집 규칙을 포함합니다.

WAF(웹 애플리케이션 방화벽) 규칙은 WAF를 사용하는 애플리케이션 또는 조직의 특정 요구 사항에 맞게 튜닝되어야 하는 경우가 많습니다. 조직은 일반적으로 다음 작업 중 하나를 수행하여 튜닝을 수행합니다.

규칙 제외 정의
사용자 지정 규칙 만들기
문제 또는 가양성의 원인이 될 수 있는 규칙을 사용하지 않도록 설정

이 문서에서는 WAF를 통과해야 하는 요청이 차단되는 경우 수행할 수 있는 작업을 설명합니다.

참고 항목

Microsoft 관리형 규칙 집합은 Azure Front Door 표준 SKU에 사용할 수 없습니다. 다양한 계층 SKU에 대한 자세한 내용은 계층 간 기능 비교를 참조하세요.

Azure Front Door WAF 개요 및 Azure Front Door용 WAF 정책 설명서를 읽으세요. 또한 WAF 모니터링 및 로깅을 사용하도록 설정합니다. 이러한 문서에는 WAF 함수, WAF 규칙 집합 작동 방식 및 WAF 로그에 액세스 하는 방법이 설명되어 있습니다.

WAF 로그 이해

WAF 로그의 목적은 WAF를 통해 일치되거나 차단된 모든 요청을 표시하는 것입니다. 일치하거나 차단되어 평가된 모든 요청의 컬렉션입니다. WAF가 차단하면 안 되는 요청을 차단하는 경우(가양성) 몇 가지 작업을 수행할 수 있습니다.

먼저 범위를 좁혀서 특정 요청을 찾습니다. trackingReference 필드를 포함하도록 사용자 지정 응답 메시지를 구성하여 이벤트를 쉽게 식별하고 특정 값에 대한 로그 쿼리를 수행할 수 있습니다. 로그를 살펴보고 요청의 특정 URI, 타임스탬프 또는 클라이언트 IP를 찾습니다. 관련 로그 항목을 찾으면 가양성에 대한 조치를 취할 수 있습니다.

예를 들어 WAF를 통과하려는 1=1 문자열이 포함된 합법적인 트래픽이 있다고 가정합니다. 요청은 다음과 같은 모양입니다.

POST http://afdwafdemosite.azurefd.net/api/Feedbacks HTTP/1.1
Host: afdwafdemosite.azurefd.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 55

UserId=20&captchaId=7&captchaId=15&comment="1=1"&rating=3

요청을 시도하면 WAF는 매개 변수 또는 필드에 1=1 문자열이 포함된 트래픽을 차단합니다. 이 문자열은 SQL 삽입 공격과 관련된 경우가 많습니다. 로그를 살펴보며 요청의 타임스탬프와 차단되거나 일치하는 규칙을 볼 수 있습니다.

다음 예제는 규칙 일치를 기반으로 생성된 로그 항목을 보여줍니다. 다음 Log Analytics 쿼리를 사용하여 지난 24시간 내에 차단된 요청을 찾을 수 있습니다.

AzureDiagnostics
| where Category == 'FrontDoorWebApplicationFirewallLog'
| where TimeGenerated > ago(1d)
| where action_s == 'Block'

AzureDiagnostics
| where Category == 'FrontdoorWebApplicationFirewallLog'
| where TimeGenerated > ago(1d)
| where action_s == 'Block'

requestUri 필드에서 특히 /api/Feedbacks/에 요청이 수행된 것을 볼 수 있습니다. 계속해서 ruleName 필드에서 규칙 ID 942110을 찾습니다. 규칙 ID를 알면 OWASP ModSecurity Core Rule Set 공식 리포지토리로 이동하여 규칙 ID로 검색하고 코드를 검토하면 이 규칙이 일하는 항목을 정확하게 파악할 수 있습니다.

그런 다음 action 필드를 확인하여 이 규칙이 일치할 경우 요청을 차단하도록 설정된 것을 볼 수 있습니다. policyMode가 prevention으로 설정되어 있으므로 WAF로 요청이 차단되었음을 확인할 수 있습니다.

이제 details 필드의 정보를 확인합니다. 여기에서는 matchVariableName 및 matchVariableValue 정보를 볼 수 있습니다. 누군가가 웹앱의 1=1 필드에 comment을 입력했기 때문에 이 규칙이 트리거되었습니다.

{
    "time": "2020-09-24T16:43:04.5422943Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.CDN/PROFILES/AFDWAFDEMOSITE",
    "category": "FrontDoorWebApplicationFirewallLog",
    "operationName": "Microsoft.Cdn/Profiles/WebApplicationFirewallLog/Write",
    "properties": {
        "clientIP": "1.1.1.1",
        "clientPort": "53566",
        "socketIP": "1.1.1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "ruleName": "DefaultRuleSet-1.0-SQLI-942110",
        "policy": "AFDWAFDemoPolicy",
        "action": "Block",
        "host": "afdwafdemosite.azurefd.net",
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "policyMode": "prevention",
        "details": {
            "matches": [
                {
                    "matchVariableName": "PostParamValue:comment",
                    "matchVariableValue": "\"1=1\""
                }
            ],
            "msg": "SQL Injection Attack: Common Injection Testing Detected",
            "data": "Matched Data: \"1=1\" found within PostParamValue:comment: \"1=1\""
        }
    }
}

{
    "time": "2020-09-24T16:43:04.5422943Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.NETWORK/FRONTDOORS/AFDWAFDEMOSITE",
    "category": "FrontdoorWebApplicationFirewallLog",
    "operationName": "Microsoft.Network/FrontDoor/WebApplicationFirewallLog/Write",
    "properties": {
        "clientIP": "1.1.1.1",
        "clientPort": "53566",
        "socketIP": "1.1.1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "ruleName": "DefaultRuleSet-1.0-SQLI-942110",
        "policy": "AFDWAFDemoPolicy",
        "action": "Block",
        "host": "afdwafdemosite.azurefd.net",
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "policyMode": "prevention",
        "details": {
            "matches": [
                {
                    "matchVariableName": "PostParamValue:comment",
                    "matchVariableValue": "\"1=1\""
                }
            ],
            "msg": "SQL Injection Attack: Common Injection Testing Detected",
            "data": "Matched Data: \"1=1\" found within PostParamValue:comment: \"1=1\""
        }
    }
}

액세스 로그를 확인하여 특정 WAF 이벤트에 대한 지식을 넓힐 수도 있습니다. 다음은 위 이벤트에 대한 응답으로 생성된 로그를 검토할 차례입니다.

trackingReference 값이 동일하므로 이 로그가 관련되어 있음을 확인할 수 있습니다. userAgent, clientIP와 같이 일반적인 인사이트를 제공하는 다양한 필드 중에서 httpStatusCode 필드와 httpStatusDetails 필드를 확인합니다. 여기서는 클라이언트가 이 요청이 거부되고 차단되었음을 확인하는 HTTP 403 응답을 수신한 것을 볼 수 있습니다.

{
    "time": "2020-09-24T16:43:04.5430764Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.CDN/PROFILES/AFDWAFDEMOSITE",
    "category": "FrontDoorAccessLog",
    "operationName": "Microsoft.Cdn/Profiles/AccessLog/Write",
    "properties": {
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "httpMethod": "POST",
        "httpVersion": "1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "requestBytes": "2160",
        "responseBytes": "324",
        "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36",
        "clientIp": "1.1.1.1",
        "socketIp": "1.1.1.1",
        "clientPort": "53566",
        "timeToFirstByte": "0.01",
        "timeTaken": "0.011",
        "securityProtocol": "",
        "routingRuleName": "DemoBERoutingRule",
        "rulesEngineMatchNames": [],
        "backendHostname": "13.88.65.130:3000",
        "isReceivedFromClient": true,
        "httpStatusCode": "403",
        "httpStatusDetails": "403",
        "pop": "WST",
        "cacheStatus": "CONFIG_NOCACHE"
    }
}

{
    "time": "2020-09-24T16:43:04.5430764Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.NETWORK/FRONTDOORS/AFDWAFDEMOSITE",
    "category": "FrontdoorAccessLog",
    "operationName": "Microsoft.Network/FrontDoor/AccessLog/Write",
    "properties": {
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "httpMethod": "POST",
        "httpVersion": "1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "requestBytes": "2160",
        "responseBytes": "324",
        "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36",
        "clientIp": "1.1.1.1",
        "socketIp": "1.1.1.1",
        "clientPort": "53566",
        "timeToFirstByte": "0.01",
        "timeTaken": "0.011",
        "securityProtocol": "",
        "routingRuleName": "DemoBERoutingRule",
        "rulesEngineMatchNames": [],
        "backendHostname": "13.88.65.130:3000",
        "isReceivedFromClient": true,
        "httpStatusCode": "403",
        "httpStatusDetails": "403",
        "pop": "WST",
        "cacheStatus": "CONFIG_NOCACHE"
    }
}

가양성 해결

가양성 처리에 대해 현명한 결정을 내리려면 애플리케이션에 사용되는 기술을 능숙하게 익혀야 합니다. 예를 들어 기술 스택에 SQL 서버가 없고 해당 규칙과 관련된 가양성이 발생했다고 가정해 보겠습니다. 이러한 규칙을 사용하지 않도록 설정하면 반드시 보안이 약화되는 것은 아닙니다.

이 정보와 함께 예제의 1=1 문자열과 일치하는 규칙이 규칙 942110이라는 사실을 알고 있다면 합법적인 요청이 차단되지 않도록 몇 가지 작업을 수행할 수 있습니다.

제외 목록 사용. 제외 목록에 대한 자세한 내용은 Azure Front Door Service 제외 목록이 있는 Azure Web Application Firewall을 참조하세요.
WAF 작업 변경. 요청이 규칙의 조건과 일치할 때 수행할 수 있는 작업에 대한 자세한 내용은 WAF 작업을 참조하세요.
사용자 지정 규칙 사용. 사용자 지정 규칙에 대한 자세한 내용은 Azure Front Door를 사용하는 Azure Web Application Firewall의 사용자 지정 규칙을 참조하세요.
규칙을 사용하지 않도록 설정.

팁

WAF를 통해 합법적인 요청을 허용하는 방식을 선택할 때는 최대한 좁게 설정하는 것이 좋습니다. 예를 들어 규칙을 완전히 사용하지 않도록 설정하기 보다는 제외 목록을 사용하는 것이 좋습니다.

제외 목록 사용

제외 목록을 사용하는 한 가지 이점은 제외하기로 선택한 일치 변수만큼은 특정 요청에 대해 더 이상 검사되지 않는다는 것입니다. 다시 말해, 전체 요청을 검사에서 제외하는 대신 특정 조건이 충족되면 제외할 항목을 특정 요청 헤더, 요청 쿠키, 쿼리 문자열 인수 또는 요청 본문 게시 인수 중에서 선택할 수 있습니다. 요청의 다른 지정되지 않은 변수는 정상적으로 검사됩니다.

제외는 전역 설정입니다. 구성된 제외는 특정 웹앱 또는 URI뿐만 아니라 WAF를 통과하는 모든 트래픽에 적용됩니다. 예를 들어, 특정 웹앱의 본문에서는 1=1이 유효한 요청이지만 동일한 WAF 정책에 있는 다른 앱에서는 그렇지 않은 경우 문제가 될 수 있습니다.

애플리케이션마다 다른 제외 목록을 사용하는 것이 타당하다면, 애플리케이션마다 다른 WAF 정책을 사용하고 이러한 정책을 각 애플리케이션의 프런트 엔드에 적용하는 것이 좋습니다.

관리형 규칙에 대한 제외 목록을 구성할 때 다음을 제외하도록 선택할 수 있습니다.

규칙 집합 내의 모든 규칙
규칙 그룹 내의 모든 규칙
개별 규칙

PowerShell, Azure CLI, REST API, Bicep, Azure Resource Manager 템플릿 또는 Azure Portal을 사용하여 제외 목록을 구성할 수 있습니다.

규칙 수준에서 제외: 규칙 수준에서 제외를 적용하면 지정된 제외가 해당 개별 규칙에 대해서만 분석되지 않습니다. 계속해서 규칙 집합의 다른 모든 규칙으로 분석됩니다. 이는 제외의 가장 세분화된 수준입니다. 이를 사용하여 이벤트 문제를 해결할 때 WAF 로그에서 찾은 정보에 따라 관리형 규칙 집합을 미세 조정할 수 있습니다.
규칙 그룹 수준에서 제외: 규칙 그룹 수준에서 제외를 적용하면 지정한 제외가 특정 규칙 유형 집합에 대해 분석되지 않습니다. 예를 들어 SQLI를 제외 규칙 그룹으로 선택하면 정의된 요청 제외가 SQLI 관련 규칙으로 검사되지 않음을 나타냅니다. PHP, RFI 또는 XSS와 같은 다른 그룹의 규칙으로 계속 검사됩니다. 이런 유형의 제외는 애플리케이션이 특정 유형의 공격에 취약하지 않다고 확신하는 경우 유용할 수 있습니다. 예를 들어, SQL 데이터베이스가 없는 애플리케이션에서는 보안 수준에 부정적인 영향을 주지 않으면서 모든 SQLI 규칙을 제외할 수 있습니다.
규칙 집합 수준에서 제외: 규칙 집합 수준에서 제외를 적용하면 지정한 제외가 규칙 집합에서 사용 가능한 보안 규칙으로 분석되지 않습니다. 이 제외는 포괄적이므로 신중하게 사용해야 합니다.

이 예제에서는 단일 규칙에 제외를 적용하여 가장 세분화된 수준에서 제외를 수행합니다. comment가 포함된 일치 변수 요청 본문 게시물 인수 이름을 제외하려고 합니다. 방화벽 로그 "matchVariableName": "PostParamValue:comment"에서 일치 변수 세부 정보를 볼 수 있습니다. 특성은 comment입니다. 이 특성 이름은 몇 가지 다른 방법으로도 찾을 수 있습니다. 자세한 내용은 요청 특성 이름 찾기를 참조하세요.

제외 규칙을 보여 주는 스크린샷.

특정 규칙에 대한 규칙 제외를 보여 주는 스크린샷.

때로는 직관적이지 않은 방식으로 특정 매개 변수가 WAF에 전달되는 경우가 있습니다. 예를 들어 Microsoft Entra ID를 사용하여 인증하면 토큰이 전달됩니다. 일반적으로 __RequestVerificationToken 토큰은 요청 쿠키로 전달됩니다.

쿠키를 사용하지 않도록 설정한 경우 이 토큰은 요청 게시 인수로도 전달됩니다. 이러한 이유로 Microsoft Entra 토큰 가양성을 해결하려면 __RequestVerificationToken이 RequestCookieNames 및 RequestBodyPostArgsNames 모두에 대한 제외 목록에 추가되었는지 확인해야 합니다.

필드 이름(Selector)에 대한 제외는 값이 더 이상 WAF에서 평가되지 않습니다. 필드 이름 자체는 계속 평가되며 드물게 WAF 규칙과 일치하여 작업을 트리거할 수 있습니다.

규칙 집합에 대한 규칙 제외를 보여 주는 스크린샷.

WAF 작업 변경

WAF 규칙의 동작을 처리하는 또 다른 방법은 요청이 규칙의 조건과 일치할 때 수행할 작업을 선택하는 것입니다. 사용 가능한 작업은 Allow, Block, Log, Redirect입니다.

이 예제에서는 기본 작업인 Block이 규칙 942110에 대한 Log 작업으로 변경되었습니다. 이렇게 하면 WAF가 요청을 로그하고 나머지 낮은 우선 순위 규칙에 대해 동일한 요청을 계속해서 평가합니다.

WAF 작업을 보여 주는 스크린샷.

동일한 요청을 수행한 후 로그를 다시 참조하여 이 요청이 규칙 ID 942110과 일치하는지 확인할 수 있습니다. 이제 action_s 필드는 Block 대신 Log를 나타냅니다. 그런 다음, trackingReference_s 정보를 포함하도록 로그 쿼리를 확장하여 이 요청에 발생한 일을 확인합니다.

여러 규칙 일치를 보여 주는 로그를 보여 주는 스크린샷.

이제 규칙 ID 942110이 처리되고 밀리초 후에 다른 SQLI 규칙 일치가 발생한 것을 볼 수 있습니다. 동일한 요청이 규칙 ID 942310에서 일치했고 이번에는 기본 동작 차단(Block)이 트리거되었습니다.

WAF 튜닝 또는 문제 해결 중에 로그(Log) 작업을 사용하는 또 다른 이점은 특정 규칙 그룹 내 여러 규칙이 지정한 요청과 일치하고 이것을 차단하는지 여부를 식별할 수 있다는 것입니다. 그런 다음 적절한 수준, 즉 규칙 또는 규칙 그룹 수준에서 제외를 만들 수 있습니다.

사용자 지정 규칙 사용

WAF 규칙 일치의 원인을 식별한 후에는 사용자 지정 규칙을 사용하여 WAF가 이벤트에 응답하는 방식을 조정할 수 있습니다. 사용자 지정 규칙은 관리형 규칙 전에 처리됩니다. 둘 이상의 조건을 포함할 수 있으며 가능한 작업은 Allow, Block, Log 또는 Redirect입니다.

Warning

요청이 사용자 지정 규칙과 일치하면 WAF 엔진이 요청 처리를 중지합니다. 관리형 규칙은 이 요청에 대해 처리되지 않으며 우선 순위가 낮은 다른 사용자 지정 규칙도 처리되지 않습니다.

다음 예제는 두 가지 조건이 있는 사용자 지정 규칙을 보여줍니다. 첫 번째 조건은 요청 본문에서 comment 값을 찾습니다. 두 번째 조건은 요청 URI에서 /api/Feedbacks/ 값을 찾습니다.

사용자 지정 규칙으로 가장 세분화하여 WAF 규칙을 미세 조정하고 가양성을 처리할 수 있습니다. 이 경우 동일한 WAF 정책에 따라 여러 사이트 또는 앱에 존재할 수 있는 comment 요청 본문 값만을 기반으로 조치를 취하는 것은 아닙니다.

특정 요청 URI /api/Feedbacks/에서도 일치하도록 다른 조건을 포함하는 경우 이 사용자 지정 규칙이 사용자가 심사한 이 명시적 사용 사례에 실제로 적용되는지 확인합니다. 이러한 방식으로 다른 조건에 대해 동일한 공격을 수행하는 경우에도 WAF 엔진에서 검사하고 예방합니다.

로그를 보여 주는 스크린샷.

로그를 살펴보면 ruleName_s 필드에 사용자 지정 규칙 redirectcomment에 지정된 이름이 포함된 것을 확인할 수 있습니다. action_s 필드에서 이벤트에 대해 리디렉션 작업이 수행된 것을 볼 수 있습니다. details_matches_s 필드에서는 두 조건이 일치하는 세부 정보를 볼 수 있습니다.

규칙 사용 안 함

가양성을 해결하는 또 다른 방법은 WAF가 악성이라고 생각한 입력과 일치하는 규칙을 사용하지 않도록 설정하는 것입니다. WAF 로그를 구문 분석했고 규칙을 942110으로 좁혔으므로 Azure Portal에서 사용하지 않도록 설정할 수 있습니다. 자세한 내용은 Azure Portal을 사용하여 Azure Web Application Firewall 규칙 사용자 지정을 참조하세요.

특정 조건을 충족하는 모든 요청이 합법적인 요청이라고 확신하거나 규칙이 환경에 적용되지 않는다고 확신하는 경우(예: SQL이 아닌 백 엔드가 있기 때문에 SQL 삽입 규칙을 사용하지 않는 경우)에는 규칙을 사용하지 않도록 설정하는 것이 유용합니다.

규칙 비활성화는 전역 설정으로 WAF 정책에 연결된 모든 프런트 엔드 호스트에 적용됩니다. 규칙을 사용하지 않도록 선택하면 WAF 정책에 연결된 다른 프런트 엔드 호스트에 대한 보호 또는 탐지 기능 없이 취약성에 노출된 상태로 남을 수 있습니다.

Azure PowerShell을 사용하여 관리형 규칙을 사용하지 않도록 설정하려면 PSAzureManagedRuleOverride 개체 설명서를 참조하세요. Azure CLI를 사용하려면 az network front-door waf-policy managed-rules override 설명서를 참조하세요.

WAF 규칙을 보여 주는 스크린샷.

팁

WAF 정책에 대한 변경 내용은 모두 문서화합니다. 가양성 탐지를 설명하는 예제 요청을 포함합니다. 사용자 지정 규칙을 추가하거나, 규칙 또는 규칙 집합을 사용하지 않도록 설정하거나, 예외를 추가한 이유를 설명합니다. 나중에 애플리케이션을 다시 디자인하는 경우 변경 내용이 여전히 유효한지 확인해야 할 수 있습니다. 또는 감사되거나 기본 설정에서 WAF 정책을 다시 구성한 이유의 근거를 보여야 할 수 있습니다.

요청 필드 찾기

Fiddler와 같은 브라우저 프록시를 사용하면 개별 요청을 검사하고 웹 페이지의 어떠한 특정 필드가 호출되는지 확인할 수 있습니다. 이 기술은 WAF의 제외 목록을 사용하여 검사에서 특정 필드를 제외해야 하는 경우에 유용합니다.

요청 특성 이름 찾기

이 예제에서는 1=1 문자열이 입력된 필드를 comment라고 합니다. 이 데이터는 POST 요청의 본문에 포함되어 전달되었습니다.

Fiddler 요청의 본문을 보여 주는 스크린샷.

이 필드를 제외할 수 있습니다. 제외 목록에 대해 자세히 알아보려면 웹 애플리케이션 방화벽 제외 목록을 참조하세요. 이 경우 다음 제외를 구성하여 평가를 제외할 수 있습니다.

제외 규칙을 보여 주는 스크린샷.

방화벽 로그를 검사하면 제외 목록에 추가해야 하는 항목을 확인하기 위한 정보를 얻을 수도 있습니다. 로깅을 사용하도록 설정하려면 Azure Front Door에서 메트릭 및 로그 모니터링을 참조하세요.

검사하려는 요청이 발생한 시간은 PT1H.json 파일에서 방화벽 로그를 검토하여 찾을 수 있습니다. PT1H.json 파일은 FrontDoorWebApplicationFirewallLog 및 FrontDoorAccessLog 진단 로그가 저장된 스토리지 계정 컨테이너에서 확인할 수 있습니다.

검사하려는 요청이 발생한 시간은 PT1H.json 파일에서 방화벽 로그를 검토하여 찾을 수 있습니다. PT1H.json 파일은 FrontdoorWebApplicationFirewallLog 및 FrontdoorAccessLog 진단 로그가 저장된 스토리지 계정 컨테이너에서 확인할 수 있습니다.

이 예제에서는 요청을 차단하고(동일한 트랜잭션 참조) 동일한 시간에 발생한 규칙을 볼 수 있습니다.

{
    "time": "2020-09-24T16:43:04.5422943Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.CDN/PROFILES/AFDWAFDEMOSITE",
    "category": "FrontDoorWebApplicationFirewallLog",
    "operationName": "Microsoft.Cdn/Profiles/WebApplicationFirewallLog/Write",
    "properties": {
        "clientIP": "1.1.1.1",
        "clientPort": "53566",
        "socketIP": "1.1.1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "ruleName": "DefaultRuleSet-1.0-SQLI-942110",
        "policy": "AFDWAFDemoPolicy",
        "action": "Block",
        "host": "afdwafdemosite.azurefd.net",
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "policyMode": "prevention",
        "details": {
            "matches": [
                {
                    "matchVariableName": "PostParamValue:comment",
                    "matchVariableValue": "\"1=1\""
                }
            ],
            "msg": "SQL Injection Attack: Common Injection Testing Detected",
            "data": "Matched Data: \"1=1\" found within PostParamValue:comment: \"1=1\""
        }
    }
}

{
    "time": "2020-09-24T16:43:04.5422943Z",
    "resourceId": "/SUBSCRIPTIONS/<Subscription ID>/RESOURCEGROUPS/<Resource Group Name>/PROVIDERS/MICROSOFT.NETWORK/FRONTDOORS/AFDWAFDEMOSITE",
    "category": "FrontdoorWebApplicationFirewallLog",
    "operationName": "Microsoft.Network/FrontDoor/WebApplicationFirewallLog/Write",
    "properties": {
        "clientIP": "1.1.1.1",
        "clientPort": "53566",
        "socketIP": "1.1.1.1",
        "requestUri": "http://afdwafdemosite.azurefd.net:80/api/Feedbacks/",
        "ruleName": "DefaultRuleSet-1.0-SQLI-942110",
        "policy": "AFDWAFDemoPolicy",
        "action": "Block",
        "host": "afdwafdemosite.azurefd.net",
        "trackingReference": "0mMxsXwAAAABEalekYeI4S55qpi5R7R0/V1NURURHRTA4MTIAZGI4NGQzZDgtNWQ5Ny00ZWRkLTg2ZGYtZDJjNThlMzI2N2I4",
        "policyMode": "prevention",
        "details": {
            "matches": [
                {
                    "matchVariableName": "PostParamValue:comment",
                    "matchVariableValue": "\"1=1\""
                }
            ],
            "msg": "SQL Injection Attack: Common Injection Testing Detected",
            "data": "Matched Data: \"1=1\" found within PostParamValue:comment: \"1=1\""
        }
    }
}

Azure 관리형 규칙 집합이 작동하는 방식에 대한 지식을 통해 action: Block 속성이 있는 규칙은 요청 본문에서 일치하는 데이터를 기반으로 차단된다는 것을 알 수 있습니다. 자세한 내용은 Azure Front Door의 Azure Web Application Firewall을 참조하세요. 세부 정보에서 패턴(1=1)과 일치하고 필드 이름이 comment라는 것을 볼 수 있습니다. 동일한 이전 단계를 수행하여 comment가 포함된 요청 본문 게시물 인수 이름을 제외합니다.

요청 헤더 이름 찾기

Fiddler는 요청 헤더 이름을 찾을 때 유용한 도구입니다. 다음 스크린샷은 Content-Type 및 User-Agent를 포함하는 이 GET 요청에 대한 헤더를 보여줍니다. 요청 헤더를 사용하여 WAF에서 제외 및 사용자 지정 규칙을 만들 수도 있습니다.

Fiddler 요청의 헤더를 보여 주는 스크린샷.

요청 및 응답 헤더를 보는 또 다른 방법은 Microsoft Edge 또는 Chrome과 같은 브라우저의 개발자 도구 내부를 보는 것입니다. F12를 선택하거나검사>개발자 도구를 마우스 오른쪽 단추로 클릭합니다. 네트워크 탭을 선택합니다. 웹 페이지를 로드하고 검사할 요청을 선택합니다.

네트워크 검사기 요청을 보여 주는 스크린샷.

요청에 쿠키가 포함된 경우 쿠키 탭을 선택하면 Fiddler에서 쿠키를 볼 수 있습니다. 쿠키 정보를 사용하여 WAF에서 제외 또는 사용자 지정 규칙을 만들 수도 있습니다.

변칙 채점 규칙

WAF 튜닝 프로세스 중에 규칙 ID 949110이 표시되면 해당 요청이 변칙 점수 매기기 프로세스로 인해 요청이 차단된 것입니다.

동일한 추적 참조를 통해 로그 항목을 검색하여 동일한 요청에 대한 다른 WAF 로그 항목을 검토합니다. 트리거된 각 규칙을 확인합니다. 이 문서의 지침에 따라 각 규칙을 튜닝합니다.

다음 단계

Azure 웹 애플리케이션 방화벽에 대해 알아봅니다.
Azure Front Door의 인스턴스를 만드는 방법을 알아봅니다.

다음을 통해 공유

Azure Front Door용 Azure Web Application Firewall이란?

WAF 로그 이해

가양성 해결

제외 목록 사용

WAF 작업 변경

사용자 지정 규칙 사용

규칙 사용 안 함

요청 필드 찾기

요청 특성 이름 찾기

요청 헤더 이름 찾기

변칙 채점 규칙

다음 단계

피드백

추가 리소스

다음을 통해 공유

Azure Front Door용 Azure Web Application Firewall이란?

WAF 로그 이해

가양성 해결

제외 목록 사용

WAF 작업 변경

사용자 지정 규칙 사용

규칙 사용 안 함

요청 필드 찾기

요청 특성 이름 찾기

요청 헤더 이름 찾기

요청 쿠키 이름 찾기

변칙 채점 규칙

다음 단계

피드백

추가 리소스