[방화벽] 리눅스 호스트 방화벽 iptables에 대해 알아보자

iptables는 리눅스 서버 운영에서 매우 중요하다.

클라우드 환경과 컨테이너 오케스트레이션 도구들이 내부적으로 iptables 규칙을 생성하기 때문에 iptables를 잘 다루어야 네트워크 디버깅을 할 수 있다.

 

참고로 리눅스 커널 3.13부터 iptables의 후속 기술인 nftables가 도입되었고, 최신 배포판들은 nftables를 기본으로 채택하고 있다.

그럼에도 도커와 쿠버네티스는 여전히 내부적으로 iptables 규칙을 대량 생성하고, 많은 운영 환경의 기존 스크립트가 iptables 문법으로 작성되어 있기 때문에 iptables를 이해하는 것이 중요하다.

1. iptables의 특징

1️⃣ 호스트 기반 방화벽

방화벽은 위치에 따라 크게 두 가지로 나뉜다.

네트워크 방화벽은 네트워크 경계에서 트래픽을 통제하고, 호스트 기반 방화벽(Host-based Firewall)은 개별 서버 위에서 동작한다. iptables는 호스트 기반 방화벽에 해당한다.

호스트 기반 방화벽의 장점은 각 서버가 독자적인 보안 정책을 가질 수 있다는 점이다.

동일한 내부 네트워크에 있더라도 서버마다 다른 포트 접근 정책을 적용할 수 있고, 소프트웨어로 구현되어 별도 하드웨어 없이 동작한다.

iptables는 OSI 7계층 기준으로 Layer 3(Network, IP)와 Layer 4(Transport, TCP/UDP) 수준에서 패킷을 필터링한다.

즉, 소스/목적지 IP 주소, 포트 번호, 프로토콜 종류를 기반으로 패킷 허용 또는 차단 여부를 결정한다.

 

 

2️⃣ netfilter 프레임워크와 iptables

iptables는 독립적인 프로그램이 아니라 리눅스 커널 내부의 netfilter 프레임워크 위에 올라가는 사용자 공간(userspace) 도구다.

netfilter는 리눅스 커널 2.4부터 도입된 패킷 필터링 아키텍처로, 패킷이 커널 네트워크 스택을 통과하는 경로 곳곳에 훅(hook) 을 심어 놓는다.

iptables는 이 훅에 규칙을 등록하는 인터페이스 역할을 한다.

 

사용자 (iptables 명령어)
        ↓
   netfilter 훅 (커널)
        ↓
  패킷 허용 / 차단 / 변환

 

3️⃣ firewalld와의 비교

많은 최신 리눅스 배포판(RHEL 7+, CentOS 7+, Fedora)은 iptables 대신 firewalld를 기본으로 채택하고 있다. 

구분	iptables	firewalld
동작 방식	정적 규칙 집합	동적 규칙 관리
규칙 변경 시	전체 ruleset 재로드	변경 부분만 적용
백엔드	netfilter 직접	nftables / iptables
개념 모델	table/chain/rule	zone/service
복잡도	낮음(직관적)	높음(추상화 레이어 존재)
적합 상황	세밀한 제어 필요 시	빠른 정책 적용 필요 시

firewalld는 내부적으로 iptables 또는 nftables를 백엔드로 사용한다.

즉, iptables를 이해하면 firewalld의 내부 동작도 파악할 수 있다.

 

4️⃣ 패킷 흐름: netfilter 훅 포인트

 

 

 

패킷은 크게 세 가지 경로를 따른다.

 

첫째, 외부에서 로컬 프로세스로 향하는 패킷은 PREROUTING → 라우팅 판단 → INPUT을 거친다.

둘째, 로컬 프로세스가 외부로 보내는 패킷은 OUTPUT → POSTROUTING을 거친다.

셋째, 이 서버가 라우터 역할을 할 때 다른 호스트로 전달되는 패킷은 PREROUTING → 라우팅 판단 → FORWARD → POSTROUTING을 거친다.

 

5️⃣ table, chain, rule 구조

iptables의 핵심 개념은 table → chain → rule 계층 구조다.

 

Table은 기능적 목적에 따라 구분된 규칙 그룹이다. 주요 테이블은 다음과 같다.

• filter — 패킷 허용/차단 (기본 테이블, 가장 많이 사용)
• nat — 주소 변환 (SNAT, DNAT, MASQUERADE)
• mangle — 패킷 헤더 수정 (TTL, TOS 등)
• raw — conntrack 제외 등 저수준 처리

Chain은 패킷이 통과하는 처리 포인트다.

각 테이블이 사용할 수 있는 빌트인 체인이 다르다.

filter 테이블은 INPUT, FORWARD, OUTPUT 세 가지 체인을 가진다.

 

Rule은 체인 안에 순서대로 배치된 개별 조건+행동 묶음이다.

패킷은 규칙을 위에서부터 순차적으로 검사하며, 처음 매치된 규칙의 행동(target)이 실행된다.

어떤 규칙에도 매치되지 않으면 체인의 기본 정책(default policy)이 적용된다.

 

2. iptables 사용 방법

1️⃣ iptables 설치

대부분의 리눅스 배포판에는 iptables가 기본 설치되어 있지만 없다면 아래 명령어로 설치한다.

# Debian / Ubuntu
sudo apt-get update && sudo apt-get install -y iptables

# RHEL / CentOS / Fedora
sudo yum install -y iptables-services
# 또는
sudo dnf install -y iptables-services

# 서비스 활성화 (RHEL 계열)
sudo systemctl enable --now iptables

 

현재 적용된 규칙 확인:

sudo iptables -L -v -n

 

 

2️⃣ 주요 명령어와 옵션

🟢 명령 구조

iptables [-t TABLE] COMMAND CHAIN [MATCH] -j TARGET+

 

🟢 주요 커맨드

커맨드	설명
-A CHAIN	체인 끝에 규칙 추가 (Append)
-I CHAIN [N]	체인 N번 위치에 규칙 삽입 (Insert, 기본 1번)
-D CHAIN N	N번째 규칙 삭제 (Delete)
-R CHAIN N	N번째 규칙 교체 (Replace)
-L	규칙 목록 출력 (List)
-F [CHAIN]	체인 규칙 전체 삭제 (Flush)
-P CHAIN TARGET	기본 정책 설정 (Policy)
-N CHAIN	사용자 정의 체인 생성 (New)
-X CHAIN	사용자 정의 체인 삭제

🟢 주요 매치 옵션

옵션	설명
-p tcp|udp|icmp	프로토콜 지정
-s IP/CIDR	출발지 IP 또는 대역
-d IP/CIDR	목적지 IP 또는 대역
--sport PORT	소스 포트
--dport PORT	목적지 포트
-i IFACE	입력 인터페이스
-o IFACE	출력 인터페이스
-m state --state STATE	연결 상태 (NEW, ESTABLISHED, RELATED, INVALID)

🟢 타겟(행동)

타겟	설명
ACCEPT	패킷 허용
DROP	패킷 조용히 차단 (응답 없음)
REJECT	패킷 차단 + 오류 응답 전송
LOG	커널 로그에 기록 (계속 진행)
RETURN	현재 체인 종료, 호출 체인으로 복귀

 

3️⃣ 방화벽 룰 추가 실습

🟢 기본 패턴: stateful 방화벽 구성

실제 서버에서 가장 많이 쓰이는 패턴은 다음과 같다.

# 1. 기존 규칙 초기화
sudo iptables -F
sudo iptables -X

# 2. 기본 정책 설정 (OUTPUT 제외하고 모두 차단)
sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT

# 3. 루프백 인터페이스 허용 (필수)
sudo iptables -A INPUT -i lo -j ACCEPT

# 4. 이미 수립된 연결 허용 (stateful)
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# 5. SSH 허용 (특정 IP에서만)
sudo iptables -A INPUT -p tcp -s 203.0.113.0/24 --dport 22 -j ACCEPT

# 6. HTTP / HTTPS 허용
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# 7. ICMP(ping) 허용
sudo iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

 

🟢 규칙 순서의 중요성

iptables는 규칙을 위에서 아래로 순차 검사한다.

먼저 매치된 규칙이 적용되므로, 더 구체적인 규칙을 위에 배치해야 한다.

ESTABLISHED,RELATED 매치를 앞에 두는 이유도 여기에 있다.

한 번 수립된 연결의 응답 패킷을 매번 개별 규칙과 비교하지 않아도 되기 때문에 성능 면에서도 유리하다.

 

 

4️⃣ 사용자 정의 체인

규칙이 늘어나면 관리가 어려워진다.

이때 사용자 정의 체인으로 규칙을 논리적으로 분리할 수 있다.

# 사용자 정의 체인 생성
sudo iptables -N WEB-IN

# WEB-IN 체인에 규칙 추가
sudo iptables -A WEB-IN -s 10.0.0.0/8 -j ACCEPT
sudo iptables -A WEB-IN -s 192.168.1.0/24 -j ACCEPT
sudo iptables -A WEB-IN -j RETURN

# INPUT 체인에서 WEB-IN 체인 호출
sudo iptables -A INPUT -p tcp --dport 80 -j WEB-IN

# 사용자 정의 체인 삭제 (규칙 먼저 비워야 함)
sudo iptables -F WEB-IN
sudo iptables -X WEB-IN

 

RETURN 타겟은 사용자 정의 체인에서 어떤 규칙에도 매치되지 않았을 때 호출 체인(예: INPUT)으로 돌아가도록 한다.

사용자 정의 체인에 기본 정책은 없으므로, 명시적인 RETURN이나 마지막 DROP/ACCEPT를 넣어줘야 의도한 동작을 보장할 수 있다.

 

5️⃣ 규칙 영구 저장

iptables 규칙은 메모리에 저장되므로 재부팅 시 초기화된다.

영구 적용하려면 저장이 필요하다.

# Debian / Ubuntu
sudo apt-get install iptables-persistent
sudo netfilter-persistent save

# RHEL / CentOS
sudo service iptables save
# 저장 경로: /etc/sysconfig/iptables

# 수동 저장 (범용)
sudo iptables-save > /etc/iptables/rules.v4

# 복원
sudo iptables-restore < /etc/iptables/rules.v4

 

6️⃣ 패킷 처리 흐름 (HTTP 요청 예시)

7️⃣ 자주 쓰는 명령어 레퍼런스

# 규칙 번호와 함께 상세 출력
sudo iptables -L INPUT -v -n --line-numbers

# 특정 규칙 번호 삭제
sudo iptables -D INPUT 3

# nat 테이블 확인
sudo iptables -t nat -L -v -n

# MASQUERADE (NAT 라우터 설정)
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# 로깅 (앞 단에 배치)
sudo iptables -A INPUT -p tcp --dport 22 -j LOG --log-prefix "SSH-ATTEMPT: " --log-level 4

# 포트 포워딩 (8080 → 80)
sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j REDIRECT --to-port 80

# 모든 규칙 초기화 (주의!)
sudo iptables -F && sudo iptables -X && sudo iptables -Z

 

정리

• iptables는 낮은 추상화 수준 덕분에 세밀한 제어가 가능하고, netfilter 프레임워크를 직접 다루기 때문에 성능 오버헤드도 낮다.
• Kubernetes나 Docker 같은 컨테이너 환경도 내부적으로 iptables 규칙을 대량 생성하므로, iptables를 이해하는 것은 현대 인프라 운영에서 중요하다.
• iptables-save로 현재 규칙 스냅샷을 남기는 습관을 들이고, 변경 전에는 항상 기존 규칙을 백업해두는 것이 권장된다.
• 잘못된 INPUT DROP 정책은 SSH 세션을 끊어버릴 수 있다.