AWS WAF (Web Application Firewall)
-웹 어플리케이션 방화벽으로 웹 공격으로부터 보호하고, 트래픽 가시성을 제공하며,
서비스별 보안 정책에 따라 비인가적 행위를 탐지하거나 차단하는 역할을 담당한다.
- SQL 인젝션, 크로스 사이트 스크립팅(XSS) 등 다양한 웹 기반 공격으로부터 보호하며, 사용자 정의 규칙을 설정하여 트래픽을 제어할 수 있다.
- 공식 문서에는 AWS WAF에 보호된 리소스가 HTTP(S) 웹 요청에 응답하는 방식을 제어한다고 되어있다.
즉 HTTP 기반인 AWS 리소스가 WAF를 사용할 수 있다.
CloudFront( 엣지로케이션에 함께 존재 ) , ALB 및 API Gateway(리전서비스이므로 각각의 리전에 배치) 등 AWS의 다른 서비스와 통합해서 사용
- WAF는 크게 웹 ACL, 규칙, 규칙 그룹이라는 3가지 요소로 구성되어 있다. 웹 ACL은 AWS WAF의 핵심 구성 요소로, 트래픽을 필터링하고 관리하는 역할을 한다. 웹 ACL은 웹 애플리케이션에 대한 요청을 평가하고, 이를 기반으로 허용(Allow), 차단(Block), 모니터링(Count) 등의 동작을 수행한다.
구성요소
① Web ACLs
- 규칙 그룹이나 개별 규칙을 포함하는 AWS WAF의 보안 정책의 모음( AWS 리소스 집합을 보호하기 위한 논리적인 단위 )
-Web ACL 생성 - 그 안에서 보호할 리소스 지정(연결) - 규칙 추가
-규칙들 간의 우선순위 지정가능
- CloudWatch metrics 지정 (allow,deny,count 요청 수나 각 rule group에 전달된 요청의 수 등 볼 수 있다 )
② Rule (규칙)
-웹 ACL을 이루는 구성 요소 중 하나로 AWS WAF의 보안 정책
- 사용자 지정 정책을 사용하는 경우 IP 매칭, 국가별 매칭, 문자열 매칭, SQL 주입 공격 매칭, XSS (Cross Site Scripting) 공격 매칭 등을 사용할 수 있으며 AWS 관리형 규칙이나 보안 파트너가 판매하는 관리형 규칙을 사용할 수 있다.
/*
Allow: 요청을 허용.
Block: 요청을 차단.
Count: 요청을 기록만 하고 차단하거나 허용하지 않음.
Captcha/Challenge
: CAPTCHA 또는 추가 인증
*/
③ Rule Groups ( 규칙 그룹)
- 규칙의 조합으로 웹 ACL 에 포함되는 규칙들이 서로 다른 웹 ACL 에서 반복적으로 사용 되는 경우를 위해 웹 ACL 에서 참조하여 사용
-재사용 가능한 커스텀 규칙을 저장하는데 사용
-여러 Web ACL에 걸쳐 동일한 규칙을 사용하게 되는 경우 재사용 가능한 규칙들을 따로 만들어서 관리할 수 있다.
아래 요소들은 미리 정의를 해놓고 Web ACL이나 Rule Group 내부에서 규칙을 만들 때 선언해서 사용한다.
④ IP sets ( IP 세트)
-규칙문에서 사용되는 IP 주소 및 범위
-허용하거나 차단하고자 하는 IP 주소 집합으로 CIDR 을 기준으로 설정
- IP Address Header 나 관리자가 지정한 HTTP Header 의 값을 검사하여 IP 주소 정보를 추출
⑤ Regex pattern sets (정규 표현식 세트)
-규칙문에서 사용되는 정규 표현식 모음
- 허용하거나 차단하고자 하는 문자열의 집합으로 정규표현식을 기준으로 설정
- 관리자가 지정한 HTTP Request 영역에서 지정된 변환 원칙에 따라 문자열을 추출
WAF 규칙적용방법
- 지속적으로 보안 규칙을 모니터링하고 개선할 수 있어 보안의 자동화가 가능 - 애플리케이션에 맞는 보안 규칙을 손쉽게 작성하고 적용할 수 있다.규칙 적용 방법으로는 Amazon의 관리 규칙 세트, 커스텀 규칙의 작성, 그리고 AWS의 보안 전문 파트너의 규칙 세트 구매 및 적용이 있다.
① 관리형 규칙세트 ( Amazon Managed rule)
출처 : https://docs.aws.amazon.com/ko_kr/waf/latest/developerguide/aws-managed-rule-groups-list.html
-아마존이 구축한 안전성을 기반으로 하여 규칙 세트를 제공되며, PHP, 워드프레스, SQL 인젝션 등 특정 애플리케이션의 성격에 맞는 규칙 그룹을 포함한다.
-오탐이 발생하는 세부룰에 대해서만 예외처리 가능하다.
② 커스텀 규칙 (Custom rule)
-어플리케이션 성격에 맞는 규칙을 정의하거나 관리 중인 규칙그룹에서 오탐(false-positive)이 발생해서 예외처리 해야하는 경우 커스텀 규칙을 작성
-검사요소(헤더,메소드,쿼리 문자열, 바디 등) 와 일치 조건 (문자열,IP,정규식패턴 등) 을 조합해서 규칙문을 만든다.
- 허용(allow) , 차단(deny) , 혹은 규칙 테스트를 위해 실제로 차단하지 않고 카운트만 하는 count 모드로 배포
-규칙들은 AND,NOT,OR 등으로 서로 중첩기 가능하며 최종적으로 JSON 형식으로 표현된다.
③ 마켓플레이스 (AWS Marketplace)
-AWS에 다양한 보안 전문 파트너들이 판매하는 규칙 세트 구매
규칙 작동방식 설명
- 우선순위대로 적용이 되며 HIT 가 되는 규칙이 있다면 검사를 마친다.
- HIT가 되는 규칙이 없을 때 취하는 action이 allow 라고 가정하였을 때 각각의 규칙은 우선순위에 따라서 평가
우선순위 예시)
Manged Rule Group ( 관리형 규칙 세트 ) -> Custom Rule 1 -> Custom Rule 2 -> Custom Rule Group ( 다른 커스텀 규칙들을 모아놓은 규칙 그룹 ) -> default action : allow ( HIT 되는 규칙 없으면 최종적으로 allow) -> Cloudfront
count 모드는 사용자 요청에 대해 로그에 저장하지만 allow나 deny하지 않고 하위 우선순위로 규칙을 넘긴다.
실제 WAF 운영 예시)
1. 새로운 리소스에 적용된 룰이 적합한지를 검토하기 위해 전체 룰을 탐지 후 로깅하도록 설정하여 1~2주 정도 모니터링(count)한다.
2-1. 이후 이상이 없을 경우 예외처리조건이 없는 web ACL로 연동한다.
3-1.특정 룰에 대해서 오탐발생 혹은 수정이 필요한 경우는 새로운 web ACL을 만들어 연동하고 예외처리를 필요하지 않은 정책만 block 적용한다.
3-2.오탐이 발생하는 사유가 근시일내에 수정 가능하면 다시 원래의 web ACL로 이동하고
근시일내에 수정이 어려운 경우는 count 모드로 예외처리하고 cloudwatch 등을 활용하여 사전절차에 따라 이상증상을 모니터링하고 발생 시 조치를 가능하게 한다.
WAF 로그 저장 및 운영
S3 나 Cloudwatch에 저장할 수 있고 Kinesis Data Firehose에도 저장할 수 있다.
Amazon Data Firehose ( (구) Kinesis Data Firehose) 를 사용하면 Lambda 를 연동해서 로그 데이터를 가공할 수 있다.
위의 워크플로우는 Athena ( 표준 SQL을 사용하여 Amazon S3의 데이터를 분석하는 데 사용할 수 있는 대화형 쿼리 서비스 )를 활용하여 AWS WAF 로그가 저장된 S3 버킷에 연결하고 AWS WAF 로그를 쿼리하는 방식을 활용한 예시이다.
- 애플리케이션 사용자가 애플리케이션에 요청을 합니다.
- AWS WAF는 수신 요청에 대한 정보를 캡처하여 Amazon Kinesis Data Firehose로 보냅니다.
- Kinesis Data Firehose는 로그를 저장할 Amazon Simple Storage Service(Amazon S3) 버킷으로 전달합니다.
- 운영 팀은 Amazon Athena를 사용하여 SQL 쿼리로 로그를 분석합니다.
- Athena는 S3 버킷의 로그를 쿼리하고 쿼리 결과를 표시합니다.
- 운영 팀은 쿼리 결과를 사용하여 적절한 AWS WAF 속도 기반 규칙을 결정합니다.
출처 : https://aws.amazon.com/ko/blogs/tech/three-most-important-aws-waf-rate-based-rules/
라벨
AWS WAF에서 처리한 HTTP Request 에 대해 관리형 규칙에 의해 자동으로 부여되거나 관리자에 의해 수동으로 부여되는 속성값이다.
- Label 을 사용하면 AWS WAF 에 로그를 저장할 때 Label 이 적용된 Log Filter 를 사용하면 특정 규칙에 매칭된 트래픽에 대해만 로그를 기록하는 것이 가능하다.
- Label 을 사용하면 AWS 관리형 규칙을 사용하는 환경에서 특정 사용자 요청에 대해 관리형 규칙에서 오탐이 발생하는 경우 이를 예외 처리하는데 좀 더 효율적인 설정이 가능진다.
일정한 규칙에 따라 자동으로 생성되거나 관리자가 사용자 정의 Label 을 생성하여 사용할 수 있다.
1) 사용자 정의 Label
사용자가 임의의 값을 입력하여 AWS WAF 규칙에 매칭되는 HTTP Request 에 부여할 수 있는 Label
awswaf:<entity owner account id>:<entity type>:<entity name>:<custom namespace>:...:<label name>
예시 ) awswaf:111122223333:rulegroup:testRules:testNS1:testNS2:LabelNameA
2개의 Namespace(testNS1, testNS2)를 포함하는 Label(LabelNameA)
2) 관리형 규칙 Label
관리형 규칙 Label 은 사용자가 임의로 설정할 수 없으며 각 관리형 Rule Group 에 설정되어 있는 Label
awswaf:managed:<vendor>:<rule group name>:<custom namespace>:...:<label name>
예시 ) awswaf:managed:aws:core-rule-set:NoUserAgent_Header
3) 관리형 규칙 Process Label
awswaf:managed:<process>:<custom namespace>:...:<label name>
관리형 규칙 Process Label은 AWS 관리형 규칙 그룹을 사용하는 경우에 적용되는 관리형 Label
다음은 라벨 활용방법 중 하나이다.
로그메세지를 활용하여 라벨을 확인한 후 해당 라벨을 count 처리하여 규칙에 매칭되더라도 차단하지 않고 나머지 규칙에 대한 검사를 계속 수행하게 된다.
실습준비
https://sessin.github.io/awswafhol/
본 실습은 위의 링크의 CloudFormation 스택을 사용하여 실습하였다.
스택 생성이 완료되면 ALB 생성 및 DVWA 서버가 구축되어있다.
WEB ACL 과 Regional resources를 클릭하고 가지고 있는 ALB 리소스를 연결시킨다.
Default action은 Allow 로 설정하였다.
로깅 목적지는 Firehose stream으로 설정
Redacted fields는 로그에서 민감하거나 불필요한 데이터를 보이지 않도록 처리하는 것이다. 쿼리스트링으로 지정하였다.
Logging 탭에서 로그기록을 활성화 되어 있고 Query string 부분은 숨겨진다고 표시되어 있다.
공격테스트
1) 관리형 규칙세트 ( Amazon Managed rule) 적용 테스트
1) SQL Injection (Low) 설정하여 공격 테스트 결과 모습이다.
2) XSS (Low) 설정하여 공격 테스트 결과 모습이다.
Rules 탭 - Add rules - managed rule groups로 들어간다.
Free rule group에서 Core rule set과 SQL database 부분을 WEB ACL에 추가한다.
참고로 Edit을 누르면 rule set에 대한 설명이 나오고 version 및 rule action에 대해서 세부 설정할 수 있다.
action override 는 특정 규칙의 기본 동작을 무시하고 다른 동작으로 설정할 수 있다.
완료되면 rule 탭에 aws managed ruleset이 추가된 것을 확인할 수 있다.
다시 한번 SQL Injection과 XSS 공격 테스트 시 403 Forbidden으로 차단 된 것을 볼 수 있다.
2) 커스텀 규칙 (Custom rule) 적용 테스트
이번에는 Add my own rules and rule groups 로 들어간다.
싱가포르로 들어오는 출발지 IP에 대하여 Block 설정을 하는 룰을 만들었다.
크롬 확장프로그램으로 국가를 싱가포르로 선택 후 활성화시킨다.
홈으로 들어가기만 해도 403으로 차단되는 것을 확인할 수 있다.
이번에는 User Agent 헤더를 이용하여 Block 설정을 하는 룰을 만들었다.
iphone 문자열이 들어가면 차단시키는 룰이다.
크롬 확장프로그램으로 User Agent를 iphone 6로 선택 후 활성화시킨다.
마찬가지로 403 페이지가 발생하는 것을 볼 수 있다.
3) JSON 파일로 넣은 커스텀 규칙 (Custom rule) 적용 테스트
이번에는 콘솔이 아니라 직접 JSON 을 직접 작성하서 차단시키는 룰을 적용시킬 것이다.
JSON 문서를 설명해보면
가장 상단은 요청 샘플을 수집하고 Cloudwatch 메트릭을 기록하며 메트릭 이름은 TestRule로 한다는 내용이다.
중단부는 AndStatement로 하위 조건이 참이어야 룰이 적용되게 하였으며 1. KR에서 온 요청이면서 2. OrStatement 조건이 참이어야 차단된다.
2. OrStatement가 발동되려면 ①100바이트보다 크거나 ②x-vlaue 헤더가 bot으로 포함되어 들어오는 둘 중 하나의 조건이 정확히 일치하면 발동된다.
이전에 적용했던 룰을 다 지우고 테스트룰을 적용하였다.
공격자가 공격한 것처럼 X-VALUE 헤더에 bot 문자열을 넣어 공격을 진행하였다.
{
"terminatingRuleId": "TestRule",
"terminatingRuleType": "REGULAR",
"action": "BLOCK",
"httpSourceName": "ALB",
"httpRequest": {
"clientIp": "MY IP",
"country": "KR",
"headers": [
{
"name": "Host",
"value": "mydvwa-appli-hclivbeb76k9-1234.ap-northeast-2.elb.amazonaws.com"
},
{
"name": "User-Agent",
"value": "curl/8.0.1"
},
{
"name": "Accept",
"value": "*/*"
},
{
"name": "x-value",
"value": "bot"
}
],
"uri": "/",
"args": "REDACTED",
"httpVersion": "HTTP/1.1",
"httpMethod": "GET",
"requestId": "1-7750e3aa-03cd374b1692767f5099c695"
},
"labels": [
{
"name": "awswaf:clientip:geo:country:KR"
},
{
"name": "awswaf:clientip:geo:region:KR-11"
}
]
}
위 요청에 대한 S3에 저장된 로그 값은 위와 같다.
block되었고 x-value 값이 bot으로 설정된 것을 볼 수 있다.
해당 로그에서 룰 ID 와 라벨에 대한 정보도 확인할 수 있다.
/*
민감한 정보로 보이는 정보는 일부 잘라내거나 편집했다.
*/
공격자가 공격한 것처럼 POST 메소드로 key-value 형태의 긴 문자열의 데이터를 본문에 담아 전송하였다.
{
"terminatingRuleId": "TestRule",
"terminatingRuleType": "REGULAR",
"action": "BLOCK",
"httpSourceName": "ALB",
"httpRequest": {
"clientIp": "MY IP",
"country": "KR",
"headers": [
{
"name": "Host",
"value": "mydvwa-appli-hclivbeb76k9-1234.ap-northeast-2.elb.amazonaws.com"
},
{
"name": "User-Agent",
"value": "curl/8.0.1"
},
{
"name": "Accept",
"value": "*/*"
},
{
"name": "Content-Length",
"value": "182"
},
{
"name": "Content-Type",
"value": "application/x-www-form-urlencoded"
}
],
"uri": "/",
"args": "REDACTED",
"httpVersion": "HTTP/1.1",
"httpMethod": "POST",
"requestId": "1-7750e3be-56e394eb0ac7543c43f311e7"
},
"labels": [
{
"name": "awswaf:clientip:geo:country:KR"
},
{
"name": "awswaf:clientip:geo:region:KR-11"
}
],
"requestBodySize": 182,
"requestBodySizeInspectedByWAF": 182
}
위 요청에 대한 S3에 저장된 로그 값은 위와 같다.
block되었고 180바이트로 요청 본문 크기가 100바이트를 초과한 것을 볼 수 있다.
sampled request 탭에서는 샘플링된 요청을 볼 수 있는데 여기서 내가 했던 공격도 확인할 수 있었다.
또한 실습을 진행했던 1~2시간 잠깐의 사이에 BG 국가의 IP에서 공격이 들어온 것도 확인할 수 있었다.
우측 상단에 metric name 별로 지정해서 확인할 수 있다.
참고
https://sessin.github.io/awswafhol/
https://www.youtube.com/watch?v=r84IuPv_4TI
https://www.youtube.com/watch?v=HTjOj4qM4Xo
https://www.youtube.com/watch?v=fweHx0vFCS8&t=1s
https://aws.amazon.com/ko/blogs/tech/three-most-important-aws-waf-rate-based-rules/
https://aws.amazon.com/ko/blogs/korea/aws-waf-operation-guide-rule-setting-and-false-positive/
https://aws.amazon.com/ko/blogs/tech/aws-waf-using-label-to-use-exception-rules/
'Cloud > AWS' 카테고리의 다른 글
| AWS KMS (3) | 2024.12.13 |
|---|---|
| S3 vs EBS vs EFS (0) | 2024.11.25 |
| VPC Endpoints & VPC (0) | 2024.11.23 |
| Autoscaling Group & ALB (0) | 2024.11.20 |
| IAM User가 아닌 EC2에 역할 부여 (0) | 2024.11.20 |