183. Outbound 정책

📚 네트워크 · 패킷 분석 › 04. 네트워크 장비 실습 — 183편
이전 글: 182. Inbound 정책 · 다음 글: 184. Allow와 Deny

1. 개념

Outbound 정책(Egress 정책) 은 내부(사용자망·서버망·DMZ)에서 외부로 시작하는 연결을 통제하는 정책입니다. 많은 조직이 Inbound는 엄격하게 막으면서 Outbound는 "내부 → 외부 전체 허용"으로 두는데, 이 경우 침해 이후의 단계가 모두 자유로워집니다.

침해 이후 단계	Outbound 연결의 역할
악성코드 추가 다운로드	외부 서버에서 도구를 내려받음
C2(명령제어) 통신	외부 서버와 주기적으로 통신하며 명령 수신
데이터 유출	내부 자료를 외부로 전송
외부 공격의 경유지	내부 호스트가 다른 조직을 공격·스캔

Inbound 정책(182. Inbound 정책)이 "들어오지 못하게", Outbound 정책은 "들어왔더라도 밖과 연락하지 못하게" 하는 역할입니다.

---

2. 동작 원리

Outbound 정책은 "무엇이, 어디로, 어떤 경로로 나갈 수 있는가"를 구역별로 정합니다. 핵심은 직접 나가는 길을 줄이고 통제 지점(프록시·내부 DNS·메일 게이트웨이)으로 모으는 것입니다.

[사용자 PC]
   ├─ 웹(80/443) ──→ [웹 프록시] ──→ 인터넷      ← 프록시만 외부 웹 허용
   ├─ DNS(53) ────→ [내부 DNS]  ──→ 외부 DNS    ← 내부 DNS만 외부 53 허용
   ├─ 메일 ────────→ [메일 서버] ──→ 외부 25     ← 메일 서버만 외부 25 허용
   └─ 그 외 직접 외부 연결 → [경계 방화벽] 차단 + 로그

[서버망]  업데이트 저장소 등 지정 목적지만 허용
[DMZ]     기본 차단 (응답만), 필요한 목적지만 개별 허용

서비스별 Outbound 허용 원칙의 예입니다.

서비스	허용 출발지	원칙
웹 (TCP 80/443)	프록시 서버	사용자 PC의 직접 외부 웹 연결 차단
DNS (UDP·TCP 53)	내부 DNS 서버	PC가 외부 DNS로 직접 질의하는 것 차단
SMTP (TCP 25)	메일 서버	PC의 직접 25 연결은 스팸·악성코드 징후
NTP (UDP 123)	내부 NTP 서버	시간 동기화는 내부 서버 경유
그 외 포트	요청·승인된 출발지·목적지	기본 차단

---

3. 주요 특징

• 출발지 검증(Egress 필터링): 경계에서는 출발지가 내부 대역인 패킷만 외부로 내보냅니다. 내부에서 위조 출발지 패킷이 나가는 것을 막는 것으로, BCP 38(RFC 2827)의 개념입니다.
• 포트 허용만으로는 부족합니다. 443은 거의 항상 열려 있으므로, 공격자는 C2를 443으로 운영합니다. 목적지 평판·도메인 분류는 프록시·NGFW가 담당하고, 방화벽은 프록시를 우회하는 직접 연결을 막는 역할을 합니다.
• DNS는 특별 취급합니다. 외부 53 직접 연결을 막아야 DNS 터널링과 내부 DNS 로그 우회를 줄일 수 있습니다. 다만 DoH(443 위의 DNS)는 포트로 구분되지 않으므로 별도 대책이 필요합니다.
• 호스트 방화벽의 output은 기본 허용이 일반적입니다. 서버 단위 Outbound 통제는 주로 네트워크 방화벽이 맡고, 중요 서버만 호스트 output 정책을 추가합니다.

---

4. 예시

실습 예시 — 방화벽 VM(nftables)에서 사용자망(ens37, 192.168.10.0/24)의 외부(ens33) 통신을 프록시와 내부 DNS로 모으는 forward 정책입니다(Rocky/Ubuntu 공통, 180. DMZ의 inet fw 테이블 가정). 값은 예시(값은 환경마다 다름)입니다.

# table inet fw { ... } 안의 chain 부분만 표시, 프록시 192.168.10.5, 내부 DNS 192.168.10.53
chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    # 출발지 검증: 사용자망 인터페이스에서 온 패킷은 사용자망 출발지만
    iifname "ens37" ip saddr != 192.168.10.0/24 counter log prefix "EGRESS-SPOOF " drop
    iifname "ens37" oifname "ens33" ip saddr 192.168.10.5 tcp dport { 80, 443 } accept
    iifname "ens37" oifname "ens33" ip saddr 192.168.10.53 meta l4proto { tcp, udp } th dport 53 accept
    iifname "ens37" oifname "ens33" counter log prefix "EGRESS-DENY " drop
}

실습 예시 — Rocky의 firewalld(0.9 이상)는 구역 간 통과 트래픽을 policy 객체로 제어합니다(179. Network Segmentation에서 만든 users zone과 기본 external zone 가정).

sudo firewall-cmd --permanent --new-policy users-to-ext
sudo firewall-cmd --permanent --policy users-to-ext --add-ingress-zone users
sudo firewall-cmd --permanent --policy users-to-ext --add-egress-zone external
sudo firewall-cmd --permanent --policy users-to-ext --set-target REJECT
sudo firewall-cmd --permanent --policy users-to-ext \
  --add-rich-rule='rule family="ipv4" source address="192.168.10.5" service name="https" accept'
sudo firewall-cmd --reload
sudo firewall-cmd --info-policy users-to-ext

실습 예시 — Ubuntu 호스트 방화벽(ufw)에서 서버 자신의 Outbound를 제한하는 경우입니다.

sudo ufw default deny outgoing
sudo ufw allow out to 192.168.10.53 port 53 proto udp
sudo ufw allow out to 192.168.10.5 port 3128 proto tcp     # 프록시 포트는 환경마다 다름
sudo ufw status verbose

⚠️ deny outgoing은 패키지 업데이트·시간 동기화·로그 전송까지 막을 수 있으므로, 필요한 목적지를 먼저 정리한 뒤 적용합니다.

📷 [실습 화면 삽입 위치] 사용자망 VM에서 외부 DNS(예: 198.51.100.53)로 직접 질의했을 때 실패하고, 방화벽 VM 커널 로그에 EGRESS-DENY 접두어와 DPT=53이 기록된 화면

---

5. 보안 관점

• Outbound 차단은 침해 이후의 방어선입니다. 초기 침투를 막지 못해도 C2 연결과 유출을 어렵게 만들고, 시도 흔적을 로그에 남깁니다.
• 전체 허용 상태에서 기본 차단으로 바꾸는 것은 업무 영향이 크므로, 로그 모드로 먼저 관찰 → 필요한 흐름 목록화 → 단계적 차단 순서로 진행하는 것이 일반적입니다.
• 서버망·DMZ는 사용자망보다 Outbound가 훨씬 적어야 정상입니다. 서버가 외부에 먼저 연결할 이유는 많지 않습니다.

---

6. SOC 관점

흔적	의미
프록시를 우회한 직접 외부 웹 시도(차단 로그)	프록시 설정을 따르지 않는 프로세스, 악성코드 가능성
PC → 외부 53 직접 질의	비인가 DNS 사용, DNS 터널링 가능성
PC → 외부 25 연결	스팸 발송형 악성코드 가능성
서버·DMZ 출발 신규 외부 목적지	침해 후 다운로드·C2 가능성
일정 간격으로 반복되는 소량 연결	C2 비콘(Beacon) 패턴 가능성

관제자가 확인할 질문

• 이 내부 호스트는 왜 직접 외부에 연결하려 했는가? 어떤 프로세스인가(EDR 연계)?
• 차단된 목적지와 같은 목적지로 허용된 연결은 없는가(다른 포트·다른 호스트 경유)?
• 전송 바이트가 수신보다 비정상적으로 큰 Outbound 세션이 있는가?

오탐 주의: 소프트웨어 업데이트, 클라우드 동기화, 보안 에이전트는 정상적으로 반복 연결을 만듭니다. 목적지 도메인·서명된 프로세스 정보와 함께 판단합니다. Outbound 로그 분석은 264. Outbound Policy에서 다룹니다.

---

7. 핵심 정리

• Outbound 정책은 내부에서 외부로 시작하는 연결을 통제하며, 침해 이후의 다운로드·C2·유출을 어렵게 합니다.
• 웹은 프록시, DNS는 내부 DNS, 메일은 메일 서버로 모으고 그 외 직접 외부 연결은 기본 차단합니다.
• 경계에서는 출발지가 내부 대역인 패킷만 내보내는 Egress 필터링을 적용합니다.
• nftables forward 체인, firewalld policy(ingress-zone → egress-zone), ufw default deny outgoing으로 구성할 수 있습니다.
• 프록시 우회·외부 DNS 직접 질의·서버발 신규 외부 연결은 우선 확인 대상입니다.