254. Stateful Firewall

📚 네트워크 · 패킷 분석 › 06. 방화벽 · IDS 기초 — 254편
이전 글: 253. Packet Filtering Firewall · 다음 글: 255. Application Firewall

1. 개념

Stateful Firewall(상태 기반 방화벽) 은 연결의 상태를 세션(상태) 테이블에 기억하고, 패킷을 개별이 아니라 연결의 일부로 판단하는 방화벽입니다. 세션 테이블 구조, conntrack 상태 값, 타임아웃과 테이블 용량 같은 장비 측 내용은 04 영역 185. Stateful Firewall에서 다뤘습니다.

이 글은 상태 기반 판단이 탐지·차단 결과와 로그 해석에 어떤 차이를 만드는가를 다룹니다.

상황	Packet Filtering(253. Packet Filtering Firewall)	Stateful
내부발 연결의 응답	응답용 규칙 필요	세션 테이블로 자동 허용
세션 없이 들어온 ACK 패킷	규칙에 따라 통과 가능	차단(out-of-state / invalid)
정책 평가 횟수	모든 패킷	새 연결의 첫 패킷
로그 단위	패킷	세션 시작·종료(제품 설정에 따라)

---

2. 동작 원리

TCP 연결을 기준으로 상태 기반 방화벽의 판단 흐름을 보면 다음과 같습니다.

SYN  192.168.10.25:51544 → 203.0.113.80:443
   ↓ 세션 테이블에 없음 → 정책 평가 → Allow → 세션 생성 (로그: 세션 시작)
SYN/ACK, ACK, 데이터 ...
   ↓ 세션 테이블 일치 → 정책 평가 없이 통과
FIN / RST 또는 유휴 타임아웃
   ↓ 세션 삭제 (로그: 세션 종료, 바이트 수·지속 시간·종료 사유)
이후 같은 5-tuple의 늦은 패킷
   ↓ 세션 없음 + SYN 아님 → 차단 (out-of-state)

여기서 관제에 중요한 결과가 나옵니다.

• 정책은 연결 시작 시점에만 평가됩니다. 차단 규칙을 새로 추가해도 이미 수립된 세션은 그 세션이 끝날 때까지 유지될 수 있습니다. 즉시 끊으려면 해당 세션을 세션 테이블에서 지워야 합니다(Linux는 conntrack -D).
• "차단 로그"에는 두 종류가 있습니다. 정책(규칙)에 의한 차단과, 정책과 무관하게 상태가 맞지 않아 버린 패킷입니다.

---

3. 주요 특징

세션 종료 로그의 종료 사유는 연결이 어떻게 끝났는지 알려 줍니다. 필드 이름과 값은 제품마다 다르므로 일반적인 의미로 정리합니다.

종료 사유(일반적 표현)	의미	분석 포인트
FIN 정상 종료	양쪽이 정상적으로 연결 종료	데이터 교환이 완료된 연결
RST(클라이언트/서버)	한쪽이 연결을 강제 종료	서비스 거부, 스캔 응답, 앱 오류
타임아웃(aged-out)	유휴 시간 초과로 삭제	UDP·미완성 연결에 많음
정책 차단	규칙에 의해 거부	규칙 ID 확인
위협 차단	IPS 등 보안 기능이 끊음	해당 보안 이벤트와 연결

• 세션 로그의 바이트 수는 "연결이 시도만 됐는가, 실제 데이터가 오갔는가"를 구분하는 중요한 근거입니다.
• UDP·ICMP도 상태로 관리합니다. 연결 개념이 없는 프로토콜은 "요청 후 일정 시간 안의 역방향 패킷"을 응답으로 간주합니다.
• RELATED 상태는 기존 연결과 관련된 새 흐름(예: ICMP 오류 메시지, FTP 데이터 채널)을 뜻합니다.

---

4. 예시

Linux에서 상태 기반 판단과 세션 밖 패킷을 확인하는 실습 예시입니다(Rocky는 conntrack-tools, Ubuntu는 conntrack 패키지 설치 필요, 값은 환경마다 다름).

# 현재 추적 중인 TCP 세션 중 443 포트 확인
sudo conntrack -L -p tcp --dport 443

# 특정 출발지의 기존 세션 강제 삭제 (정책 변경 후 즉시 차단이 필요할 때)
sudo conntrack -D -s 198.51.100.23

세션 밖 패킷을 별도 로그로 남기면 정책 차단과 구분하기 쉽습니다.

# 실습 예시 (nftables forward 체인 일부)
ct state invalid log prefix "FW-INVALID " drop
ct state established,related accept

# 형식 예시 — 세션 종료 로그 (값은 환경마다 다름)
2026-09-30T10:20:41 type=traffic subtype=end action=allow rule=USERS-WEB src=192.168.10.25 sport=51544 dst=203.0.113.80 dport=443 proto=tcp bytes_sent=1840 bytes_recv=48213 duration=37 end_reason=tcp-fin

---

5. 보안 관점

• 상태 기반 방화벽은 세션에 없는 패킷을 버리므로 ACK·FIN 기반 스캔이나 위조 응답 패킷에 강합니다.
• 반대로 세션 테이블 자체가 자원 고갈 공격의 대상이 됩니다. 대량의 SYN이나 UDP 흐름은 세션 테이블을 채워 정상 연결을 막을 수 있습니다.
• 긴 타임아웃은 편리하지만 열린 세션이 오래 유지되어 공격 창이 길어집니다.
• 긴급 차단 후에도 기존 세션이 살아 있는지 확인하지 않으면 차단이 무력화될 수 있습니다.

---

6. SOC 관점

관제자가 확인할 질문

• 차단 로그가 정책 차단인가, 상태 불일치 차단인가? 둘은 원인이 전혀 다릅니다.
• 허용 로그의 세션에서 실제로 몇 바이트가 오갔는가? 수십 바이트 수준이면 연결 시도에 가깝고, 수 MB 이상이면 실제 데이터 교환입니다.
• 차단 규칙 적용 시각 이후에도 같은 5-tuple 세션의 트래픽이 이어졌는가?

Alert 또는 의심 IP 확인
   ↓
방화벽 세션 시작 로그 → 어떤 규칙이 허용했는가
   ↓
세션 종료 로그 → 바이트 수·지속 시간·종료 사유
   ↓
차단 조치 후 → 세션 테이블에 잔존 세션이 없는가

오탐 주의: out-of-state 차단 로그는 공격이 아니어도 자주 발생합니다. 타임아웃 후 도착한 늦은 패킷, 비대칭 라우팅, 방화벽 재시작 직후의 기존 연결이 대표적입니다.

---

7. 핵심 정리

• Stateful Firewall은 세션 테이블로 연결을 기억하고, 새 연결의 첫 패킷만 정책으로 평가합니다.
• 정책 변경은 기존 세션에 즉시 적용되지 않을 수 있어, 긴급 차단 시 세션 삭제를 함께 확인합니다.
• 차단 로그는 정책 차단과 상태 불일치 차단을 구분해서 해석합니다.
• 세션 종료 로그의 바이트 수·지속 시간·종료 사유는 연결의 실제 결과를 보여 줍니다.
• out-of-state 이벤트는 스캔 외에도 타임아웃·비대칭 라우팅 같은 정상 원인이 많습니다.