📚 네트워크 · 패킷 분석 › 06. 방화벽 · IDS 기초 — 263편
이전 글: 262. Protocol 정책 · 다음 글: 264. Outbound Policy
1. 개념
Inbound Policy는 신뢰 수준이 낮은 쪽(외부)에서 시작되어 높은 쪽(내부·DMZ)으로 들어오는 연결을 통제하는 정책입니다. 인터페이스 in/out 방향과의 구분, 위조 출발지 필터링, 장비별 설정 문법은 04 영역 182. Inbound 정책에서 다뤘습니다.
이 글은 Inbound 정책을 "우리 조직이 외부에 무엇을 공개했는가"의 기록으로 보고, 관제에서 어떻게 해석하는지 다룹니다.
방향 판단의 기준은 패킷의 방향이 아니라 연결을 누가 시작했는가입니다.
| 상황 | 패킷 방향 | 연결 시작 | Inbound 정책 대상인가 |
|---|---|---|---|
| 외부 사용자가 DMZ 웹 서버 접속 | 외부 → 내부 | 외부 | 예 |
| 내부 PC가 외부 웹 접속 후 받는 응답 | 외부 → 내부 | 내부 | 아니오 (세션으로 처리) |
| 외부 스캐너의 SYN | 외부 → 내부 | 외부 | 예 (대부분 차단) |
| 내부 서버가 외부로 보내는 응답 | 내부 → 외부 | 외부 | 예 (허용된 세션의 일부) |
2. 동작 원리
일반적인 경계 방화벽의 Inbound 판단 흐름입니다.
외부 → 방화벽 외부 인터페이스 (새 연결 SYN)
↓
[위조·차단 목록 출발지?] → Drop
↓
[목적지가 공개 서비스인가? (공인 IP:포트 → DNAT)]
├─ 예 → [허용 규칙: 출발지 조건, 서비스 포트] → Allow → DMZ 서버
└─ 아니오 → 기본 차단(Default Deny) → 로그좋은 Inbound 정책은 다음과 같은 모양이 됩니다.
- 허용 규칙 수가 적고, 각 규칙이 공개 서비스 하나와 1:1로 대응합니다.
- 목적지는 내부망이 아니라 DMZ입니다(270. DMZ와 Firewall).
- 나머지는 모두 기본 차단입니다(267. Default Deny).
3. 주요 특징
Inbound 로그는 허용과 차단의 분석 가치가 크게 다릅니다.
| 로그 종류 | 양 | 분석 가치 | 주로 답하는 질문 |
|---|---|---|---|
| Inbound 차단 | 매우 많음 | 개별 가치 낮음, 추세·표적성 분석에 유용 | 누가 우리를 탐색하는가? |
| Inbound 허용 | 공개 서비스 수에 비례 | 높음 | 외부의 누가 실제로 서버와 통신했는가? |
| Inbound 허용 + 대용량 응답 | 적음 | 매우 높음 | 서버에서 무엇이 나갔는가? |
- 인터넷에 공개된 주소는 연결 직후부터 자동화된 스캔을 받습니다. 차단 로그의 존재 자체는 위협이 아닙니다.
- 진짜 질문은 허용된 연결에서 무슨 일이 있었는가입니다. 허용 로그는 IDS·WAF·서버 로그와 연결해야 의미가 생깁니다.
- 공개 서비스 목록(자산 목록)과 Inbound 허용 규칙 목록은 일치해야 합니다. 불일치는 정책 오류이거나 관리되지 않는 자산입니다.
4. 예시
공개 서비스 목록과 Inbound 허용 로그를 대조하는 형식 예시입니다(값은 환경마다 다름).
# 공개 서비스 목록 (형식 예시)
203.0.113.10:443 → 10.30.0.10:443 웹 서비스
203.0.113.11:25 → 10.30.0.25:25 메일 수신
# Inbound 허용 로그 요약 (형식 예시)
dst_translated dport 허용 건수 고유 출발지 수
10.30.0.10 443 182,440 9,812
10.30.0.25 25 3,120 611
10.30.0.40 22 37 2 ← 목록에 없는 공개분석 방법
- 세 번째 줄은 공개 서비스 목록에 없는 SSH 공개입니다. 어떤 규칙이 허용했는지 규칙 ID를 확인합니다.
- 고유 출발지 2개가 누구인지 확인합니다. 협력사 유지보수 IP라면 정책 등록 누락, 알 수 없는 IP라면 침해 가능성을 봅니다.
- 해당 서버(10.30.0.40)의 인증 로그에서 같은 시각 로그인 성공 기록을 확인합니다.
실습 환경에서는 방화벽 VM의 Inbound 허용 규칙에 로그를 켜고, 다른 VM에서 공개 포트와 비공개 포트에 각각 접속해 허용·차단 로그가 어떻게 다르게 남는지 비교해 볼 수 있습니다.
5. 보안 관점
- Inbound 허용 규칙 하나하나가 외부 공격 표면입니다. 규칙 수를 최소화하고 정기적으로 공개 필요성을 재검토합니다.
- 관리 서비스는 Inbound로 직접 공개하지 않고 VPN·배스천 호스트를 거치게 합니다.
- 공개 서버는 내부망이 아닌 DMZ에 두어, 침해되더라도 내부로 바로 이어지지 않게 합니다.
- 출발지를 제한할 수 있는 서비스(협력사 연동 등)는 출발지 조건을 반드시 겁니다.
6. SOC 관점
관제자가 확인할 질문
- 이 Inbound 허용은 공개 서비스 목록에 있는 서비스인가?
- 허용된 세션의 바이트 수가 요청 대비 비정상적으로 크지 않은가?
- 허용 직후 같은 서버에서 Outbound 연결(외부 다운로드, 역방향 셸 형태의 연결)이 새로 생기지 않았는가?
Inbound 허용 로그 (외부 → 10.30.0.10:443)
↓ 같은 시각 WAF·IDS 이벤트 확인
↓ 웹 서버 access log에서 응답 코드 확인
↓ 이후 10.30.0.10 → 외부 신규 Outbound 연결 확인 (Outbound 관점)
판단: 단순 접속 / 공격 시도 / 공격 성공 후 후속 행위오탐 주의: 검색 엔진 크롤러, 보안 평판 서비스, 가용성 모니터링 서비스도 Inbound 허용 로그를 대량으로 남깁니다. User-Agent·역방향 DNS 등으로 정상 자동화 트래픽을 구분합니다. 후속 Outbound 분석은 264. Outbound Policy에서 이어집니다.
7. 핵심 정리
- Inbound Policy는 외부에서 시작된 연결을 통제하며, 방향 기준은 패킷이 아니라 연결 시작 주체입니다.
- 좋은 Inbound 정책은 공개 서비스와 1:1로 대응하는 소수의 허용 규칙과 기본 차단으로 구성됩니다.
- Inbound 차단 로그는 양이 많지만 개별 가치가 낮고, 허용 로그가 실제 분석 대상입니다.
- 공개 서비스 목록과 허용 규칙·허용 로그를 대조하면 관리되지 않는 공개를 찾을 수 있습니다.
- Inbound 허용 이후 같은 서버의 Outbound 행위를 이어서 확인합니다.
