Amazon Web Services 한국 블로그
AWS WAF를 통한 웹 공격 방어 정책 설정 및 오탐 예외 처리하기
인터넷 공간에서 많은 사용자들을 대상으로 하는 웹서비스가 대중화되고 중요도가 높아지면서 웹서비스를 안전하게 운영할 수 있도록 보호할 수 있는 웹 애플리케이션의 보호 솔루션 역시 꾸준하게 발전되어 왔습니다. 웹 서비스는 서비스의 특성 상 불특정 사용자들에게 공개적으로 접속할 수 있는 환경을 제공하기 때문에 웹서버를 통해 기업이나 조직이 보유하고 있는 다양한 중요 데이터가 개인 정보들을 탈취하거나 혹은 정치적인 목적으로 해당 웹 서비스를 서비스 불능 상태로 만들거나 페이지를 변조하려는 악의적인 사용자 혹은 해커로부터의 위험에 노출될 수 밖에 없습니다. 기업이나 조직의 입장에서는 이러한 위험을 최소화하기 위하여 다양한 웹 서비스 보호 수단을 강구할 수 있는데 대표적으로 다음과 같은 보호 수단을 적용할 수 있습니다.
- DDoS 솔루션 적용을 통한 서비스 거부 공격의 방어
- 웹방화벽 적용을 통한 알려진 공격에 대한 차단 및 알려지지 않은 공격에 대한 차단
- 외부 공격에 취약점을 갖는 코드를 제거하는 시큐어 코딩
- 웹 서버 구동에 필요한 다양한 구성 요소에 대한 보안 업데이트의 최신 상태 유지
AWS 에서는 여러분들의 웹 서비스가 안전한게 운영될 수 있도록 다양한 보안 서비스를 제공하고 있는데요. 그 중 여러분들이 대표적으로 사용하실 수 있는 웹 서비스 보호를 위한 AWS 서비스는 AWS WAF (Web Application Firewall) 입니다. AWS WAF는 2015년 10월 처음 서비스를 시작한 후, 꾸준하게 그 기능을 개선해 왔고 2019년 11월에 기존 AWS WAF에서 제공하던 기능들 중 고객의 개선 요청사항이 있었던 부분들을 반영하고 많은 것들을 새롭게 구성한 AWS New WAF를 출시하게 되었습니다. AWS New WAF 가 출시됨에 따라 기존의 AWS WAF는 WAF 클래식(Classic)이라는 이름으로 명명되었고 새로워진 New WAF 가 AWS WAF의 이름을 물려받게 되었는데요.
이 글에서는 이렇게 새로워진 AWS WAF를 이용해서 AWS 환경에서 제공되는 웹서비스를 보호하고 AWS WAF운영 과정에서 많이 접할 수 있는 WAF 에서의 오탐(False Positive) 발생 시 예외 처리를 할 수 있는 방법에 대해 살펴보도록 하겠습니다.
AWS WAF 정책 구성 살펴보기
AWS WAF에 접근 허용/차단 정책을 구성할 때 다음과 같은 구성 요소들을 조합하여 정책을 구성할 수 있습니다.
구성 요소 1 – IP 세트 (IP set)
AWS WAF를 통해서 허용하거나 차단하고자 하는 IP 주소 집합으로 CIDR 을 기준으로 설정할 수 있습니다. AWS WAF에서는 사용자가 웹서비스에 접속하게 되면 사용자의 접속 정보 중 IP Address Header 나 관리자가 지정한 HTTP Header 의 값을 검사하여 IP 주소 정보를 추출하게 됩니다. 관리자는 이렇게 추출된 IP 주소 정보를 IP 세트와 비교하는 IP 매칭 규칙을 만들어 요청이 허용되거나 차단되도록 구성할 수 있습니다.
구성 요소 2 – 정규 표현식 세트 (Regex Set)
AWS WAF를 통해서 허용하거나 차단하고자 하는 문자열의 집합으로 정규표현식을 기준으로 설정하실 수 있습니다. AWS WAF에서는 관리자가 지정한 HTTP Request 영역에서 지정된 변환 원칙에 따라 문자열을 추출하게 됩니다. 관리자는 이렇게 추출된 문자열 정보를 정규 표현식 세트와 비교하는 문자열 매칭 규칙을 만들어 요청이 허용되거나 차단되도록 구성하실 수 있습니다.
구성 요소 3 – 규칙 (Rule)
웹 ACL을 이루는 구성 요소 중 하나로 AWS WAF 관리자가 웹서비스를 보호하기 위해 적용하고자 하는 AWS WAF의 보안 정책입니다. 규칙은 설정에 따라 사용자 지정 정책을 사용하는 경우 IP 매칭, 국가별 매칭, 문자열 매칭, SQL 주입 공격 매칭, XSS (Cross Site Scripting) 공격 매칭 등을 사용할 수 있으며 AWS 관리형 규칙이나 보안 파트너가 판매하는 관리형 규칙을 사용할 수 있습니다.
규칙 조건 중 SQL 주입 공격을 탐지하고 차단하는 방법을 예로 들면, 크게 4가지의 방법으로 나눌 수 있습니다.
첫번째, AWS WAF에서 제공하는 SQL 주입 패턴을 검사하는 사용자 정의 규칙(Rule)을 생성할 수 있습니다.
두번째, AWS 에서 제공하는 AWS 관리형 규칙 세트를 사용할 수 있습니다.
세번째, 서드파티 에서 제공하는 파트너 관리 규칙(Partner Managed Rule)을 사용할 수 있습니다.
네번째, 특정 SQL 주입 공격 패턴을 알고 있는 경우 사용자 정의 규칙을 사용할 수 있습니다.
이중 첫번째 방법인 AWS WAF에서 제공하는 SQL 주입 패턴을 이용하여 SQL 주입 공격을 탐지하고 차단하는 방법에 대해 살펴보도록 하겠습니다.
먼저 SQL 주입 공격을 탐지 및 차단하는 규칙을 생성하기 위하여 아래와 같이 규칙명을 입력한 후 규칙의 타입이 “Regular Rule” 인 것을 확인한 후 조건문의 “Match Type” 을 “Contains SQL Injection attacks” 로 선택합니다. 조건문의 검사(Inspect) 항목은 사용 환경에 따라 다양하게 선택될 수 있는데 이 예에서는 “All query parameters” 를 선택하여 사용자가 전송하는 쿼리 스트링의 모든 파라미터에 대해 SQL 주입 공격이 포함되어 있는지 검사하도록 했습니다. 그리고 AWS WAF가 브라우저 혹은 기타 웹 클라이언트가 보낸 사용자 요청을 인식하고 분석할 수 있도록 “Text transformation” 옵션을 선택해 주었습니다.
규칙명과 조건문이 모두 설정 되었다면 SQL 주입 공격이 차단될 수 있도록 “Action” 을 차단(Block) 으로 선택합니다.
이와 같은 규칙을 생성한 후 적용하게 되면 AWS WAF는 사용자의 요청이 웹 ACL 이 연결된 Amazon CloudFront 배포나 ALB (Application Load Balancer) 혹은 Amazon API Gateway 로 수신되게 되면 요청 트래픽을 검사한 후 사용자의 요청에 SQL 주입 공격이 포함되어 있는 경우 해당 공격을 탐지하게 되고 해당 요청을 차단하게 됩니다. 이와 같은 AWS WAF 동작은 사용자가 보내는 모든 트래픽에 대해 진행됩니다.
구성 요소 4 – 규칙 그룹 (Rule Group)
규칙 그룹은 규칙의 조합으로 웹 ACL 에 포함되는 규칙들이 서로 다른 웹 ACL 에서 반복적으로 사용 되는 경우를 위해 웹 ACL 에서 참조하여 사용할 수 있도록 규칙들을 그룹화하여 생성하는 구성요소로 웹 ACL 생성 시 참조하여 정책을 생성할 수 있습니다.
구성 요소 5 – 웹 ACL (Web ACL)
웹 ACL 은 규칙 그룹이나 개별 규칙을 포함하는 AWS WAF의 보안 정책의 모음으로 웹 ACL이 Amazon CloudFront 나 API Gateway, ALB 와 같은 보호 대상 AWS 자원과 연계되는 구성 요소입니다.
AWS WAF의 정책 검사 구조
AWS WAF는 여러가지 규칙들이 개별 규칙과 규칙 그룹으로 조합되어 있는 웹 ACL 을 통해 정책 검사를 수행합니다. 이 때 관리자는 웹 ACL 에 포함되어 있는 규칙에 순서를 지정할 수 있게 되는데 AWS WAF는 관리자가 지정한 이 순서에 따라 정책 검사를 수행합니다. 또한, 규칙의 Action 이 허용 혹은 차단인 경우 특정 규칙에 사용자의 HTTP 요청이 매칭되는 경우 AWS WAF는 다른 규칙에 대해 더이상 정책 검사를 수행하지 않고 정의된 Action 에 따라 “허용” 또는 “차단” 을 수행하게 됩니다.
단, 규칙의 Action 이 “개수(Count)” 인 경우에는 해당 규칙에 사용자 요청이 매칭되더라도 다음 순서의 규칙에 대한 검사를 계속 진행하게 됩니다. 따라서, 새로운 규칙을 생성한 후 적용하거나 기존의 규칙 설정을 변경하는 경우에는 의도하지 않은 사용자의 차단을 방지하기 위하여 일정 기간동안 “개수” 모드를 적용하여 해당 규칙의 정상 동작 유무를 확인하는 것이 중요합니다.
아래의 그림은 하나의 웹 ACL 에 두 개의 규칙 ( 규칙 A 와 규칙 B ) 와 함께 3개의 규칙이 포함되어 있는 규칙 그룹이 적용되어 있는 상태에서 AWS WAF가 규칙 검사를 수행하는 순서를 나타내고 있습니다. 웹 ACL 에 포함되어 있는 각각의 규칙과 규칙 그룹은 하나의 우선순위 값을 갖게 되며 “0” 이 가장 정책 검사 우선 순위가 높고 숫자가 높을 수록 정책 검사 우선 순위가 낮습니다. 또한 규칙 그룹 내의 개별 규칙도 마찬가지로 규칙 별로 우선순위 값을 갖게 되는데 이 우선순위가 갖는 정책 검사 우선 순위도 동일합니다.
이와 같은 우선 순위가 적용되어 있고 사용자의 요청이 모든 규칙에 매칭되지 않는다는 조건이라면 아래와 같은 순서로 사용자의 요청이 AWS WAF에서 검사되게 됩니다.
사용자 요청 → Rule A → Rule B → Rule #1 in Rule Group → Rule #2 in Rule Group → Rule #3 in Rule Group
예를 들어, 사용자의 요청이 규칙 A 에 매칭이 된다면 AWS WAF는 규칙 A 의 Action 이 “개수”가 아닌 이상 규칙 B 를 포함한 기타 규칙에 대해 검사하지 않습니다. 만일 사용자의 요청이 규칙 A 에 매칭이 되고 규칙 A 의 Action 이 “개수” 라면 AWS WAF는 사용자의 요청에 대해 규칙 B 에 대해서도 검사를 진행하게 됩니다.
AWS WAF를 통한 로그 분석
여러분들은 AWS WAF에서 처리하는 사용자의 요청을 로깅 기능을 통하여 분석하실 수 있습니다. 따라서, AWS WAF 운영 과정에서 발생할 수 있는 오탐에 대한 처리 과정에서도 로깅 기능을 통해 필요한 정보를 얻을 수 있습니다.AWS WAF는 두 가지 로깅 기능을 제공합니다.
첫번째 방법은 AWS 관리 콘솔에서 직접 확인하실 수 있는 샘플 로깅이며 다른 하나는 Amazon Kinesis Data Firehose와 연계하여 Amazon S3 에 저장되도록 구성하실 수 있는 풀로깅(Full Logging) 방식입니다. 이와 같은 AWS WAF 풀로깅은 웹 ACL을 생성하면 기본적으로 비활성화 되어있지만,설정을 통하여 풀로깅을 활성화할 수 있습니다. 풀로깅을 활성화 하기 위해서는 접두사 aws-waf-logs-로 시작하는 이름을 사용하여 Amazon Kinesis Data Firehose를 생성하고 로그를 저장할 대상 위치를 선택한 뒤, AWS WAF웹 ACL에서 로깅을 구성할 수 있습니다. 로깅이 활성화가 되면 AWS 리소스로부터 요청을 받은 시간, 요청에 대한 세부 정보, 각 요청이 부합되는 규칙 등에 대한 상세한 기록이 대상 위치에 저장됩니다.
그럼 실제 로그 예시를 보도록 하겠습니다.
{
"timestamp": 1590388359830,
"formatVersion": 1,
"webaclId": "arn:aws:wafv2:ap-northeast-2:xxxxxxxx:regional/webacl/MyWAF/8e61f8a9-xxxx-4f78-b4f0-6862d36982b2",
"terminatingRuleId": "AWS-AWSManagedRulesCommonRuleSet",
"terminatingRuleType": "MANAGED_RULE_GROUP",
"action": "BLOCK",
"terminatingRuleMatchDetails": [
{
"conditionType": "XSS",
"location": "ALL_QUERY_ARGS",
"matchedData": [
"<",
"script"
]
}
],
"httpSourceName": "ALB",
"httpSourceId": "xxxxxxx-app/MyDVW-Appli-1G779GWG26KJQ/75f9xxxx052e6512",
"ruleGroupList": [
{
"ruleGroupId": "AWS#AWSManagedRulesCommonRuleSet",
"terminatingRule": {
"ruleId": "CrossSiteScripting_QUERYARGUMENTS",
"action": "BLOCK"
},
"nonTerminatingMatchingRules": [],
"excludedRules": null
}
],
"rateBasedRuleList": [],
"nonTerminatingMatchingRules": [],
"httpRequest": {
"clientIp": "54.xx.119.1",
"country": "KR",
"headers": [
{
"name": "Host",
"value": "mydvw-appli-1g779gwg26kjq-xxxxx.ap-northeast-2.elb.amazonaws.com"
},
{
"name": "User-Agent",
"value": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.138 Safari/537.36"
},
# ...중간 생략
],
"uri": "/vulnerabilities/xss_r/",
"args": "name=%3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E",
"httpVersion": "HTTP/1.1",
"httpMethod": "GET",
"requestId": null
}
}이 로그는 AWS WAF에서 제공되는 관리형 규칙 중 하나인 핵심 규칙 집합(CRS, Core rule set)에 의해 차단된 로그입니다. 특히 SQL injection 이나 Cross site scripting 공격 차단건에 대해서는 terminatingRuleMatchDetails 필드가 제공되어 요청의 어떤 부분 때문에 차단이 되었는지 명확하게 확인이 가능합니다. 또한, ruleGroupList 필드에는 요청을 차단한 세부 규칙과 규칙그룹에서 제외된 규칙들을 알 수 있습니다. 그 외에도 sourceId 나 httpRequest 등의 필드를 통해 요청에 대한 가시성을 얻을 수 있습니다.
AWS WAF를 통해 오탐 확인하기
자, 그럼 이제 여러분이 AWS WAF로그 분석이나 사용자의 피드백 등을 통해 오탐(False Positive) 항목이 있다는 걸 알았다고 가정해보겠습니다. AWS 관리형 규칙(AMR)은 가장 일반적인 보안 위협을 차단하는데 적합하지만, 애플리케이션 특성에 따라 SQL 주입 공격이나 XSS 등에서 오탐이 발생할 수 있습니다. 또한, 사용자 정의 규칙을 만들었다고 해도, 운영을 하다보면 오탐이 발견될 수 있습니다. 예를 들어 수정이 필요한 일부 애플리케이션은 악의적인 요청으로 보일 수 있는 요청을 사용할 수도 있습니다. 따라서, 원활한 서비스 운영을 위해서는 이러한 오탐을 방지해야합니다.
WAF 를 사용하는 환경에서 오탐이 발생하는 것을 예방하기 위해서는 개발 혹은 스테이징 환경에서 WAF 의 규칙을 Block 으로 전환하기 전 규칙을 먼저 테스트하는 것이 가장 좋습니다. 그리고 이와 같은 과정에서 규칙이 애플리케이션에 적합하다고 판단되면 관리 규칙을 카운트 모드로 배포하고 Amazon CloudWatch 지표, AWS WAF 샘플 요청 또는 AWS WAF 로그를 사용하여 지표를 검토합니다. 이를 통해 관리형 규칙에 속한 개별 규칙을 선택적으로 비활성화 할지 여부를 결정할 수 있습니다.
정상적인 사용자의 요청이 오탐에 의해 규칙 차단이 되는 것을 확인하기 위해서는 다음과 같은 방법을 사용할 수 있습니다.
- curl을 사용합니다. (예 :
$ curl -ikv http://example.com/[false positive]) 이때 [false positive]를 해당하는 오탐을 일으키는 사용자 요청으로 바꿔야 합니다. 응답은 “403 Forbidden” 오류입니다. - 웹 브라우저를 사용합니다. 예를 들어 “example.com” 도메인에서 “style==xxx” 오탐을 확인하는 경우 웹 브라우저에 “example.com/style==xxx”를 입력합니다. 응답은 “403 Forbidden” 오류입니다.
- AWS WAF에서 [Sampled request]을 확인합니다. 또는 get-sampled-requests 명령을 사용하여 샘플링된 요청 목록을 수신합니다. 샘플링된 요청 목록에서 오탐에 의한 요청 목록을 확인합니다. [작업]이 [차단]인지 확인합니다.
- AWS WAF로그를 확인하여 “terminatingRuleId“를 확인합니다. 자세한 내용은 로그의 “terminatingRuleMatchDetails” 섹션을 참조하십시오.
WAF 오탐 예외 처리 하기
오탐을 해결하는 가장 좋은 방법은 공격처럼 보이는 요청을 생성하는 애플리케이션 코드를 수정하는 것이지만, 이는 많은 시간과 노력이 소요될 수 있습니다. 또한, 이런 오탐 사례는 실제 공격 샘플에서 파생되어 AWS WAF관리 규칙에 추가가 된 것이므로 요청 시그니처를 변경하거나 제거하면 고객이 현재 차단 된 공격에 노출될 수 있어 오탐에 대한 단일 보고에 대한 응답으로 해당 요청 시그니처를 제거하지는 않습니다. AWS WAF에서는 이러한 오탐이 광범위한 문제인 경우 요청 시그니처 제거의 영향에 대해 오탐을 재평가하고, 업데이트를 할 것 인지를 결정합니다. 따라서 고객이 직접 WAF 규칙을 이용해 수정을 하기 위해서는 다음과 같은 예외 처리를 할 수 있습니다.
예 1: 관리형 규칙 그룹에서 특정 규칙 카운트 모드로 변경
규칙 그룹 내에 사용하고 싶지 않은 특정 규칙이 있으면 요청을 차단 하지 못하도록 “Override rules action”을 통해 특정 규칙을 항상 제외 할 수 있습니다. AWS WAF는 제외되는 규칙에 대해 일치하는 웹 요청을 계수하되, 다른 작업은 수행하지 않습니다. 규칙 그룹에서 지표가 활성화된 경우 이 상태의 각 규칙에 대한 개수 지표를 수신합니다. 이 방법으로 관리형 규칙 세트의 나머지 규칙들을 계속 사용할 수 있습니다.
예를 들어 AWS 에서 제공하는 Core rule set 과 같은 관리형 규칙세트를 적용했을 때 교차 사이트 스크립팅 특정 규칙에 의해 차단된 합법적인 URI 패턴인 ‘style=’가 있다고 가정합니다. 이 경우 오탐을 일시적으로 완화하도록 카운트 모드로 설정하여 차단 하위 규칙의 동작을 무시할 수 있습니다.
- AWS WAF콘솔에서 편집하려는 웹 ACL을 선택합니다.
- [Rules] 탭을 선택합니다.
- 규칙 목록을 보고자하는 규칙 그룹을 선택한 다음 [Edit]을 클릭합니다. 그러면 해당 규칙 그룹의 규칙 목록이 표시됩니다.
- 규칙 그룹에서 제외할 규칙에 대해 [Override rules action]을 선택합니다.
그러나 이는 해당 하위 규칙에 의해 차단 되던 실제 공격을 허용할 수 있습니다. 따라서 이 방법은 패턴이 여러개이거나 불분명한 경우 임시적으로 사용할 수 있습니다.
예 2 : AWS WAF 규칙에 NOT 문을 사용하여 예외 처리
URI 경로에서 크로스 사이트 스크립팅 규칙에 의해 차단 된 합법적인 URL 패턴 ‘style=‘가 있다고 가정합니다.’style=‘ URL 패턴에 예외를 포함하기 위해 추가 규칙을 정의하여 다음과 같이 차단을 재정의 할 수 있습니다.
BLOCK [XSS condition] AND NOT [String Match Condition on Path]
WAF 콘솔에서 시각화 에디터를 이용하면 ‘NOT’ 조건이 부정 중첩된 ‘AND’ 조건을 생성 할 수 없습니다. 따라서 JSON 에디터로 작성할 수 있습니다. 다음 WAF 규칙 문은 그러한 예를 보여줍니다. 이 방법은 SQLi 및 XSS 규칙과 모든 사용자 지정 규칙에 적용될 수 있습니다.
{
"Name": "XSSprotection",
"Priority": 0,
"Action": {
"Block": {}
},
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "XSSprotection"
},
"Statement": {
"AndStatement": {
"Statements": [
{
"XssMatchStatement": {
"FieldToMatch": {
"UriPath": {}
},
"TextTransformations": [
{
"Type": "URL_DECODE",
"Priority": 0
}
]
}
},
{
"NotStatement": {
"Statement": {
"ByteMatchStatement": {
"FieldToMatch": {
"UriPath": {}
},
"PositionalConstraint": "CONTAINS",
"SearchString": "style=",
"TextTransformations": [
{
"Type": "URL_DECODE",
"Priority": 0
},
{
"Type": "LOWERCASE",
"Priority": 1
}
]
}
}
}
}
]
}
}
} 예 3 : AWS WAF 규칙간 우선 순위 조정
또 다른 방법으로 오탐을 발생시키는 규칙 보다 우선순위를 높게하여(숫자를 낮게하여) 예외처리 규칙을 웹 ACL 에 적용할 수 있습니다. 웹 ACL에 여러개의 규칙이 적용되어있는 경우 실제로 AWS WAF는 각각의 규칙을 우선 순위에 따라 평가하게 되고 만약 hit 되는 규칙이 있으면 더이상 이후 규칙들을 평가하지 않고 검사가 끝나게 됩니다. 따라서 오탐 케이스와 일치하는 경우 트래픽을 허용하고 나머지 규칙의 평가를 중지 하도록 구성할 수 있습니다.
하지만, 이러한 접근 방식을 사용하면 허용(Allow) 규칙 때문에 애플리케이션이 공격에 노출 될 위험이 있습니다. 이 위험을 줄이기 위해 웹 ACL 규칙의 우선 순서에서 허용 규칙 전에 필요한 다른 규칙들을 더 높은 우선순위로 설정할 수 있습니다. 다음 규칙 구성은 그러한 예를 보여줍니다. 오탐 예외처리를 위한 false_positive_pattern 규칙이 Core rule set 규칙그룹보다 우선 순위가 높으면서도 flood 공격 방지 규칙과 블랙리스트 보다는 낮은 우선순위로 설정되어 있습니다.
마무리
AWS WAF를 이용하면 다양한 관리형 규칙과 커스텀 규칙, 그리고 보안 파트너가 제공하는 규칙 그룹을 이용해 쉽고 빠르게 웹 애플리케이션을 위한 방화벽을 구성할 수 있습니다. 이러한 WAF에 있어 인력, 시간, 그리고 비용의 효율적인 운영을 위해서는 오탐을 줄이는 것이 아주 중요합니다. 하지만 오탐 방지를 위한 예외처리는 자칫 애플리케이션이 잠재적인 공격이 노출 될 수 있으므로 주의가 필요합니다. 따라서, 효율적인 AWS WAF의 운영을 위해서는 지속적으로 변경되고 추가되는 웹 애플리케이션의 구조나 요청들에 대해 자동화된 방식을 통하여 AWS WAF의 규칙에 대해 검증하고 발견된 오탐에 대해 효율적으로 대응할 수 있는 체계를 구축하는 것이 무엇보다 중요합니다.
AWS WAF에 대한 더 자세한 내용은 웹사이트 및 AWS 개발자 가이드를 참고해 주시기 바랍니다.
– 신은수, Security Specialist 솔루션즈 아키텍트
– 조이정, 솔루션즈 아키텍트