📚 네트워크 · 패킷 분석 › 04. 네트워크 장비 실습 — 182편
이전 글: 181. Firewall 정책 · 다음 글: 183. Outbound 정책
1. 개념
Inbound 정책은 신뢰 수준이 낮은 쪽(주로 인터넷)에서 높은 쪽(DMZ·내부망·호스트 자신)으로 들어오는 연결을 통제하는 정책입니다. 기본 원칙은 한 문장입니다. 공개하기로 결정한 서비스만 허용하고, 나머지는 모두 차단합니다.
먼저 "방향"이라는 단어가 두 가지 뜻으로 쓰인다는 점을 구분해야 합니다.
| 용어 | 기준 | 예 |
|---|---|---|
| 트래픽 방향 (Inbound/Outbound) | 연결을 시작한 쪽이 어디인가 | 외부 → 내부 웹 서버 접속 = Inbound |
| 인터페이스 방향 (in/out) | 패킷이 이 인터페이스를 들어오는가 나가는가 | Cisco ip access-group X in |
| 호스트 방화벽 방향 | 이 호스트로 들어오는가 | nftables input 체인, firewalld zone |
Inbound 연결에도 응답 패킷은 반대 방향(내부 → 외부)으로 나갑니다. 상태 기반 방화벽은 응답을 세션으로 자동 허용하므로(185. Stateful Firewall), 정책은 연결을 시작하는 방향만 기준으로 작성합니다.
2. 동작 원리
경계 장비에서 Inbound 패킷이 거치는 판단 순서의 예입니다.
인터넷에서 패킷 도착 (WAN 인터페이스 in)
↓
① 출발지 검증: 인터넷에서 올 수 없는 출발지인가? (사설·루프백·문서용·자기 대역)
├─ 예 → 차단 + 로그 (위조 출발지)
↓
② 기존 세션의 응답인가? ─ 예 → 통과
↓ 새 연결
③ 목적지 변환: 공개 서비스 공인 IP:포트 → DMZ 사설 IP:포트 (DNAT)
↓
④ Inbound 허용 규칙과 비교: 공개 서비스 목적지·포트와 일치?
├─ 예 → 세션 생성 + 로그 → DMZ 서버
└─ 아니오 → 기본 차단 + 로그①은 Ingress 필터링입니다. 인터넷에서 들어오는 패킷의 출발지가 다음과 같다면 위조로 봅니다.
| 차단할 Inbound 출발지 | 대역 | 근거 |
|---|---|---|
| 사설 주소 | 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 | RFC 1918 |
| 루프백·"이 네트워크" | 127.0.0.0/8, 0.0.0.0/8 | RFC 1122 등 |
| 링크 로컬 | 169.254.0.0/16 | RFC 3927 |
| 문서용 | 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 | RFC 5737 |
| 멀티캐스트 | 224.0.0.0/4 | 출발지로 쓰이지 않음 |
| 자기 조직의 공인 대역 | 할당 대역 | 외부에서 자기 주소로 올 수 없음 |
⚠️ 이 글의 예시는 실습 편의상 문서용 대역을 "외부"로 사용하므로, 실습망에서는 문서용 대역 차단 줄을 빼야 통신이 됩니다.
3. 주요 특징
- uRPF(Unicast Reverse Path Forwarding): 라우터가 "이 출발지로 가는 경로가 패킷이 들어온 인터페이스 쪽인가"를 확인해 위조 출발지를 자동으로 걸러 내는 기능입니다. Strict 모드는 비대칭 경로에서 정상 트래픽을 떨어뜨릴 수 있어 경계 구성에 맞게 선택합니다. Linux의
rp_filter도 같은 개념입니다(1 = strict, 2 = loose). - 서비스 공개는 목적지를 좁게: "DMZ 대역 전체 443"이 아니라 "리버스 프록시 한 대의 443"처럼 호스트 단위로 허용합니다.
- 관리 서비스는 Inbound 공개 대상이 아닙니다. SSH·RDP·장비 관리 페이지는 VPN을 거쳐 관리망에서만 접근하게 합니다.
- 호스트 방화벽도 Inbound 정책입니다. 네트워크 방화벽을 통과한 뒤에도 서버 자신의
input정책이 한 번 더 걸러 냅니다.
4. 예시
실습 예시 — GNS3 등의 Cisco IOS 계열 경계 라우터 WAN 인터페이스(Gi0/0)의 ingress 필터링과 uRPF입니다. 값은 예시(값은 환경마다 다름)입니다.
ip access-list extended WAN-IN
deny ip 10.0.0.0 0.255.255.255 any log
deny ip 172.16.0.0 0.15.255.255 any log
deny ip 192.168.0.0 0.0.255.255 any log
deny ip 127.0.0.0 0.255.255.255 any log
permit tcp any host 203.0.113.10 eq 443
permit tcp any any established
deny ip any any log
!
interface GigabitEthernet0/0
ip access-group WAN-IN in
ip verify unicast source reachable-via rx실습 예시 — 서버 호스트 방화벽의 Inbound 정책입니다. 값은 예시이며 관리망은 10.99.0.0/24로 가정합니다.
# Rocky (firewalld): 웹 공개 + 관리망에서만 SSH
sudo firewall-cmd --permanent --zone=public --add-service=https
sudo firewall-cmd --permanent --zone=public --remove-service=ssh
sudo firewall-cmd --permanent --zone=public \
--add-rich-rule='rule family="ipv4" source address="10.99.0.0/24" service name="ssh" accept'
sudo firewall-cmd --reload
sudo firewall-cmd --zone=public --list-all
# Ubuntu (ufw): 같은 의미
sudo ufw default deny incoming
sudo ufw allow 443/tcp
sudo ufw allow from 10.99.0.0/24 to any port 22 proto tcp
sudo ufw enable⚠️ 원격(SSH)으로 접속한 상태에서 SSH 허용을 제거하거나 ufw를 활성화하면 접속이 끊길 수 있으므로, 관리망 허용 규칙을 먼저 추가하고 콘솔 접근을 확보한 뒤 적용합니다.
nftables로 직접 구성한다면 input 체인에 policy drop을 두고 ct state established,related accept, iif "lo" accept, 허용 서비스 순으로 규칙을 둡니다(181. Firewall 정책의 구조와 같음).
📷 [실습 화면 삽입 위치]
firewall-cmd --zone=public --list-all결과에서 services에 ssh가 없고 rich rules에 관리망 출발지 SSH 허용이 보이는 화면
5. 보안 관점
- Inbound 정책의 품질은 공개 서비스 목록의 정확성에 달려 있습니다. 외부에 무엇이 열려 있는지 모르는 조직은 정책을 검증할 수 없습니다.
established같은 Stateless 응답 허용은 위조 ACK 패킷을 통과시키므로, 경계에서는 상태 기반 방화벽이 최종 판단을 맡습니다(178. ACL).- 서비스 공개 규칙은 한 번 열리면 공격 표면이 됩니다. 공개 서버의 취약점 관리와 로그 수집이 규칙 추가와 함께 이루어져야 합니다.
6. SOC 관점
| 흔적 | 의미 |
|---|---|
| WAN 인터페이스의 위조 출발지 차단 로그 | 스푸핑 트래픽, 반사 공격의 흔적 또는 설정 오류 |
| 공개 포트 외 Inbound 차단 로그 | 외부 스캔(양이 많음) |
| 공개 서비스 허용 로그 | 실제 연결 성립 여부, 이후 웹 로그와 대조 |
| 관리 포트 Inbound 허용 로그 | 정책상 없어야 하므로 즉시 확인 |
관제자가 확인할 질문
- 차단된 Inbound 시도 중 허용된 공개 서비스와 같은 출발지가 있는가(스캔 이후 공격 전환)?
- 관리 서비스(22·3389 등)에 외부 출발지 허용 로그가 있는가?
- 새로 생긴 Inbound 허용 규칙에 변경 승인 기록이 있는가?
오탐 주의: 인터넷에 노출된 모든 주소는 상시 스캔을 받으므로 Inbound 차단 로그 건수 자체는 위협 지표가 약합니다. 방화벽에서의 스캔 흔적 해석은 234. Firewall에서 Scan 흔적 찾기, Inbound 정책 로그 분석은 263. Inbound Policy에서 다룹니다.
7. 핵심 정리
- Inbound 정책은 연결을 시작하는 방향이 외부 → 내부인 트래픽을 통제하며, 공개 서비스만 허용하고 나머지는 차단합니다.
- 트래픽 방향(Inbound/Outbound)과 인터페이스 방향(in/out)은 다른 개념입니다.
- 경계에서는 사설·루프백·자기 대역 등 올 수 없는 출발지를 먼저 걸러 내고, uRPF·rp_filter로 보완합니다.
- 서비스 공개는 호스트·포트 단위로 좁게, 관리 서비스는 관리망에서만 허용합니다.
- 관제에서는 차단 건수보다 공개 서비스 허용 세션과 관리 포트 허용 로그가 더 중요합니다.
