[클라우드 보안] WAF DVWA 미니프로젝트 -상편-

클라우드 보안 상-중-하편 목록

https://raid-1.tistory.com/185

https://raid-1.tistory.com/189

https://raid-1.tistory.com/190

 

 

 

이론

 

참고 칼럼 https://techblog.woowahan.com/2699/

 

 

 

WAF란?

Web Application Firewall

HTTP(S) 요청을 모니터링하고 보호하는 웹 애플리케이션 방화벽

특정 공격 패턴(SQL Injection, XSS 등)을 차단, 특정 트래픽 패턴을 필터링 등을 할 수 있다

차단된 요청에 대해선 HTTP 403 코드로 응답한다

비용은 사용한 만큼 : 배포한 규칙 수와 애플리케이션이 수신한 웹 요청 수 기준

WAF 배포 가능한 리소스 : CloudFront, ALB, API Gateway, AppSync

 

일반적으로 이야기하는 방화벽(FW)과는 차이점이 있는데,

단순 방화벽(FW)은 TCP/IP 레벨에 포함된 정보들을 기반으로 차단 룰을 설정한다.

하지만 웹 방화벽은 웹 프로토콜 HTTP 정보를 바탕으로 차단 룰을 설정한다.

WAF는 웹 해킹 공격으로부터 웹 서비스를 전문적으로 보호하기 위해 탄생한 정보 보호 시스템이라고 이해할 수 있다.

그리고 침입 탐지, 차단 시스템(IDS/IPS) 와도 역할이 다르다.

FW, WAF, IDS/IPS의 역할을 정확히 구분하고 적절한 룰을 수립하여 운용하는 것이 중요하다.

따라서 이 중 하나의 솔루션을 사용하고 있다고 다른 보안 솔루션이 필요 없다는 생각은 잘못된 생각이다.

 

클라우드 환경에서의 WAF 구성

VPC 프록시 구성

먼저 알아볼 구성은 VPC내 설치형 WAF인데, 보통 설치형 WAF라 말하는 구성은 IDC 환경에서 Inline WAF구성과 유사한 구성입니다. 아래 그림과 같이 VPC 내에 프록시 형태로 구성할 수 있습니다.

[VPC Proxy 형태의 구성]

이 구성은 네트워크 흐름 상 중간에서 모든 L7 패킷을 검증한 뒤 Origin LB로 보냅니다. 이 구성을 선택하면 WAF의 리소스를 직접 관리할 수 있고 origin LB를 Private으로 숨길 수 있는 이점이 있습니다.
하지만 VPC내에 구성한 WAF 리소스 자체가 하나의 주요 장애 포인트가 될 수 있습니다. 이해를 돕기위해 이벤트와 같이 트래픽이 몰리는 상황을 가정해보겠습니다.
각 서비스팀에서 Origin 서버의 리소스는 스케일 아웃을 실시하였으나 만약, WAF 리소스는 평소와 같은 수준으로 유지한 채로 트래픽을 받게 된다면, WAF가 제대로 된 트래픽 처리를 하지 못하므로 장애가 발생합니다.
이러한 WAF에 의한 장애를 방지하려면 Origin Private ELB (WEB, WAS 리소스)와 함께 Public ELB(WAF ELB)의 리소스도 상시 모니터링을 하면서 이벤트, 공격에 대비해 확장성 정책 및 프로세스를 유연하게 적용해야 합니다.
또, WAF 장애가 발생했지만, 정확한 원인 파악이 바로 되지 않는 상황이라면 우선 WAF 우회 작업을 진행할 수 있습니다. WAF를 우회하기 위해 간단하게 DNS를 WAF에서 직접 Origin LB를 바라보도록 변경하거나, WAF의 자체 Bypass 기능을 사용할 수 있습니다.
하지만 이 구성에서는 Origin LB는 Private으로 구성하였기에 Public DNS가 바로 바라보는 게 불가능하므로 기능적으로 Bypass 작업을 수행해야 해서 이 부분을 고려하여 장애 대응 프로세스를 수립해야 합니다.

 

 

SECaaS구성

[SECaaS 형태의 구성]

위 그림에서 설명하는 구성은 비교적 쉽게 WAF를 도입하는 방법으로 SaaS 혹은 SECaaS 라고 불리는 형태입니다. 복잡한 구성 및 운용에 대한 부담 없이 간단하게 DNS 설정만으로 트래픽을 우회하여 비정상 웹 트래픽을 필터링할 수 있습니다.
하지만, SECaaS WAF를 제공하는 업체와의 네트워크 환경이 고려되어야 합니다.
예를 들어 서비스가 서울 리전을 사용한다면 같은 서울 리전을 통해 서비스를 제공하는 SECaaS WAF서비스를 선택하는 것이 Latency 측면에서 유리할 것입니다.
단점으로는 리소스 관리를 직접 할 수 없다는 점에서 장애가 발생했을 때, 트러블 슈팅 및 대응이 느려질 수 있고, 데이터 기밀성에 대한 문제가 있습니다.

서비스 아키텍처를 수립할 때 처음부터 이러한 보안을 위한 아키텍처를 고려하지 않았다면 위에서 언급한 문제점들 때문에 WAF를 바로 도입하거나 운영 계획을 수립하기 어려울 수 있습니다.
AWS를 사용한다면 앞서 알아본 두 가지 구성보다 더 간단하게 구성할 수 있는 WAF가 있습니다. AWS WAF가 바로 그러한데요.
AWS WAF는 WAF도입 시 위 구성상 문제점에 대한 고민을 해소해줄 수 있는 장점이 있습니다.

• Cloudfront나 ALB, API Gateway를 사용 중이면 바로 적용할 수 있다.
• 적용 대상과 동일 선상에서 동작하기에 네트워크 홉이 추가되지 않는다.
• 트래픽이 증가하는 상황에서 확장이 유연하다.
• 유지보수에 많은 노력이 들어가지 않는다.
• 장애 발생시 원복 시나리오가 간단하다.
• AWS WAF가 아키텍처상 유리할 수는 있지만 다양한 측면에서 상용 WAF보다 부족한 점이 많습니다. 하지만 AWS에서도 피드백을 받아 점차 이러한 부분들을 개선하려는 노력이 보이네요.

 

WAF를 어디에 연동할까?

AWS WAF는 Cloudfront와 ALB, API Gateway에 연동할 수 있습니다. 이는 단순히 ‘선택지가 있구나’ 를 이야기하는 것은 아닙니다. 어느 곳에 연동하는 것이 보안 측면에서 더 나을지 고민해야 합니다.

Cloudfront는 AWS에서 제공하는 CDN 서비스 입니다. 관점에 따라서 다를 수 있겠지만, 필자는 보안 측면에서 AWS WAF를 Cloudfront에 연동하는 것이 더 유리하다고 생각합니다.
트래픽 급증은 이벤트와 같은 예측된 상황에서도 발생하지만, DDoS와 같은 상황에도 발생합니다. Volumetric 한 DDoS 공격에 대한 대비를 위해서라도 Cloudfront의 Global edge를 통해서 DDoS 공격이 처리된 후 VPC내에 트래픽이 유입되는 게 더욱 유리합니다. 그리고 L7을 겨냥한 DDoS도 있어 Cloudfront에 적용된 WAF에서 적절한 임계치 룰과 L7 DoS 차단 룰이 적용되어 있을 테니, VPC에 부적절한 트래픽 유입은 적어집니다.

혹은 Cloudfront와 ALB 두 곳에 전부 WAF를 연동하는 방법이 있습니다. Cloudfront의 WAF는 L7 DoS및 임계치 조절, IP Blacklist 차단 규칙으로 WAF룰을 수립하고, ALB의 WAF는 웹 취약점 공격을 중점으로 룰을 구분하여 수립할 수 있습니다.

[Cloudfront + WAF 와 ALB + WAF를 함께 사용하는 구조]

보안 아키텍처를 선택할 때는 한 번 선택하면 다시 바꾸기 어려울 수 있으므로 여러 가지 사항을 사전에 고려해봐야 합니다. 국내 한정된 서비스라면 굳이 CDN이 필요하지 않은 서비스일 수도 있고 Cloudfront 비용도 무시할 수 없습니다. 그리고 위협 및 취약성, 장애 발생, 더 나아가 멀티 클라우드 가능성 등 보안만 고집할 게 아니라 여러 가지 IT 전반적인 상황을 고려하여 적절한 아키텍처를 선택할 수 있어야 합니다.

 

 

 

 

 

DVWA란?

Damn Vulerable Web Application

PHP와 MySQL로 만들어진 웹의 취약점에 대한 공격 및 방어 기술 교육에 사용되는 오픈소스 애플리케이션

 

 

 

 

 

AWS CloudFormation란?

Amazon Web Services 리소스를 모델링하고 설정하여 리소스 관리 시간을 줄이고 AWS에서 실행되는 애플리케이션에 더 많은 시간을 사용하도록 해 주는 서비스.

필요한 모든 AWS 리소스(예: Amazon EC2 인스턴스 또는 Amazon RDS DB 인스턴스)를 설명하는 템플릿(json, yml)을 생성하면 AWS CloudFormation이 해당 리소스의 프로비저닝과 구성을 담당한다.

AWS 리소스를 개별적으로 생성하고 구성할 필요가 없으며 어떤 것이 무엇에 의존하는지 파악할 필요도 없습니다. AWS CloudFormation에서 모든 것을 처리한다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

========================================================================================

 

실습 개요

웹 공격에 취약하도록 의도된 웹 애플리케이션(ALB와 연결)에 WAF를 사용해 방어 체계 구성

• 사전 리소스 구성은 주어진 CloudFormation 템플릿 사용
• 사전 리소스엔 DVWA용 Ubuntu 서버가 구성되어 ALB와 연결됨
• WAF의 로그는 Kinesis Firehose를 통해 S3 버킷에 전달됨
• DVWA 서버에 접속 후 모의해킹을 진행한 뒤, WAF를 사용해서 막아보는 식으로 진행
• WAF의 Rule은 AWS managed 사용과 직접 만드는 일 둘 다 진행

 

 

공식 aws 실습을 참고하였다.

https://sessin.github.io/awswafhol/overview/module1.html

 

 

1. 리전 확인

작업은 AWS 서울 (ap-northeast-2) 리전에서 이루어지므로 꼭 리전을 변경하고 진행하자.

 

2.EC2 키페어 생성

 

 

2. CloudFormation 템플릿 실행

 

템플릿을 통해 완성할 구성도는 다음과 같다.

 

 

 

 

 

원래의 스택 생성 과정은 아래와같은 모습으로,

어디서 사왔던지, 아래처럼 디자이너 툴로 드레그엔 연결 해서 자체 제작할 수도 있고, 엄청 다양한 샘플 중에 고를 수도 있다.

 

일단 지금 단계에선 템플릿을 제작할 실력은 아니니 다음과 같은 샘플을 사용해 진행하겠다.

AWS WAF ICN 랩용 AWS CloudFormation 템플릿.

EC2, Application Load Balancer 및 EC2의 일부 파일과 같은 AWS WAF용 일부 리소스를 생성해주는 템플릿을

추가하는  링크

리소스 생성 허용 체크를 한뒤 스택을 생성해보겠다.

 

템플릿에서 설계돼있는 내용들이 하나 하나 구성중이다.

진행상태는 아래와 같이 확인 가능하다.

 

완료됐을때 쯤 새로고침 해주면 아래와 같이 설계서 (템플릿) 대로 구축된 목록들이 보여지고 초록색 완료라고 뜬다.

 

※ 참고로,

DVWA 생성에 사용된 템플릿은 별도의 VPC 와 EIP 등을 추가로 생성하므로

기존에 사용하던 계정에 VPC 나 EIP 의 수가 한계에 도달한 경우 스택 생성이 실패하게 되므로 주의한다.

 

 

 

 

3. DVWA 환경 설정

EC2 매뉴에 가서 보면 새로운 ALB (Application Load Balancer)가 생성돼있다. 

 

해당 ALB 의 DNS 이름을 이용하여 인터넷 브라우져에서 접속한다.

DVWA 서버에 접속했다.

“ID = admin”, “Password = password” 를 입력하고 다음과 같이 DVWA 에 정상적으로 로그인이 되는 것을 확인한다.

 

 

본 실습에서 생성된 DVWA 서버는 기본적으로 주요 취약점을 사용할 수 없는 환경으로 설정이 되어 있다.

따라서, 실습 진행과정에서 공격을 쉽게 수행하기 위해서는 DVWA 의 Security Level 설정을 변경해주어야 한다.

(레벨별로 공격하는 방법이 다르다)

• DVWA 에 접속한 후 다음과 같이 화면 하단의 “DVWA Security” 메뉴를 클릭
• “Impossible” 을 “Low” 로 변경한 후 “Submit” 

 

 

 

 

 

4. CHROME EXTENTION 설치

 

Browsec VPN 설치

AWS WAF 에서는 국가별 공인 IP 를 기준으로 트래픽을 허용/차단 하는 기능을 제공하고 있다.

랩 과정에서 지정된 국가를 차단하는 환경을 가상으로 구성하기위하여 Chrome 에서 사용할 수 있는 “Browsec VPN” 을 설치하도록 한다.

Chrome Store 

설치된 Browsec VPN Exntension 은 이후 실습 과정에서 브라우저의 출발지 국가 정보를 변경하여 AWS WAF 의 국가별 차단 기능을 점검하는데 사용된다.

 

User-Agent Switcher 설치

AWS WAF 에서는 웹 요청의 user-agent 헤더를 기준으로 트래픽을 허용/차단 하는 기능을 제공하고 있다.

랩 과정에서 특정 user-agent 값을 차단하는 환경을 가상으로 구성하기위하여 Chrome 에서 사용할 수 있는 “User-Agent Switcher” 을 설치하도록 한다.

Chrome Store 

설치된 User-Agent Switcher Exntension 은 이후 실습 과정에서 브라우저의 요청 user-agent 헤더를 변경하여 AWS WAF 의 헤더 필터 기능을 점검하는데 사용된다.

 

 

 

 

5. AWS WAF WEB ACL 구성

웹 공격을 방어하기 위한 AWS WAF 를 구성해본다.

AWS WAF 를 구성하는 방법은 여러가지가 있지만 본 실습에서는 초기 Web ACL 을 먼저 생성한 후

이후 각 공격 유형별로 Rule 을 생성하여 Web ACL 에 계속 추가해보도록 하겠다.

 

※ 현재 AWS WAF 는 기존에 제공되던 AWS WAF 메뉴와 함께 새로운 AWS WAF v2 메뉴가 제공되고 있다.

본 실습에서는 AWS WAF v2 를 기준으로 진행되기 때문에 반드시 새로운 AWS WAF 메뉴를 선택한 후 진행한다.

 

 

Rule 설정은 이후 과정에서 진행할 것이므로 그대로두고\

화면 하단의 “Default Action” 이 “Allow” 로 되어 있는 것을 확인한 후 “Next” 버튼을 클릭한다.

쭉쭉 넘겨서 web acl을 생성해준다.

 

 

 

6.AWS WAF 로깅 활성화

 

AWS WAF는 Amazon Kinesis Firehose를 사용하여 로그를 저장한다. (사실 WAF는 Kinesis Firehose로밖에 못보냄)

이를 통해 Amazon S3, Amazon Redshift 또는 Amazon Elastic Search와 같은 모든 Kinesis Firehose 대상으로 로그를 전달하고 또 분석할 수 있다.

웹 ACL에서 요청을 로깅하려면 먼저 Kinesis Data Firehose를 생성해야 하는데,

앞서 이미 CloudFormation 스택을 통해 Kinesis Firehose와 최종 대상인 S3 bucket을 생성했다.

이미 Firehose와 S3 버킷은 서로 연결되어 있다

 

참고로 AWS WAF에서 kinesis로 로그를 스트리밍하기 위해서는

접두사 aws-waf-logs-로 시작하는 이름을 사용하여 Amazon Kinesis Data Firehose를 생성해야한다.

 

다시 WAF - Web ACL - 서울리전 고르기 - MyWAF 선택 (생성시 이름) - Logging and metrics - enable로 바꿔준다.

Amazon Kinesis Data Firehose Delivery Stream에서 CloudFormation으로 자동생성된 “aws-waf-logs-test”를 선택

하기의 Redacted fields에서는 필요없다고 생각되는 필드인 “Query string“을 클릭

Logging이 Enable된 것을 확인

 

이제 다음 단계부터 진행할 공격 테스트 및 차단 테스트는 모두 kinesis firehose를 타고 S3 버킷에 쌓이게 된다.

 

 

 

클라우드 보안 WAF DVWA 미니프로젝트 -중편- 에 이어서 공격테스트를 진행해보도록 하겠다.