[55일 차] 21.10.12 : AWS 15

Security Group/Network ACL

WAF

---

1교시

 

 

오늘 AWS 기반 서비스 마무리 예정

 

AWS Direct Connect는 실제 회선이 있어야 사용 가능.

Co-location 환경(= IDC 환경)에서 AWS와 전용 네트워크 연결을 제공하는 전용 선 서비스

VPN과 목표가 유사하지만, VPN은 암호화/복호화를 통해 보안 통신을 추구하기에 인터넷 환경에 따라 연결 품질이 바뀔 수 있다. 하지만 Direct Connect는 실제 회선을 연결하기 때문에 일관성 있게 서비스를 보장받을 수 있다.

 

이건 실제 회선이 있어야 하니 실습은 안 하고 넘어간다.

 

 

• AWS Security Group과 네트워크 ACL

-> 보안 그룹은 인스턴스 레벨의 접근 제어를 수행 : EC2 인스턴스나 ALB와 같은 특정 인스턴스에 대한 접근 제어 정책

-> 네트워크 ACL은 서브넷 레벨의 접근 제어를 수행 : VPC상 생성한 서브넷 네트워크에 대한 접근 제어 정책

 

• 네트워크 통신 접근 제어(Network Access Control List)

-> 접근 대상의 IP 주소/프로토콜/포트 번호를 통해 대상을 식별하여 허용 대상은 접근을 허용하고, 거부 대상은 접근을 제한

 

 

• Statefull : 이전 상태 정보(TCP 연결)를 기억하고 있다가 다음 단계에서 그 상태 정보를 활용할 수 있다.
• Stateless : 이전 상태 정보를 기억하지 않아 다음 단계에 관여를 하지 않는다.

통신의 방향이 인바운드/아웃바운드가 있을 때, 어떤 통신이 인바운드 규칙을 통과해서 들어왔다고 치자.

-> Stateful이라면 이 통신이 인바운드를 통과해서 들어왔다는 것을 기억하기 때문에 응답 시 아웃바운드 규칙을 무시하고 다시 돌아갈 수 있다.

-> Stateless라면 이 통신이 인바운드를 통과해서 왔는지 아닌지 모른다. 통신이 나갈 때에도 아웃바운드 규칙을 적용해 확인한다.

 

보안 그룹은 Stateful 접근 제어 동작을 하고 있다. 인바운드의 기본값은 22번 포트(SSH) 허용, 아웃바운드의 기본값은 '모두 허용'

HTTP도 Stateful 방식이 적용되어 있다.

 

• 보안 그룹은 허용 정책만 존재 : 기본적으로 인바운드 규칙에는 모두 차단되어 있다.

-> 규칙상 허용 정책만 나열하며, 대상이 아닌 것은 자동 거부

• 네트워크 ACL은 허용/거부 정책 모두 존재

정책들을 순차적으로 비교하여 매칭이 되는 대상이 있다면 정책에 따라 허용 또는 거부를 판단한다. 

-> 가장 마지막 정책은 자동으로 모든 대상을 거부하는 것.

-> 가장 작은 시퀀스 넘버부터 순차적으로 확인. 정책 별로 허용/거부를 지정 가능하며, 매칭 되는 대상이 있다면 동일한 대상의 하위 정책을 더 이상 확인하지 않음.

 

그래서 네트워크 ACL은 역삼각형 구조를 권장하지 않는다.

-> 상위 정책에서 전부 허용해 버리면 아래 정책들이 의미가 없다.

 

 

• ACL-VPC Flow Log

VPC에 속한 네트워크 인터페이스에서 송수신되는 트래픽에 대한 정보를 수집할 수 있는 기능.

-> Amazon CloudWatch Log 또는 Amazon S3에 게시될 수 있다.

-> 실시간 서비스 아니다. 플로우 로그 생성 후 데이터를 수집, 플로우 로그 레코드를 게시하는데 대기 시간이 소요된다.

---

2교시

 

 

[실습 7-1] 기본 구조 구축 후 테스트 몇가지 : Stateful/Stateless의 차이를 직접 보자.

Server-EC2의 보안 그룹 인바운드 규칙에 22번 포트 허용. 

1. Server-EC2-SG의 기본 아웃바운드 규칙 삭제 후 핑 테스트(변경 후 재접속해야 한다)

-> 작동하던 외부 인터넷과의 핑 테스트가 작동하지 않음

2. 인바운드 그룹에 HTTP를 추가하지 않았으니 웹 페이지로 접속 불가. 아웃바운드 규칙에 80번 포트에 대한 허용 추가

-> HTTP 유형에 대한 80번 포트, 0.0.0.0/0 대상

-> 8.8.8.8에 대한 핑은 여전히 작동하지 않지만, curl로 google 페이지를 긁어오는 명령은 작동한다.

-> 인바운드 규칙에 80번 포트(웹 트래픽)에 대한 허용이 없음에도 불구하고, 아웃바운드 규칙에서 허용되었으므로 다시 돌아오는데 문제가 없다 : Stateful 방식

 

※ 인바운드 규칙에서 작성하는 프로토콜/포트는 목적지, IP 주소는 출발지 주소

※ 아웃바운드 규칙에서 작성하는 프로토콜/포트는 목적지, IP 주소는 목적지 주소

---

3교시

 

 

콘솔에서는 VPC 선택, 우측 작업에서 플로우 로그 생성 > 정보 작성

이 생성 과정의 Type은 AWS::EC2::FlowLog 

플로우 로그 설정에서 필터(TrafficType)는 어떤 항목을 기록할지에 대한 것.

최대 집계 간격(MaxAggregationInterval)은 집계에 걸리는 최대 시간 간격

대상은 CloudWatch가 기본값

 

뭔지는 몰라도 IAM 때문에 수업이 지연되었다. 난잡해서 정신이 없었다.

 

 

클라우드 워치 내의 로그 이벤트 

 

어쨌거나

 

VPC내의 서브넷 내의 인스턴스에 통신이 도달하는 과정은?

외부 -> VPC 진입 -> 네트워크 ACL 필터 -> 서브넷 진입 -> 보안 그룹 필터 -> 인스턴스 도달

---

4교시

 

 

네트워크 ACL

 

일단 콘솔에서

VPC > 좌측 목록에서 네트워크 ACL

네트워크 ACL은 서브넷마다 1개가 매핑되어 있다. 기본 구조 구축 후 들어가 보면

기본 서브넷 4개에 매핑된 ACL 1개, 방금 구축한 기본 구조에서 만들어진 기본 ACL 1개가 있다.

해당 ACL을 체크해보면 여러 정보들을 볼 수 있다.

인바운드/아웃바운드 규칙 탭을 보면 기본값이 모두 허용으로 되어 있는 것을 볼 수 있다.

 

새로 만들어 보자.

네트워크 ACL 생성 > 이름 작성, VPC 선택 > 생성

(코드 타입은 AW::EC2::NetworkAcl)

체크하고 서브넷 연결 탭 > 서브넷 연결 편집 > 연결할 서브넷 체크 후 저장

(코드 타입은 AWS::EC2::SubnetNetworkAclAssociation)

새로 만든 것은 인바운드/아웃바운드 모두 거부하는 엔트리만 있다.

-> 접속했던 원격 접속도 다 끊기고, 웹 접속은 당연히 안되고.

인바운드 규칙 편집 > 새 규칙 추가 > SSH 유형으로 허용 엔트리 추가

 

보안 그룹은 Stateful, 네트워크 ACL은 Stateless 방식으로 동작

 

그럼 방금 네트워크 ACL에 SSH 인바운드 추가했으니 접속해볼까?

-> 접속 안됨. 인바운드로 들어갈 수는 있지만 아웃바운드에서 막혀서 나오지를 못한다.

 

아웃바운드 규칙 편집 > 새 규칙 추가 > 사용자 지정 TCP 유형, 포트 1024-65535로 허용 엔트리 추가

---

5교시

 

 

네트워크 ACL은 자주 사용하는 기능이 아니라서 코드 실습은 생략.

보안 그룹에서 충분히 필터링이 가능한데 굳이 인바운드/아웃바운드 각각 신경 써가며 설정할 필요가 없다.

 

어쨌거나 위와 같이 아웃바운드 규칙을 추가하면 SSH로 인바운드 규칙을 거쳐 들어온 통신을 기억하지 못하고 인스턴스에서 시작된 통신으로 생각하고 아웃바운드 규칙으로 필터링

 

또 새로운 규칙을 추가할 때, 기존 규칙보다 먼저 적용시키고 싶다면 

-> 기존 규칙의 번호보다 작은 규칙 번호 부여하기

 

curl 실행을 위해 아웃바운드에 HTTP 허용 규칙을 추가해도 통신 안됨.

-> 인바운드에서 막힌다. 위 SSH 추가에서 아웃바운드에 한 것처럼 인바운드에 사용자 지정 TCP에 대한 허용 추가.

 

 

 

이번에는 WAF(Web Application Firewall)

-> 웹 App 보안에 특화된 전용 서버. 웹 서비스 취약점에 대한 공격을 탐지하고 차단하는 기능을 수행하며 웹 접근 트래픽에 대한 payload 분석 및 패턴 기반의 필터링을 통해 공격을 탐지하고 차단할 수 있다.

 

WAF 구성 요소

1. Web ACL

최상위 컴포넌트. 하위 컴포넌트인 Rule을 추가하여 AWS 리소스를 보호. 이것을 사용하여 여러 웹 요청을 세부적으로 제어할 수 있다.

2. Rule

하위 컴포넌트. 검사 기준을 정의하고 기준을 충족할 경우 수행 작업을 포함. Rule을 사용하여 일치 대상에 대해 요청을 차단하거나 허용할 수 있다. 하위 구성요소로 Statement가 있으며, 최대 5개의 Statement를 설정할 수 있다. Statement에 대한 Match Action을 수행할 수 있다.

3. Statement

웹 필터링의 상세 조건을 정의하는 컴포넌트. 상세 조건은 Inspect(Inpsection 대상을 정의하는 조건), Match Condition(Inspection 분류 방법), Transformation, Action으로 구분.

---

6~7교시

 

 

WAF 실습

OWASP

 

WAF로 트래픽 차단하기(AWS::WAF::WebACL, AWS::WAF::Rule 등의 타입 사용)

AWS WAF > Web ACLs > Create web ACL > 리전 선택, 이름 작성 > 규칙 추가 > Add managed rule groups > 'Anonymous IP list'/'Core rule set'/'SQL database' 활성화(체크) 후 Add rules > 이번에는 Add my own rules and rule groups > Rule만 만들 거니까 Rule type은 Rule builder, 이름 작성, Regular rule 체크, Inspect는 URI path/Contains string/exec/None 선택, 작성

 

좀 많이 놓쳤다

---

8교시

 

 

• 개인 프로젝트 설명

1. IDC 기업망을 사용하던 기업이 AWS에 웹 서버를 구축하고자 한다 : 웹 서버 인스턴스 2개(프라이빗 서브넷)

-> 외부에서는 ALB를 통해서만 접속 가능. 프라이빗에서 나가는 것은 가능

-> NAT 인스턴스 2개(퍼블릭 서브넷). 타깃 그룹은 2개의 웹 서버

-> 프라이빗 라우팅 테이블 각각에는 외부 네트워크로 가는 라우팅 경로를 각 NAT 인스턴스로 잡는다(하나씩 연결)

프라이빗 인스턴스(웹 서버)가 나가려면 당연히 NAT 디바이스가 연결되어 있어야지.

 

2. Route 53 프라이빗 호스팅 영역을 AWS에 구축, 웹 서버에 연동

-> IDC 기업망 영역에 DNS 인스턴스 생성

-> AWS에 사용하는 도메인은 저번에 Freenom에서 받은 도메인 사용

 

3. 웹 서버는 DB로 기업망 내에 있는 DB 인스턴스 사용.

-> 주어질 예정

 

4. 예전에 했던 VGW를 TGW로 대체하는 실습을 적용

-> 기업망에 CGW 인스턴스 생성

-> 기업망과 AWS망을 연결

 

5. 기존에 싱가포르에 동일하게 IDC 기업망을 운용하고 있었는데, 여기에도 서울처럼 마이그레이션 적용

-> 대신 여기는 NAT 인스턴스 1개, 프라이빗(웹 서버) 인스턴스 1개, 그냥 프라이빗 서브넷 1개(연결만)

-> 사설 호스팅 영역 생성

 

6. 서울-싱가포르 기업망에 있는 DB는 장애에 대비해 마스터-슬레이브 구조를 구축해야 한다.

-> 슬레이브는 마스터를 복제하기만 할 뿐, 슬레이브에서 DB 수정 불가

-> 마스터는 서울에, 슬레이브는 싱가포르에

 

7. 각 리전에 Global Accelerator 적용, 외부에서 접속할 때 원활히 접속 가능하도록

 

8. 서울-싱가포르 TGW 간 피어링 연결

 

 

화요일(10.12) ~ 일요일(10.15)까지 구축 + PPT 작성까지

월요일 오전 9시 전까지 강사님께 보내기.

---

2교시 중반(10:45~11:10) 잠깐 놓침

3교시 전체 IAM부터 다시 훑기

5교시 (13:50~) WAF 설명 다시 듣기

7교시 후반 다시 듣기