AWS 기술 블로그
AWS WAF 의 COUNT ACTION 이해하기
참고 – AWS WAF 에서 제공하는 COUNT Logging 기능이 업데이트되어 이 블로그의 내용도 업데이트 되었습니다.
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” 로그가 생성된 것을 확인하였습니다.
로그 정보에 대한 설명
- terminatingRuleID = 요청을 처리(허용 혹은 차단)한 규칙의 유형을 뜻합니다. 이 로그의 경우 “SQL-Injection_CustomrRule” 규칙에 의해 처리되었음을 나타냅니다.
- terminatingRuleType = 요청을 처리(허용 혹은 차단)한 규칙의 유형을 뜻합니다. 사용자 정의 규칙의 경우 “REGULAR” 로 표기됩니다.
- action = 요청을 처리(허용 혹은 차단)한 규칙의 Action 을 뜻합니다. 이 로그의 경우 “BLOCK” 입니다.
- 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 설정
모든 설정이 정상적으로 적용되었다면 이번에는 아래 그림과 같이 AWS 관리형 규칙의 개별 규칙 수준의 “Count” Action 이 로그로 남는 것을 확인할 수 있습니다.
그림. AWS 관리형 규칙에서의 SQL Injection 공격 Count 처리 로그(개별 규칙 수준 설정)
4. 결론
여기까지 AWS WAF 에서 제공하는 “Count“ Action 의 로그와 ”Count“ Action 을 로깅하는 과정에서 반드시 숙지해야하는 로그 필터 사용법에 대해 살펴보았습니다. 서론에서 언급한 것처럼 ”Count“ Action 은 신규 규칙 적용 시 오탐(False Positive)을 최소화하고 AWS WAF 운영 과정에서 발생할 수 있는 의도하지 않은 문제 상황을 해결하기 위해 사용되는 가장 대표적인 Action 유형 중 하나입니다. 그리고 로그 필터 역시 AWS WAF 에서 처리하는 로그를 효율적으로 수집하고 분석하기 위한 중요 기능입니다. 이 포스팅이 이와 같은 두 가지 중요 기능을 조합하여 사용하는데 도움이 되셨기를 바랍니다.