[Networking] 운영 서버 접속 장애 진단: iptables INPUT 체인 완전 분석

같은 훅 포인트를 여러 테이블이 공유합니다. 예를 들어 PREROUTING 훅에는 raw, mangle, nat 테이블이 모두 걸려있습니다. 우선순위 순서로 raw가 가장 먼저, nat이 가장 나중에 실행됩니다. 왜 하나로 합치지 않았을까요? 패킷에 해야 할 작업의 성격이 완전히 다르기 때문입니다.

확대

filter 테이블 — 허용/차단 판단

오늘 다루는 테이블입니다. "이 패킷을 통과시킬 것인가, 버릴 것인가"만 판단합니다. INPUT, FORWARD, OUTPUT 체인이 있습니다. iptables -L의 기본값이 이 테이블입니다. -t filter를 생략해도 filter 테이블이 선택됩니다.

iptables -L INPUT -n          # -t filter 생략, 기본값으로 filter 선택
iptables -t filter -L INPUT -n  # 명시적으로 filter 테이블 지정, 동일한 결과

nat 테이블 — 주소 변환

패킷의 소스나 목적지 IP/포트를 바꿉니다. 포트 포워딩이 이 테이블에서 일어납니다.

# 외부 포트 80을 내부 서버 8080으로 포워딩 (DNAT)
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.1.10:8080

# 내부 서버들이 외부로 나갈 때 공인 IP로 위장 (MASQUERADE/SNAT)
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

mangle 테이블 — 패킷 헤더 수정

TTL 조작, ToS 마킹, QoS 우선순위 설정 등 패킷 자체를 변형합니다. 일반 서버에서는 거의 쓸 일이 없습니다.

# 나가는 패킷의 TTL을 64로 고정 (망 사업자 검출 우회 등에 사용)
iptables -t mangle -A OUTPUT -j TTL --ttl-set 64

raw 테이블 — conntrack 제외

특정 패킷을 연결 추적(conntrack)에서 제외합니다. conntrack은 모든 연결을 추적하는 비용이 있습니다. 초고속 트래픽 처리 서버(DDoS 방어 장비 등)에서 conntrack 오버헤드를 줄이는 용도입니다.

# UDP 53번 포트(DNS) 트래픽을 conntrack에서 제외
iptables -t raw -A PREROUTING -p udp --dport 53 -j NOTRACK

오늘 장애와 관련된 것은 전부 filter 테이블의 INPUT 체인입니다. 다른 테이블은 이번 장애 원인이 아닙니다.

세 체인이 헷갈리는 이유는 이름이 직관적이지 않기 때문입니다. 기준은 하나입니다. 패킷의 출발지와 목적지 중 이 서버 자신이 있는가, 없는가.

INPUT 체인

외부에서 이 서버로 들어오는 트래픽이 통과하는 체인입니다. 정확히는 "이 서버의 프로세스가 수신하는 패킷"입니다. SSH 클라이언트가 보낸 SYN 패킷, HTTP 요청, 데이터베이스 쿼리 — 이 서버에 접속하려는 모든 패킷이 INPUT을 통과합니다. 오늘 장애의 핵심입니다.

오해하기 쉬운 것: "서버에서 나가는 응답 패킷도 INPUT인가?" — 아닙니다. 응답 패킷은 OUTPUT 체인을 통과합니다. 하지만 그 응답에 대한 클라이언트의 ACK는 다시 INPUT을 통과합니다.

OUTPUT 체인

이 서버의 프로세스가 시작하는 아웃바운드 트래픽이 통과하는 체인입니다. curl, apt install, git clone, 데이터베이스 클라이언트가 외부 DB에 접속하는 것 — 이 서버가 먼저 연결을 시작하는 모든 것이 OUTPUT을 통과합니다.

# OUTPUT에 DROP이 있으면 서버에서 외부로 어떤 요청도 보낼 수 없습니다
iptables -A OUTPUT -p tcp --dport 443 -j DROP
# 이 규칙이 있으면 서버에서 https로 접근하는 apt, curl, pip 등이 전부 실패합니다

FORWARD 체인

이 서버를 거쳐 다른 목적지로 전달되는 트래픽이 통과하는 체인입니다. 이 서버가 출발지도 목적지도 아닐 때 사용됩니다. 라우터나 게이트웨이 역할, 또는 Docker가 컨테이너로 트래픽을 전달할 때 FORWARD 체인이 관여합니다.

# Docker를 사용하면 FORWARD 체인에 자동으로 규칙이 생깁니다
iptables -L FORWARD -n
# Docker 컨테이너로 가는 트래픽 허용 규칙이 자동 생성된 것을 볼 수 있습니다

일반 웹 서버로만 사용하는 경우 FORWARD는 기본 DROP으로 두면 됩니다.

정리

오늘 장애: 외부 개발팀 → 서버 SSH(22) → INPUT 체인에서 차단.

단순한 방화벽은 패킷 하나하나를 독립적으로 봅니다. "포트 22 TCP면 허용, 아니면 차단"처럼 패킷의 현재 정보만 판단합니다. 이것을 stateless 방화벽이라고 합니다.

iptables는 여기서 더 나아가 연결의 **상태(state)**를 추적합니다. 이것이 stateful 방화벽입니다. 커널의 nf_conntrack 모듈이 현재 활성화된 모든 연결을 메모리 테이블에 기록합니다.

현재 추적 중인 연결을 직접 볼 수 있습니다.

cat /proc/net/nf_conntrack
# 또는
conntrack -L 2>/dev/null || cat /proc/net/ip_conntrack

tcp  6 431999 ESTABLISHED src=203.0.113.5 dst=10.0.0.1 sport=52341 dport=22
     src=10.0.0.1 dst=203.0.113.5 sport=22 dport=52341 [ASSURED] mark=0 use=1

이 출력은 203.0.113.5:52341 → 서버:22 의 SSH 연결이 ESTABLISHED 상태임을 보여줍니다. conntrack이 이 정보를 가지고 있기 때문에 응답 패킷이 INPUT 체인에 도달했을 때 "이것은 이미 수립된 연결의 응답"임을 알 수 있습니다.

각 패킷에 붙는 conntrack 상태입니다.

NEW — 새 연결을 시작하는 첫 번째 패킷. TCP라면 SYN 패킷이 여기 해당합니다. 서버에 처음 접속을 시도하는 패킷입니다.

ESTABLISHED — 이미 수립된 연결의 패킷. SYN-ACK 이후의 모든 패킷입니다. 서버가 curl로 외부에 요청을 보내면, 그 응답 패킷은 ESTABLISHED 상태로 INPUT 체인에 도달합니다.

RELATED — 기존 연결과 관련된 새 연결의 패킷. FTP 활성 모드의 데이터 채널, ICMP 에러 응답 등이 해당합니다.

INVALID — conntrack이 어떤 연결에도 속하지 않는다고 판단한 패킷. 손상된 패킷, 보안 스캔 패킷, 연결 추적 테이블에서 만료된 연결의 패킷 등입니다.

확대

실제 서버 규칙에서 자주 보이는 패턴입니다.

ACCEPT  all  --  *  *  0.0.0.0/0  0.0.0.0/0  state RELATED,ESTABLISHED

이 규칙 하나가 없으면 어떻게 될까요? policy DROP 환경에서 apt install nginx를 실행해봅니다.

1. 서버 → 외부 apt 서버: SYN 패킷 (OUTPUT 체인 통과, 허용)
2. 외부 apt 서버 → 서버: SYN-ACK 패킷 (INPUT 체인 도달)
3. INPUT 체인에 ESTABLISHED 허용 규칙 없음 → policy DROP → SYN-ACK 차단
4. apt가 응답을 받지 못해 타임아웃

결과: curl google.com, apt update, git clone, pip install 전부 실패합니다. 서버가 외부와 통신하는 거의 모든 것이 동작하지 않습니다.

# ESTABLISHED,RELATED 규칙이 있는지 확인
iptables -L INPUT -n | grep -i established
# 아무것도 안 나오면 이 규칙이 없는 것 — 서버에서 외부로 요청하는 모든 것이 응답을 못 받음

INVALID 패킷 처리

INVALID 패킷은 명시적으로 DROP하는 것이 권장됩니다.

iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

이 패킷들을 ACCEPT하면 손상된 패킷이나 보안 스캔 트래픽이 서비스에 영향을 줄 수 있습니다.

conntrack 테이블 포화 문제

트래픽이 많은 서버에서 conntrack 테이블이 가득 차면 새 연결이 전부 실패합니다.

# 현재 conntrack 사용량 확인
cat /proc/sys/net/netfilter/nf_conntrack_count   # 현재 추적 중인 연결 수
cat /proc/sys/net/netfilter/nf_conntrack_max     # 최대 허용 연결 수

nf_conntrack: table full, dropping packet

이 로그가 /var/log/kern.log에 나오면 conntrack 테이블이 포화 상태입니다. 해결은 nf_conntrack_max 값을 늘리거나, 불필요한 연결 추적을 raw 테이블에서 제외하는 것입니다.

체인의 기본 정책(policy)은 "어떤 규칙에도 매칭되지 않은 패킷을 최종적으로 어떻게 처리하는가"를 결정합니다.

policy ACCEPT — 블랙리스트 방식

기본이 허용이고, 명시적으로 막은 것만 차단합니다. 새 서비스를 올릴 때 방화벽 규칙을 추가할 필요가 없습니다. 하지만 누군가 실수로 백도어 포트를 열거나, 예상치 못한 서비스가 포트를 열어도 기본적으로 허용됩니다. 규칙을 잘못 추가해도 서비스가 중단되지 않습니다. 개발 환경에서 편의를 위해 쓰기도 하지만 운영 서버에는 권장하지 않습니다.

policy DROP — 화이트리스트 방식

기본이 차단이고, 명시적으로 허용한 것만 통과합니다. 새 서비스를 올리면 반드시 방화벽 규칙도 함께 추가해야 합니다. 실수로 서비스를 추가해도 방화벽이 자동으로 차단합니다. 규칙 관리가 엄격해야 하지만 보안 수준이 높습니다. 운영 서버의 표준 설정입니다.

중요한 것: policy DROP은 -j DROP 규칙이 아닙니다. -P INPUT DROP 명령으로 설정하는 체인의 기본 정책입니다. 두 가지는 동작 방식이 다릅니다.

# policy DROP 설정 (아무 규칙에도 매칭 안 된 패킷의 기본 처리)
iptables -P INPUT DROP

# 명시적 DROP 규칙 (규칙 평가 중 이 규칙에 매칭된 패킷 차단)
iptables -A INPUT -j DROP

오늘 장애 서버는 policy DROP입니다. policy DROP 환경에서 SSH 허용 규칙이 없으면 SSH는 무조건 차단됩니다.

iptables의 규칙 평가 알고리즘은 단순하지만 치명적인 함정이 있습니다.

for 규칙 in 체인:
    if 패킷이 규칙의 조건에 매칭됨:
        규칙의 타깃(ACCEPT/DROP/REJECT/LOG/...) 실행
        평가 종료  ← 이후 규칙은 절대 보지 않음
        
어떤 규칙에도 매칭 안 됨 → policy 적용

이것 때문에 같은 규칙이라도 위치에 따라 결과가 완전히 달라집니다.

# 케이스 A — SSH 됨
1: ACCEPT tcp dpt:22    ← SSH 패킷이 여기서 ACCEPT. 평가 종료.
2: DROP   all           ← 이 규칙은 SSH 패킷에게 평가되지 않음

# 케이스 B — SSH 안 됨 (오늘 장애 상황)
1: DROP   all           ← SSH 패킷이 여기서 DROP. 평가 종료.
2: ACCEPT tcp dpt:22    ← 영원히 평가되지 않음

확대

케이스 B에서 pkts를 확인해보면:

1  9201  1.2M  DROP   all  -- * * 0.0.0.0/0  0.0.0.0/0
2     0     0  ACCEPT tcp  -- * * 0.0.0.0/0  0.0.0.0/0  tcp dpt:22

2번 규칙의 pkts가 0입니다. 한 번도 평가된 적이 없다는 뜻입니다. 이 패턴이 보이면 규칙 순서 문제입니다.

-I INPUT 1로 맨 앞에 삽입하는 이유가 바로 이것입니다. -A(Append)로 끝에 추가하면 이미 앞에 있는 DROP 규칙에 막힐 수 있습니다. -I INPUT 1은 어떤 규칙이 있든 맨 앞에 오므로 안전합니다.

지금까지 훅·테이블·체인·conntrack·규칙 순서를 따로 봤습니다. 하지만 실제로 SSH 패킷 하나가 서버에 도착하면 이 조각들이 정해진 순서로 한 번에 작동합니다. 이 순서를 통째로 따라가면 "SSH가 왜 막혔나"를 어느 단계에서 끊겼는지로 좁힐 수 있습니다.

[외부에서 SSH SYN 도착]  dst = 이 서버:22
   │
   ① NIC 수신 → PREROUTING (nat 테이블)
   │     DNAT·리다이렉트가 있으면 여기서 목적지가 바뀜
   │
   ② 라우팅 판단: 목적지가 "이 서버 자신"인가?
   │     ├─ 예(로컬 프로세스행)   → INPUT 체인으로
   │     └─ 아니오(경유·전달)     → FORWARD 체인으로
   │
   ③ INPUT 체인 규칙을 1번부터 순차 평가
   │     매 규칙마다 "이 패킷이 조건에 맞나?" 대조
   │
   ④ 첫 매칭 규칙의 타깃 실행 → 즉시 평가 종료
   │     ACCEPT(통과) / DROP(무응답 폐기) / REJECT(거부 응답)
   │
   ⑤ 어떤 규칙에도 안 맞으면 → 체인 기본 정책(policy)
   │     policy DROP이면 조용히 폐기
   ▼
[④에서 ACCEPT된 경우만] sshd 프로세스로 전달

각 단계에서 무슨 일이 일어나고, 막히면 어떤 증상인가:

즉 "SSH 접속 성공"은 ②에서 INPUT으로 분기되고 ④에서 ACCEPT를 만난다는 뜻입니다. 접속이 안 될 때는 iptables -L INPUT -n -v --line-numbers로 policy와 규칙 순서를 읽어 이 중 어느 단계에서 끊겼는지 좁힙니다 — pkts가 0인 ACCEPT 규칙이 보이면 ③ 순서 함정, dpt:22 규칙 자체가 없으면 ⑤ 정책 차단입니다. 증상까지 갈리는데, 무응답 timeout이면 DROP, 즉시 refused면 REJECT입니다.

특정 IP 또는 대역에서만 SSH를 허용하는 규칙입니다.

# 단일 IP에서만 SSH 허용
iptables -I INPUT 1 -p tcp --dport 22 -s 203.0.113.5 -j ACCEPT

# 특정 CIDR 대역에서만 허용 (사무실 네트워크 예시)
iptables -I INPUT 1 -p tcp --dport 22 -s 203.0.113.0/24 -j ACCEPT

# 여러 IP 대역을 허용할 때는 규칙을 여러 개 추가
iptables -I INPUT 1 -p tcp --dport 22 -s 203.0.113.0/24 -j ACCEPT
iptables -I INPUT 1 -p tcp --dport 22 -s 198.51.100.0/24 -j ACCEPT

-s 옵션에 IP 또는 CIDR 표기를 씁니다. 이렇게 하면 지정한 소스 IP에서 온 패킷만 dpt:22 ACCEPT 규칙에 매칭됩니다. 다른 IP에서의 SSH 시도는 매칭 규칙이 없어 policy DROP에 의해 차단됩니다.

IP 범위를 지정할 때 iprange 모듈을 쓸 수도 있습니다.

# 192.168.1.10 ~ 192.168.1.50 범위만 허용
iptables -I INPUT 1 -p tcp --dport 22 \
  -m iprange --src-range 192.168.1.10-192.168.1.50 -j ACCEPT

SSH 소스 IP를 제한하면 /var/log/auth.log에 기록되는 브루트포스 시도가 극적으로 줄어듭니다. 실무에서 SSH를 0.0.0.0/0으로 열어두면 하루에 수만 건의 로그인 시도가 들어옵니다.

두 타깃의 차이는 발신자 경험에서 극명하게 드러납니다.

DROP

패킷을 조용히 버립니다. 발신자는 응답을 기다리다 타임아웃 후 실패를 인지합니다. TCP의 경우 기본 타임아웃이 수십 초에서 수 분입니다.

# DROP이면 클라이언트에서 이런 현상이 나타남
ssh user@서버IP
# 아무 응답 없이 수십 초 후 "Connection timed out" 에러

REJECT

패킷을 버리되 발신자에게 ICMP 에러 메시지를 보냅니다. 발신자가 즉시 실패를 인지합니다.

# REJECT이면 즉각 에러
ssh user@서버IP
# 즉시 "Connection refused" 에러

# REJECT 타입 지정
iptables -A INPUT -p tcp --dport 22 -j REJECT --reject-with tcp-reset
iptables -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable

--reject-with 옵션으로 거부 메시지 타입을 지정할 수 있습니다. tcp-reset은 TCP RST를 보내 즉각 연결 종료를 알립니다. icmp-port-unreachable은 ICMP 메시지를 보냅니다.

언제 어떤 것을 쓰는가

policy DROP은 타임아웃 방식이므로, 내부 서비스가 외부로 잘못된 포트에 연결을 시도하면 타임아웃까지 수십 초를 기다립니다. 내부 네트워크에서는 REJECT를 쓰면 빠른 실패로 디버깅이 훨씬 쉽습니다.

LOG는 패킷을 차단하지 않고 기록만 합니다. 보통 LOG 다음에 DROP 규칙을 추가하는 패턴을 씁니다.

# 차단되기 직전 패킷을 로그로 남기고 DROP
iptables -A INPUT -j LOG --log-prefix "INPUT_DROP: " --log-level 4
iptables -A INPUT -j DROP   # 위 LOG 다음에 DROP
# 또는 policy DROP이 이미 있으면 LOG만 추가해도 됨 (policy가 DROP을 담당)

--log-prefix "INPUT_DROP: ": 로그에 붙는 식별 문자열입니다. kern.log에서 grep "INPUT_DROP:" 으로 찾을 수 있습니다.

--log-level 4: 로그 우선순위입니다. 4는 WARNING 수준으로, /var/log/kern.log에 기록됩니다.

로그 확인 방법입니다.

# 실시간 차단 로그 확인
tail -f /var/log/kern.log | grep "INPUT_DROP:"

# 특정 IP에서의 접근 시도 확인
grep "INPUT_DROP:" /var/log/kern.log | grep "SRC=203.0.113.5"

로그 출력 예시입니다.

Jun 10 09:17:43 server kernel: [12345.678] INPUT_DROP: IN=eth0 OUT= MAC=... 
  SRC=203.0.113.5 DST=10.0.0.1 LEN=60 TTL=64 ID=12345 PROTO=TCP 
  SPT=52341 DPT=22 FLAGS=S WINDOW=65535

이 로그에서 확인할 수 있는 정보입니다.

• SRC=203.0.113.5: 접속을 시도한 소스 IP
• DPT=22: 목적지 포트 (SSH 시도)
• FLAGS=S: SYN 플래그 (새 연결 시도)
• PROTO=TCP: TCP 프로토콜

이 정보로 누가 어떤 포트에 접근을 시도하는지 실시간으로 파악할 수 있습니다.

로그 폭발 방지 — rate limiting

LOG 규칙이 있으면 DDoS 공격 시 로그 파일이 폭발적으로 커질 수 있습니다. -m limit으로 속도를 제한합니다.

# 분당 최대 5개, 버스트 10개까지만 로그
iptables -A INPUT -m limit --limit 5/min --limit-burst 10 \
  -j LOG --log-prefix "INPUT_DROP: " --log-level 4

이 규칙은 분당 5개, 순간 최대 10개까지만 로그를 남깁니다. 그 이상은 로그 없이 policy DROP으로 처리됩니다.

Docker 데몬이 시작되면 아무 말 없이 iptables에 체인과 규칙을 추가합니다. DOCKER, DOCKER-USER, DOCKER-ISOLATION-STAGE-1, DOCKER-ISOLATION-STAGE-2 체인이 생기고, FORWARD 체인에 Docker 관련 규칙이 삽입됩니다. 이 때문에 Docker를 쓰는 서버에서는 수동으로 FORWARD 규칙을 만들어도 Docker 재시작 시 덮어쓰여지는 문제가 발생합니다.

Docker가 iptables를 관리하는 이유는 컨테이너 포트 포워딩을 자동화하기 위해서입니다. docker run -p 8080:80을 실행하면 Docker는 nat 테이블 PREROUTING에 DNAT 규칙을 추가하고, filter 테이블 FORWARD에 해당 트래픽 허용 규칙을 추가합니다. 운영자가 직접 할 필요 없이 자동으로 처리해주는 것입니다.

IP 100개를 개별 iptables 규칙으로 차단하면 패킷마다 100번 순차 비교가 일어납니다. IP가 10만 개라면 성능 문제가 심각해집니다. ipset은 해시 테이블을 사용해 수만 개의 IP를 **O(1)**에 검색합니다. 공격 IP 목록 차단, 지역 IP 차단, 화이트리스트 접근 제어 등 대량 IP 관리에 필수 도구입니다.

iptables 규칙을 아무리 맞게 짜도, 터널·VPN·PPPoE 뒤에서는 '작은 요청은 되는데 큰 전송만 멈추는' 이상한 장애가 납니다. 원인이 규칙이 아니라 경로의 MTU와 그걸 알려 주는 ICMP를 방화벽이 막은 데 있어서, iptables -L만 봐선 영영 못 찾습니다.

• 경로 MTU가 1500보다 작을 수 있다: VPN·GRE·PPPoE는 헤더 오버헤드로 실제 전송 가능 크기가 1500보다 작습니다(예: 1400). 이보다 큰 패킷은 쪼개거나(fragment) 경로에서 버려집니다.
• DF 비트 + PMTUD 실패 = 블랙홀: 대용량 TCP 패킷은 보통 DF(Don't Fragment)가 켜져 있어, 중간 장비가 쪼개는 대신 'ICMP fragmentation needed'로 크기를 낮추라고 알립니다. 방화벽이 그 ICMP를 DROP하면 송신자는 계속 큰 패킷만 보내고 전부 사라집니다(PMTU 블랙홀).
• 증상이 '규칙 문제'로 오인된다: handshake와 짧은 요청(작은 패킷)은 통과하므로 포트는 열려 보이고, 대용량 응답·파일 전송·큰 헤더 요청만 멈춥니다.
• 해결은 규칙이 아니라 MSS 클램핑: FORWARD/mangle에 TCPMSS --clamp-mss-to-pmtu로 handshake의 MSS를 경로 MTU에 맞춰 낮추면, 애초에 큰 세그먼트가 생기지 않아 블랙홀을 피합니다. 더불어 'fragmentation needed' ICMP는 반드시 허용해야 PMTUD가 동작합니다.

즉 방화벽 트러블슈팅의 마지막 층은 '무엇을 허용/차단했나'를 넘어 '허용된 패킷이 경로를 통째로 통과할 만큼 작은가'까지 봐야 합니다.