iptables와 Security Group

한 줄 답변#

iptables는 OS 커널 레벨 방화벽이고, Security Group은 AWS VPC 레벨 가상 방화벽이다. iptables는 호스트 안에서, SG는 호스트 밖(하이퍼바이저)에서 동작한다.

동작 위치#

[인터넷]
    ↓
[AWS VPC]
    ↓
[Security Group]  ← 하이퍼바이저(ENI) 레벨, EC2 밖에서 필터링
    ↓
[EC2 인스턴스]
    ↓
[iptables]        ← OS 커널(netfilter) 레벨, EC2 안에서 필터링
    ↓
[애플리케이션]

SG는 트래픽이 EC2에 도달하기 전에 필터링한다. iptables는 EC2 안에서 커널이 필터링한다.

iptables는 Linux 전용이다#

iptables는 Linux 커널의 netfilter 프레임워크 위에서 동작한다. 다른 OS에는 각자의 방화벽이 있다:

iptables라는 도구는 Linux에만 존재한다. Windows의 방화벽이나 macOS의 PF와 개념은 비슷하지만(패킷 필터링) 완전히 다른 구현체다.

Linux에서 iptables 설정 위치#

# 현재 규칙 확인
sudo iptables -L -n -v

# 규칙 파일 (배포판마다 다름)
/etc/iptables/rules.v4          # Debian/Ubuntu (iptables-persistent)
/etc/sysconfig/iptables          # RHEL/CentOS

# ufw 사용 시 (Ubuntu 기본)
sudo ufw status
sudo ufw allow 443/tcp
# 내부적으로 iptables 규칙을 생성함

# nftables (iptables 후속)
/etc/nftables.conf
sudo nft list ruleset

iptables vs nftables#

iptables는 레거시가 되어가고 있고, nftables가 후속이다:

최신 Ubuntu/Debian에서 iptables 명령을 치면 내부적으로 nftables 백엔드를 사용하는 경우도 있다 (iptables-nft).

핵심 차이#

상태 추적 (Stateful)#

둘 다 Stateful이 가능하지만 차이가 있다:

Security Group (항상 Stateful)#

인바운드: 443 허용
  → 클라이언트 요청 들어옴 (443)
  → 응답 나감 (자동 허용, 아웃바운드 규칙 불필요)

SG는 무조건 Stateful이다. 인바운드를 허용하면 그에 대한 응답 트래픽은 아웃바운드 규칙 없이도 자동 허용된다.

iptables (선택 가능)#

# Stateful (conntrack 사용)
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Stateless (conntrack 없이)
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 443 -j ACCEPT  # 응답도 명시 필요

iptables는 conntrack 모듈로 Stateful을 선택할 수 있다. 성능이 중요하면 Stateless로도 운영 가능.

규칙 평가 방식#

iptables: 순서대로 매칭 (First Match)#

iptables -A INPUT -s 10.0.0.5 -j DROP      # 규칙 1: 이 IP 차단
iptables -A INPUT -p tcp --dport 443 -j ACCEPT  # 규칙 2: 443 허용

10.0.0.5에서 443으로 요청 → 규칙 1에서 DROP. 순서가 중요하다.

Security Group: 전체 평가 (All Match)#

인바운드:
  443 ← 0.0.0.0/0
  443 ← sg-ecs-app

모든 규칙을 평가하고, 하나라도 매칭되면 허용. 순서가 없다. 그리고 DENY 규칙이 없다 — 특정 IP를 차단하려면 SG가 아닌 NACL을 써야 한다.

DENY 규칙#

SG로 특정 IP를 차단하고 싶으면? → 못 한다. AWS에서 IP 차단은 NACL(Network ACL) 또는 WAF를 써야 한다.

차단이 필요한 경우:
  L3/L4 차단 → NACL (서브넷 레벨, Stateless)
  L7 차단   → WAF (HTTP 레벨, 경로/헤더 기반)
  호스트 차단 → iptables (OS 레벨)

쿠버네티스에서는#

K8s 환경에서는 둘 다 사용된다:

[AWS VPC]
  Security Group → EKS 노드/Pod 레벨 네트워크 접근 제어
      ↓
[K8s 클러스터]
  NetworkPolicy → Pod 간 통신 제어 (CNI가 iptables/eBPF로 구현)
      ↓
[Pod]
  iptables/nftables → Istio sidecar, kube-proxy 서비스 라우팅

• kube-proxy: Service → Pod 라우팅을 iptables 규칙으로 구현
• Calico/Cilium: NetworkPolicy를 iptables 또는 eBPF로 구현
• Istio: Envoy sidecar로 트래픽 제어 (iptables로 트래픽을 sidecar로 리다이렉트)

Security Group vs NACL#

같은 AWS 방화벽이지만 적용 레벨이 다르다:

[인터넷]
    ↓
[NACL]  ← 서브넷 입구에서 필터링 (IP 차단 가능)
    ↓
[Security Group]  ← ENI 레벨에서 필터링 (허용 규칙만)
    ↓
[EC2 / Pod]

언제 NACL을 쓰나#

SG로는 특정 IP를 차단할 수 없다 (DENY 규칙이 없으니까). IP 차단이 필요하면 NACL:

NACL 인바운드:
  Rule 10: DENY  TCP 443  from 203.0.113.5/32   ← 악성 IP 차단
  Rule 100: ALLOW TCP 443  from 0.0.0.0/0        ← 나머지 허용
  Rule *:   DENY  ALL      from 0.0.0.0/0        ← 기본 거부

NACL은 Stateless라서 아웃바운드 응답도 별도 규칙이 필요하다:

NACL 아웃바운드:
  Rule 100: ALLOW TCP 1024-65535 from 0.0.0.0/0  ← 응답 포트 (임시 포트)

실무에서는#

대부분 SG만으로 충분하고, NACL은 건드리지 않는 경우가 많다. NACL을 쓰는 경우:

• 특정 IP/대역 차단 (공격자 IP)
• 서브넷 단위로 통신 제한 (규정 준수)
• SG만으로 표현 못 하는 DENY 규칙

정리#

클라우드에서는 SG가 1차 방어선이고, iptables는 호스트 내부 또는 K8s 내부 구현에서 사용된다. 온프렘에서는 iptables(또는 ufw)가 메인 방화벽이다.