VPC를 오가는 트래픽을 Suricata 규칙으로 검사하세요

Stateful rules

규칙은 Suricata 문법 그대로 씁니다

아래는 아웃바운드 허용 목록 예시입니다. 새 방화벽 정책의 기본값인 strict order에서는 규칙 그룹은 우선순위 순서로, 그룹 안의 규칙은 적힌 순서대로 평가됩니다.

# 승인된 도메인으로 가는 TLS만 허용
pass tls $HOME_NET any -> $EXTERNAL_NET 443 (tls.sni; content:".amazonaws.com"; endswith; nocase; flow:to_server; msg:"allow AWS endpoints"; sid:1000001; rev:1;)
pass http $HOME_NET any -> $EXTERNAL_NET 80 (http.host; content:"repo.example.com"; startswith; endswith; flow:to_server; msg:"allow package repo"; sid:1000002; rev:1;)

# 평문 관리 프로토콜은 TCP RST로 즉시 차단
reject tcp $HOME_NET any -> $EXTERNAL_NET 23 (flow:to_server; msg:"block telnet"; sid:1000003; rev:1;)

# 나머지 TLS는 기록 후 차단
alert tls $HOME_NET any -> $EXTERNAL_NET any (msg:"unapproved TLS destination"; flow:to_server, established; sid:1000004; rev:1;)
drop tls $HOME_NET any -> $EXTERNAL_NET any (flow:to_server, established; sid:1000005; rev:1;)

Features

주요 기능

Deployment models

트래픽을 방화벽으로 보내는 네 가지 방법

방화벽은 라우팅으로 트래픽을 받습니다. 어느 라우팅 테이블에서 방화벽을 다음 홉으로 지정하느냐에 따라 배포 모델이 나뉩니다.

Reference architecture

Transit Gateway에 직접 붙이는 중앙 검사

스포크 VPC와 온프레미스 트래픽은 TGW 라우팅 테이블을 따라 방화벽 attachment로 갑니다. 방화벽이 쓰는 VPC는 Network Firewall이 관리하므로 보이지 않고, 검사를 통과한 트래픽은 목적지 VPC나 이그레스 VPC로 이어집니다.

Getting started

첫 방화벽을 배포하는 순서

1. STEP 1

   규칙 그룹 작성

   stateless, stateful 규칙 그룹을 만들거나 관리형 규칙 그룹을 고릅니다.

2. STEP 2

   방화벽 정책

   규칙 그룹을 묶고 평가 순서(기본값 strict order)와 기본 액션을 정합니다.

3. STEP 3

   방화벽 생성

   VPC와 AZ별 방화벽 서브넷을 지정하거나, Transit Gateway(다른 계정 소유면 RAM으로 공유받은)에 직접 연결합니다.

4. STEP 4

   라우팅 변경

   VPC 또는 TGW 라우팅 테이블에서 방화벽 엔드포인트나 attachment를 다음 홉으로 지정합니다.

5. STEP 5

   로깅과 검증

   alert · flow 로그를 켜고, 허용과 차단이 의도대로 동작하는지 확인합니다.

Pricing

비용 항목

리전과 가용 영역별 방화벽 엔드포인트 시간과 처리한 트래픽 양이 기본 요금입니다. TLS 검사와 active threat defense를 켜면 요금이 더해집니다.

요금 단가는 리전과 사용량에 따라 다릅니다. TGW 연결형 방화벽은 별도 추가 요금 없이 Network Firewall과 Transit Gateway 표준 요금이 적용되며, Transit Gateway의 flexible cost allocation으로 데이터 처리 비용을 다른 계정에 배분할 수 있습니다. 최신 단가는 AWS Network Firewall 요금 페이지에서 확인하세요.