본문 바로가기

Security

[이론] AWS Network Firewall 기본 개념

반응형

안녕하세요 서후아빠입니다. ^_^

이번 세션은 2020년 12월에 출시?한 Network Firewall에 개념에 대해서 간단히 정리해 보았습니다.

정리 하다보니 많은 부분에서 GWLB 구성 기본 개념과 겹치는 부분이 있었습니다. 아마도 실습 구성도 비슷하지 않을까 생각됩니다. 

그리고 일반 방화벽은 stateful 정책만 지원하는데 반해, Network firewall은 stateless+stateful 혼용 지원이 되어 개념상 차이가 있습니다.


개요

AWS VPC 기반의 관리형 방화벽(IDS/IPS ) 서비스

Internet Gateway를 통해 움직이는 트래픽을 필터링하여 리소스 보호 

Open source IPS인 Suritaca 사용 

도메인 정책 지원

구성요소

Firewall : VPC subnet에 대한 Traffic filtering

Policy : Default action, Stateless rule group, Stateful rule group 정의

Rule group : Stateless rule, Stateful rule 정의

1개의 Policy에는 Stateless rule group과 Stateful group이 존재하고 각 rule group에서 여러 개의 rule을 등록할 수 있습니다. 
각 rule에는 capacity를 입력하게 되어있으며, 각 group에 등록 가능한 rule의 capacity 합계는 30,000으로 제한됩니다.
그러므로 rule을 정의할 때, capacity 정리가 필요합니다.

Firewall engine

종류

  - Stateless engine : 우선순위에 따른 rule 검사, deep packet inspection 기능 활성화 시 payload까지 검사 가능

  - Stateful engine : 전체 rule 검사, Default 정책은 Pass

적용 순서 : Stateless > Stateful

Firewall engine 내부의 rule 적용 순서

Network Firewall을 구성하여 여러가지 시나리오를 테스트 해 본 결과, 아래처럼 적용되는 것을 확인하였습니다.
전통적인 On-premise 방화벽과 구조적으로 많이 다르다는 느낌을 받았습니다.
① Stateless rule의 Default action 적용
    - Pass : 즉시 통과
    - Drop or Forward to stateful rule groups : Stateless rule 전달
      ※ Drop이면 Pass처럼 즉시 차단될 것 같았으나, Stateless rules에 Pass가 적용되었음
② Stateless rule : 우선순위 따라 적용
    - Drop : 즉시 차단
    - Pass : Stateful rule 전달
③ Stateful rule : 모든 정책 확인하여 적용
    - Default action : 정책 없으면 통과, 정책 있으면 Pass or Drop 정책 모두 검토하여 처리

On-premise 방화벽과 가장 비슷하게 사용하려면 아래처럼 정책 설정해야 합니다.
① Stateless rule의 Default action : Forward to stateful rule groups
② Stateless rule : Drop 설정만
③ Stateful rule : Pass 설정만 

주의
  ②단계에 적용되지 않고, ③단계에 아무 정책 설정하지 않으면 패킷은 무조건 Pass입니다.
  이런 동작은 On-premise 방화벽(기본 모두 Drop)과 차이점입니다.

Traffic Flow

Traffic Flow

구성 시 장점

통합 운영으로 오버 헤드(운영인력 리소스 상승) 절감, 비용 절감 : Service A/B/C…, PRD/STG/DEV,…과 같이 비슷한 서비스를 묶어 통합 정책 관리가 가능함

보안장비 인라인 구성의 경우 보안장비 장애 시 조치가 어려운 반면, Network Firewall 구성은 Ingress 라우팅 테이블을 Firewall Endpoint에서 ALB로 연결하고, Outbound 라우팅 테이블도 IGW로 변경하는 즉시 서비스는 복구됨

구성 시 참고사항

Firewall endpoint 종류는 GWLB Endpoint이며 가용 영역(AZ)별 생성 

인터넷과 통신(VPC <-> Firewall endpoint <-> 인터넷) : VPC의 "ingress route" 설정(IGW는 ingress route tables에 Edge 연결) 

TGW은 App이 연결되는 VPC와 Network Firewall이 연결되는 VPC(일명 Inspection VPC)를 각각 구분하여 라우팅 설정해야 하므로 라우팅 자동 연결 설정을 disabled

고객 추천? 3rd-Party 방화벽 vs Network Firewall 

고객이 방화벽에 대해서 전혀 모른다면? 이거나 저거나 지식이 없기 때문에 아무거나 추천 가능

고객이 방화벽을 써 봤다면? Network Firewall 추천하지 않음
  - 정책 적용(본문 Firewall engine 내용)에 대한 개념부터 많이 다르고, 3rd-Party 방화벽이 정책 적용이 많이 쉬움

  - 정책 적용 및 장애 등 실시간 로그 확인이 어렵고, 실시간 로그를 어떻게 수집되었더라도 정리된 테이블이 아니므로 보기가 쉽지 않음

  - 정확한 데이터 대조는 하지 못하였으나, idle 상태의 한달 비용만 비교해 봤을 때 획기적으로 저렴하지 않음

반응형