AWS WAF 란 무엇인가?
AWS WAF(Web Application Firewall)는 Application 가용성에 영향을 미치거나 보안을 손상시키거나 과도한 리소스를 사용할 수 있는 일반적인 웹 악용으로부터 웹 응용 프로그램을 보호하는 데 도움이 되는 보안 서비스입니다.
AWS WAF는 SQL 주입, 사이트 간 스크립팅(XSS) 및 요청 위조(CSRF)와 같은 가장 일반적인 웹 취약성에 대한 보호 기능을 제공합니다.
AWS WAF를 사용하여 Amazon CloudFront 배포, Amazon API Gateway API 또는 애플리케이션 로드 밸런서로 전달되는 HTTP 및 HTTPS 요청을 모니터링할 수 있습니다. 헤더, 쿼리 문자열 및 기타 요청 매개 변수의 값과 같은 지정된 조건에 따라 요청을 차단하거나 허용하는 규칙을 만들 수 있습니다. AWS WAF는 또한 클라이언트의 IP 주소 또는 지리적 위치 또는 클라이언트가 수행한 요청의 비율을 기반으로 요청을 차단하거나 허용하는 데 사용할 수 있습니다.
AWS WAF 로그 확인 방안은?
AWS WAF의 로그를 확인하는 방법은 여러가지가 있습니다.
1) Amazon CloudWatch: Amazon CloudWatch를 사용하여 AWS WAF에서 생성된 로그를 볼 수 있습니다. 이러한 로그를 보려면 AWS WAF 리소스에 대한 로깅을 사용하도록 설정한 다음 CloudWatch Logs Insights 쿼리를 생성해야 합니다.
2) AWS 관리 콘솔: 또한 AWS Management Console에서 AWS WAF에 의해 생성된 로그를 볼 수 있습니다. 이렇게 하려면 콘솔의 AWS WAF 대시보드로 이동하여 로그를 볼 리소스(예: 웹 ACL 또는 규칙)를 선택한 다음 "로그" 탭을 클릭합니다. 그러나 샘플링된 로그만을 확인할 수 있습니다.
3) AWS WAF API: AWS WAF API를 사용하여 AWS WAF 리소스에 대한 로그를 검색할 수 있습니다. 이를 위해 사용할 수 있는 API에는 GetSampledStatisticsSummary, GetSampledRequests 및 GetLoggingConfiguration이 있습니다.
4) AWS CLI(명령줄 인터페이스): AWS CLI를 사용하여 AWS WAF에서 생성된 로그를 볼 수 있습니다. 이렇게 하려면 aws logs description-log-streams 및 aws logs get-log-events 명령을 사용할 수 있습니다.
5) 마지막으로 WAF의 Full 로그를 확인하기 위해서는 Kinesis Data Firehose를 통해 가능합니다.
이 밖에 Application Load Balancer 로그에서도 WAF 관련 로그를 확인할 수도 있습니다.
(ALB의 로그 target:port 필드에서 WAF로 차단된 요청의 경우 "-"로 표시되며 상태코드는 403으로 분류)
Access Logs for Your Application Load Balancer - Elastic Load Balancing
The AWS Documentation website is getting a new look! Try it now and let us know what you think. Switch to the new look >> You can return to the original look by selecting English in the language selector above. Access Logs for Your Application Load Balance
docs.aws.amazon.com
그러나 기존 SIEM과 같은 황경에서 볼 수 있는 AWS WAF 서비스는 별도로 존재하지 않습니다.
따라서 ELK(Elastic Serach, Log stash, Kibana)와 같은 형태의 스택을 구성해서 AWS WAF 로그를 분석/필터링 해야 합니다. AWS 환경에서는 대부분 S3로 로그 데이터를 저장하기 때문에 AWS의 ELK 스택을 이용하는 것을 권장합니다. 추가로 AWS Athena와 같은 서비스를 이용해서 로그 분석도 가능합니다.
Athena를 사용하여 Load Balancer 액세스 로그 분석
기본적으로 Elastic Load Balancing은 액세스 로깅을 활성화하지 않습니다. 액세스 로깅을 활성화할 때 Amazon Simple Storage Service(Amazon S3) 버킷을 지정합니다. 모든 Application Load Balancer 및 Classic Load Balancer 액세스 로그는 해당 S3 버킷에 저장됩니다. 그런 다음 로드 밸런서의 문제를 해결하거나 성능을 분석하려는 경우 Athena를 사용하여 S3의 액세스 로그를
aws.amazon.com
Kinesis Data Firehose를 통해 AWS WAF Full 로그 확인(AWS 콘솔)
이번 글은 네 번째 방법(Kinesis Data Firehose)에 대해서 서술합니다.
각 Web ACL이 매핑된 객체(CloudFront, ALB, API G/W 등) 요청에 대한 트래픽 로그를 제공합니다.
로그를 수집하는 과정에서 Kinesis Data Firehose 서비스 설정이 필요하며, Kinesis Data Firehose의 제약사항(초당 레코드 수)를 고려해야 합니다.
Firehose delivery stream으로 전달된 레코드는 아래 4개의 Destination 중 원하는 객체에 적재할 수 있습니다.
- Amazon S3
- Amazon Redshift
- Amazon Elasticsearch Service
- Splunk
또한 위 과정을 통해 일부 레코드 포맷이나 일부 형식을 수정하는 것이 제한적으로 가능합니다.
추가로 Kinesis에 적재된 로그 데이터량에 따라 추가 과금이 발생됩니다.
그럼 실제로 AWS 콘솔을 통해 진행해보도록 합니다.
[AWS Management Console] -> [Kinesis] -> [Dashboard] -> [Create delivery stream]
이 때 리전 선택에 주의해야 합니다. Web ACL이 Global 타입인 경우 버지니아 리전을 선택해야 하고, Reginal 타입인 경우 동일한 위치의 리전을 선택해야 합니다.
그 다음 스트리명을 지정합니다.
이름은 규칙에 따라 반드시 "aws-waf-logs-"로 시작해야 합니다.
레코드 프로세스 규칙을 정의합니다.
필요 시 전달 과정에서 원본 레코드를 Lambda 함수를 통해 수정하거나 포맷 등을 변경할 수 있습니다.
저장될 스토리지를 선택합니다.
S3부터 Splunk 등 다양한 데이터 저장소를 지원하며, 이번 테스트는 S3를 지정합니다.
로그의 Prefix를 지정합니다.
설정한 경로 하위로 "YYYY/MM/DD/HH" 형슥(기본값)으로 키값이 추가됩니다.
그리고 S3의 버퍼 크기나 주기, 압축/암호화 설정을 합니다.
버퍼 크기의 경우 WAF 로그가 쌓이는 수준을 고려하여 설정합니다. 또한 로그임으로 GZIP 형태를 권장하고 암호화는 선택하지 않았습니다.
그리고 IAM role을 설정해야 합니다.
IAM role의 경우 "Create new or choose" 버튼을 선택하면, AWS에서 알맞은 Policy를 갖고 있는 Role을 생성해줍니다.
객체 생성이 완료된 후에 Status 값이 Active가 될 때까지 기다립다.
보통 해당 과정은 약 1분 전후로 완료됩니다.
그럼 다시 [AWS Management Console] -> [WAF & Shield] -> [Web ACLs] 로 WAF 화면으로 돌아갑니다.
"Logging" 탭으로 이동한 뒤에 Enalbe Logging을 선택해줍니다.
그럼 이제 이전에 생성한 Kinesis Data Firehose 객체와 매핑합니다다.
혹시 객체의 목록이 표시되지 않는 경우 이름이 "aws-waf-logs-"로 시작하는 지 다시 한 번 확인합니다.
또한 원하는 경우 로그에서 제외될 필드를 지정할 수 있습니다.
그럼 AWS WAF Full 로깅 설정을 완료할 수 있습니다.
이후에 선택적으로 해당 로그를 "Disable" 할 수 있습니다.
그럼 Kinesis Data Firehose의 모니터링 탭에서 로그 데이터가 정상적으로 유입되는 지 확인할 수 있습니다.
또한 S3에서도 정상적으로 로그 파일이 저장되는 지 확인해봅니다.
아래와 같은 형태의 로그를 확인할 수 있습니다.
{
"timestamp":1570770782134,
"formatVersion":1,
"webaclId":"cdedc3c5-609c-4c01-9813-21a87409a55b",
"terminatingRuleId":"Default_Action",
"terminatingRuleType":"REGULAR",
"action":"ALLOW",
"httpSourceName":"ALB",
"httpSourceId":"575930131594-app/demo/c6ca3914c8d05420",
"ruleGroupList":[
],
"rateBasedRuleList":[
],
"nonTerminatingMatchingRules":[
{
"ruleId":"b17bd560-7a1f-46ed-929c-d3ec7e3632e9",
"action":"COUNT"
},
{
"ruleId":"aa67843d-dcc3-49f4-aada-375f178e532c",
"action":"COUNT"
}
],
"httpRequest":{
"clientIp":“111.222.333.444",
"country":"KR",
"headers":[ ... ]
...
}
자세한 로그 내역은 아래 링크를 통해 확인할 수 있습니다.
Logging Web ACL Traffic Information - AWS WAF, AWS Firewall Manager, and AWS Shield Advanced
The AWS Documentation website is getting a new look! Try it now and let us know what you think. Switch to the new look >> You can return to the original look by selecting English in the language selector above. Logging Web ACL Traffic Information You can e
docs.aws.amazon.com
기존 SQL 인젝션, XSS 탐지 시에 어떤 스트링 값이 원인인지 알 수 없었으나, terminatingRuleMatchDetails 필터가 추가되어 탐지 원인을 일정 부분 확인할 수 있게 되었습니다.
탐지된 QueryString이나 Body 값을 확인할 수 있다.
AWS WAF, 일치하는 규칙과 관련된 컨텍스트에 대한 로깅 요청 개선
이 새 로그 필드는 화이트리스트에 올릴 문제 영역을 빠르게 식별할 수 있으므로 거짓 긍정 시나리오 문제를 해결하는 데도 유용합니다. 또한 악의적인 공격자가 자주 목표로 삼는 요청 내 영역도 찾을 수 있습니다. 기존 로그 스트림에 대해 이 새 필드를 활성화하는 데 추가 구성은 필요하지 않습니다. 새 로그 스트림의 경우 웹 ACL에서 로깅을 활성화하면 새 필드가 포함됩니다. 웹 ACL에서 로깅을 활성화하는 작업은 2단계로 구성됩니다. 먼저, Amazon Ki
aws.amazon.com
'Storage&CDN > WAF' 카테고리의 다른 글
| AWS WAF Rate-based Rules 사용하기(Brute force) (0) | 2019.12.24 |
|---|
