NAT와 방화벽 (2) - 방화벽의 원리와 상태 추적 - soo:bak

작성일 : 2026년 01월 20일

방화벽은 어떻게 트래픽을 필터링하는가

인터넷은 누구나 접속할 수 있는 공개 네트워크입니다. 웹 브라우저가 서버에 요청을 보내는 것과 같은 방식으로, 공격자도 아무 서버에 패킷을 보낼 수 있습니다.

1988년, 코넬 대학원생 로버트 모리스(Robert Morris)가 만든 모리스 웜(Morris Worm)이 인터넷을 통해 퍼졌습니다. 인터넷을 경유한 최초의 대규모 공격입니다.

이 웜은 Unix 시스템의 알려진 취약점을 이용해 자동으로 전파되었고, 당시 인터넷에 연결된 약 6만 대의 컴퓨터 가운데 약 6,000대를 감염시켰습니다.

이 사건을 계기로 “외부 네트워크는 기본적으로 신뢰할 수 없다“는 전제가 자리 잡았습니다. 내부 네트워크를 보호하려면, 들어오고 나가는 트래픽을 검사하여 허용할 것과 차단할 것을 구분해야 합니다.

방화벽(Firewall)이 이 역할을 맡습니다. 네트워크 트래픽을 검사하여, 관리자가 정한 규칙에 따라 허용하거나 차단하는 보안 장비입니다.

Part 1에서 살펴본 NAT의 연결 추적(Connection Tracking) 기술은 방화벽의 핵심이기도 합니다. 누가 누구와 통신 중인지를 기록하고 추적하는 원리가 동일하기 때문입니다.

방화벽의 역사

1세대: 패킷 필터링 (1980년대)

1980년대, 인터넷이 확산되면서 네트워크 보안이 화두로 떠올랐습니다. 어떤 트래픽을 허용하고 어떤 트래픽을 막을 것인가? 이 질문에 대한 첫 번째 답이 패킷 필터(Packet Filter)입니다.

패킷 필터는 각 패킷의 헤더(IP 주소, 포트 번호, 프로토콜)만 보고 허용 또는 차단을 결정합니다. 이전에 어떤 패킷이 오갔는지는 기록하지 않습니다.

덕분에 처리 속도가 빠르지만, 외부에서 패킷이 도착했을 때 그것이 내부에서 먼저 보낸 요청의 응답인지, 공격자가 일방적으로 보낸 패킷인지 구분할 수 없습니다.

2세대: 상태 기반 검사 (1990년대)

“이 패킷이 우리가 먼저 시작한 연결의 응답인가?” 1세대 패킷 필터에는 이 질문에 답할 방법이 없었습니다.

상태 기반 검사(Stateful Inspection)는 내부에서 외부로 나간 요청을 테이블에 기록하여 이 문제를 해결합니다.

외부에서 패킷이 도착하면 테이블과 대조하여, 기록된 연결의 응답인지 판단합니다.

3세대: 애플리케이션 계층 필터링 (2000년대~)

상태 기반 검사로 “누가 연결을 시작했는가”는 파악할 수 있게 되었습니다. 하지만 1세대와 2세대가 검사한 것은 IP 주소와 포트 번호, 즉 L3/L4(네트워크/전송 계층)의 정보뿐이었습니다. 연결이 허용된 뒤 그 안에서 무엇이 오가는지까지는 알 수 없었습니다.

차세대 방화벽(NGFW: Next-Generation Firewall)은 L7(애플리케이션 계층)까지 검사합니다. 패킷의 내용을 분석하여 웹 브라우징인지, 파일 전송인지, 동영상 스트리밍인지 식별하고, 같은 포트를 사용하더라도 서비스별로 다른 정책을 적용할 수 있습니다.

Stateless 방화벽

앞에서 방화벽의 발전 흐름을 살펴보았습니다. 이제 각 방식의 동작 원리를 살펴봅니다.

Stateless 방화벽은 각 패킷을 독립적으로 평가합니다. 패킷의 헤더(출발지 IP, 목적지 IP, 포트, 프로토콜)만 보고 규칙과 대조하며, 이전에 어떤 패킷이 오갔는지는 고려하지 않습니다.

패킷 1 도착 → 규칙 검사 → 허용/차단
패킷 2 도착 → 규칙 검사 → 허용/차단
패킷 3 도착 → 규칙 검사 → 허용/차단
(각 패킷은 이전 패킷의 존재를 모름)

장점

빠른 처리: 상태를 저장하거나 조회할 필요가 없어 패킷당 처리가 빠릅니다.
적은 메모리 사용: 상태 테이블을 유지하지 않으므로 메모리 소비가 낮습니다.
예측 가능한 동작: 같은 헤더를 가진 패킷은 언제나 같은 결과를 반환합니다.

단점

상태를 기억하지 않으므로, 외부에서 들어오는 패킷이 정당한 응답인지 공격인지 구분할 수 없습니다.

예를 들어, 내부 호스트가 외부 웹 서버에 접속한 상황입니다.

요청: [내부] 192.168.1.10:12345 ──► 93.184.216.34:80  [외부]
응답: [외부] 93.184.216.34:80  ──► 192.168.1.10:12345 [내부]

응답 패킷이 돌아오면, Stateless 방화벽에는 단지 “외부에서 내부로 들어오는 트래픽”으로만 보입니다. 내부에서 요청을 보냈다는 기록이 없기 때문입니다.

이 상황에서 인바운드 트래픽(외부에서 내부로 들어오는 트래픽)을 모두 허용하면, 공격자의 패킷도 함께 들어와 방화벽의 의미가 사라집니다. 반대로 모두 차단하면, 정당한 응답까지 차단되어 인터넷 사용 자체가 불가능해집니다.

“우리가 먼저 보낸 요청의 응답”과 “외부에서 일방적으로 보내는 패킷”을 구분하려면, 연결 상태를 추적해야 합니다.

Stateful 방화벽

Stateful 방화벽은 현재 활성 중인 모든 연결을 추적합니다. 각 패킷이 어떤 연결에 속하는지 판단하고, 그에 따라 허용과 차단을 결정합니다.

이를 위해 상태 테이블(State Table)을 유지합니다. Part 1에서 살펴본 NAT의 매핑 테이블과 유사한 구조로, 프로토콜, IP, 포트, 현재 상태를 항목별로 기록합니다.

상태 테이블 예시:
┌──────────────────────────────────────────────────────────┐
│  프로토콜  출발지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     │
└──────────────────────────────────────────────────────────┘

외부에서 패킷이 도착하면, 방화벽은 상태 테이블에서 매칭되는 항목을 먼저 찾습니다. 매칭되는 항목이 있으면 내부에서 시작한 연결의 응답이므로 허용하고, 없으면 규칙 검사로 넘기거나 차단합니다.

상태 테이블 조회 한 단계만으로, Stateless 방화벽에서 구분할 수 없었던 정당한 응답과 외부 공격을 구분할 수 있게 됩니다.

동작 방식

Stateful 방화벽의 핵심 동작은 두 단계로 나뉩니다.

첫째, 내부에서 외부로 나가는 패킷이 규칙 검사를 통과하면 상태 테이블에 기록합니다.

둘째, 외부에서 도착한 패킷은 상태 테이블부터 조회합니다.

아웃바운드 연결 시작:

내부에서 외부로 패킷 전송
규칙 검사 → 허용
상태 테이블에 항목 생성
패킷 전달

이 과정을 마치면 상태 테이블에 “내부가 외부에 연결을 시도했다”는 기록이 남습니다.

인바운드 응답:

외부에서 응답 패킷 도착
상태 테이블 조회 → 내부에서 시작한 연결의 응답임을 확인
상태 업데이트
패킷 전달

별도의 규칙 검사 없이, 상태 테이블 매칭만으로 통과합니다.

비정상 인바운드:

상태 테이블에 매칭 항목이 없는 외부 패킷이 도착하면, 내부에서 먼저 시작한 연결이 아니라는 뜻입니다. 외부에서 일방적으로 보낸 패킷이므로 차단합니다.

이 흐름을 한눈에 보면 다음과 같습니다.

               ┌───────────────┐
패킷 도착 ───►│ 상태 테이블   │
               │     조회      │
               └───────┬───────┘
                       │
          ┌────────────┴────────────┐
          │                         │
     매칭 있음                  매칭 없음
          │                         │
          ▼                         ▼
    ┌───────────┐            ┌──────────┐
    │ 상태 전이 │            │  규칙    │
    │   검증    │            │  검사    │
    └─────┬─────┘            └────┬─────┘
          │                       │
     ┌────┴────┐             ┌────┴────┐
     │         │             │         │
   정상 전이  비정상       허용       차단
     │         │             │
     ▼         ▼             ▼
   상태      차단         새 항목
   업데이트                생성

다이어그램의 “상태 전이 검증”은 연결의 현재 상태와 도착한 패킷을 대조하여, 정상적인 다음 단계인지 확인하는 과정입니다.

예를 들어, TCP 연결이 SYN_SENT 상태(연결 시도 중)일 때 SYN-ACK가 도착하면 정상 전이입니다. 상태를 업데이트하고 패킷을 전달합니다. 반면, 현재 상태에서 올 수 없는 패킷이 도착하면 비정상으로 판단하여 차단합니다.

UDP처럼 연결 수립 절차가 없는 프로토콜은 상태 머신 자체가 존재하지 않습니다. 이 경우 방화벽이 자체적으로 가상의 연결 기록을 만들고 타임아웃으로 관리합니다.

TCP 연결 상태 추적

상태 테이블에 기록되는 “상태”는 구체적으로 어떤 값일까요?

TCP 연결에는 시작, 수립, 종료라는 명확한 단계가 있습니다. 각 단계에서 주고받는 패킷의 종류도 정해져 있어, “현재 상태”와 “도착한 패킷”의 조합이 “다음 상태”를 결정합니다. 이처럼 정해진 상태들과 입력에 따른 전이로 동작을 기술하는 모델을 상태 머신(State Machine)이라고 합니다.

Stateful 방화벽은 이 상태 머신을 기준으로 각 연결의 진행 단계를 추적합니다. TCP 연결은 SYN_SENT → ESTABLISHED → FIN_WAIT처럼 정해진 순서대로 상태가 바뀌며, 방화벽은 이 전이 규칙에 맞지 않는 패킷을 비정상으로 판단합니다.

방화벽은 3-way 핸드셰이크(SYN → SYN-ACK → ACK)의 각 단계에서 상태를 갱신합니다.

단계	패킷	상태 테이블 변화	의미
1	SYN	NEW 또는 SYN_SENT	연결 시도 시작
2	SYN-ACK	SYN_RECV	상대방이 연결 수락
3	ACK	ESTABLISHED	연결 수립 완료
4	FIN	종료 시작 측: FIN_WAIT → TIME_WAIT, 상대 측: CLOSE_WAIT → LAST_ACK	연결 종료 과정
5	(종료 완료)	항목 삭제	상태 테이블에서 제거

핵심은 ESTABLISHED 상태에 도달한 연결만 양방향 트래픽이 허용된다는 점입니다.

TCP 연결은 반드시 SYN으로 시작해야 합니다. SYN 없이 ACK만 도착하면 상태 테이블에 매칭되는 항목이 없고, 정상적인 핸드셰이크를 거치지 않은 패킷이므로 즉시 차단됩니다.

UDP의 상태 추적

TCP는 핸드셰이크와 종료 절차가 명확하므로 상태 머신으로 추적할 수 있었습니다. UDP에는 연결 수립 절차가 없고, 단순히 패킷을 보내고 받을 뿐이므로 추적할 연결 상태 자체가 존재하지 않습니다.

Stateful 방화벽은 UDP 트래픽에 대해 의사 연결(Pseudo-Connection)을 만들어 이 문제를 해결합니다. 의사 연결은 프로토콜이 제공하는 실제 연결이 아니라, 방화벽이 자체적으로 생성하는 가상의 연결 기록입니다.

내부에서 외부로 UDP 패킷 전송
(출발지, 목적지, 포트) 조합을 상태 테이블에 기록
일정 시간 동안 역방향 패킷 허용 (구현에 따라 다르지만, 보통 30초 내외)
타임아웃이 지나면 항목 삭제

TCP는 명시적인 종료 절차(FIN)가 있어서 연결이 끝났는지 확인할 수 있지만, UDP에는 종료 신호가 없습니다. “일정 시간 동안 패킷이 없으면 끝난 것으로 간주”하는 것이 유일한 기준이므로, 타임아웃을 짧게 잡아 불필요한 항목을 빠르게 정리합니다.

예를 들어, DNS 쿼리의 경우입니다.

[내부] 192.168.1.10:53214 → [8.8.8.8:53]  UDP 쿼리 "example.com의 IP는?"
        → 상태 테이블에 기록

[8.8.8.8:53] → [내부] 192.168.1.10:53214  UDP 응답 "93.184.216.34입니다"
        → 상태 테이블에 매칭 → 허용 (타임아웃 이내)

방화벽 규칙의 구조

어떤 패킷을 허용하고 어떤 패킷을 차단할 것인가는 방화벽 규칙에 정의됩니다. 규칙은 두 부분으로 나뉩니다. 패킷이 조건에 해당하는지 판단하는 매칭 조건, 그리고 해당하면 어떻게 처리할 것인지 지정하는 액션입니다.

매칭 조건

Part 1에서 NAT가 연결을 식별할 때 사용한 5-tuple(출발지 IP, 목적지 IP, 출발지 포트, 목적지 포트, 프로토콜)을 기본으로, 다음 조건을 조합하여 패킷을 식별합니다.

인터페이스 — 패킷이 외부망과 내부망 중 어느 쪽에서 들어왔는지 구분합니다.
방향 — 인바운드(외부→내부)인지 아웃바운드(내부→외부)인지 구분합니다.
연결 상태 — NEW, ESTABLISHED 등 상태 테이블의 현재 상태를 기준으로 판단합니다.

액션

매칭된 패킷에 대해 다음 중 하나의 처리를 지정합니다.

ACCEPT / ALLOW — 패킷을 허용합니다.
DROP — 패킷을 폐기합니다. 송신자에게 아무런 응답도 보내지 않으므로, 외부에서는 장비의 존재 여부를 알기 어렵습니다.
REJECT — 패킷을 거부하고, ICMP 응답을 송신자에게 보냅니다. 정상 사용자는 거부 원인을 파악할 수 있지만, 장비의 존재도 드러납니다.
LOG — 패킷 정보를 로그에 기록합니다. 보통 다른 액션과 함께 사용하여 감사 추적(audit trail)에 활용합니다.

예시 규칙 (iptables 스타일)

Linux에 내장된 방화벽 도구인 iptables의 규칙은 조건 나열 → 액션 지정 순서로 구성됩니다.

-A INPUT -p tcp --dport 80 -j ACCEPT
         ──── 조건 ─────    ─ 액션 ─

플래그	값	설명
`-A`	`INPUT`	규칙을 추가할 체인. INPUT은 외부에서 들어오는 패킷
`-p`	`tcp`, `udp` 등	프로토콜 조건
`--dport`	포트 번호	목적지 포트 조건 (예: `80` = HTTP, `443` = HTTPS)
`-m state --state`	`NEW`, `ESTABLISHED`, `RELATED` 등	상태 추적 모듈로 연결 상태를 조건으로 지정
`-j`	`ACCEPT`, `DROP` 등	액션 지정. ACCEPT는 허용, DROP은 폐기(응답 없음)

이 플래그들을 조합하면 다음과 같은 규칙 세트를 만들 수 있습니다.

# 기존 연결의 응답 트래픽 허용
-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

ESTABLISHED,RELATED 규칙이 가장 먼저 위치하는 이유가 있습니다. 이미 허용된 연결의 패킷은 이후 규칙을 검사할 필요 없이 바로 통과시킬 수 있기 때문입니다.

ESTABLISHED — 이미 수립된 연결에 속하는 패킷. 내부에서 시작한 연결의 응답 트래픽이 해당됩니다.
RELATED — 허용된 연결에서 파생된 새로운 연결. 예를 들어 FTP는 제어 연결(명령)과 데이터 연결(파일 전송)을 별도로 사용하는데, 데이터 연결은 제어 연결에서 파생되므로 RELATED로 분류됩니다.

규칙 순서의 중요성

대부분의 방화벽은 규칙을 위에서 아래로 평가합니다. 패킷이 어떤 규칙에 먼저 매칭되면 그 규칙의 액션을 적용하고, 이후 규칙은 검사하지 않습니다. 같은 규칙이라도 순서에 따라 결과가 달라집니다.

[순서 A]                              [순서 B]
규칙 1: 192.168.1.10 허용             규칙 1: 모든 트래픽 차단
규칙 2: 모든 트래픽 차단              규칙 2: 192.168.1.10 허용

→ 192.168.1.10 허용, 나머지 차단      → 규칙 1에서 모두 차단, 규칙 2에 도달 불가

실무에서는 보통 다음 순서로 규칙을 구성합니다.

기존 연결 허용 (ESTABLISHED, RELATED) — 실제 트래픽의 대부분은 이미 수립된 연결의 패킷이므로, 가장 먼저 배치하여 이후 규칙 검사를 생략합니다.
루프백 인터페이스 허용 — 장비가 자기 자신과 통신하는 루프백(loopback, 127.0.0.1)은 외부 네트워크를 거치지 않으므로 항상 허용합니다.
특정 서비스 허용 — SSH, HTTP 등 외부에 노출할 서비스 포트를 열어줍니다.
필요한 ICMP 허용 — ping 등 네트워크 진단에 필요한 트래픽을 허용합니다.
기본 차단 (Default Deny) — 위의 어떤 규칙에도 매칭되지 않은 패킷은 모두 차단합니다. 명시적으로 허용하지 않은 것은 전부 거부하는 원칙이므로, 새 서비스를 추가할 때는 이 규칙보다 위에 허용 규칙을 배치해야 합니다.

계층별 필터링

방화벽이 패킷의 어느 계층까지 검사하느냐에 따라 필터링의 정밀도가 달라집니다.

L3/L4 필터링

L3(네트워크 계층)의 IP 주소, L4(전송 계층)의 포트 번호와 프로토콜(TCP/UDP)을 기준으로 트래픽을 걸러내는 방식입니다. 전통적인 방화벽 대부분이 이 수준에서 동작합니다.

하지만 포트 번호만으로는 서비스를 정확히 식별할 수 없습니다.

포트 443(HTTPS) 하나에 업무용 클라우드, 동영상 스트리밍, 소셜 미디어가 공존하지만, L4 필터링은 “포트 443”이라는 숫자만 볼 뿐 어떤 서비스인지 구분하지 못합니다. 악성 프로그램이 포트 80이나 443 같은 정상 포트로 위장하는 경우에도 마찬가지입니다.

L7 필터링 (애플리케이션 필터링)

L7(애플리케이션 계층)은 HTTP, FTP 등 실제 서비스가 동작하는 최상위 계층입니다. NGFW는 패킷의 페이로드(헤더를 제외한 실제 데이터 부분)까지 분석하여, 포트 번호가 아닌 애플리케이션 단위로 트래픽을 제어합니다.

HTTP 메서드, URL, 헤더 검사 — 같은 웹 트래픽이라도 GET/POST, 요청 URL 등을 기준으로 세분화
애플리케이션 식별 — 같은 포트 443을 사용하더라도 YouTube, Netflix, Slack 등을 구분
사용자 기반 정책 — IP 주소가 아닌 로그인한 사용자 계정 기준으로 정책 적용
악성코드 탐지 — 페이로드 내용을 분석하여 악성 패턴을 식별

포트 443에 대해 L4와 L7의 차이를 비교하면 다음과 같습니다.

[L4] 포트 443 허용 → 모든 HTTPS 트래픽이 통과

[L7] 포트 443 중에서
     - 업무용 SaaS   → 허용
     - 소셜 미디어   → 차단
     - 파일 업로드   → 차단

L4는 포트 443을 통째로 허용하거나 차단할 수밖에 없지만, L7은 같은 포트 안에서 서비스별로 정책을 달리할 수 있습니다.

DPI (Deep Packet Inspection)

심층 패킷 검사(DPI, Deep Packet Inspection)는 페이로드의 바이트 내용 자체를 정밀 분석합니다. 애플리케이션을 식별하는 L7 필터링과 달리, 데이터가 악성인지, 규격에 맞는지까지 검사합니다.

패턴 매칭으로 악성 트래픽 탐지 — 알려진 악성코드의 바이트 패턴이나 공격 문자열을 데이터베이스에 유지하고, 패킷 내용을 이 패턴과 대조합니다.
프로토콜 준수 여부 검사 — 패킷이 해당 프로토콜의 규격에 맞는지 확인합니다.
데이터 유출 방지(DLP) — 주민등록번호, 신용카드 번호 등 민감 데이터가 외부로 유출되는 것을 탐지하고 차단합니다.

다만 페이로드 전체를 분석하므로 대가가 따릅니다.

처리 부하 — 모든 패킷의 내용을 분석하므로 CPU와 메모리 소비가 큽니다.
암호화 트래픽의 한계 — HTTPS 등 암호화된 트래픽은 내용을 볼 수 없어 효과가 제한됩니다.
프라이버시 우려 — 통신 내용을 들여다보므로 사용자 프라이버시 침해 논란이 뒤따릅니다.

Zone 기반 아키텍처

개별 IP와 포트 단위로 규칙을 작성하면, 규칙이 수백 개로 늘어났을 때 관리가 어려워집니다.

방화벽은 네트워크를 신뢰 수준이 다른 영역(Zone)으로 나누어 이 문제를 해결합니다. 개별 IP가 아닌 영역 단위로 정책을 정의하므로 규칙 수가 줄어듭니다.

┌─────────────────────────────────────────────────────────┐
│                     인터넷 (Untrusted)                  │
└────────────────────────┬────────────────────────────────┘
                         │
                   ┌─────┴─────┐
                   │  방화벽   │
                   └──┬────┬───┘
                      │    │
        ┌─────────────┘    └─────────────┐
        │                                │
┌───────┴───────┐              ┌─────────┴───────┐
│     DMZ       │              │  내부 네트워크   │
│ (Semi-trusted)│              │    (Trusted)    │
│               │              │                 │
│ - 웹 서버     │              │ - 워크스테이션  │
│ - 메일 서버   │              │ - 내부 서버     │
│ - DNS 서버    │              │ - 데이터베이스  │
└───────────────┘              └─────────────────┘

DMZ (Demilitarized Zone)

DMZ는 군사 용어인 “비무장지대”에서 유래한 이름입니다. 외부 인터넷과 내부 네트워크 사이의 완충 구역입니다.

웹 서버나 메일 서버는 외부에 서비스를 제공해야 하지만, 내부 네트워크에 함께 두기에는 위험합니다. 이 서버들을 DMZ에 배치합니다.

외부에서 DMZ로의 접근은 허용됩니다.
DMZ에서 내부 네트워크로의 접근은 엄격히 제한됩니다. DMZ 서버가 해킹당하더라도 공격자가 데이터베이스나 직원 PC까지 침투하는 것을 막기 위해서입니다.

Zone 간 정책 예시

인터넷 → DMZ:       포트 80, 443만 허용
인터넷 → 내부:      모두 차단
DMZ → 내부:         특정 DB 포트만 허용
내부 → DMZ:         관리용 포트만 허용
내부 → 인터넷:      HTTP, HTTPS 허용

공통 원칙은 최소 권한(Least Privilege)입니다. Zone 사이에는 필요한 통신만 허용하고, 나머지는 전부 차단합니다.

상태 추적의 한계

상태 추적에는 두 가지 구조적 한계가 있습니다.

상태 테이블 소진 공격

상태 테이블의 크기는 유한합니다. 수십만에서 수백만 항목을 저장할 수 있지만, 공격자가 대량의 연결을 동시에 생성하면 테이블이 가득 차서 정상 연결까지 처리할 수 없게 됩니다.

대표적인 공격이 SYN Flood입니다. 3-way 핸드셰이크의 첫 단계(SYN)만 대량으로 보내고 나머지를 완료하지 않아, 미완성 연결로 상태 테이블을 소진시킵니다.

공격자: 수만 개의 SYN 패킷 전송
방화벽: 각 SYN에 대해 상태 항목 생성 (상태: SYN_SENT)
        → 공격자는 SYN-ACK에 응답하지 않음 (연결 완료 의사 없음)
        → 미완성 연결이 테이블을 가득 채움
        → 정상 사용자의 새 연결도 처리 불가

대응책은 세 가지입니다.

SYN 쿠키 — SYN을 받아도 상태 항목을 즉시 생성하지 않습니다. 대신 연결 정보(IP 주소, 포트, 타임스탬프 등)를 암호학적 해시 함수로 계산하여 SYN-ACK의 초기 시퀀스 번호에 인코딩합니다. 상대방이 정상적인 ACK를 보내오면, 서버는 같은 해시를 다시 계산하여 유효성을 검증한 뒤 비로소 상태 항목을 생성합니다. 미완성 연결이 테이블을 차지하지 않습니다.
상태 항목 타임아웃 조정 — 미완성 연결의 만료 시간을 짧게 잡아 빠르게 정리합니다.
연결 수 제한 — 동일한 출발지 IP에서 생성할 수 있는 동시 연결 수에 상한을 둡니다.

암호화 트래픽

HTTPS 등 암호화된 트래픽은 페이로드를 복호화하지 않는 한 내용을 볼 수 없으므로, L7 필터링과 DPI의 효과가 제한됩니다. 보완 방법은 세 가지입니다.

TLS 검사 — 방화벽이 클라이언트와 서버 사이에서 중간자(Man-in-the-Middle) 역할을 합니다. 암호화를 풀고, 내용을 검사한 뒤, 다시 암호화하여 전달합니다. 다만 사용자의 통신 내용을 기업이 열람할 수 있어 프라이버시 논란이 따르고, 인증서 관리도 복잡해집니다.
엔드포인트 보안 — 각 사용자의 PC나 서버에 보안 소프트웨어를 설치하여, 암호화 전/후의 데이터를 검사합니다.
메타데이터 검사 — 페이로드를 복호화하지 않고, 암호화되지 않은 부가 정보만으로 판단합니다. 대표적인 예가 SNI(Server Name Indication)입니다. TLS 핸드셰이크의 첫 메시지(ClientHello)에서 클라이언트는 접속할 서버 이름을 보내는데, 이 시점에는 아직 암호화가 시작되지 않았으므로 서버 이름이 평문으로 노출됩니다. 방화벽은 이 SNI 값을 읽어 접속 대상을 식별합니다. L7 필터링이 복호화된 페이로드(HTTP 헤더, URL 등)를 분석하는 것과 달리, SNI 검사는 암호화를 풀지 않고도 “어디에 접속하는가”를 알 수 있습니다. 다만 내용까지는 볼 수 없으므로, 서비스 단위의 허용/차단만 가능합니다.

마무리

패킷 필터 → 상태 기반 검사 → NGFW로 방화벽은 진화해 왔으며, 핵심은 상태 추적
NAT와 방화벽은 연결 추적 테이블, 5-tuple 식별, 상태 기반 판단이라는 동일한 기술 기반을 공유
Zone 아키텍처로 신뢰 수준을 분리하고, 최소 권한 원칙으로 Zone 간 통신을 통제
상태 추적에도 한계가 있으며, 상태 테이블 소진 공격이나 암호화 트래픽이 대표적인 과제

두 기능은 같은 연결 추적 테이블 위에서 동작하므로, 대부분의 장비가 NAT와 방화벽을 하나로 통합합니다. 가정용 공유기도 두 기능을 함께 제공합니다.

NAT는 외부에서 내부로의 직접 연결을 차단합니다. 보안에는 유리하지만, 화상 통화처럼 두 사용자가 직접 통신해야 하는 상황에서는 문제가 됩니다. 두 사용자가 각각 NAT 뒤에 있다면, 양쪽 모두 외부에서 들어오는 연결이 차단되므로 어느 쪽도 상대방에게 먼저 연결할 수 없습니다.

Part 3에서는 STUN, TURN, ICE 같은 NAT 트래버설 기법과 P2P 통신이 어떻게 이루어지는지 살펴봅니다.

관련 글

시리즈