안녕하세요. 최근 CloudNet@ AWS Security Study를 진행하며 해당 내용을 이해하고 공유하기 위해 작성한 글입니다. 해당 내용은 ‘쉽게 적용하는 AWS 보안 레시피’ 책과 AWS Docs 내용을 기반으로 했습니다.
ELB
ELB를 통해 트래픽을 부하분산합니다. 아래 그림과 같이 ELB Owner/IAM User가 console, api, cli 등으로 ELB를 생성하게 되고 사용자 트래픽에 따라 ALB, NLB 등이 서버 앞단에 배치되어 트래픽을 부하분산해줍니다.
Overview of AWS Elastic Load Balancer (ELB)
여기에 도메인을 붙이기 위해 AWS route53 서비스를 사용하거나 인증서 발행을 위해 ACM 서비스를 사용해서 TLS 설정으로 보안을 강화해줄 수 있습니다.
ELB listener & SG 설정(SSL 터미네이션 반영할 경우)
- ALB는 listener에서 HTTP를 받아 HTTP로 넘겨줍니다
- ALB가 listener에서 HTTPS를 받아 웹 서버에는 HTTP로 전송하도록 설정합니다(SSL 터미네이션)
- ALB에서 SSL 터미네이션을 수행하였으므로 EC2 보안그룹에서는 HTTP만 사용하고 ALB로부터만 트래픽을 받기 위해 ALB 보안그룹의 ID를 소스로 지정합니다.
ELB Type
Kubernetes Ingress with AWS ALB Ingress Controller
Kubernetes Ingress with AWS ALB Ingress Controller
EKS 구성 시에도 컨테이너 내부로 통신을 위해 AWS Load Balancer가 필요하게 됩니다. EKS를 구성하면서 생성하게되는 AWS Load Balancer Controller는 Kubernetes 클러스터의 AWS ELB를 관리해줍니다.
즉, AWS ALB Ingress controller는 Kubernetes 사용자가 클러스터에서 ingress resource를 선언할 때마다 ALB와 필요한 AWS 리소스를 생성할 수 있도록 감시하는 역할을 합니다.
Ingress resource는 ALB를 사용하여 HTTP(S) 트래픽을 클러스터 내부로 라우팅해줍니다.
위 그림에 나타난 순서대로 Ingress 생성 절차를 살펴보면
- API 서버의 Ingress 이벤트 변화를 감시하다가 요구 사항을 충족하는 Ingress 리소스를 찾으면 AWS 리소스 생성을 시작합니다.
- Ingress 리소스에 대한 ALB가 생성됩니다.
- Ingress 리소스에 지정된 각 백엔드에 대해 TargetGroups 이 생성되게 됩니다.
- Ingress 리소스 지정된 모든 포트에 대해 리스너 가 생성됩니다. 포트를 지정하지 않으면 적절한 기본값( 80또는 443)이 사용됩니다.
- Ingress 리소스에 지정된 각 경로에 대해 Rule 이 생성됩니다. 이렇게 하면 특정 경로에 대한 트래픽이 TargetGroup생성된 올바른 경로로 라우팅됩니다.
Cloudfront
CloudFront에서 제공되는 콘텐츠의 보안을 위한 방법입니다.
- HTTPS 연결 구성
- 특정 지리적 위치의 사용자가 콘텐츠에 액세스하지 못하도록 차단
- 사용자가 CloudFront 서명된 URL 또는 서명된 쿠키를 사용하여 콘텐츠에 액세스하도록 요구
- 특정 콘텐츠 필드에 대한 필드 수준 암호화 설정
- AWS WAF를 사용하여 콘텐츠에 대한 액세스 제어
최근에 cloudfront ip range 관리형접두사 목록이 추가되서 cloufront 추가를 편하게 할 수 있습니다.
WAF
AWS WAF는 웹 공격으로부터 웹 애플리케이션이나 API를 보호하는 웹 애플리케이션 전용 방화벽입니다.
AWS WAF에서는 SQL Injection, XSS 등과 같은 공격 패턴을 차단하는 보안 규칙 및 사용자 정의의 특정 트래픽 패턴을 필터링하는 규칙을 생성하여, 웹 애플리케이션 트래픽을 제어할 수 있습니다.
이러한 AWS WAF를 CloudFront, ALB, API Gateway에 배포할 수 있습니다.[출처]
WAF 구성
- AWS WAF는 단계별로 Web ACL, Rule, Statement로 구성됩니다. 순서에 따라 상위 컴포넌트와 하위 컴포넌트로 구분 지을 수 있습니다.
(Web ACL > Rule > Statement)
WAF 실습
위 WAF Workshop 실습 내용입니다.
실습 환경 구성
1. AWS WAF WEB ACL 구성
미리 모듈1을 통해 취약한 웹 서비스 환경을 구성해둡니다.
실습 환경
- 아래와 같이 AWS WAF 메뉴에서 Web ACL 을 선택한 후 “Create Web ACL” 버튼을 클릭합니다.
2. 먼저 화면 중간의 “Resource Type” 을 “Regional Resources” 로 선택한 후 “Region” 을 “Asia Pacific(Seoul)” 로 선택하시기 바랍니다. Region 선택이 끝나신 후 “Name” 에 적당한 이름을 입력하시기 바랍니다. “Name” 을 입력한 후 TAB 을 누르시면 “Cloudwatch Metric Name” 이 Web ACL Name 과 동일한 이름으로 자동입력 됩니다.
3. 생성되는 WebACL 에 리소스를 할당하기 위하여 “Add AWS Resources” 버튼을 클릭합니다. “Add AWS Resources” 화면에서 이전 과정에서 생성되었던 ALB 를 선택한 후 “Add” 버튼을 클릭합니다.
4. 아래와 같이 ALB 가 정상적으로 추가된 것을 확인한 후 “Next” 버튼을 클릭합니다.
5. Rule 설정은 이후 과정에서 진행할 것이므로 그대로두고 화면 하단의 “Default Action” 이 “Allow” 로 되어 있는 것을 확인한 후 “Next” 버튼을 클릭합니다.
6. 설정된 Rule 없으므로 “Set Rule Priority” 에서 “Next” 를 클릭합니다.
7. “Configure Metrics” 에서도 “Next” 를 클릭합니다.
8. 지금까지 설정한 내용이 모두 맞는지 확인한 후 “Create Web ACL” 버튼을 클릭합니다.
9. 정상적으로 진행되었다면 아래 화면과 같이 새로운 Web ACL 이 생성되는 것을 확인할 수 있습니다.
2. AWS WAF 로깅 활성화
AWS WAF는 Amazon Kinesis Firehose를 사용하여 로그를 저장합니다. 웹 ACL에서 요청을 로깅하려면 먼저 Kinesis Data Firehose를 생성해야 하는데, 해당 실습에서는 이미 모듈 1. 에서 CloudFormation 스택을 통해 Kinesis Firehose와 최종 대상인 S3 bucket을 생성했습니다.
- 우선 Kinesis Firehose가 잘 생성되었는지 확인합니다. 다음과 같이 ‘aws-waf-log-‘로 시작하는 kinesis firehose delivery stream이 생성되어있는 것을 확인합니다.
2. 다시 WAF 콘솔로 돌아와 이번에는 로깅을 활성화합니다. WebACL “MyWAF” 에서 Logging and Metrics 탭으로 이동하여 Logging이 Disable되어있는 것을 확인하고 “Enable Logging”을 클릭합니다.
3. Amazon Kinesis Data Firehose Delivery Stream에서 CloudFormation으로 자동생성된 “aws-waf-logs-test”를 선택합니다.
4. 아래 Redacted fields에서는 필요없다고 생각되는 필드인 “Query string“을 클릭합니다. 이 설정으로 인해 로그에는 Query string값이 기록되지 않습니다. 설정이 끝나면 “Enable logging”을 클릭하여 저장합니다.
5. 다음과 같이 Logging이 Enable된 것을 확인할 수 있습니다.
- 이제 다음 모듈부터 진행할 공격 테스트 및 차단 테스트는 모두 kinesis firehose를 타고 S3 버킷에 쌓이게 됩니다.
- 이제 다음 모듈부터 진행할 공격 테스트 및 차단 테스트는 모두 kinesis firehose를 타고 S3 버킷에 쌓이게 됩니다.
공격 테스트
- 모듈2 참고
1. SQL Injection
- SQL Injection 공격이란 공격자가 취약점을 이용하여, 임의의 SQL 문을 주입시켜 데이터베이스 정보를 확인하거나 비정상 동작을 유발시키는 공격입니다.
2. Command Injection
- Command Injection 공격이란 공격자가 취약점을 이용하여, 임의의 명령어를 주입시켜 웹 서버의 정보들을 탈취하는 공격 기법입니다.
3. XSS Exploit
- Cross Site Script(XSS) 공격이란 공격자가 의도적으로 악성 스크립트를 웹 서버에 입력또는 출력될 수 있게 하는 공격 기법입니다.
AWS WAF를 이용한 방어
1. AWS MANAGED RULE 추가
- 새로운 Rule 을 Web ACL 에 추가하기 위하여 좌측의 AWS WAF 메뉴에서 Web ACL 을 선택합니다. 리전이 “Asia Pacific(Seoul)” 로 선택되어 있는 것을 확인한 후 하단의 Web ACL 리스트 중 이전 과정에서 생성한 Web ACL 을 클릭합니다.
2. 하위 메뉴 중 “Add managed rule groups” 메뉴를 클릭합니다. 이 메뉴를 선택하면 AWS Managed Rule 혹은 3rd Party 파트너가 제공하는 관리형 Rule Group 을 Web ACL 에 추가할 수 있습니다.
- 가장 상단의 AWS managed rule groups 를 클릭하면 적용가능한 rule group들이 나타납니다.
- Core rule set 과 SQL database 에 대해 “Add to web ACL”을 클릭하고 하단의 “Add rules”를 클릭합니다.
2. 적용한 Rule 테스트
- 적용한 Rule들이 정상적으로 동작을 하는지 확인하기 위해 앞서 모듈 1에서 구성했던 DVWA 웹에 접속해서 모듈 2에서 실행했던 SQL injection 과 XSS exploit를 재시도 해봅니다.
- 모든 설정이 정상적으로 이뤄졌다면 아래와 같이 이전 과정에서 차단되지 않았던 SQL injection 구문이 “403 Forbidden” 메시지와 함께 차단된 것을 확인할 수 있습니다.
추가적으로 살펴볼 것
Amazon CloudFront introduces Origin Access Control (OAC)
DDoS-resilient Best Practice
DDoS-resilient reference architecture
완화 기법 - DDoS 복원성에 대한 AWS 모범 사례
완화 기법 일부 형태의 DDoS 완화는 AWS 서비스에 자동으로 포함됩니다. 다음 섹션에서 설명하는 특정 서비스가 포함된 AWS 아키텍처를 사용하고 사용자와 애플리케이션 간의 네트워크 흐름의 각
docs.aws.amazon.com
blog migration project
written in 2022.9.18
https://medium.com/techblog-hayleyshim/aws-elb-cloudfront-waf-68d0f439c236
'IT > Infra&Cloud' 카테고리의 다른 글
| [aws] GuardDuty, Macie, Inspector (0) | 2023.10.29 |
|---|---|
| [aws] CloudWatch,CloudTrail,Config (0) | 2023.10.29 |
| [aws] KMS/CloudHSM (0) | 2023.10.29 |
| [aws] Systems Manager (0) | 2023.10.29 |
| [aws] S3 Security — 4. Create S3 pre-signed URL with validity period (0) | 2023.10.29 |