[Secworkshop] Protecting workloads on AWS

Scenario - Protecting Workloads on AWS from the Instance to the Edge (awssecworkshops.com)

Scenario - Protecting Workloads on AWS from the Instance to the Edge

 

이번 회차에서 알아볼 것은 AWS에서 웹 서비스를 제공하고 있을 때, 웹 서비스를 어떻게 보호할 것인가? 이다.

 

일반적인 기업 환경에서는 보통 DMZ에 대고객 서비스 제공을 위한 웹서버를 구축하고,

해당 웹서버를 보호하기 위해 SSL 암/복호화 솔루션 - WAF - IPS를 통해 외부 침입을 많이 막는다.

 

아직 AWS의 기능을 다 알지 못해서.. 내가 모르는 것도 있겠지만

AWS에서 IPS, SSL 암/복호화 솔루션의 기능을 제공하진 않는거 같고, WAF는 서비스로 제공하고 있다.

 

즉, 이번 workshop에서는 네트워크에서의 취약점 방어/모니터링 방안과 호스트단에서의 취약점 식별/조치 실습 이다!!

 

□ 실습 목적

1) AWS를 통해 웹서비스를 제공할 때, 악의적인 웹 공격을 방어 및 모니터링 할 수 있는 WAF 서비스를 구성한다.

2) Inspector + Patch Manager를 통해 서버 취약점을 식별하고 조치한다.

 

□ 실습 시나리오

1. ALB 뒤로 위젯 LLC 서비스를 제공하는 웹서버가 존재한다.

2. 초기 보안 취약점 평가에서 많은 취약점이 확인되었으나, 개발자가 부족해서 소스 수정이 불가능하다.

3. 웹서버를 보호하기 위한 수단을 구축하고 모니터링할 수 있는 체계를 만들어야 한다.

    1) WAF를 통한 네트워크단에서의 취약점 방어 및 모니터링 방안

    2) Inspector + Patch를 통한 호스트단에서의 취약점 식별 및 조치 방안

 

□ 실습 준비물

AWS WAF 서비스에 대한 이해 : AWS WAF 서비스 개념 및 메뉴설명 :: 평범한 직장인의 평범한 블로그 (tistory.com)

AWS WAF 서비스 개념 및 메뉴설명

 

□ 실습 목표 아키텍처

Private Subnet에 2대의 웹서버가 있고, 웹서버로 인입되는 악의적인 공격을 방어/모니터링하기 위해 AWS WAF를 구축하고

호스트단에서의 서버 취약점을 식별하고 이를 조치한다.

실습 목표 아키텍처

□ 실습 빌드

1. 먼저 실습에서 제공해주는 CloudFormation을 통해 실습 환경을 만든다.

Bulid Phase에서 [Click here if you're not at an AWS event or are using your own account] 를 선택하면 된다.

다양한 리즌에서 실습할 수 있는 환경을 제공하는데, 나는 east-1을 선택했다.

CloudFormation 출력 화면

CloudFormation Create가 다 끝난 다음에, 출력을 들어가보면 위와 같이 RedTeam과 Endpoint가 생긴다.

RedTeam을 웹서버 공격을 위한 Scanner이며, Endpoint은 실습을 위한 임시 웹서버이다.

 

Endpoint를 선택하면 아래와 같이 임시 웹서버 접속이 가능하다. 위 시나리오에서 말했던 위젯LLC이다.

WAF 실습을 위한 임이 웹서버

그리고 위의 RedTeam의 URI를 선택하면 AWS System Manager를 통해 RedTeam EC2의 SSH를 접속할 수 있다.

 ※ 본래 EC2의 SSH를 접속하려면 EC2의 보안그룹을 설정하고, SSH 키페어를 따로 등록하는 등의 번거로움이 있지만

    System Manager를 EC2에 연결하면 별도의 키페어 등록 없이 SSH 연결이 가능하다.

AWS System Manager

 

무튼.. CloudForamtion을 함으로써 환경 설정은 끝이 났다.

 

2. 위 출력에서 RedTeamHostSession URI을 선택하여, 생성되는 Session 창에서 "runscanner"를 입력하여

임시로 생성한 웹서버 대상으로 다양한 공격 Script를 실행한다.

runscanner 결과

runscanner를 입력하면 아래와 같이 임시로 만들었던 웹서버에 WAF Test 패킷이 발송된다.

WAF Test 시작

scanner에서 카나리아 GET,POST 요청부터 XSS, CSRF 등의 미리 정의 된 공격이 시작되고

200 OK 응답은 공격 성공, 403 Forbidden을 공격 실패로 보면 된다!

 

WAF Overview를 보면 [어떤IP]에서[어떤 URI]로 [몇시]에 요청이 있었고, [허용] 여부를 알 수 있다.

본 실습의 궁극적인 목표는 AWS WAF 기능을 통해 scanner의 공격을 차단하는 것이 주된 실습 과제이다!

scanner, WAF Overview

3. WAF Rule 생성하여 외부 공격 차단하기

AWS WAF 작동 방식

AWS WAF는 Web ACLs를 만든 다음에 하나 이상의 AWS Resource를 연결할 수 있다.

Web ACLs를 통해 보호할 수 있는 Resource는 AWS API Gateway, CloudFront, ALB 이다.

 

즉, 웹서버를 보호할 경우 각 웹 도메인마다 ALB 설정을 하고, 해당 ALB를 보호하는 개념이다.

 ※ 여기에서 좀 혼란이 왔다. Cloud를 사용하지 않는 환경이라면 WAF 솔루션에 IP/도메인 정보를 입력하여

    해당 도메인 주소를 갖는 웹서버를 보호하는 개념이다. 즉 LB는 아무런 연관을 하지 않는다.

    하지만 Cloud 환경에서는 ALB가 Public Subnet 영역에 존재하여 공인IP를 보유하고 있고,

    WAF ALB - WAF - ALB - 웹서버 Flow로 트래픽이 흐르며 웹서버 공격을 보호한다. 아마..

 

SQL Injection 등의 공격을 방지하기 위해, Web ALCs > Rule을 만들어야 한다.

아래와 같이 Match Type 부분에 AWS에서 제공해주는 Pattern을 통해서 Rule을 만들수도 있고

문자열 검사, Pattern 검사 등의 정규표현식을 사용하여 사용자 정의 Rule도 만들 수 있다.

AWF Rule 생성

또한, 특정 문자열이 포함되는 경우가 아니라 IP 기반의 임계치 설정 및 IP의 국가별로 차단 설정이 가능하다.

 

물론 IP 기반의 임계치 설정은 DDos 서비스에서도 탐지 또는 차단할 수 있겠지만,

DDos 보다는 조금 더 낮은 민감도를 사용하거나 특정 문자열이 포함 된 문자열에 대해서 가능하기 때문에 모니터링에 좋다.

 

4. 근본적인 취약점 해결을 위해 AMI 이미지에 대한 보안 취약점 점검을 하자.

이미지에 대한 보안 취약점 점검은 AWS Inspector 서비스를 이용하면 아주 쉽게 할 수 있다.

물론 실습환경에서는 CloudForamtion이 Inspector Group을 만들고, 실행하기 모두 해두었다.

Inspector 화면

위 Inspector를 누르면 DashBorad로 요약본 화면이 보이기 때문에, 

어떤 템플릿으로 어떤 EC2를 점검하고 점검 결과가 어떻게 나오는지 보기 위해서는 주요 기능에 나와 있는 메뉴를 선택해야 한다.

 

CloudFormation으로 아래와 같이 평가 대상 Group을 만들었고,

Preview Target을 선택하면 최초에 확인했던 EC2 3개가 Group으로 취약점 점검 대상으로 지정되어 있음을 알 수 있다.

Inspector Group

Insepctor Target

그리고 평가 템플릿을 선택하면, 평가 대상을 어떤 템플릿으로 취약점 점검 하는지 알 수 있다.

본 실습에서는 아래의 규칙 패키지 2개가 지정되어 있고, AWS에서는 4개의 패키지를 제공한다.

Inspector 평가 템플릿

보아하니, [Common Vulnerabilities and Exposures-1.1]는 CVE에 초점에 맞춰져있는 패키지이며,

[CIS Operating System Security Configuration Benchmarks-1.0]는 ISMS/전자금융기반시설 취약점 점검에 초점인것 같다.

 

금융권에 다니면서, 정기적으로 수행하는 것이 서버 OS 취약점 점검이다.

물론 AWS에서는 전자금융기반시설 + 금융보안원 취약점 안내 가이드가 딱 명시적으로 기재되어 있지는 앟지만

CIS가 그 수준에 맞는 취약점 점검 항목이며 정기적으로 취약점 진단이 가능하기에 아주 좋은 것 같다!

 

그리고 결과는 평가 실행 탭에서 아래와 같이 확인이 가능하다.

Inspector 결과 보기

AWS TEST 웹서버 inspector 결과.pdf

0.05MB

 

5. 서버 취약점이 확인됬다면, 패치를 통해서 조치를 해보자!

AWS System Manager의 패치 관리자로 취약한 서버 OS에 대한 취약점 패치를 할 수 있다!

 

1) 먼저 패치 기준을 만들어줘야 한다!

패치 기준 생성

실습 과정에서는 따로 구분 없이 모든 취약점 패치를 할 예정이지에 ALL을 선택한다.

물론 실제 업무에 사용할 때는 내부 규정 또는 유관조직과의 논의를 통해서 패치할 심각도 등을 조정하면 된다.

패치 기준 생성 2 

이후 패치 기준이 생성되면 패치 관리자 2페이지에 기본 기준이 없는 상태의 아래 신규 패치 기준이 생성 된다.

패치 기준 생성 3

우리는 ClodeFormation으로 생성한 EC2에 대해서만 패치를 진행할 예정이기에 패치 기준을 EC2의 Tag로 지정하면 좋다!

 

2) 패치 기본 그룹을 생성해야 한다.

패치 적용 그룹 1

EC2를 선택해서 Tag를 보면 아래와 같이 Stack name이 지정되어 있고

EC2 Tag 확인

패치 그룹에 Tag 정보를 기입함으로써 내가 원하는 Tag를 가지고 있는 EC2에 대해서만 패치를 할 수 있다.

인프라 입장에서는 패치가 아주 예민한 부분이다. 패치로 인해 서버 형상이 변경되기에 패치 이전에 영향도 파악이 중요하고

전체 시스템을 일괄적으로 패치하는 것이 아니라, 개발계 등 소수 서버에 먼저 적용한 다음에 패치하는 등의 작업 순서를 가진다.

 

이런 과정으로 본다면, 각 EC2 인스턴스마다 Tag를 지정하고, 해당 Tag만 패치하는건 아주 좋은 기능같다.

패치 적용 그룹 2

3) 시스템 패치 적용

위 1,2 과정으로 생성한 패치 그룹을 선택하고 지금 패치 적용을 누르면 패치가 적용 된다.

패치 결과는 노드 관리 > 명령 실행에서 볼 수 있으며, 패치가 다 완료되고 나면 명령기록에서 History를 볼 수 있다.

 

정상적인 경우 아래와 같이 패치 성공 명령을 볼 수 있고

 

패치 완료

명령 ID를 선택해서 보면 어떤 인스턴스에 패치를 했는지도 볼 수 있다.

아까 패치 그룹을 정할 때, 우리는 EC2를 직접 지정하지 않았다. 다만 Tag를 지정했을 뿐

Tag를 지정하니, 해당 Tag를 가지고 있는 EC2 Resource가 그룹핑 되었고, 해당 EC2에만 패치가 되었음을 알 수 있다!

패치 완료 2

6. 패치 적용 이후, 다시 Inspector 점검하기!

Inspector 결과 비교

위 5.의 System Manager를 통해 Patch 배포 이후, 취약점 건수가 급격히 줄어든 모습을 볼 수 있다.

물론 아직 3개의 취약점이 남아 있지만, 매우 의미 있는 패치 결과이다.

 

□ 실습 결론

이번 실습에서는 웹서버 취약점 보호를 위한 1) WAF 설정 2) Inspector + Patch manager을 실습해보았다.

 

1)의 WAF 설정은 최초 WAF 설정 이후, Security Rule을 비용을 들여서 제3의 Rule을 사용하면 크게 손 댈건 없는거 같다.

하지만, 2)는 다르다.

2)의 Inspector + Patch Manager는 주기적으로 점검해서 취약점이 있는지 확인하고 이에 맞는 Patch를 적절하게 해줘야 한다.

 

[Inspector 최초점검 > Patch Manager 기준 수립 > Patch 진행 > Inspector 이행점검] << 이 과정이 계속해서 진행되어야 한다.