AWS Protecting Workloads Workshops
Workshop - Protecting Workloads on AWS from the Instance to the Edge
원문 링크: https://github.com/aws-samples/protecting-workloads-workshop/
1. 실습 CloudFormation 생성
- AWS IAM 계정 생성 후 AdministratorAccess 권한 부여, 테스트용으로 모든 권한 부여합니다.
- 개인 계정 사용자이기 때문에 제공되는 리전중 하나를 선택하여 CloudFormaion을 사용하여 실습 리소스를 프로비저닝할 것입니다.
- 방금 생성한 IAM 계정으로 접속합니다.
- 서울 리전은 없기 때문에 저는 US-EAST-1 미국 동부 (버지니아 북부)를 선택하였습니다.
- 파라미터 옵션 값에서 신뢰할 수 있는 네트워크에 내 아이피와 /32 서브넷까지 입력합니다.
- 콘솔로 CloudFormation에 들어가서 CREATE_COMPLETE 상태를 확인합니다.
스택 에러
Resource handler returned message: "The runtime parameter of python3.6 is no longer supported for creating or updating AWS Lambda functions. We recommend you use the new runtime (python3.9) while creating or updating functions."런타임에서 사용하도록 지정한 파이썬 버전이 문제인 것 같습니다. 워크샵이 2년전 내용이라 파이썬 버전이 오래됬습니다.
람다에서 사용하는 파이썬 버전을 모두 변경 후 생성해야합니다. python 3.6으로 표시된 부분을 모두 3.8으로 변경해줍니다.
리소스 생성이 완료되면 클라우드 포메이션>생성한 스택>출력 탭을 클릭하여 ALB주소와 호스트 주소를 볼 수 있습니다.
레드팀 호스트 주소에는 스캐닝 툴이 존재하여 공격 테스트에 사용됩니다.
저 같은 경우는 해당 호스트 주소를 클릭해도 세션매니저 연결이 안되었습니다.
그래서 AWS콘에서 세션매니저에 들어가서 세션시작을 클릭합니다.
리소스는 총 세개가 생성되어 있으며 두개는 각 AZ별로 인스턴스 두개와 공격자용 인스턴스 하나가 생성되어있습니다.
공격자 호스트에서 runscanner 명령어를 입력하면 ALB쪽으로 자동으로 공격스캐너가 실행됩니다.
2. WAF 동작 방식
- 사용자 요청
- WAF-WebACL Rule Group(Rule1 > Rule2 > Rule3… )
- API Gateway or CloudFront or ALB
룰 셋팅에는 세가지 요소가 있습니다.
- Web ACL, Rule, Rule Group
- Rule Group은 AWS 마켓플레이스에서 제공하는 것을 사용하거나 사용자가 만들어서 사용할 수 있습니다.
3. WebACL 보호 리소스 유형
Web ACL을 생성한 후 하나 이상의 AWS 리소스와 연결할 수 있습니다.
AWS WAF Web ACL을 사용하여 보호할 수 있는 리소스 유형은 다음과 같습니다.
- Amazon CloudFront
- Amazon API Gateway API
- Application Load Balancer
습니다.
4. Rule 생성 및 테스트
공격스캐너를 사용하고 방어로직을 적용해봅니다. SQL Injection, XSS, LFI 등...
워크샵을 보시면 예제에 대한 솔루션이 있습니다.
해당 스캐너 결과를 보시면 페이로드와 응답코드가 함께 보입니다.
실습에서는 스캐너에 의해 실행되는 공격들에 대한 방어룰을 생성하는 대응방안을 배우게됩니다.
스캐너 실행 > 규칙설정 > 스캐너실행을 반복하면서 규칙을 테스트하시면 됩니다.
SQLi와 XSS에 대한 규칙을 설정하였더니 200OK에서 방화벽에 의해 차단함으로써 403 Forbidden으로 수정되었습니다.
이러한 공격 페이로드 방어 외에도 다음과 같이 비정상적 요청과 소스아이피를 탐지하여 차단도 가능합니다. 몇가지 특수한 경우에 대해서만 코멘트합니다.
이상 징후 감지 및 완화
비율 기반 규칙을 사용하여 각 발신 IP 주소에 대한 요청 비율을 추적하고 한도를 초과하는 비율의 IP를 차단하는 규칙 작업을 트리거합니다. 5분 시간 범위당 요청 수로 제한을 설정합니다. AWS WAF에서 계산하는 요청의 범위를 좁힐 수 있습니다. 이렇게 하려면 비율 기반 명령문 안에 다른 명령문을 중첩합니다.
몇 가지 일반적인 이상 패턴은 다음과 같습니다.
• 일반적으로 비정상적으로 증가된 요청 볼륨
• 특정 URI 경로에 대한 비정상적으로 증가된 요청 볼륨
• 특정 비 HTTP 상태 200 응답을 생성하는 비정상적으로 상승된 수준의 요청
• 특정 소스(IP, 지역)에서 비정상적으로 증가된 볼륨
• 사이트 양식에 대한 과도한 요청(5분 시간 범위 내에서 100개)을 제한하는 비율 기반 규칙을 구축합니다. /form.php
평판 목록, 방해 요청(선택 사항)
평판 목록(화이트리스트 또는 블랙리스트)은 가치가 낮은 요청을 필터링하고 서비스를 중지하는 좋은 방법입니다. 이를 통해 운영 비용을 절감하고 공격 벡터에 대한 노출을 줄일 수 있습니다. 평판 목록은 자체적으로 관리할 수 있습니다. 식별 가능한 행위자의 목록은 바람직하지 않다고 판단한 것입니다. 여러 가지 방법으로 식별할 수 있습니다.
• 소스 IP 주소
• 사용자 에이전트 문자열
• 하이재킹된 승인 또는 세션 토큰의 재사용,
• 애플리케이션에 분명히 존재하지 않지만 잘 알려진 취약한 소프트웨어 패키지인 경로에 대한 요청 시도(탐색)
• 일반적인 요청 서명(리퍼러, 사용자 에이전트 문자열, 콘텐츠 유형 등)
relevant statement을 사용하여 그러한 행위자의 블랙리스트를 작성하고 이를 일치시키고 차단하는 규칙을 설정하십시오. 예시 IP 기반 블랙리스트는 이미 샌드박스 환경에 존재합니다.
평판 목록은 제3자가 유지 관리할 수도 있습니다. AWS WAF 보안 자동화를 사용하면 IP 기반 평판 목록을 구현할 수 있습니다.
5. Amazon CloudWatch를 사용하여 WAF 모니터링 대시보드 구현
- CloudWatch 설정을 통해 비정상 요청이 들어온 요청의 시간대와 패킷량에 대해서 모니터링 가능합니다.
https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/
Example
• Allowed Requests vs Blocked Requests : 허용된 액세스(정상 최대 액세스의 2배) 또는 차단된 액세스(1,000개 이상의 차단된 요청을 식별하는 기간)가 급증하는 경우 경고를 보내도록 CloudWatch를 구성할 수 있습니다. 여기에서 아이디어는 알려진 DDoS(차단된 요청이 증가하는 경우) 또는 새로운 버전의 공격(요청이 시스템에 액세스하도록 허용된 경우)을 추적하는 것입니다.
• BytesDownloaded vs. Uploaded : DDoS 공격이 리소스를 고갈시키기 위해 엄청난 양의 액세스를 수신할 필요가 없는 서비스를 표적으로 하는 시기를 식별하는 데 도움이 됩니다(예: 하나의 특정 요청 매개변수 세트에 대해 MB의 정보를 보내는 검색 엔진 구성요소).
• ELB Spillover 및 대기열 길이 : 이러한 메트릭을 사용하여 공격이 이미 인프라에 손상을 입히고/또는 어떤 이유로 공격자가 보호 계층을 우회하고 보호되지 않은 리소스를 직접 공격하는지 확인합니다.
• ELB 요청 수 : 위와 동일, 공격자가 보호 계층 및/또는 CloudFront 캐시를 우회하는지 확인하여 손상을 식별하는 데 도움이 됩니다. 캐시 적중률을 높이기 위한 규칙 검토
• ELB Healthy Host : 다른 시스템 상태 확인 메트릭.
• ASG CPU Utilization : 공격자가 CloudFront/WAF뿐만 아니라 ELB 계층을 우회하는지 식별하고 공격의 손상 영향을 식별하는 데 사용합니다.
끝맺음 말
워크샵을 실습해보면서 WAF의 구조와 동작방식에 대한 이해, 테스트 방법, 실습을 진행하면서 해당 내용에 대해 간략하게 정리해 보았습니다. 상세 문서를 보면 봇설정만 뿐만 아니라 룰에 대하여 정교하고 다양한 방식으로 활용해 볼 수 있습니다.
Deep하게 들어갈 수록 어려운 서비스입니다. AWS WAF를 제대로 운영하기 위해서는 개발환경에서 충분한 테스트와 다양한 페이로드를 접할 필요가 있을 것 같습니다.
여유가 된다면 워크샵의 CloudFormation을 참고해서 직접 설계를 해보거나 CloudWatch의 모니터링 대시보드를 만들어 보는 것도 좋을 것 같습니다.
