180. DMZ

📚 네트워크 · 패킷 분석 › 04. 네트워크 장비 실습 — 180편
이전 글: 179. Network Segmentation · 다음 글: 181. Firewall 정책

1. 개념

DMZ(DeMilitarized Zone) 는 인터넷에 서비스를 공개해야 하는 서버(웹·메일·DNS·리버스 프록시 등)를 두는 완충 구역입니다. 외부 사용자가 접속할 수 있어야 하므로 내부망에 둘 수는 없고, 그렇다고 방화벽 바깥에 그대로 두면 보호를 받지 못합니다. 그래서 외부와 내부 사이에 별도 구역을 만들고, 양쪽 모두와의 통신을 방화벽으로 통제합니다.

DMZ는 179. Network Segmentation의 구역 설계 중 "외부에 노출되어 가장 먼저 침해될 수 있는 구역" 에 해당합니다. 설계의 전제는 "DMZ 서버는 언젠가 침해될 수 있다"이며, 침해되어도 내부망으로 이어지지 않게 하는 것이 목적입니다.

DMZ에 두는 것	DMZ에 두지 않는 것
공개 웹 서버, 리버스 프록시	데이터베이스 원본
메일 게이트웨이(외부 수신용)	내부 메일 서버·사서함
외부용 DNS	내부 도메인 컨트롤러·내부 DNS
VPN 게이트웨이(구성에 따라)	업무 시스템, 파일 서버

---

2. 동작 원리

DMZ를 만드는 대표적인 장비 배치는 두 가지입니다.

[단일 방화벽, 3-leg 구조]
 인터넷 ── (outside) [방화벽] (inside) ── 내부망
                        │
                      (dmz)
                        │
                      DMZ 서버

[이중 방화벽 구조]
 인터넷 ── [외부 방화벽] ── DMZ 서버 ── [내부 방화벽] ── 내부망

항목	단일 방화벽(3-leg)	이중 방화벽
장비 수	1대 (인터페이스 3개 이상)	2대
장점	구성·관리 단순, 비용 낮음	한 방화벽이 뚫려도 다른 하나가 남음
단점	방화벽 1대가 모든 경계를 담당	정책 2벌 관리, 비용
보완	인터페이스별 엄격한 정책	가능하면 서로 다른 제조사로 구성하기도 함

방향별 통신 원칙은 다음과 같습니다. 핵심은 DMZ에서 내부로 먼저 연결을 시작하지 못하게 하는 것입니다.

방향	원칙	예
인터넷 → DMZ	공개 서비스 포트만 허용	TCP 443 → 리버스 프록시
DMZ → 내부	기본 차단, 꼭 필요한 연결만 개별 허용	프록시 → 내부 WAS 8443 한 개
내부 → DMZ	관리망에서 관리 포트만	관리망 → DMZ SSH
DMZ → 인터넷	기본 차단, 업데이트·외부 DNS 등만	패치 서버 443

---

3. 주요 특징

• 리버스 프록시 배치: 실제 애플리케이션 서버는 내부 서버망에 두고, DMZ에는 요청을 받아 전달하는 리버스 프록시(또는 WAF)만 두는 구성이 많습니다. DMZ → 내부 허용 규칙이 "프록시 → WAS 한 포트"로 좁아집니다.
• 공개 방식: 외부 공인 IP → DMZ 사설 주소는 Static NAT나 포트 포워딩으로 연결합니다(176. NAT).
• DMZ 서버끼리도 분리합니다. 같은 DMZ에 웹 서버와 메일 게이트웨이가 있다면, 한 서버가 침해되었을 때 다른 서버로 옮겨 가지 못하도록 DMZ 내부 통신도 최소화합니다.
• DMZ의 아웃바운드가 자주 간과됩니다. 침해된 웹 서버가 외부에서 도구를 내려받거나 C2와 통신하는 경로가 되므로, DMZ → 인터넷도 기본 차단이 원칙입니다(183. Outbound 정책).

---

4. 예시

실습 예시 — NIC 3개를 가진 Linux 방화벽 VM에서 3-leg DMZ의 통과 트래픽 정책을 nftables로 구성합니다(Rocky/Ubuntu 공통, 런타임 설정). ens33=외부, ens37=내부(192.168.10.0/24), ens38=DMZ(10.50.0.0/24)이며 값은 예시(값은 환경마다 다름)입니다. firewalld·ufw가 켜져 있으면 규칙이 섞이므로 실습 VM에서는 하나만 사용합니다.

sudo nft add table inet fw
sudo nft 'add chain inet fw forward { type filter hook forward priority 0 ; policy drop ; }'

# 이미 허용된 연결의 후속 패킷
sudo nft add rule inet fw forward ct state established,related accept
sudo nft add rule inet fw forward ct state invalid drop

# 인터넷 → DMZ 리버스 프록시 443
sudo nft add rule inet fw forward iifname "ens33" oifname "ens38" ip daddr 10.50.0.10 tcp dport 443 accept
# DMZ 프록시 → 내부 WAS 8443 한 개만
sudo nft add rule inet fw forward iifname "ens38" oifname "ens37" ip saddr 10.50.0.10 ip daddr 192.168.10.30 tcp dport 8443 accept
# 내부 → 인터넷
sudo nft add rule inet fw forward iifname "ens37" oifname "ens33" accept
# DMZ에서 내부로 가는 나머지 시도는 기록 후 폐기
sudo nft 'add rule inet fw forward iifname "ens38" oifname "ens37" log prefix "DMZ-TO-IN-DROP " drop'

sudo nft list chain inet fw forward

외부 공인 IP → 10.50.0.10 변환(DNAT)은 176. NAT의 nat 테이블 구성을 함께 적용한다고 가정합니다. 로그는 sudo journalctl -k | grep DMZ-TO-IN-DROP으로 확인합니다.

📷 [실습 화면 삽입 위치] DMZ 서버 VM에서 내부 서버 22번 포트 접속을 시도했을 때 방화벽 VM의 커널 로그에 DMZ-TO-IN-DROP 접두어와 IN=ens38 OUT=ens37 필드가 기록된 화면

---

5. 보안 관점

• DMZ의 가치는 침해를 가정한 설계에 있습니다. DMZ → 내부 규칙이 넓으면 DMZ는 완충 구역이 아니라 내부망의 입구가 됩니다.
• 운영 편의를 위해 "DMZ 서버 → 내부 DB 직접 연결", "DMZ → 내부 AD 인증" 같은 예외가 추가되기 쉽습니다. 각 예외는 침해 시 그대로 공격 경로가 됩니다.
• DMZ 서버의 관리 접속은 인터넷이 아니라 관리망에서만 허용합니다.
• DMZ 서버는 외부 공격을 가장 많이 받는 자산이므로, 패치·설정 점검 주기를 내부 서버보다 짧게 가져갑니다.

---

6. SOC 관점

흔적	의미
DMZ → 내부 차단 로그	침해된 DMZ 서버의 내부 정찰·확산 시도 가능성 (우선순위 높음)
DMZ → 인터넷 신규 목적지 연결	도구 다운로드, C2 통신 가능성
인터넷 → DMZ 공개 포트 외 접근	일반적인 외부 스캔 (양이 많음)
DMZ 서버에서 시작된 대량 DNS 질의	비정상 프로세스 가능성

관제자가 확인할 질문

• DMZ 서버가 연결을 시작한 쪽(출발지) 인 로그가 있는가? DMZ 서버는 보통 응답만 합니다.
• DMZ → 내부 허용 규칙으로 통과한 연결이 허용된 목적지·포트와 정확히 일치하는가?
• 공개 서비스 로그(웹 접근 로그)의 공격 시도 이후, 같은 서버에서 아웃바운드 연결이 생겼는가?

오탐 주의: 인터넷 → DMZ 차단 로그는 대부분 무차별 스캔이므로 건수보다 공격 이후 DMZ 서버의 행동 변화를 봅니다. 방화벽 정책 관점의 DMZ 분석은 270. DMZ와 Firewall에서 다룹니다.

---

7. 핵심 정리

• DMZ는 외부 공개 서버를 두는 완충 구역으로, 외부와 내부 양쪽 모두와의 통신을 방화벽으로 통제합니다.
• 구성은 단일 방화벽(3-leg)과 이중 방화벽이 대표적이며, 관리 단순성과 방어 계층 사이의 선택입니다.
• 핵심 원칙은 DMZ → 내부 기본 차단, 필요 시 특정 출발지·목적지·포트만 개별 허용입니다.
• 리버스 프록시만 DMZ에 두고 애플리케이션 서버는 내부에 두면 허용 범위가 좁아집니다.
• DMZ 서버가 출발지인 내부·외부 연결 로그는 침해 가능성을 보여 주는 우선 확인 대상입니다.