AWS 기술 블로그

AWS WAF 의 COUNT ACTION 이해하기

1. 서론

AWS WAF(Web Application Firewall) 는 AWS 가 제공하는 가장 대표적인 데이터 및 어플리케이션 보안 솔루션 중의 하나이며, 사용자 정의 규칙 뿐만 아니라 AWS 관리형 규칙 및 파트너 관리형 규칙 등을 제공하여 각 고객사의 운영환경에 맞게 다양한 설정 옵션을 제공하고 있는 웹 보안 서비스 입니다. AWS WAF 는 외부에서 유입되는 SQL Injection 이나 XSS(Cross Site Script) 공격과 같은 해킹 시도나 악의적으로 사용되는 Bot 트래픽을 차단하는 것 뿐만 아니라 웹서비스를 대상으로하는 DDoS 공격을 차단하는 용도로도 활용될 수 있습니다. 이번 포스팅에서는 AWS WAF 에서 제공하는 이와 같은 다양한 기능들을 사용하는 과정에서 사용자들이 자주 사용하는 “COUNT” Action 의 동작에 대해 살펴보고자 합니다.

AWS WAF 는 현재 아래와 같이 5가지의 Action 을 제공하고 있습니다.

그림. AWS WAF 제공 Action

그리고, 5가지 Action 중 “Count” Action 에 대해서는 AWS WAF 의 공식 문서에서 아래와 같이 정의하고 있습니다.

그림. AWS WAF 의 Action 에 대한 정의

즉, “Count” Action 은 사용자 정의 규칙이나 관리형 규칙 사용 시 AWS WAF 로 유입되는 요청이 해당 규칙에 매칭되더라도 규칙에 지정된 Action 이 “Count” 인 경우라면 허용이나 차단하지 않고 WebACL 에 적용된 다음 우선 순위의 규칙으로 요청을 전달하도록 동작합니다. 이와 같은 동작방식 때문에 “Count” Action 은 새로운 사용자 정의 규칙이나 관리형 규칙을 사용하는 경우 해당 규칙의 오탐(False Positive) 로 인해 발생할 수 있는 서비스 영향도를 최소화하기 위해 사용되고 있습니다. 즉, AWS WAF 운영 시 “Count” Action 를 적절히 사용하면 “Allow” 나 “Block” Action 을 적용하기 전에 적용될 규칙에 의한 영향도를 최소화할 수 있습니다.

2. AWS WAF Block 및 Count Action 동작 확인

그럼 이제 본격적으로 이와 같은 장점을 지닌 “Count” Action 을 실제 운영 환경에서 적용하는 경우 반드시 알아야하는 몇 가지 특징들을 살펴보도록 하겠습니다.

테스트 환경에 대해 설명드리면, AWS WAF 의 동작을 확인하기 위해 취약점을 가지고 있는 아주 간단한 웹 어플리케이션을 AWS 환경에 구성하였으며 WebACL 을 연계하여 AWS WAF 의 보호를 받도록 구성하였습니다.

WebACL 은 설정은 초기 상태에서 CloudWatch Log Group 으로 로그를 전송하도록 로그 설정만 활성화 한 상태에서 진행하였으며 로그 필터는 이 포스팅의 후반부에 진행한 로그필터 변경 시나리오를 제외하고는 모두 별도로 로그 필터를 생성하지 않은 상태로 테스트를 진행하였습니다.

참고. 테스트에 사용한 WebACL 의 Default Action 은 “Allow” 로 설정하여 “Count” Action 적용 시 공격이 허용되도록 구성하였습니다.

2.1 사용자 정의 규칙에서의 “Block” 및 “Count” Action

공격 방어 설정 – Application Load Balancer 에 연결된 Web Application 이 정상적으로 접속되는 것을 확인한 후 대상 웹 서비스에 적용될 SQL Injection 공격을 방어할 수 있도록 아래와 같이 사용자 정의 규칙을 적용하였습니다. 그리고 차단 여부를 확인할 수 있도록 Action 은 “Block” 으로 설정하였습니다.

그림. SQL Injection 공격 차단 용 사용자 정의 규칙

로그 확인 – 웹 서비스를 대상으로 SQL Injection 공격을 수행한 후 AWS WAF 에서 해당 공격이 정상적으로 차단되는 것을 확인하였으며 자세한 로그 정보를 확인하기 위하여 CloudWatch Log Group 에 접속 후 아래와 같이 “Block” 로그가 생성된 것을 확인하였습니다.

로그 정보에 대한 설명

  1. terminatingRuleID = 요청을 처리(허용 혹은 차단)한 규칙의 유형을 뜻합니다. 이 로그의 경우 “SQL-Injection_CustomrRule” 규칙에 의해 처리되었음을 나타냅니다.
  2. terminatingRuleType = 요청을 처리(허용 혹은 차단)한 규칙의 유형을 뜻합니다. 사용자 정의 규칙의 경우 “REGULAR” 로 표기됩니다.
  3. action = 요청을 처리(허용 혹은 차단)한 규칙의 Action 을 뜻합니다. 이 로그의 경우 “BLOCK” 입니다.
  4. terminatingRuleMatchDetails = 요청을 처리(허용 혹은 차단)한 규칙의 상세 정보를 제공합니다.
    • conditionType = 규칙에 적용된 조건의 유형을 뜻합니다. 이 규칙의 경우 정규 표현식이 사용되었으므로 “REGEX” 로 표기됩니다.
    • location = 규칙에 적용된 검사 위치를 뜻합니다. 이 규칙의 경우 “QUERY_STRING” 이 지정되었습니다.
    • matchData = 규칙에 매칭된 데이터 정보를 제공합니다. 매칭된 데이터 제공이 가능한 경우 관련 데이터 정보를 표시하며 데이터 제공이 불가능한 경우 “null” 로 표기합니다.
    • matchFieldName = 규칙에 매칭된 영역 정보를 제공합니다.

그림. SQL Injection 공격 차단 로그

이번에는 동일한 공격 시나리오에서 사용자 정의 규칙의 Action 을 “Count” 로 변경한 후 로그 정보를 확인해보도록 하겠습니다.

정상적으로 테스트가 진행되는 경우 공격 요청은 사용자 정의 규칙에 의해 탐지되더라도 차단되지 않고 지정된 Default Action(Allow) 에 의해 허용되게 됩니다. 이와 같은 요청 처리에 대한 흐름은 아래와 같은 로그를 통해 확인할 수 있습니다.

아래 로그를 보면 이전 차단 로그와 다르게 “terminatingRuleID” 가 “Default_Action” 으로 변경된 것을 확인할 수 있으며 “nonTerminationMatchRules” 필드가 로그에 추가된 것을 확인할 수 있습니다. 우리는 이와 같은 로그를 통해 공격 요청이 사용자 정의 규칙 “SQL-Injection_CustomrRule” 이 매칭되었으나 Termination 처리되지 않고 “Default_Action” 에 의해 허용되었음을 알 수 있습니다.

그림. SQL Injection 공격 Count 처리 로그

2.2 AWS 관리형 규칙에서의 “Block” 및 “Count” Action

이번에는 AWS 에서 제공하는 AWS 관리형 규칙 중 테스트 시나리오에서 사용되는 SQL Injection 공격을 탐지 및 차단할 수 있는 무료 AWS 관리형 규칙을 이용하여 AWS WAF 의 동작을 살펴보도록 하겠습니다.

시나리오에 사용된 SQL Injection 공격을 탐지 및 차단하기 위해 아래 그림과 같이 “SQL database rules” 를 적용하였으며 기본값으로 설정된 옵션들은 모두 변경없이 적용하였습니다.

그림. SQL Injection 공격 차단용 AWS 관리형 규칙

규칙이 정상적으로 적용된 후 공격 요청이 차단되는지 확인한 후 CloudWatch Log Group 에 접속하여 로그가 발생하였는지 확인하였으며 아래 그림과 같이 정상적으로 차단 로그가 발생한 것을 확인하였습니다. 아래의 공격 차단로그의 각 필드 정보를 확인하시기 바랍니다.

그림. SQL Injection 공격 차단 로그

SQL Injection 공격이 AWS 관리형 규칙으로 차단되는 것을 확인하였으니 이제 AWS 관리형 규칙의 기본 Action 인 “Block” 을 “Count” 로 Override 하는 설정을 적용한 후에 로그를 확인해보도록 하겠습니다. 사용자 정의 규칙의 경우 Action 을 “Count” 로 설정하는 방법은 한 가지만 가능하지만 AWS 관리형 규칙의 경우 Rule Group 수준에서 “Count” Action 으로 Override 하는 방법과 개별 규칙 수준에서 “Count” Action 으로 Override 하는 방법을 제공하고 있습니다.

먼저, 아래 그림과 같이 개별 규칙 수준에서 “Count” Action 으로 Override 하도록 설정한 후 공격 요청이 허용되는지 확인해도록 하겠습니다.

그림. AWS 관리형 규칙의 개별 규칙 수준의 Count Action 설정

정상적으로 테스트가 진행되었다면 아래 그림과 같이 “Default_Acton” 에 의해 허용처리된 로그를 확인할 수 있습니다. 로그의 내용을 살펴보면 “terminatingRuleId” 정보를 통해 “Default_Action” 에 의해 처리되었음을 알 수 있으며, “nonTerminatingMatchingRules” 정보를 통해 해당 요청을 처리(허용 혹은 차단)하지는 않았지만 AWS 관리형 규칙에 포함된 “SQLi_QUERYARGUMENTS” 규칙이 공격 요청을 탐지(매칭)하였음을 확인할 수 있습니다.

그림. AWS 관리형 규칙에서의 SQL Injection 공격 Count 처리 로그(개별 규칙 수준 설정)

이번에는 AWS 관리형 규칙에서 “Count” Action 을 설정하는 또 다른 방법인 로그 그룹 수준의 “Count” Action 을 설정한 후 동일한 테스트를 진행하도록 하겠습니다. 아래 그림과 같이 개별 규칙 수준의 설정은 모두 기본값으로 두고 화면 하단의 “Override rule group action to count” 옵션을 활성화합니다.

그림. AWS 관리형 규칙의 규칙 그룹 수준의 Count Action 설정

“Override rule group action to count” 옵션을 활성화한 후 동일한 테스트를 진행하여 공격이 허용된 것을 확인한 후 Cloud Watch Log Group 에 접속하여 로그를 확인합니다.

AWS 관리형 규칙에서 개별 규칙 수준으로 “Count” Action 을 설정했을 때처럼 정상적으로 공격 요청이 허용되었지만 로그 정보를 보면 로그의 유형이 약간 변경된 것을 확인할 수 있습니다. 개별 규칙 수준에서 “Count” Action 을 지정했을 때는 “SQLi_QUERYARGMENTS” 의 Action 이 “Count” 였지만 이번에는 “SQLi_QUERYARGMENTS” 의 Action 이 “BLOCK” 인 것을 확인할 수 있으며, 별도의 “nonTerminatingMatchRules” 영역에 있는 “AWS-AWSManagedRulesSQLiRuleSet” 의 Action 이 “COUNT” 로 지정되어 있는 것을 확인할 수 있습니다.

그림. AWS 관리형 규칙에서의 SQL Injection 공격 Count 처리 로그(규칙 그룹 수준 설정)

우리는 여기까지 간단한 테스트를 통해 AWS WAF 가 SQL Injection 공격을 사용자 정의 규칙이나 AWS 관리형 규칙을 통해 탐지 및 차단할 수 있으며 “Count” Action 을 통해 공격 요청을 처리하지 않고 허용하는 방법과 각각의 로그를 확인하는 방법을 살펴 보았습니다.

3. 로그 필터 사용법

그럼 이제 AWS WAF 를 운영하면서 “Count” Action 을 사용하는 경우 실제 업무 환경에서 부딪힐 수 있는 가장 흔한 실수 중 하나인 AWS WAF 로그 필터에 대해 살펴보도록 하겠습니다.

AWS WAF 는 로그를 활성화하면 기본값으로 AWS WAF 에서 처리하는 모든 요청을 로그로 기록합니다. 즉, 관리자가 규칙에 적용한 Action 에 관계 없이 모든 요청을 기록하기 때문에 기본값으로 AWS WAF 로그를 운영하면 사용자 요청을 Action 의 종류와 관계없이 모두 로깅하는 것이 가능합니다. 하지만, 일부 사용 사례의 경우 모든 요청을 로그로 기록하는 것보다는 특정 Action 에 매칭되는 요청만을 로그로 남기는 것을 선호할 수도 있습니다. 예를 들어, 차단된 요청만 로그로 남긴다거나 “Count” 처리된 로그만 남김으로써 로그 저장에 필요한 저장공간을 효율적으로 사용한다거나 로그 분석에 필요한 자원의 효율성을 추구할 수 있습니다.

위 단계에서 진행한 테스트에서는 별도의 로그 필터 없이 로그를 남기도록 했었지만 이번에는 아래와 같이 “COUNT” Action 만 로깅하도록 로그 필터를 적용한 후 테스트를 진행해 보도록 하겠습니다.

그림. Count 로그만을 남기는 로그 필터 옵션

3.1 사용자 정의 규칙의 COUNT 로그 필터 동작 확인

아래와 같이 사용자 정의 규칙의 Action 을 “Count” 로 설정한 후 SQL Injection 공격 요청이 허용되고 로그 필터에 의해 로그에 남는지 확인해보도록 하겠습니다.

그림. 사용자 정의 규칙의 Count Action 설정

확인 결과 아래 그림과 같이 사용자 정의 규칙이 정상적으로 공격 요청을 허용하고 로그에 남는 것을 확인할 수 있었습니다.

그림. 사용자 정의 규칙에 의한 Count 로그

3.2 AWS 관리형 규칙의 COUNT 로그 필터 동작 확인

이번에는 AWS 관리형 규칙에 대해 동일한 테스트를 진행해보도록 하겠습니다. 위에서 언급한 것처럼 AWS 관리형 규칙은 2가지 유형의 “Count“ Action 설정 방법을 제공하는데 먼저 아래 그림과 같이 규칙 그룹 수준의 ”Count“ 설정을 적용한 후 테스트를 수행하도록 하겠습니다.

그림. AWS 관리형 규칙의 규칙 그룹 수준의 Count Action 설정

테스트가 정상적으로 수행되었다면 AWS 관리형 규칙 그룹에서 규칙 그룹 수준의 “Count” Action 설정 후 아래와 같이 SQL Injection 공격이 매칭되었지만 “Default_Action” 에 의해 허용된 Count 로그를 확인할 수 있습니다.

그림. AWS 관리형 규칙에서의 SQL Injection 공격 Count 처리 로그(규칙 그룹 수준 설정)

그럼 이제 마지막으로 아래 그림과 같이 AWS 관리형 규칙에서 개별 규칙 수준으로 “Count” Action 을 설정한 후 동일한 테스트를 진행해보도록 하겠습니다.

아래 그림과 같이 “Override rule group action to count” 옵션은 비활설화하고 공격 요청을 탐지할 수 있는 개별 규칙에 대해서만 Rule Action 을 “Override to Count” 로 변경하고 저장한 후 공격 요청을 수행합니다.

그림. AWS 관리형 규칙의 개별 규칙 수준의 Count Action 설정

모든 설정과 테스트가 정상적으로 진행되었다면(로그 필터는 “Count” Action 만 로그를 남기도록 설정 + AWS 관리형 규칙에서는 개별 규칙 수준에서 “Count” Action 설정) 아래 그림과 같이 아무런 로그가 남지 않는 것을 확인할 수 있습니다.

그림. AWS 관리형 규칙에서의 SQL Injection 공격 Count 처리 로그(규칙 수준 설정)

이처럼 사용자 입장에서는 동일한 “Count” Action 으로 이해할 수 있지만 AWS WAF 의 로그 필터에서 개별 규칙 수준으로 AWS 관리형 규칙을 “Count” 처리했을 때는 로그 필터가 기대했던 것처럼 동작하지 않는 것을 볼 수 있습니다.  관리자는 “Count” 로그 필터를 적용했고 AWS WAF 도 해당 로그를 “Count” 처리했음에도 불구하고 왜 아무런 로그가 남지 않았을까요? 이 의문에 대한 해답은 좀 더 테스트를 진행한 후에 내려보도록 하겠습니다.

이번에는 로그 필터를 아래 그림과 같이 “EXCLUDED_AS_COUNT” Action 만 로깅하도록 설정을 수정한 후 AWS 관리형 규칙의 개별 규칙 수준의 “Count” Action 테스트를 동일하게 수행해보도록 하겠습니다.

그림. “EXCLUDED_AS_COUNT” Action 로그 필터

모든 설정이 정상적으로 적용되었다면 이번에는 아래 그림과 같이 AWS 관리형 규칙의 개별 규칙 수준의 “Count” Action 이 로그로 남는 것을 확인할 수 있습니다.

그림. AWS 관리형 규칙에서의 SQL Injection 공격 Count 처리 로그(개별 규칙 수준 설정)

아마도 AWS WAF 를 운영하는 사용자들은 “AWS WAF 의 로그 필터가 왜 이렇게 동작하는가?“ 에 대해 의문이 많으실 것 같습니다. 간단하게 관련 내용을 설명드리면, 사용자 입장에서는 동일한 ”Count“ Action 임에도 불구하고 이렇게 로그 필터가 다르게 적용되는 이유는 ”Count“ Action 이 적용되는 구조 때문입니다. 주의 깊게 이 블로그 포스팅을 보신 분들이라면 AWS 관리형 규칙의 ”Count“ Action 에 의해 남겨지는 로그가 개별 규칙 수준의 ”Count“ 와 규칙 그룹 수준의 ”Count“ 에 따라 차이가 있다는 것을 확인하셨을겁니다. 이 두가지 로그의 구조를 기반으로 로그 필터와 연계해서 간단하게 설명드리면 각각의 ”Count“ 는 아래와 같은 의미를 갖습니다

  • 개별 규칙 수준의 “Count” Action -개별 규칙이 속한 AWS 관리형 규칙 그룹의 기본 Action 은 “BLOCK” 이지만 “COUNT” 로 지정된 규칙은 예외적으로 “COUNT” Action 으로 처리한다. (EXCLUDED_AS_COUNT)
  • 규칙 그룹 수준의 “Count” Action – AWS 관리형 규칙 그룹의 기본 Action 을 “COUNT” 로 변경한다. 즉, 규칙 그룹 수준의 Action 이 수정되었으므로 개별 규칙 수준에서 별도로 예외적인 처리가 필요 없다.(COUNT)

따라서, AWS WAF 운영 환경에서 AWS 관리형 규칙을 사용하고 있고 해당 AWS 관리형 규칙에서 개별 규칙 수준의 “Count” Action 처리를 하고 있으며 로그 필터를 사용하고 있는 관리자라면 모든 “COUNT” 로그를 기록하기 위해서는 아래 그림과 같이 “COUNT” 와 “EXCLUDED_AS_COUNT” 를 모두 로그로 남기도록 하는 로그필터를 생성해야 합니다.

그림. 모든 유형의 AWS 관리형 규칙의 Count 로그를 남기기 위한 로그 필터

4. 결론

여기까지 AWS WAF 에서 제공하는 “Count“ Action 의 로그와 ”Count“ Action 을 로깅하는 과정에서 반드시 숙지해야하는 로그 필터 사용법에 대해 살펴보았습니다. 서론에서 언급한 것처럼 ”Count“ Action 은 신규 규칙 적용 시 오탐(False Positive)을 최소화하고 AWS WAF 운영 과정에서 발생할 수 있는 의도하지 않은 문제 상황을 해결하기 위해 사용되는 가장 대표적인 Action 유형 중 하나입니다. 그리고 로그 필터 역시 AWS WAF 에서 처리하는 로그를 효율적으로 수집하고 분석하기 위한 중요 기능입니다. 이 포스팅이 이와 같은 두 가지 중요 기능을 조합하여 사용하는데 도움이 되셨기를 바랍니다.

Eunsu Shin

Eunsu Shin

신은수 Security Specialist Solutions Architect 는 보안 담당 SA로서 다양한 산업군의 고객들이 AWS 환경에서 수행해야하는 규정 준수 및 인증획득(개인정보보호법, 전자금융감독규정, ISMS-P 인증 등)을 위한 기술적인 도움을 제공해드리고 있습니다. 또한, 고객이 보다 안전하게 AWS 클라우드를 구성하고 운영할 수 있도록 다양한 모범 사례 공유, AWS 보안 서비스 교육 및 기술자문 등의 업무를 수행하고 있습니다.