방화벽은 "허용/차단 규칙을 정하는 것"까지는 직관적인데, 막상 규칙을 짜면 "응답 패킷도 따로 열어줘야 하나?"에서 막힙니다. 이 혼란의 정체가 바로 무상태와 상태 기반의 차이입니다. 방화벽이 연결을 기억하느냐 마느냐, 거기서 모든 게 갈립니다.
핵심: 연결을 기억하느냐
방화벽은 통과하는 패킷을 규칙(출발지·목적지 IP, 포트, 프로토콜)에 맞춰 허용하거나 버립니다. 차이는 판단 방식입니다.
- 무상태(stateless): 패킷을 한 개씩 독립적으로 본다. 이전에 무슨 통신이 오갔는지 기억하지 않는다. 규칙에 맞으면 통과, 아니면 차단. 그게 전부다.
- 상태 기반(stateful): 진행 중인 연결을 추적한다. "내가 먼저 보낸 요청"에 대한 응답인지 알기 때문에, 응답 패킷은 별도 규칙 없이도 자동 허용한다.
| 구분 | 무상태(stateless) | 상태 기반(stateful) |
|---|---|---|
| 판단 단위 | 패킷 한 개씩 | 연결 흐름 전체 |
| 연결 추적 | 안 함 | 함 (연결 테이블 유지) |
| 응답 패킷 | 따로 규칙 필요 | 자동 허용 |
| 자원 사용 | 적음·빠름 | 상태 테이블만큼 더 씀 |
| 보안 수준 | 상대적으로 낮음 | 높음(위조 응답 차단) |
왜 이 차이가 중요한가
웹 서버에 접속하는 상황을 보면 차이가 분명해집니다. 내 PC가 서버의 443 포트로 요청을 보내면, 서버는 내 PC의 임의 높은 포트(예: 51234)로 응답합니다.
무상태 방화벽이라면 이 응답을 받기 위해 "들어오는 높은 포트 전부 허용" 같은 넓은 규칙을 따로 열어야 합니다. 구멍이 커지죠. 반면 상태 기반 방화벽은 "내가 먼저 나간 연결의 응답"임을 연결 테이블에서 확인하고 알아서 통과시킵니다. 그래서 규칙은 "나가는 건 허용, 들어오는 새 연결만 통제"처럼 깔끔해집니다.
로컬 터미널
# 상태 기반 규칙의 전형적 형태 (개념)
# 1) 이미 맺어진 연결의 응답은 허용
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# 2) 새로 들어오는 연결은 필요한 포트만 허용
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# 3) 나머지는 차단
iptables -A INPUT -j DROP
여기서 ESTABLISHED,RELATED가 바로 연결 추적입니다. 리눅스의 conntrack이 진행 중인 연결을 기억하기 때문에, 응답 포트를 일일이 열 필요가 없습니다.
로컬 터미널
conntrack -L | head # 현재 추적 중인 연결 목록 확인
OUTPUT
tcp ESTABLISHED src=10.0.0.5 dport=443 ...
요점 정리
- 차이의 본질은 연결을 기억하느냐 — 무상태는 패킷 단위, 상태 기반은 연결 단위로 판단한다.
- 무상태는 가볍지만 응답 패킷용 규칙을 따로 열어야 해 구멍이 커진다.
- 상태 기반은 연결 테이블로 응답을 자동 허용해 규칙이 간결하고 더 안전하다.
- 리눅스에서는
conntrack/ESTABLISHED,RELATED가 상태 추적의 핵심이다.
방화벽 규칙과 패킷 흐름을 직접 설정하며 익히는 실습은 네트워크 트랙에서 회원가입 없이 무료로 할 수 있습니다.