NAT와 방화벽 (2) - 방화벽의 원리와 상태 추적 - soo:bak
작성일 :
방화벽은 어떻게 트래픽을 필터링하는가
Part 1에서 NAT의 연결 추적을 살펴보았습니다.
연결 추적은 방화벽의 핵심 기술이기도 합니다.
방화벽(Firewall)은 네트워크 트래픽을 검사하고 허용하거나 차단하는 장비입니다.
이름은 건물의 방화벽에서 유래했습니다.
화재의 확산을 막듯이, 네트워크의 위협 확산을 막습니다.
방화벽의 역사
1세대: 패킷 필터링 (1980년대)
가장 초기의 방화벽은 패킷 필터(Packet Filter)였습니다.
각 패킷을 개별적으로 검사하며, IP 주소, 포트 번호, 프로토콜을 기준으로 필터링합니다.
1
2
3
4
규칙 예시:
- 외부에서 포트 80으로 오는 TCP 허용
- 외부에서 포트 22로 오는 TCP 차단
- 내부에서 외부로 나가는 모든 트래픽 허용
단순하고 빠르지만, 각 패킷을 독립적으로 판단하기 때문에 연결의 상태를 파악할 수 없다는 한계가 있습니다.
2세대: 상태 기반 검사 (1990년대)
상태 기반 검사(Stateful Inspection)가 등장합니다.
Check Point가 1994년 FireWall-1에서 상용화했습니다.
패킷뿐만 아니라 연결 상태를 추적하여 정당한 연결의 일부인지 판단할 수 있게 되었습니다.
3세대: 애플리케이션 계층 필터링 (2000년대~)
차세대 방화벽(NGFW: Next-Generation Firewall).
L7(애플리케이션 계층)까지 검사합니다.
HTTP 내용, 사용자 인증, 애플리케이션 식별 등이 가능합니다.
Stateless 방화벽
Stateless 방화벽은 각 패킷을 독립적으로 평가하며, 이전 패킷이나 연결 상태를 기억하지 않습니다.
1
2
3
4
패킷 1 도착 → 규칙 검사 → 허용/차단
패킷 2 도착 → 규칙 검사 → 허용/차단
패킷 3 도착 → 규칙 검사 → 허용/차단
(각각 독립적으로 처리)
장점
- 단순하고 빠름
- 적은 메모리 사용
- 예측 가능한 동작
단점
정당한 응답 트래픽을 식별하기 어렵습니다.
예를 들어:
내부 호스트가 외부 웹 서버에 요청합니다.
1
[내부] 192.168.1.10:12345 ──► 93.184.216.34:80 [외부]
응답이 돌아옵니다.
1
[외부] 93.184.216.34:80 ──► 192.168.1.10:12345 [내부]
Stateless 방화벽은 이 응답을 어떻게 처리할까요?
“외부에서 내부로 들어오는 트래픽”으로만 보이기 때문에, 이것이 정당한 응답인지 공격인지 구분할 수 없습니다.
해결책 1: 모든 인바운드 트래픽 허용 → 보안 취약
해결책 2: 모든 인바운드 트래픽 차단 → 인터넷 사용 불가
해결책 3: 상태 추적
Stateful 방화벽
Stateful 방화벽은 연결 상태를 추적합니다.
NAT 테이블과 유사한 상태 테이블(State Table)을 유지합니다.
1
2
3
4
5
6
7
8
상태 테이블 예시:
┌──────────────────────────────────────────────────────────┐
│ 프로토콜 출발지IP:포트 목적지IP:포트 상태 │
├──────────────────────────────────────────────────────────┤
│ TCP 192.168.1.10:12345 93.184.216.34:80 ESTABLISHED │
│ TCP 192.168.1.11:54321 142.250.185.46:443 ESTABLISHED│
│ UDP 192.168.1.10:53214 8.8.8.8:53 ACTIVE │
└──────────────────────────────────────────────────────────┘
동작 방식
아웃바운드 연결 시작:
- 내부에서 외부로 SYN 패킷 전송
- 규칙 검사 → 허용
- 상태 테이블에 항목 생성 (상태: SYN_SENT)
- 패킷 전달
인바운드 응답:
- 외부에서 SYN-ACK 패킷 도착
- 상태 테이블 조회 → 기존 연결의 일부
- 상태 업데이트 (상태: ESTABLISHED)
- 패킷 전달
비정상 인바운드:
상태 테이블에 매칭 항목이 없는 외부 패킷이 도착하면 차단됩니다.
이러한 동작을 도식화하면 다음과 같습니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
┌───────────────┐
패킷 도착 ───►│ 상태 테이블 │
│ 조회 │
└───────┬───────┘
│
┌────────────┴────────────┐
│ │
매칭 있음 매칭 없음
│ │
▼ ▼
┌──────────┐ ┌──────────┐
│ 상태에 │ │ 규칙 │
│ 따라처리 │ │ 검사 │
└──────────┘ └──────────┘
TCP 연결 상태 추적
Stateful 방화벽은 TCP의 상태 기계를 이해합니다.
1
2
3
4
5
6
7
8
9
10
TCP 3-way 핸드셰이크:
클라이언트 서버
│ │
│ ────── SYN ──────► │
│ │
│ ◄── SYN-ACK ───── │
│ │
│ ────── ACK ──────► │
│ │
방화벽의 상태 전이:
- SYN 패킷 → 상태: NEW 또는 SYN_SENT
- SYN-ACK 패킷 → 상태: SYN_RECV
- ACK 패킷 → 상태: ESTABLISHED
- FIN 패킷 → 상태: FIN_WAIT 등
- 연결 종료 → 상태 테이블에서 제거
ESTABLISHED 상태의 연결만 양방향 트래픽을 허용합니다.
비정상적인 상태 전이(예: SYN 없이 ACK)는 차단됩니다.
UDP의 상태 추적
UDP는 연결 개념이 없어서 상태 기계가 존재하지 않습니다.
그러나 Stateful 방화벽은 UDP도 추적합니다.
의사 연결(Pseudo-Connection)을 생성합니다.
동작 방식:
- 내부에서 외부로 UDP 패킷 전송
- (출발지, 목적지, 포트) 조합을 테이블에 기록
- 일정 시간(예: 30초) 동안 역방향 패킷 허용
- 타임아웃 후 항목 삭제
DNS 쿼리가 대표적인 예입니다.
1
2
[내부] → [8.8.8.8:53] UDP 쿼리
[8.8.8.8:53] → [내부] UDP 응답 (30초 이내이면 허용)
방화벽 규칙의 구조
방화벽 규칙은 매칭 조건과 액션으로 구성됩니다.
매칭 조건
5-tuple과 추가 조건을 검사합니다.
- 출발지 IP / 네트워크
- 목적지 IP / 네트워크
- 출발지 포트
- 목적지 포트
- 프로토콜 (TCP, UDP, ICMP 등)
- 인터페이스 (어느 인터페이스로 들어왔는가)
- 방향 (인바운드/아웃바운드)
- 연결 상태 (NEW, ESTABLISHED 등)
액션
- ACCEPT / ALLOW: 패킷 허용
- DROP: 패킷 폐기 (응답 없음)
- REJECT: 패킷 거부 (ICMP 응답 전송)
- LOG: 로그 기록
예시 규칙 (iptables 스타일)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 기존 연결의 응답 트래픽 허용
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# SSH 접속 허용 (포트 22)
-A INPUT -p tcp --dport 22 -j ACCEPT
# HTTP 접속 허용 (포트 80)
-A INPUT -p tcp --dport 80 -j ACCEPT
# HTTPS 접속 허용 (포트 443)
-A INPUT -p tcp --dport 443 -j ACCEPT
# 그 외 모든 인바운드 차단
-A INPUT -j DROP
규칙 순서의 중요성
대부분의 방화벽은 위에서 아래로 규칙을 평가하며, 먼저 매칭되는 규칙이 적용됩니다.
1
2
3
4
규칙 1: 192.168.1.10에서 오는 트래픽 허용
규칙 2: 모든 트래픽 차단
→ 192.168.1.10은 허용, 나머지는 차단
순서가 바뀌면:
1
2
3
4
규칙 1: 모든 트래픽 차단
규칙 2: 192.168.1.10에서 오는 트래픽 허용
→ 규칙 1에서 모두 차단되어 규칙 2에 도달하지 못함
일반적인 규칙 구성 순서:
- 기존 연결 허용 (ESTABLISHED, RELATED)
- 루프백 인터페이스 허용
- 특정 서비스 허용 (SSH, HTTP 등)
- 필요한 ICMP 허용 (ping 등)
- 기본 차단 (Default Deny)
계층별 필터링
L3/L4 필터링
전통적인 방화벽의 영역입니다.
- IP 주소 기반 필터링
- 포트 번호 기반 필터링
- 프로토콜 기반 필터링
한계:
- 같은 포트를 사용하는 다른 애플리케이션을 구분 못 함
- 암호화된 트래픽의 내용을 알 수 없음
- 포트 80을 사용하는 모든 것이 웹은 아님
L7 필터링 (애플리케이션 필터링)
차세대 방화벽(NGFW)이 제공합니다.
- HTTP 메서드, URL, 헤더 검사
- 애플리케이션 식별 (YouTube vs Netflix)
- 사용자 기반 정책
- 악성코드 탐지
1
2
3
4
5
6
L4 규칙: 포트 443 허용
L7 규칙: 포트 443 중에서
- 업무용 SaaS 허용
- 소셜 미디어 차단
- 파일 업로드 차단
DPI (Deep Packet Inspection)
심층 패킷 검사는 패킷의 내용까지 분석합니다.
- 패턴 매칭으로 악성 트래픽 탐지
- 프로토콜 준수 여부 검사
- 데이터 유출 방지 (DLP)
단점:
- 높은 처리 부하
- 암호화 트래픽(HTTPS 등)에서는 제한적
- 프라이버시 우려
Zone 기반 아키텍처
네트워크를 신뢰 수준이 다른 영역(Zone)으로 나눕니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
┌─────────────────────────────────────────────────────────┐
│ 인터넷 (Untrusted) │
└────────────────────────┬────────────────────────────────┘
│
┌─────┴─────┐
│ 방화벽 │
└──┬────┬───┘
│ │
┌─────────────┘ └─────────────┐
│ │
┌───────┴───────┐ ┌─────────┴───────┐
│ DMZ │ │ 내부 네트워크 │
│ (Semi-trusted)│ │ (Trusted) │
│ │ │ │
│ - 웹 서버 │ │ - 워크스테이션 │
│ - 메일 서버 │ │ - 내부 서버 │
│ - DNS 서버 │ │ - 데이터베이스 │
└───────────────┘ └─────────────────┘
DMZ (Demilitarized Zone)
비무장지대는 외부에 서비스를 제공하지만 내부 네트워크와 분리된 영역입니다.
DMZ의 특성:
- 외부에서 접근 가능
- 내부 네트워크로의 접근은 제한
- 침해되더라도 내부 네트워크는 보호
Zone 간 정책 예시
1
2
3
4
5
인터넷 → DMZ: 포트 80, 443만 허용
인터넷 → 내부: 모두 차단
DMZ → 내부: 특정 DB 포트만 허용
내부 → DMZ: 관리용 포트만 허용
내부 → 인터넷: HTTP, HTTPS 허용
핵심 원칙: 최소 권한(Least Privilege).
필요한 통신만 허용합니다.
상태 추적의 한계
상태 테이블 소진 공격
상태 테이블은 유한하기 때문에, 공격자가 대량의 연결을 생성하면 테이블이 가득 찰 수 있습니다.
1
2
3
4
공격자: 수만 개의 SYN 패킷 전송 (SYN Flood)
방화벽: 각각에 대해 상태 항목 생성
→ 상태 테이블 소진
→ 정상 연결도 처리 불가
대응:
- SYN 쿠키
- 상태 항목 타임아웃 조정
- 연결 수 제한
암호화 트래픽
HTTPS 등 암호화된 트래픽은 내용을 볼 수 없으므로 L7 필터링이 제한됩니다.
대응 (논란):
- TLS 검사 (방화벽이 중간자 역할)
- 엔드포인트 보안에 의존
- 메타데이터(SNI 등)만 검사
정리: 상태 추적이 핵심이다
현대 방화벽의 핵심은 상태 추적입니다.
NAT와 방화벽은 같은 기술을 공유합니다:
- 연결 추적 테이블
- 5-tuple 기반 식별
- 상태 기반 판단
이러한 유사성 때문에 많은 장비가 NAT와 방화벽을 통합하며, 가정용 공유기도 두 기능을 모두 제공합니다.
Part 3에서는 NAT가 만들어낸 문제, 즉 NAT 뒤의 장치끼리 어떻게 통신하는지 살펴봅니다.
관련 글