AWS 한국사용자모임: 네트워크 소모임

 

12월 3일 을지로 입구역 삼화타워에 3층에서 AWS사용자모임 네트워크 소모임이 열렸다. 

 

나는 해당 모임의 첫 참석이었으며 Room 2에서 개최하신 분들이 모임을 준비하고 계셨다. 

 

들어가자마자 옆에 간단한 허기를 채울 수 있게 음료수와 김밥을 구비해 놓으셨고 덕분에 배가 좀 나아졌습니다.

 

 

 

오늘의 세션 주제는 AWS 서비스중 NetworkFireWall이었습니다. 그리고 발표자 분은 AWS의 심은수 님이 발표와 진행을 

 

해주셨습니다. 바로 시작은 하지 않았고 가볍게 Q&A 시간을 가진 뒤에 진행이 되었습니다.

 

우선 NetworkFireWall은 수리카타 엔진기반으로 만들어진 방화벽 서비스로써 규칙에 맞게 트래픽을 허용 및 차단하고

 

DNS 필터링과 애플리케이션 계층 규칙을 지원하며 차단된 트래픽에 대한 로그를 남겨서 보안을 강화하고 분석하게 만들

 

어 놓은 서비스 입니다. AWS가 관리하는 완전 관리형  방화벽 시스템으로 온프레미스에서 팔로알토나 포티넷에서 방화벽

 

을 구매해서 관문 및 백본 쯤에 방화벽을 설치하여 보안을 유지 하는 것처럼 사용하는 게NetworkFireWall입니다.

NetworkFireWall 의 트래픽처리 흐름도

 

 

 

그러나 그전에 해당 본론 주제로 넘어가기 전에 AWS 서비스 중 Gateway LoadBalancer에서 대해 설명해 주셨습니다.

 

자세한 내용은 밑에 요약하여서 남겨두겠습니다. 해당 설명이 끝난 후에는 Gateway LoadBalancer를 사용해서

 

NetworkFireWall을 적용한 아키텍처 사례를 설명해 주셨습니다. 비록 비용이 많이 나가기도 하고 아무래도 수리카타 엔진

 

이 다루기 어렵기도 할 만뿐 아니라 비용 또한 많이 들긴 하지만 마치 온프레미스에서 로드밸런서를 사용하는 것보다 AWS

 

로드벨런서를 쓰는 것처럼 안정성과 구축 및 설치 비용 그리고 가장 AWS를 사용하는 이유인 완전관리형 서비스 이기 때문

 

에 해외에서도 국내에서도 쓰는 추세가 증가 중이라고 얘기해주셨습니다. 그리고 어느 정도의 마지막 Q&A를 마치고 세션

 

이 종료되었습니다. 이렇게 좋은 시간을 만들어 주신 심은수 님에게 여기에서 나마 감사의 인사를 드립니다.(꾸벅)

 

아래에는 세션에서 들었던 내용을 정리해서 올리겠습니다. 

 

 

세션: AWS Network Firewall: 이제는 써봐야 하지 않을까?

AWS 신은수 님

 

 

1. Gateway Load Balancer (GWLB)

• 네트워크 트래픽을 받아서 보안 장치(방화벽 같은 장비)로 보내주는 중간 관리자.
• 보안성과 트래픽 관리 목적으로 설계된 특수한 게이트웨이 로드 밸런서.
• 네트워크 트래픽을 투명하게 처리하며, 서드파티 보안 장치(예: 방화벽)와의 통합에 최적화.

특징

• 로드 밸런서 역할:
  • 트래픽의 부하를 분산하고, 보안 장치로 트래픽을 라우팅.
  • 각 엔드포인트와 한 쌍으로 동작하며, DNS/IP는 별도로 제공되지 않음.
• GENEVE 프로토콜 기반 캡슐화:
  • L3 캡슐화를 통해 트래픽을 터널링 방식으로 전송.
  • 흐름: 클라이언트 → 엔드포인트 DNS → GWLB → 방화벽 → 목적지.
• 트래픽 처리:
  • TLS/SSL 암호화/복호화 없이 트래픽을 그대로 처리.
  • 투명한 트래픽 처리를 통해 사용자 네트워크와 방화벽 간의 원활한 통합 지원.

활용 시나리오

• 서드파티 방화벽 통합:
  • Palo Alto, Fortinet 등의 서드파티 방화벽 장치와 결합.
• 멀티 엔드포인트 지원:
  • 향후 업데이트를 통해 트래픽 관리 효율성 증대.

---

2. AWS Network Firewall

개요

• 완전 관리형 방화벽 서비스로, VPC 네트워크 트래픽을 보호.
• Suricata 기반으로 동작하며, 강력한 규칙 엔진을 제공.

• 

특징

1. 트래픽 제어 플로우:
   • Pass: 허용.
   • Drop: 차단.
   • Forward: Stateful Rule Engine으로 전달.
2. Stateful Rule Engine:
   • Strict Order: 방화벽 기능을 강조하여 규칙을 엄격히 적용(권장).
   • Action Order: IPS(Intrusion Prevention System) 방식 처리(비권장).

구성

• GWLB와의 통합:
  • GWLB에 Network Firewall을 추가로 설정하여 트래픽 검사를 강화.
  • 현재는 개별 엔드포인트 및 방화벽 생성으로 I/O 트래픽을 관리.
• 보안 VPC 구성:
  • Transit Gateway를 사용하여 여러 VPC를 연결하고, 특정 VPC만 인터넷 트래픽 허용.
  • 리소스의 변함이 별로 필요하지 않은 아키텍처에 권장.

추천 설정

• Drop Action:
  • 기본 설정으로 any any drop 규칙 추가하여, 미지정 트래픽을 차단.
• Stateful 규칙 사용:
  • 로깅 지원, 연결 상태 인식.
  • L7 기반의 세부 규칙 생성 가능.

---

3. Stateful vs. Stateless 규칙

Stateless 규칙

• 연결성을 인식하지 않음 → 비대칭 패킷 검사로 인해 보안 취약점 발생 가능.
• 로깅 미지원.

Stateful 규칙

• 장점:
  • 연결성을 인식하여 응답 트래픽을 자동으로 허용.
  • Layer 7 기반의 고급 규칙 설정 가능.
  • 규칙에 주석 추가 가능.
• 추천 사용:
  • Stateful Rule Engine을 활용해 네트워크 보안 강화.

---

4. 활용 사례

1. 멀티 VPC 보안 관리:
   • 여러 VPC를 보안 VPC와 연결하여 중앙에서 트래픽 제어.
   • 자원 변동이 심한 환경에서는 구성 난이도가 증가할 수 있음.
2. 중앙 집중식 방화벽 구성:
   • GWLB와 Network Firewall을 결합하여 트래픽 검사 및 제어를 중앙에서 수행.
3. 애플리케이션 보안 강화:
   • Stateful 규칙을 사용해 응용 프로그램 계층 트래픽(L7)을 상세히 분석하고 보안 강화.

---

5. 기술적 핵심 요소

• Suricata 기반:
  • 오픈소스 IDS/IPS 엔진으로, 고성능 트래픽 분석 및 규칙 처리.
• 중요 키워드:
  • $HOME_NET: 네트워크 정의 변수.
  • flow:to_server, established: 서버로의 트래픽 및 연결 상태 유지.

 

6. 요약

AWS Network Firewall은 GWLB와 결합하여 클라우드 네트워크 보안의 유연성과 확장성을 제공합니다. Stateful 규칙과 Drop Action을 통해 강력한 보안 제어가 가능하며, Suricata 기반의 고성능 규칙 엔진으로 트래픽 분석 및 제어를 효율적으로 수행할 수 있습니다.

활용 추천:

• 대규모 멀티 VPC 아키텍처.
• 서드파티 방화벽과의 통합 필요 환경.
• 고급 네트워크 보안 및 트래픽 분석 요구사항이 있는 기업.

 

 

# 키워드

• Suricata: 네트워크 보안 시스템을 만들어주는 오픈 소스 엔진. , IDS/IPS 및 트래픽 분석 제공. 규칙 기반 탐지
• Stateful Rule Engine: 네트워크에서 데이터를 주고받을 때, "이 데이터가 어떤 연결에서 왔지?"를 기억하는 엔진.
• Strict Order: 규칙을 위에서 아래로 엄격하게 적용하는 처리 방식.
• Transit Gateway: 멀티 VPC와 온프레미스 네트워크를 연결하는 중앙 네트워크 허브.
• Stateless 규칙: 데이터 트래픽을 그냥 "이 패킷 맞아? 허용/차단"만 하고 끝내는 단순한 규칙.
• Stateful: 요청을 보면 "이거 응답도 나중에 올 거니까 허용!" 함.