성문지기의 마지막 임무: 아웃바운드 통제 🏰👮

By PLURA 2025-09-28

옛날, 성문지기의 가장 중요한 일은 들어오는 자를 살피는 것이었습니다.
하지만 진짜 위기는 세작이 정보를 품고 다시 ‘나갈 때’ 찾아옵니다.

오늘의 시스템도 같습니다. 우리는 인입을 막는 데 익숙하지만, 유출(아웃바운드)을 통제하지 못하면 전투는 패합니다.

Protect the Castle

1) 우화로 보는 현실: “들어오는 적보다, 나가는 정보가 더 무섭다”

성문 = 80/443 웹 서비스(정문)
세작 = 웹셸·백도어·권한 탈취 후 설치된 지속화 도구
성문지기의 마지막 임무 = 나가는 사람도 조사해 무기·전리품(데이터)를 확인하는 일

침입한 세작은 정보를 들고 반드시 다시 나간다. 따라서 아웃바운드 통제는 인입만큼, 아니 그 이상 중요하다.

2) 왜 우리는 ‘나가는 트래픽’을 놓치나?

인증·점검의 사각: 많은 제도/점검이 인입·접근통제 중심으로 설계되어 아웃바운드 거버넌스가 약함
운영상 편의의 유혹: “서버가 외부로 나갈 일도 많다” → 기본허용(allow-by-default) 습관
TLS 암호화·클라우드 확산: 내용·목적지가 가려진 채 타사 서비스로 흘러감
정량 지표 부재: 세션·사용자·프로세스 단위의 송신량/속도를 측정·경보하지 않음

3) ISMS-P 2.6.7 해석과 보완 — ‘주요 시스템’에서 DMZ 전체로

기준 요지(사실):

“주요 정보시스템(DB 서버 등)에서 불필요한 외부 인터넷 접속을 통제하고, 인터넷 접속 모니터링 정책을 수립·이행한다.” → 이는 서버·단말의 아웃바운드 통제를 요구하는 조항으로 해석됩니다.

현장 문제(해석의 함정): 이 문구를 좁게 받아들이면 ‘DB 등 핵심 시스템만’ 방화벽 아웃바운드 통제로 인식하기 쉽습니다. 그러나 실제 유출 시나리오의 대부분은 DMZ(웹/앱/API/배치/프록시/관리 게이트웨이)에서 시작됩니다. 가장 자주 밖으로 통신하는 DMZ가 통제 사각이 되면, 방어는 뚫립니다.

보완 원칙(정책 제안): ‘주요 시스템’이 아니라 ‘DMZ 전체’

대상: DB 등 핵심 → DMZ 상주 모든 시스템
기본값: 기본 거부(Default Deny) + 프록시 강제(Explicit Proxy Mandatory)
허용 방식: FQDN/카테고리 기반 허용목록, 직접 80/443 차단
가시성: TLS 종단 지점 검사 가능(SNI/URL/헤더·본문), 내부 DNS만 허용(DoH/DoT 차단), 송신량/신규 목적지 지표 수집
상관 분석: DMZ의 웹 이벤트 ↔ 호스트 프로세스(자식 생성·압축/암호화) ↔ 프록시 송신량 급증을 스토리라인 경보로 운영

권고 문구(문서용 요약):

“ISMS-P 2.6.7의 ‘주요 정보시스템’을 DMZ 전체로 확장 적용한다.
DMZ는 아웃바운드 기본 거부를 원칙으로 하고, 프록시 경유·FQDN 허용목록·TLS 가시성으로 허용은 좁게, 가시성은 넓게 설계한다.”

DMZ 아웃바운드 체크(추가):

DMZ VLAN/보안그룹 아웃바운드 기본 거부
프록시 강제 및 직접 인터넷 차단(80/443)
업데이트/필수 외부 API 도메인만 허용(승인·만료 관리)
내부 DNS만 허용, DoH/DoT 차단, SNI/FQDN 로깅
TLS 종단 위치 명시 및 본문 검사 가능 설계

한 줄 메시지: “주요 시스템만 막아선 안 됩니다. 가장 많이 밖으로 나가는 DMZ 전체가 아웃바운드 거버넌스의 주무대입니다.”

4) 공격자는 어떻게 ‘나가나’? (MITRE ATT&CK 맵)

Exfiltration
- T1041: 네트워크를 통한 유출(HTTP(S) POST/Chunked, WebSocket 등)
- T1048: 대체 프로토콜(ICMP, SMTP, FTP 등)
- T1567: 클라우드 저장소 업로드(퍼블릭 오브젝트 스토리지, 코드 저장소 악용)
Command & Control
- T1071: 웹 프로토콜 C2(정상 서비스 도메인 프론팅·SNI 위장)

전형적 패턴: 웹셸 실행 → 압축/암호화 → 조각내기(작게·자주) → 프록시/정상 서비스로 송신

5) 실전 원칙 — “Egress Zero Trust”

5.1 정책 3대 원칙

기본 거부(Default Deny): 서버→인터넷 직접 통신 금지
프록시 강제(Explicit Proxy): 허용은 도메인/FQDN·카테고리 기반으로 프록시를 통해서만
가시성 우선(See Before Allow): 목적지·콘텐츠·프로세스 주체를 확인할 로그/검사 체계 필수

5.2 최소 허용(역할 기반)

웹서버: OS/패키지 업데이트 리포지토리(프록시 경유), 필수 외부 API 도메인(서버리스·결제 등)
앱서버: 내부 DB/캐시·메시지 브로커만, 인터넷 직접 통신 금지
배치/ETL: 전용 전송 게이트웨이(전용 프록시·SFTP Bastion)만
관리망: Jump Host만 외부 접근, 다중승인(MFA)·세션기록

6) 탐지·차단 플레이북 (운영 절차)

A. 네트워크/방화벽

아웃바운드 기본 차단 규칙 적용 (서버 VLAN·보안그룹 단위)
프록시 강제 리다이렉션(방화벽/라우팅) + 직접 80/443 차단
DNS 정책: 내부 DNS만 허용, DoH/DoT 차단, 목적지 FQDN 로깅
TLS 가시성: 프록시/WAF에서 TLS 종단해 SNI/URL/헤더·본문 검사

B. 호스트/프로세스 (EDR/XDR)

웹 프로세스의 아웃바운드(예: w3wp, php-fpm, java) 선발신 탐지
자식 프로세스 체인(cmd/powershell/rundll32/ssh/curl 등) 차단·경보
압축/암호화 도구 실행(7z/rar/openssl)와 대량 파일 접근 후 송신 상관 경보

C. 상관·자동화 (SIEM/SOAR)

스토리라인 규칙: 웹루트 변경 + 비정상 자식 프로세스 + 신규 외부 연결 ⇒ 고위험 티켓
플레이북: 세션 차단 → 파일 격리 → 계정잠금/비번 리셋 → 증거 보존(해시·타임라인)

힌트: IIS라면 Sysmon EID 3/1/11/12로 w3wp.exe의 네트워크 선발신·자식 생성·파일 쓰기를 연결하면 실무 가시성이 급상승합니다.

7) 계측이 없으면 방어도 없다 — 꼭 모아야 할 로그

7.1 웹/프록시

요청/응답 본문 샘플링/필터링 로그(POST/JSON/XML/업로드)
세션·URI·사용자 단위 송신 바이트/초, 분당 전송량
URL·SNI·FQDN·카테고리 + 허용/차단 사유

7.2 호스트

프로세스 트리/명령행, 네트워크 목적지/포트, 바이너리 해시
웹루트/민감경로 파일 생성·수정 이벤트

7.3 상관 키

(웹 업로드/다운로드) ↔ (호스트 파일 이벤트) ↔ (프록시 송신량 급증)
“작게, 자주” 전송 패턴의 이상치(장기 이동평균 대비 편차)

8) 운영 체크리스트 ✅

기본 거부 아웃바운드 정책이 적용되어 있다
프록시/게이트웨이 경유만 인터넷 허용, 직접 80/443 차단
내부 DNS만 허용, DoH/DoT 차단
요청/응답 본문 로그(PII 마스킹·보존정책 포함) 가동
웹 프로세스 아웃바운드/자식 프로세스 탐지 규칙 적용
클라우드 스토리지 업로드 행위·도메인 카테고리 경보
릴리스·블루/그린/DR 전환 시 보안 룰 동기화 절차 운영
월간 Egress 리뷰(탑 목적지/신규 목적지/비인가 프로세스)

9) 자주 틀리는 반론과 답변

Q. 아웃바운드를 막으면 운영이 느려집니다.
A. 막는 게 아니라 경유하게 합니다. 프록시/게이트웨이로 통로를 좁히고 보이게 만드는 겁니다.

Q. 개발·배포가 불편해집니다.
A. 역할별 허용목록 자동화(IaC)와 CI/CD 파이프라인에 도메인 등록 단계를 넣어 해결하세요.

Q. TLS를 까면 보안이 약해지지 않나요?
A. 종단·재암호화 설계와 민감정보 마스킹으로 균형을 맞춥니다. 보이지 않는 보안은 의미가 없습니다.

10) 결론 — 성문지기의 마지막 질문

“그대가 들고 나가는 것은 무엇인가?”

🤖 AI 시대의 방어는 아웃바운드를 보는 순간 시작됩니다.

문을 보듯, 본문을 보고(웹), 성내의 속삭임을 기록하며(감사로그),

웹 ↔ 호스트 ↔ 네트워크를 하나의 사건으로 엮어 자동 대응하십시오.

📖 함께 읽기

PLURA-XDR는 웹 본문 로그 + 호스트 감사로그를 상관 분석하고, 아웃바운드 이상행위를 스토리라인으로 가시화→격리→증거화합니다. “들어온 세작”뿐 아니라 나가는 세작을 잡아내는 것이 우리의 일입니다.