AWS Network Firewall

Network Firewall 이란?

AWS Network Firewall은 VPC에서 생성하는 상태 저장 관리형 네트워크 방화벽이자 침입 탐지 및 방지 서비스입니다.

Network Firewall을 사용하면 VPC 경계에서 트래픽을 필터링할 수 있으며, 인터넷 게이트웨이, NAT 게이트웨이 또는 VPN이나 ​​AWS Direct Connect를 통해 들어오고 나가는 트래픽 필터링이 포함됩니다. 네트워크 방화벽은 상태 저장 검사를 위해 오픈 소스 침입 방지 시스템(IPS)인 Suricata를 사용합니다. 

위의 그림은 Network Firewall를 나타낸 간단한 아키텍처 입니다.

  • 인터넷 게이트웨이의 라우팅 테이블을 살펴보면 인터넷 게이트웨이를 통해 VPC 내부로 들어오는 트래픽은 모두 firewall endpoint를 통해 VPC 내부로 들어갑니다.
  • firewall의 라우팅 테이블을 살펴보면, 0.0.0.0/0 은 인터넷 게이트웨이로, VPC 대역대는 local로 통합니다.
  • Nat Gateway의 라우팅 테이블을 살펴보면 VPC 대역대는 local로, 내부에서 외부로 나가는 0.0.0.0/0은 network firewall의 endpoint로 향합니다.
  • EC2 라우팅 테이블을 살펴보면 VPC 대역대는 local로, 0.0.0.0/0은 Nat Gateway로 향합니다.

결국 VPC 내, 외부로 향하는 트래픽은 모두 Network Firewall을 거치게 됩니다.

실습

이제 간단한 실습을 통해 환경 구축 후 테스트를 진행해 보겠습니다.

저의 환경은 아래와 같이 vpc, subnet, internet gateway, nat gateway, routing table 등이 미리 구성되어 있습니다.

  • VPC : 10.0.0.0/16
  • Subnet
    • public-a : 10.0.1.0/24
    • public-c : 10.0.2.0/24
    • private-a : 10.0.3.0/24
    • private-c : 10.0.4.0/24
    • firewall : 10.0.5.0/24
  • Internet Gateway
  • Nat Gateway(public-a subnet)

Network Firewall 생성

VPC – Network Firewall을 선택하여 방화벽 생성을 클릭합니다.

적당한 이름 작성 후 firewall subnet(10.0.5.0/24)를 선택합니다. 이번 실습에서는 위에서 언급한것과 같이 단일 영역의 아키텍처로 구성하겠습니다.

빈 방화벽 정책 생성 및 연결 선택 후 적당한 이름을 작성합니다.

방화벽 생성 버튼을 누르면 방화벽이 생성되기 시작하며, 약 10분 정도의 시간이 소요됩니다. 그동안 새로 생성한 방화벽 정책을 설정해 보겠습니다.

Network Firewall Policy 설정

이글에서는 상태저장과 상태비저장에 대한 차이점에 대해서는 다루지 않겠으며, 아래 공식문서를 참고 부탁드립니다.

  • https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-rules-engines.html

상태저장 규칙 그룹 -> 작업 -> 상태유지 규칙 그룹 생성을 선택합니다.

policy 생성 시 총 3개의 규칙그룹을 통해 생성할 수 있습니다. 이번 실습에서는 표준 상태 저장 규칙을 통해 policy를 생성해 보겠습니다.

  • 표준 상태 저장 규칙 – 트래픽 흐름의 컨텍스트 내에서 패킷을 검사하기 위한 표준 네트워크 연결 속성을 정의합니다.
  • 도메인 목록 – 도메인 이름 목록을 정의하고 검사할 프로토콜 유형을 지정합니다.
  • Suricata 호환 규칙 문자열 – Suricata 호환 형식으로 일치 및 작업 설정을 제공합니다. 원하는 경우 이 방법을 통해 모든 상태 저장 규칙을 제공할 수 있습니다.

적절한 이름 설정 후 용량을 설정합니다. 용량의 경우 해당 규칙 그룹에 생성할 수 있는 규칙의 갯수로 변경이 불가하니 여유롭게 설정합니다.

프로토콜은 IP, 소스는 모든 IP로 할것이기에 임의를 선택합니다. 그후 대상은 VPC 대역대인 10.0.0.0/16으로 설정합니다. VPC 내부로 들어오는 트래픽을 block 할것이기에 작업은 삭제를 선택합니다.

규칙을 추가하여 아래와 같이 위에서 생성한 규칙이 추가 되었는지 확인 후 규칙 그룹을 생성해 줍니다. 추가적으로 public ec2에 ssh 접근을 위해 내 IP만 통과하도록 정책을 추가하여 순서를 제일 위쪽으로 하여 생성합니다.

이제 다시 Netowkr Firewall을 살펴보면 정상적으로 생성이 되었고 아래와 같이 엔드포인트가 생성된 것을 확인할 수 있습니다.

라우팅 테이블 수정

VPC 내/외부로 통하는 모든 트래픽이 방화벽을 통하도록 라우팅 테이블을 구성합니다. 아래와 같이 총 4개의 라우팅 테이블을 구성합니다.

my-vpc-01-rtb-private

프라이빗 서브넷은 기존과 동일하게 0.0.0.0/0 을 Nat Gateway로 향하게 합니다. VPC 내부 통신또한 방화벽을 통하도록 설정합니다.

my-vpc-01-rtb-public

퍼블릭 서브넷은 0.0.0.0/0을 방화벽 엔드포인트로 향하게 합니다. 이로써 프라이빗 서브넷에서 퍼블릭 서브넷에 위치한 Nat Gateway를 통해 외부로 나갈때 방화벽을 통해 트래픽이 흐르게 됩니다. VPC 대역도 위와 마찬가지로 방화벽 엔드포인트를 통하게 합니다.

my-igw-rtb

인터넷 게이트웨이를 위한 라우팅 테이블 생성 후, 엣지연결탭에서 기존 인터넷 게이트 웨이를 선택해 줍니다. 라우팅 설정은 아래와 같이 10.0.0.0/16이 방화벽 엔드포인트를 향하게 합니다.

my-firewall-rtb

마지막으로 firewall의 라우팅 테이블 설정입니다. 0.0.0.0/0은 인터넷 게이트웨이로, 10.0.0.0/16은 local로 향하게 합니다.

통신 테스트

테스트를 위해 퍼블릭, 프라이빗에 각각 하나의 EC2를 생성합니다. 보안그룹은 테스트를 위해 모든 트래픽을 허용하였습니다.

test-public EC2

  • Public IP : 43.200.1.235
  • Private IP : 10.0.1.145

test-private EC2

  • Private IP : 10.0.3.93

테스트 내용

테스트는 아래와 같이 2가지 케이스에 대하여 진행해 보겠습니다.

  1. 퍼블릭 EC2 -> 프라이빗 EC2
  2. 프라이빗 EC2 -> 외부(8.8.8.8)

1. 퍼블릭 EC2 -> 프라이빗 EC2

아래와 같이 퍼블릭 EC2에서 프라이빗 EC2로 통신이 되지 않는것을 확인할 수 있습니다.

2. 프라이빗 EC2 -> 외부(8.8.8.8)

현재 프라이빗 EC2로 접속할 수 있는 방법은 없기에 (public EC2로 터널링을 구성하거나 EC2 connect endpoint를 이용해서 접속은 가능). AWS Network Manager의 Reachability Analyzer 를 통해 알아 보겠습니다. 아래와 같이 소스 유형을 프라이빗 EC2로, 대상 유형을 8.8.8.8 로 설정 후 분석해 보겠습니다.

방화벽 정책이 제대로 설정되어 있다면 통신이 이루어지지 않습니다.

아래와 같이 Reachability Analyzer를 통해 트래픽의 흐름도를 한눈에 볼 수 있습니다.

순서대로 보면 프라이빗 EC2가 프라이빗 라우팅 테이블에 의해 Nat Gateway로 향하게 됩니다. (0.0.0.0 -> Nat Gateway) 그후 Nat Gateway에 설정되어 있는 퍼블릭 라우팅 테이블에 의해 방화벽 엔드포인트로 향합니다.(0.0.0.0 -> vpc endpoint) 그 후 방화벽 정책에 의해 트래픽이 차단됩니다.

지금 까지 AWS Network Firewall에 대해 알아본 후 간략한 실습까지 진행해 보았습니다. 해당 내용이 도움되기를 바라며 자세한 내용은 아래 공식문서를 참고 부탁드립니다.

https://docs.aws.amazon.com/network-firewall/latest/developerguide/what-is-aws-network-firewall.html

감사합니다.

By |2023-12-11T14:19:43+09:002023-12-11|Categories: AWS, TechBlog, 클라우드|

About the Author: