이 포스팅에서는 AWS WAF 에서 제공하는 몇 가지 Logging 옵션을 이용하여 WAF 의 Log 를 남기고 남겨진 Log 가 관리자의 설정에 따라 어떻게 나타나는지 살펴보도록 하겠습니다.
저는 테스트를 위하여 K8S 에 웹서비스를 배포하고 ALB 를 통해 인터넷에서 접속할 수 있도록 구성하였는데요. 웹서비스를 위한 서버 설정이나 ALB 설정에 대한 설명은 생략하도록 하겠습니다.
생성된 ALB 에 “WAFLoggingDemoACL” 이라는 WebACL 을 연결해주었고 Log 설정에서는 아래와 같이 “aws-waf’logs-wafloggingdemo” 라는 이름의 CloudWatch Log Group 을 통해 WAF Log 수신하도록 구성하였습니다.
- Allow Log
첫번째로 허용된 요청에 대해 남는 로그를 살펴 보도록 하겠습니다. 아래의 로그는 WebACL 을 생성하고 아무런 규칙을 생성하지 않은 상태에서 접속한 후 로그를 기록한 것입니다.
보시는 바와 같이 AWS WAF Log 에는 다양한 정보들이 포함이 되어 있는데요. HTTP 요청을 수신한 시간, 적용되어 있는 WebACL, 적용된 규칙, 사용자 요청에 포함되어 있던 HTTP Eahder 등 다양한 정보가 제공되어 관리자가 각 정보를 기반으로 적절한 조치를 취하는데 도움을 주고 있습니다.
2. SQL Injection 공격 차단(사용자 정의 규칙)
이번에는 아래와 같이 Login 페이지에 SQL Injection 공격을 시도하여 보도록 하겠습니다.
아무런 규칙이 없는 경우에는 위 요청이 허용될 것이므로 SQL Injection 패턴을 탐지/차단할 수 있도록 규칙을 생성한 후 적용하였습니다.
Block Action 으로 규칙이 적용된 상태에서 SQL Injection 공격을 수행하면 공격이 차단되는 것을 확인할 수 있는데요. 차단 로그는 아래와 같이 나타나게 됩니다.
이 로그를 살펴보면 한 가지 중요한 정보가 담겨 있는 것을 확인할 수 있는데요. 바로 SQL Injection 공격이 실행된 Body 부분에 대한 로그가 남겨져 있다는 것입니다. AWS WAF 는 기본적으로 Body 에 대한 로그를 남가지는 않지만 SQL Injection 과 XSS 공격 패턴에 매칭되는 경우에 한해서는 Body 에 대한 로그를 제공하여 관리자가 정탐이나 오탐에 대한 분석을 좀 더 쉽게 할 수 있도록 돕고 있습니다.
위 로그의 terminatingRuleMatchDetails 부분을 보면 conditionType 이 “SQL_INJECTION” 로 되어 있고 “matchedData” 가 [“{\”email\”:\” %”, “or”, “0”, “union”, “select”] 로 제가 공격에 사용하였던 패턴이 매칭되어 차단되었음을 알 수 있습니다.
3. IP 규칙 차단
이번에는 동일한 SQL Injection 공격을 IP 주소 기반으로 차단했을 경우에 남게되는 로그를 살펴보도록 하겠습니다.
아래의 로그는 SQL Injection 공격을 수행하였지만 IP 기반 규칙이 먼저 동작하여 차단되면서 남게된 로그입니다.
보시는 것처럼 사용자의 요청 내용은 SQL Injection 공격으로 동일했지만 WAF Log 에서는 매칭된 규칙이 SQL Injection 이 아니라 IP 기반 규칙이었기 때문에 terminatingRuleMatchDetails 부분이 [] 로 아무런 정보를 담고 있지 않은 것을 확인할 수 있습니다. 즉, 위에서 언급한 것처럼 AWS WAF 에서 Body 정보가 남는 경우는 SQL Injection 이나 XSS 공격 패턴에 매칭되는 경우라는 것을 확인할 수 있습니다.
4. Count Mode - IP규칙
이번에는 조금 전 확인하였던 IP 규칙 기반의 차단 규칙의 Action 을 Count 로 변경한 후 발생되는 로그를 확인해보도록 하겠습니다.
위에 나타난 것처럼 IP 규칙이 Count 에 의해 처리되는 경우에는 Block 과는 다르게 나타나는 것을 확인할 수 있는데요.
첫번째, terminatingRuleId 에 IP 규칙이 아닌 다른 규칙의 이름(Default_Action)이 있는 것을 확인할 수 있습니다. 이 요청이 IP 규칙에서는 Count 로 처리되었기 때문에 Termination 되지 않았고 Default_Action 이라는 규칙에서 처리되었기 때문입니다. 참고로 이 Default_Action 은 Allow 로 설정되어 있기 때문에 이 요청을 허용 되었습니다.
두번째, nonTerminatingMatchingRules 부분입니다. 여기에서는 Termination 했던 Default_Action 의 규칙이 아닌 다른 매칭되는 규칙의 정보를 확인할 수 있는데요. 이 부분을 보면 Blacklist 라는 IP 기칙이 COUNT 로 매칭되었다는 것을 확인할 수 있습니다. 여기에도 ruleMatchDetails 가 존재하지만 Blacklist 가 IP 규칙이기 때문에 아무런 정보가 포함되어 있지 않습니다.
5. Count Mode - SQL Injection 규칙
위에서 했던 IP 규칙 테스트와 마찬가지로 SQL Injection 규칙의 Action 을 Count 로 설정한 후 Log 를 확인해보도록 하겠습니다.
IP 규칙의 Count Mode 와 비슷한 로그가 남는 것을 확인할 수 있는데요. IP 규칙의 경우와의 차이점은 nonTerminatingMatchingRules 내부에 있는 ruleMatchDetails 부분에 BODY 정보가 포함되어 있다는 것입니다.
6. AWS Managed Rule Group 차단
이번에는 AWS 에서 제공하는 AWS Managed Rule Group 을 이용하여 SQL Injection 공격을 차단하는 경우 발생되는 로그를 확인해보도록 하겠습니다. 테스트를 위해서 위 과정에서 사용하였던 사용자 정의 SQL Injection 규칙은 매칭되지 않도록 처리한 후 테스트를 진행하였습니다.
동일한 SQL Injection 공격에 대해 위와 같이 정상적으로 AMR(AWS Managed Rule)에 매칭되는 것을 확인할 수 있었는데요. 이 로그를 통해 우리는 다음과 같은 몇 가지 내용을 확인할 수 있습니다.
BODY 부분의 로그 - AMR 에 매칭되는 경우에도 ConditionType 이 “SQL Injection” 이면 Body 의 로그가 남는 것을 확인할 수 있습니다.
ruleGroupList - AMR 에 포함되어 있는 여러 규칙 중 사용자 요청이 매칭되는 규칙에 대한 정보를 확인할 수 있습니다. 위 예시의 경우에는 “SQLi_BODY” 라는 세부 규칙에 매칭되었음을 알 수 있습니다.
7. Count Mode - AWS Managed Rule
이번에는 AMR 을 아래와 같이 Count Mode 로 변경한 후 Count 로그를 확인해보도록 하겠습니다.
아래와 같이 동일한 공격이 Default_Action 을 통해 허용되는 것을 확인할 수 있습니다.
위 로그를 보면 한가지 특이 사항을 확인할 수 있는데요. Count Mode 로 허용처리된 이 SQL Injection 공격의 로그를 보면 ruleGroupList 의 상세 내용에 “excludedRules” 라는 내용이 있고 그 내부에 exclusionType: “EXCLUDED_AS_COUNT”, ruleId: “SQLi_BODY” 라는 정보가 포함되어 있는 것을 확인할 수 있는데요. 이전에 진행했던 테스트에서 IP 규칙과 SQL Injection 규칙의 Count Mode 에서는 Action: COUNT 로 나타났던 것과 다르게 AMR 에서는 exclusionType: “EXCLUDED_AS_COUNT” 로 로깅 처리되는 것을 확인할 수 있습니다.
8. AMR Override Count Mode
마지막으로 AMR 의 Default Action 을 COUNT 로 Override 하도록한 후 발생되는 로그를 살펴보도록 하겠습니다.
아래와 같이 AMR 의 설정 화면에서 각 규칙의 Count 설정은 변경하지 않고 Override rule group action to count 옵션을 체크하여 AMR 이 Count Mode 로 동작하도록 설정한 후 테스트를 진행하였습니다.
이번에도 COUNT Mode 가 정상적으로 동작하여 아래와 같이 Default_Action 규칙에 의해 허용되는 것을 확인할 수 있었습니다.
Override rule group action to count 옵션에 의해 Count 처리되는 AMR 은 개별 규칙을 Count 처리했을 때와는 다른 로그가 생성되었습니다.
위 그림에서 보시는 것처럼 이번에는 nonTerminatingMatchingRules 에 Body 의 상세 정보가 남는 것을 확인할 수 있고 ruleGroupList 내부에 있는 terminatingRule 의 Action 도 Block 으로 남게되는 것을 확인할 수 있습니다.
즉, AMR 의 경우 Count Mode 를 적용할 때 개별 규칙에 COUNT 를 적용했을 경우에는 EXCLUDED_AS_COUNT 로 처리되고 Body 에 대한 정보도 남지 않지만 Override rule group action to count 옵션에 의해 Count 로 처리되었을 때는 SQL Injection 에 매칭되는 경우 Body 의 정보가 남는 것을 확인할 수 있었습니다.
간단한 테스트를 통해 Allow, Block 그리고 Count Action 을 설정하였을 때 AWS WAF 에서 어떤 Log 들을 남기는지 살펴보았습니다. 각각의 로그가 비슷한 것처럼 보이지만 사실은 설정에 따라 약간씩 다른 정보들과 패턴들을 보이는 것을 확인할 수 있었는데요. 위의 테스트 결과들이 AWS WAF 관리형 규칙의 Action 을 COUNT 로 지정하거나 생성된 로그의 내용들을 분석하는데 도움이 되시길 바랍니다.
감사합니다.
