AWS WAF – Label 을 활용한 예외 규칙의 사용

이번 포스팅에서는 AWS WAF에서 사용하는 “Label” 을 이용하여 WAF 규칙에서 오탐(False Positive)이 발생한 경우 예외처리를 하는 방법에 대해 살펴보도록 하겠습니다. AWS WAF 운영환경에서 사용하는 Label 은 AWS WAF에서 처리한 HTTP Request 에 대해 관리형 규칙에 의해 자동으로 부여되거나 관리자에 의해 수동으로 부여되는 속성값을 의미하며 “Label” 을 사용하면 관리자는AWS WAF 의 운영을 좀 더 효율적으로 하실 수 있습니다. 예를 들면, “Label” 이 없는 환경에서는 외부에서 유입되는 사용자의HTTP Request 가 AWS WAF 의 특정 규칙에 매칭되는 경우 이 규칙에 매칭되는 트래픽에 대해서만 별도로 로그를 생성하도록 하는 것이 불가능하였습니다. 하지만, Label 을 사용하면 AWS WAF 에 로그를 저장할 때 Label 이 적용된 Log Filter 를 사용하면 특정 규칙에 매칭된 트래픽에 대해만 로그를 기록하는 것이 가능합니다. 또한, Label 을 사용하면 AWS 관리형 규칙을 사용하는 환경에서 특정 사용자 요청에 대해 관리형 규칙에서 오탐이 발생하는 경우 이를 예외 처리하는데 좀 더 효율적인 설정이 가능해집니다. Label 을 이용하여 관리형 규칙의 오탐에 대한 예외 처리를 하는 방법에 대해서 이 포스팅에서 자세하게 살펴보도록 하겠습니다.

1. Label 의 구조

“Label” 은 일정한 규칙에 따라 자동으로 생성되거나 관리자가 사용자 정의 Label 을 생성하여 사용하실 수 있습니다. 또한 각 Label 은 유형에 따라 아래와 같이 사전에 정의된 구조를 포함하고 있습니다.

A. 사용자 정의 Label

사용자가 임의의 값을 입력하여 AWS WAF 규칙에 매칭되는 HTTP Request 에 부여할 수 있는 Label 입니다. 사용자 정의 Label 의 기본 구조는 아래와 같이 “Label Namespace Prefix” 와 “Custom Namespace Addition” 로 구분되어 있는 구조를 가지고 있습니다.

awswaf:<entity owner account id>:<entity type>:<entity name>:<custom namespace>:...:<label name>

위 Label 구조에서 굵은 글씨로 표현된 아래 부분은 “Label Namespace Prefix” 로서 각 Entity 에 해당하는 값들(entity owner account id, entity type, entity name)은 반드시 입력되어야 합니다.

기울림으로 표기된 아래 부분은 “Custom Namespace Addition” 영역으로 사용자가 임의의 값을 지정하여 사용하실 수 있습니다. 이 때, “custom namespace” 는 하나 이상의 Namespace 를 지정하거나 혹은 생략하실 수 있습니다. 하지만, 가장 마지막에 위치하는 “label name” 은 생략될 수 없으며 반드시 지정되어야 합니다.

아래의 예제에는 동일한 Label Namespace Prefix 를 갖는 3가지 유형의 사용자 정의 Label 이 나타나 있습니다. 이 “3가지 사용자 정의 Label”은 모두 동일한 Label Namespace Prefix 를 포함하고 있지만 Namespace 와 Label 을 지정하는 영역에 대해서는 서로 다른 구조를 포함하고 있습니다.

생성 예제

awswaf:111122223333:rulegroup:testRules:testNS1:testNS2:LabelNameA
- 2개의 Namespace(testNS1, testNS2)를 포함하는 Label(LabelNameA) 입니다.
awswaf:111122223333:rulegroup:testRules:testNS1:LabelNameQ
- 1개의 Namespace(testNS1)를 포함하는 Label(LabelNameQ) 입니다.
awswaf:111122223333:rulegroup:testRules:LabelNameZ
- =Namespace를 포함하지 않는 Label(LabelNameZ) 입니다.

B. 관리형 규칙 Label

관리형 규칙 Label 은 사용자가 임의로 설정할 수 없으며 각 관리형 Rule Group 에 설정되어 있는 Label 을 의미합니다. 관리형 규칙 Label 은 아래 예시와 같이 사용자 정의 Label 과 동일한 구조를 포함하고 있으며 사용자의 HTTP Request 가 관리형 규칙에 매칭되는 경우 자동으로 Label 이 할당되게 됩니다.

Label 기본 구조

awswaf:managed:<vendor>:<rule group name>:<custom namespace>:...:<label name>

생성 예제

awswaf:managed:aws:core-rule-set:NoUserAgent_Header
awswaf:managed:aws:sql-database:SQLiExtendedPatterns_QueryArguments
awswaf:managed:aws:atp:aggregate:attribute:compromised_credentials
awswaf:managed:token:accepted

C. 관리형 규칙 Process Label

관리형 규칙 Process Label은 AWS 관리형 규칙 그룹을 사용하는 경우에 적용되는 관리형 Label 입니다.

Label 기본 구조

awswaf:managed:<process>:<custom namespace>:...:<label name>

Label 의 구조 및 사용에 관한 보다 자세한 사항은 링크를 참고하시기 바랍니다.

주의 사항

Label 은 Rule Group 에는 적용할 수 없습니다. Label 은 Rule Group 에 포함된 개별 규칙에 설정되어야 하며 Rule Group 레벨에서는 적용할 수 없습니다.
Rate-Based 규칙을 사용하는 경우 관리자가 지정한 Rate를 초과하는 요청에 대서만 Label 이 추가됩니다.

2. Label 을 이용한 예외처리 규칙 생성

AWS WAF 에서 사용할 수 있는 Label 의 기본적인 개념과 구조에 대해 살펴보았으니 이제 이 포스팅의 주제인 Label 을 이용한 예외처리 규칙 생성방법에 대해 살펴보도록 하겠습니다.

Label 의 사용 및 설정 방법에 대한 이해를 돕기 위하여 AWS WAF 에서의 각 설정단계는 테스트 환경을 기반으로 설명하도록 하겠습니다.

2.1 정상적인 페이지 접속 확인

Label 을 이용한 예외처리 규칙 생성방법을 설명하기에 앞서 AWS WAF 가 연결되어 있는 페이지에 대한 정상적인 접속 여부를 확인하도록 하겠습니다. 이 포스팅에 사용된 웹사이트는 ALB 를 통해 서비스되고 있으며 AWS WAF 에 연결되어 있는 상태입니다. 이 웹사이트는 아래와 같이 HTTPie 와 같은 HTTP Client 로 접속하는 경우 정상적인 접속이 가능하며 <script>alert(document.cookie)</script> 와 같은 간단한 XSS(Cross Site Scripting) 공격에 대한 취약점도 포함하고 있습니다. 먼저 이 포스팅에서 사용할 웹서버에 대해 정상적으로 접속이 가능한지 확인해보도록 하겠습니다.

HTTPie 를 이용하여 ALB(Application Load Balancer)의 도메인으로 접속해보면 아래와 같이 정상적으로 접속이 되는 것을 확인할 수 있습니다.

그림. 정상 페이지 접속 확인

이번에는 테스트용 웹서버에서 XSS 패턴을 입력으로 사용할 수 있는 페이지에 대해 XSS 패턴 입력이 정상적으로 수행되는지 확인해보도록 하겠습니다.

아래 예시와 같은 아주 간단한 XSS 패턴을 입력하여 웹서버에서 정상적으로 처리가 되는지 확인해보도록 하겠습니다.

<script>alert(document.cookie)</script>

테스트용 웹서버에서는 아래와 같이 이 XSS 패턴 입력이 정상적으로 처리되는 것을 확인할 수 있습니다.

그림. XSS 공격 성공 화면

참고. 테스트에 사용한 웹서버는 의도적으로 XSS 패턴을 허용되도록 구성한 취약한 웹서버입니다.

2.2 관리형 규칙의 생성

이제 우리는 ALB 를 통해서 구성된 웹서버가 인터넷을 통해 정상적으로 서비스가 되고 있으며 XSS 패턴에 대한 정상적으로 사용할 수 있는 환경이라는 것을 확인하였습니다. 그럼 이제 이 포스팅의 목적인 AWS 관리형 규칙에 대한 예외 처리를 수행하기 위한 작업을 진행하도록 하겠습니다.

먼저, 아래와 같이 AWS WAF 에 WebACL 을 생성한 후 AWS 관리형 규칙 중 “Core Rule Set” Rule Group을 선택하여 추가하도록 하겠습니다.

그림. AWS 관리형 규칙 중 Core Ruleset 선택 화면

“Core Rule Set” Rule Group에는 아래와 같이 여러 유형의 공격에 대한 규칙들이 포함되어 있으며 정상적인 접속 단계에서 사용한 “XSS 패턴” 을 매칭하는 패턴도 포함이 되어 있습니다.

그림. Core Rulset 의 상세 규칙 정보

2.3 관리형 규칙에서의 오탐 확인

WebACL 에 “Core Rule Set” Rule Group 이 추가되었다면 생성된 WebACL 을 이전 단계에서 테스트한 ALB 와 연결한 후 “Core Rule Set” 의 규칙에 매칭되는지 확인해보도록 하겠습니다.

아래와 같이 이전 과정에서 테스트에 사용한 “XSS 패턴” 을 이용하여 동일하게 접속을 시도하면 이번에는 “403 Forbidden” 으로 접속 요청이 차단되는 것을 확인할 수 있습니다. 즉, AWS 관리형 규칙에 매칭되어 차단되었다는 것을 알 수 있습니다.

그림. XSS 공격 차단 화면

2.4 매칭된 관리형 규칙의 확인

이전 과정에서 추가한 “Core Rule Set” Rule Group 에 의해 매칭되었다는 것은 설정을 통해 알 수 있지만 Rule Group 에 포함된 여러가지 규칙 중 어떤 규칙이 매칭되었는지는 설정만으로는 파악할 수 없습니다. 따라서, 정확하게 어떤 규칙에 의해 차단이 되었는지를 파악하기 위해서는 로그를 확인해야 하는데요. WebACL 에 로그를 설정하신 후 CloudWatch Logs 나 S3 에 저장하도록 구성을 하시면 아래와 같이 관리형 규칙에 의해 차단된 사용자 요청의 로그를 확인할 수 있습니다.

저장된 로그의 내용을 보면 아래와 같이 사용자의 요청을 차단하는데 사용된(매칭된) 규칙의 ruleId 를 확인할 수 있으며 로그 정보의 가장 하단에 있는 “labels” 를 통해 이 규칙에 매칭되는 경우 어떤 Label 이 추가되는지에 대한 정보를 파악할 수 있습니다.

그림. XSS 공격 차단 로그

우리는 이 로그 메시지를 통해서 “XSS 패턴” 을 사용하는 사용자의 요청이 “CrossSiteScripting_QUERYARGUMENTS” 라는 규칙에 매칭되어 차단되었고 이 규칙에 매칭되는 경우 “awswaf:managed:aws:core-rule-set:CrossSiteScripting_QueryArguments” 라는 Label 이 추가되게 된다는 것을 알 수 있었습니다.

2.5 관리형 규칙의 Count 처리

그럼 이제 매칭된 규칙에 대한 예외 처리를 위한 절차를 수행하도록 하겠습니다. 먼저, 로그를 통해 파악한 “CrossSiteScripting_QUERYARGUMENTS” 규칙에 대해 아래와 같이 “Count” 처리하도록 설정을 변경하도록 하겠습니다. 이렇게 “Count” 옵션을 특정 규칙에 대해 활성화하는 경우 사용자 요청이 해당 규칙에 매칭된다 하더라도 AWS WAF 에서는 해당 요청을 차단하지 않고 나머지 규칙에 대한 검사를 계속 수행하게됩니다.

그림. 특정 관리형 규칙의 Count 처리

2.6 사용자 정의 예외 처리 규칙 생성

우리가 원하는 것은 모든 사용자에 대해 “XSS 패턴” 검사를 비활성화하는 것이 아닙니다. 위 단계에서처럼 단순하게 특정 규칙을 “Count” 처리하게되면 정상적인 사용자의 요청 뿐만 아니라 악의적인 사용자의 요청마저 허용하게 되는 상황을 초래할 수 있습니다. 따라서, 우리는 그러한 상황을 예방하기 위한 추가 설정이 필요합니다. 이와 같은 추가 설정 작업은 사용자 정의 규칙을 통해 이뤄지며 이 단계에서 사용되는 사용자 정의 규칙이 Label 을 이용한 오탐에 대한 예외처리 설정의 핵심이라고 볼 수 있습니다.

사용자 정의 규칙을 생성하기 전에 사용자 정의 규칙에 매칭되어 차단되는 요청에 대해 사용할 “Custom Response” 페이지를 생성하도록 하겠습니다.

AWS WAF 의 WebACL 메뉴 중 “Custom Response Bodies” 메뉴에서 “Create Custom Response Body” 를 클릭하여 새로운 사용자 정의 응답 페이지를 생성합니다.

그림. 사용자 지정 응답 페이지 설정 화면

새로운 사용자 정의 응답 페이지의 설정은 아래 그림과 같이 “Content Type” 은 “HTML” 로 지정하고 아래 그림과 같이 간단한 HTML 페이지를 적용하도록 하겠습니다.

그림. 사용자 지정 응답 페이지 설정 화면

그럼 이제 예외처리를 위한 사용자 정의 정책을 만들어 보도록 하겠습니다. 사용자 정책의 기본 구조는 다음과 같습니다.

로그에서 확인한 Label 을 포함한 사용자 요청에 대해서는 차단하도록 합니다.
단, 차단을 적용하는 조건에는 Label 이 반드시 포함되어 있어야 하며 사용자 요청에 “exception” 이라는 헤더의 값이 “true” 가 아니어야 합니다.

즉, XSS 패턴이 관리형 규칙에 매칭되더라도 사용자 요청에 “exception:true” 라는 헤더가 있다면 차단되지 않도록 하는 규칙이라고 생각하시면 되겠습니다.

이와 같은 규칙은 다음과 같은 과정을 통해 생성하실 수 있습니다.

사용자 정의 규칙의 기본 조건을 “AND” 를 선택합니다.
첫번째 Statement 에서 “Negate statement results” 를 선택하여 Statement 에 정의된 사항이 아닌 경우 매칭되도록 합니다.
예외처리에 대해 검사할 필드로 특정 헤더를 검사할 수 있도록 “Single Header” 를 선택합니다.
예외처리에 활용할 Header 의 이름을 지정합니다.
“Match Type” 을 “Exactly matches string” 을 선택합니다.
“String to match” 의 값에 “true” 를 입력합니다.

그림. WAF 규칙 설정 화면

여기까지 구성된 내용을 정리해보면 첫번째 Statement 를 만족할 수 있는 조건은 사용자의 요청에 “exception” 이라는 헤더 자체가 없거나 “exception” 헤더의 값이 “true” 가 아닌 경우 매칭하도록 설정되었습니다.

이번에는 두번째 Statement 를 설정하도록 하겠습니다.

두번째 Statement 에서는 Label 을 체크할 수 있도록 “Inspect” 옵션에서 “Has a label” 을 선택합니다.
Labels 의 세부 메뉴에서 아래 그림과 같이 차단 로그에서 확인하였던 Label 을 선택합니다.

그림. WAF 규칙에서 Label 설정 화면

두 번째 Statement 까지 설정을 완료하였다면 이 규칙은 AWS 관리형 규칙에 매칭되더라도 우리가 원하는 사용자 요청(“exception” 헤더가 존재하고 그 값이 “true” 인 요청)에 대해서는 예외처리가 가능한 조건이 만들어진 것입니다.

마지막으로 규칙의 나머지 부분들을 설정하도록 하겠습니다. “Action” 은 Block 으로 선택하고 “Custom Response” 부분에서 아래 그림과 같이 “Enable” 을 체크하여 “Custom Response” 를 활성화하고 “Response Code” 에 “200”을 입력합니다. 그리고 마지막으로 이전 단계에서 생성하였던 Custom Response-MyReseponse 를 선택한 후 새로운 규칙을 생성하겠습니다.

그림. WAF 규칙에서 응답페이지 설정 화면

여기까지 생성하였다면 WebACL 에 아래와 같이 AWS 관리형 규칙과 사용자 정의 규칙(예외처리용)이 설정되어 있는 상태일 것입니다.

그림. WAF 규칙에서 응답페이지 설정 확인

현재까지 적용된 AWS 관리형 규칙과 사용자 정의 규칙을 개념적으로 나타내면 아래와 같습니다. AWS WAF 는 사용자 요청을 수신하였을 때 숫자가 낮은 Priority 부터 검사를 진행하고 매칭된 규칙의 Action 이 “Count” 인 경우 규칙 검사를 해당 규칙에서 중지하지 않고 계속 규칙 검사를 수행한다는 점을 생각하면 Label 기반 예외처리 및 차단 규칙의 동작을 이해하는데 도움이 될 수 있습니다.

그림. Label 기반 예외처리 규칙 개념도

2.7 예외처리 규칙의 동작 확인

모든 규칙 설정을 완료하였으니 이제 각 규칙들이 의도한대로 동작하는지 확인해보도록 하겠습니다.

먼저 exception 헤더가 없는 상태에서 “XSS 패턴” 을 입력하여 차단되는지 확인해보도록 하겠습니다. 아래와 같이 “exception” 헤더가 없는 경우 우리가 지정한 사용자 정의 응답페이지의 응답메시지와 함께 차단되는 것을 확인할 수 있습니다.

그림. WAF 규칙에 의한 차단 페이지 확인

이번에는 “exception” 헤더는 존재하지만 그 값이 “true” 가 아닌 경우를 확인해보도록 하겠습니다. 이 경우 우리가 의도한대로 아래와 같이 사용자 정의 규칙에 의해 차단된 것을 확인할 수 있습니다.

그림. WAF 규칙의 헤더값에 의한 차단 확인

그럼 마지막으로 “exception” 헤더가 존재하고 그 값이 “true” 인 경우를 확인해보도록 하겠습니다. 이 경우 아래 그림과 같이 동일한 페이지에 동일한 “XSS 패턴” 을 사용하였지만 AWS WAF 에 의해 차단되지 않고 웹사이트에 정상적으로 접속되는 것을 확인할 수 있습니다.

그림. Label 예외처리를 통한 허용 확인

즉, AWS 관리형 규칙에 매칭된 특정 사용자 패턴에 대해 예외처리 규칙을 통해 관리자가 지정한 유형의 트래픽은 허용하지만 나머지 요청에 대해서는 차단이 계속 이뤄지는 것을 확인할 수 있습니다.

마무리

WAF 를 운영하는 환경에서 관리형 규칙을 사용하다보면 각 조직별로 특화된 규칙을 사용하는 것이 아닌 만큼 오탐(False Positive)가 발생하기 마련입니다. 이와 같은 현상은 AWS WAF 를 운영하는 환경에서도 마찬가지로 발생할 수 있습니다. 따라서, 관리자는 AWS WAF 에서 제공하는 기능을 통해 보안의 수준의 최대한 유지한 상태에서 조직에서 사용하는 정상적인 요청에 대한 오탐을 예외처리하는 규칙을 적용하는 것이 반드시 필요합니다. 조직의 운영환경에 따라 오늘 이 포스팅에서 소개한 예외처리 규칙이외에 특정 관리형 규칙을 Count 처리한다거나 Scope-Down 정책 등을 통해 관리형 규칙에 매칭되는 환경을 제한하는 등의 예외 처리 방법을 적용할 수 있지만 Label 을 통한 예외처리 규칙의 경우 관리형 규칙의 검사 대상을 제한하지 않고 관리자가 지정한 특정 패턴을 제외한 모든 사용자 요청에 대해 규칙 검사 및 차단 기능을 계속 제공한다는 점에서 실제 운영환경에 적용하는 경우 장점이 있습니다.

AWS WAF 는 최근 여러가지 기능을 꾸준히 업데이트하면서 사용자 편의성을 높이고 보안적으로 사용할 수 있는 기능도 추가하고 있습니다. 오늘 포스팅에서 다뤘던 Label 기반의 예외처리 이외에도 AWS WAF 의 다양한 기능에 대해 링크를 참고하시기 바랍니다.

AWS 기술 블로그