📚 네트워크 · 패킷 분석 › 04. 네트워크 장비 실습 — 185편
이전 글: 184. Allow와 Deny · 다음 글: 186. Firewall NAT 정책

1. 개념

Stateful Firewall(상태 기반 방화벽) 은 통과를 허용한 연결을 세션(상태) 테이블에 기록해 두고, 이후 패킷이 그 연결에 속하는지를 보고 판단하는 방화벽입니다. ACL처럼 패킷 하나하나를 독립적으로 보는 방식(Stateless, 178. ACL)과 달리, "이 패킷은 누가 시작한 어떤 연결의 몇 번째 패킷인가" 를 압니다.

항목Stateless (ACL)Stateful
판단 단위패킷 하나연결(세션)
응답 트래픽 허용반대 방향 규칙을 따로 작성 (established는 플래그만 확인)세션 테이블로 자동 허용
세션 없이 도착한 ACK 패킷규칙에 따라 통과할 수 있음세션이 없으므로 새 연결로서 정책 평가 대상
장비 자원규칙만 보관세션마다 메모리 사용, 용량 한계 존재
이중화규칙만 같으면 됨세션 정보 동기화 필요

정책 설계 관점의 Stateful 방화벽은 254. Stateful Firewall에서 다루고, 이 글은 세션 테이블이라는 장비 자원과 그 운영에 집중합니다.


2. 동작 원리

Linux netfilter의 연결 추적(conntrack)을 기준으로 한 처리 흐름입니다. 상용 방화벽도 구조는 비슷합니다.

패킷 도착
   ↓
[5-tuple(프로토콜, 출발지 IP·포트, 목적지 IP·포트)로 세션 테이블 조회]
   ├─ 있음 → 상태 갱신(ESTABLISHED 등) → 세션 허용 규칙으로 빠르게 통과
   ├─ 없음 + 새 연결 시작 가능한 패킷 → NEW → 정책 규칙 평가
   │        ├─ 허용 → 세션 생성(응답 방향 튜플도 함께 기록)
   │        └─ 거부 → 폐기 (세션 생성 안 함)
   └─ 어떤 연결에도 맞지 않는 패킷 → INVALID → 보통 폐기

conntrack이 부여하는 상태 값입니다(nftables ct state, iptables --ctstate에서 사용).

상태의미예
NEW새 연결의 첫 패킷TCP SYN, 새 UDP 흐름의 첫 패킷
ESTABLISHED양방향 패킷이 확인된 연결에 속함응답 SYN/ACK 이후의 패킷
RELATED기존 연결과 관련된 새 흐름기존 연결에 대한 ICMP 오류, 헬퍼가 인식한 FTP 데이터 연결
INVALID어떤 연결로도 식별되지 않거나 비정상시퀀스·윈도 범위를 벗어난 TCP 패킷, 잘못된 플래그 조합
UNTRACKED추적 제외(notrack)로 지정된 패킷대량 트래픽 서버의 예외 처리

TCP의 경우 conntrack은 SYN_SENT → SYN_RECV → ESTABLISHED → FIN_WAIT → TIME_WAIT 같은 TCP 세부 상태도 따로 추적해, 상태마다 다른 타임아웃을 적용합니다.


3. 주요 특징

  • 세션 테이블은 유한 자원입니다. Linux는 nf_conntrack_max가 상한이며, 가득 차면 새 연결의 패킷이 버려지고 커널 로그에 nf_conntrack: table full, dropping packet이 남습니다. 상용 방화벽도 모델별 최대 동시 세션 수가 있습니다.
  • 타임아웃이 세션 수를 좌우합니다. 완료되지 않은 SYN 세션, 긴 UDP 타임아웃이 쌓이면 정상 트래픽보다 먼저 테이블을 채웁니다. SYN Flood는 이 자원을 노리는 공격입니다.
  • 비대칭 라우팅에 약합니다. 요청은 방화벽 A, 응답은 방화벽 B로 가면 B의 세션 테이블에는 해당 연결이 없어 응답이 INVALID로 차단될 수 있습니다(175. Routing 경로 분석).
  • 이중화 시 세션 동기화: Active-Standby 방화벽은 세션 정보를 동기화해야 전환 순간에 기존 연결이 끊기지 않습니다. Linux에서는 conntrackd가 이 역할을 합니다.
  • 정책 변경과 기존 세션: 허용 규칙을 삭제해도 이미 ESTABLISHED인 세션은 타임아웃이나 종료 전까지 계속 통과할 수 있습니다. 차단을 즉시 적용하려면 해당 세션을 테이블에서 지워야 합니다.

4. 예시

실습 예시 — 방화벽 VM에서 세션 테이블을 관찰합니다. conntrack 도구 설치는 49. 사설 IP · 공인 IP와 NAT — 로그의 IP가 서로 다른 이유을 참고합니다(Rocky: conntrack-tools, Ubuntu: conntrack). 값은 예시(값은 환경마다 다름)입니다.

# 현재 세션 수 / 상한
cat /proc/sys/net/netfilter/nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max

# 상태별 조회
sudo conntrack -L -p tcp --state ESTABLISHED
sudo conntrack -L -p tcp --state SYN_SENT

# CPU별 통계: insert_failed, drop, invalid 등 카운터
sudo conntrack -S

# 특정 연결 강제 삭제 (차단 정책 즉시 적용 시)
sudo conntrack -D -s 192.168.10.11 -d 10.20.0.10 -p tcp --dport 22

nftables에서 상태를 이용하는 규칙의 기본형입니다(180. DMZ의 forward 체인과 같음).

ct state established,related accept
ct state invalid counter log prefix "CT-INVALID " drop
tcp flags & (fin|syn|rst|ack) != syn ct state new counter drop   # 새 TCP 연결은 SYN으로만
ct state new iifname "ens37" tcp dport 443 accept

conntrack -L 출력 형식 예시입니다.

tcp  6 431995 ESTABLISHED src=192.168.10.11 dst=10.20.0.10 sport=51514 dport=443 src=10.20.0.10 dst=192.168.10.11 sport=443 dport=51514 [ASSURED] mark=0 use=1
tcp  6 118 SYN_SENT src=192.168.10.11 dst=10.20.0.99 sport=51600 dport=443 [UNREPLIED] src=10.20.0.99 dst=192.168.10.11 sport=443 dport=51600 mark=0 use=1

두 번째 줄의 [UNREPLIED]는 응답을 한 번도 받지 못한 세션입니다. 이런 항목이 한 출발지에서 대량으로 보이면 존재하지 않는 목적지로의 연결 시도(스캔 등)를 의심할 수 있습니다.

📷 [실습 화면 삽입 위치] 클라이언트 VM에서 여러 포트로 연결을 시도하는 동안 방화벽 VM의 watch -n1 cat /proc/sys/net/netfilter/nf_conntrack_count 값 증가와 conntrack -L 의 UNREPLIED 항목을 함께 보여 주는 화면


5. 보안 관점

  • Stateful 검사는 위조 패킷에 강합니다. 세션과 맞지 않는 패킷을 INVALID로 버리고, 새 연결은 정책 평가를 거치게 합니다. 다만 Linux conntrack은 기본값(nf_conntrack_tcp_loose=1)에서 세션 중간의 ACK 패킷도 NEW로 받아들여 추적을 시작할 수 있으므로, 위 예시처럼 "새 TCP 연결은 SYN만" 규칙을 함께 두는 것이 일반적입니다.
  • 세션 테이블 고갈은 가용성 공격입니다. 방화벽이 멀쩡해도 테이블이 가득 차면 새 연결이 모두 실패합니다. SYN 쿠키·SYN 프록시, 출발지별 동시 세션 제한, 미완성 세션 타임아웃 단축이 대응 수단입니다.
  • RELATED 허용 범위를 알고 있어야 합니다. 프로토콜 헬퍼(FTP 등)가 여는 관련 연결은 편리하지만, 헬퍼 자동 할당은 최신 커널에서 기본 비활성화되는 등 명시적으로 관리하는 방향입니다.
  • 정책에서 차단했다고 끝이 아닙니다. 이미 수립된 악성 세션은 테이블에서 지워야 끊깁니다.

6. SOC 관점

흔적의미
세션 수 급증, table full 커널 로그Flood·대량 스캔, 또는 용량 부족
INVALID 차단 로그 증가비대칭 라우팅, 세션 동기화 실패, 위조 패킷
UNREPLIED(미완성) 세션 다수응답 없는 목적지로의 대량 시도
세션 종료 로그의 지속 시간·바이트장시간 유지된 세션, 대용량 전송

관제자가 확인할 질문

  • 세션이 급증했다면 특정 출발지 몇 개가 대부분을 차지하는가?
  • INVALID 차단이 늘어난 시점에 경로 변경·방화벽 이중화 전환이 있었는가?
  • 차단 정책을 적용한 뒤에도 같은 연결의 트래픽이 보인다면, 기존 세션이 남아 있는 것은 아닌가?

오탐 주의: 방화벽 전환·재시작 직후에는 기존 연결이 세션 테이블에 없어 INVALID 차단이 일시적으로 늘어나는 것이 흔합니다. 장비 이벤트 시각과 함께 봅니다. NAT와 결합된 세션 처리는 186. Firewall NAT 정책, 세션 로그 형식은 187. Firewall Log에서 이어집니다.


7. 핵심 정리

  • Stateful Firewall은 허용한 연결을 세션 테이블에 기록하고, 이후 패킷을 세션 단위로 판단합니다.
  • conntrack 상태는 NEW·ESTABLISHED·RELATED·INVALID·UNTRACKED이며, 규칙은 보통 established·related 허용과 invalid 차단으로 시작합니다.
  • 세션 테이블은 유한 자원이므로 상한·타임아웃 관리가 필요하고, 고갈되면 새 연결이 모두 실패합니다.
  • 비대칭 라우팅과 이중화 전환은 세션 불일치로 인한 INVALID 차단을 만들며, 세션 동기화로 보완합니다.
  • 규칙을 지워도 기존 세션은 남을 수 있으므로, 차단 즉시 적용에는 세션 삭제가 필요합니다.
profile
코드에 숨겨진 위협을 읽고 AI로 보안의 미래를 설계합니다. 프론트엔드 개발 경험을 자산 삼아 더 견고하고 지능적인 보안 운영 시스템을 구축해 나가는 과정을 기록합니다

0개의 댓글